Классная статья! Мне в своё время такой не хватало. Добавлял в приложение для занятия кроссфитом чтение пульса во время тренировок, чтобы понимать, насколько эффективно прошла определённая тренировка. Даже опубликовал библиотеку на Github. Сейчас сам занимаюсь спортом, использую датчик Polar H7 через фирменное приложение. Он старенький, но своё дело делает.
Насколько вижу, что интерфейса ты использовал UIKit. А почему не SwiftUI? Нет ли в CoreBluetooth обёртки для Combine, чтобы было удобней работать с Bluetooth-девайсами?
Насчет таблиц — мы используем самочинную библиотеку TableViewTools, она отлично решает эту задачу. Если кратко — каждой ячейке соответствует определенный объект, который знает, как отрисовать ячейку, заполнить данными и отреагировать на actions. И почти вся логика работы с таблицей выносится из контроллера.
По 3 вопросу — а если фасад использует несколько адаптеров, как он понимает, к какому обращаться?, к какому обращаться?
По 8 вопросу — я увидел на слайдах кастомные протокол для секции таблицы. Используете ли вы какое-то стороннее или свое решение для таблиц, чтобы избежать огромных свичей и if-else конструкций и методах delegate/datasource таблицы?
У меня немного вопросов к докладу Сергея:
1. Почему не стали использовать VIPER? Из-за любви к MVVM и реактиву?
2. Могут ли переиспользоваться фасады? Или что вы делаете, если в нескольких фасадах есть общая логика? Или фасады не относятся к определенному модулю?
3. Как фасад определяет, к какому адаптеру обращаться? Он хранит какое-то состояние?
4. Тестируете ли вы инъекции?
5. Почему между VM и View связь через делегирование?
6. Какой объект в вашей архитектуре отвечает за навигацию?
7. Если UI одного экрана сложный, разбиваете ли вы его на сабмодули? Если да, то как?
8. Что вы используете для работы с таблицами?
9. Примеры в презентации были написаны на Objective-C. Используете ли вы эту архитектуру в Swift проекте? Если да, то как собираете модули?
В продолжение 2 — А как сравниваются веса story points у разных членов команды, например, у iOS Developer и у Backend Developer?
В продолжение 3 — То есть не было моментов, когда разработчик закончил story, а тестировщик не успел вернуть ни одного бага, но спринт еще не закончился?
4. А TDD практикуете? Насколько помогает?
1. Насколько полезны ежедневные короткие митинги, особенно если вся команда в одном офисе?
2. Как оцениваются задачи? В story points?
3. Бывает ли у разработчиков простой в конце спринта? Когда ты отдал тестировщику свои задачи, а взять из бэклога уже нечего.
Спасибо, поправил!
Классная статья! Мне в своё время такой не хватало. Добавлял в приложение для занятия кроссфитом чтение пульса во время тренировок, чтобы понимать, насколько эффективно прошла определённая тренировка. Даже опубликовал библиотеку на Github. Сейчас сам занимаюсь спортом, использую датчик Polar H7 через фирменное приложение. Он старенький, но своё дело делает.
Насколько вижу, что интерфейса ты использовал UIKit. А почему не SwiftUI? Нет ли в CoreBluetooth обёртки для Combine, чтобы было удобней работать с Bluetooth-девайсами?
Наша команда опубликовала свой набор lanes: https://github.com/rosberry/RSBFastlane. Из интересного — умеет добавлять UUID девайсов и таскать тикеты в JIRA в нужные колонки.
А еще я написал небольшую утилиту на Swift: https://github.com/artemnovichkov/fastfood, чтобы удобно добавлять fastlane в новый проект.
Можно локально, можно на CI
Вопрос по первому пункту — а почему используете nil coalescing, а не дефолтные параметры?
Насчет таблиц — мы используем самочинную библиотеку TableViewTools, она отлично решает эту задачу. Если кратко — каждой ячейке соответствует определенный объект, который знает, как отрисовать ячейку, заполнить данными и отреагировать на actions. И почти вся логика работы с таблицей выносится из контроллера.
1. Почему не стали использовать VIPER? Из-за любви к MVVM и реактиву?
2. Могут ли переиспользоваться фасады? Или что вы делаете, если в нескольких фасадах есть общая логика? Или фасады не относятся к определенному модулю?
3. Как фасад определяет, к какому адаптеру обращаться? Он хранит какое-то состояние?
4. Тестируете ли вы инъекции?
5. Почему между VM и View связь через делегирование?
6. Какой объект в вашей архитектуре отвечает за навигацию?
7. Если UI одного экрана сложный, разбиваете ли вы его на сабмодули? Если да, то как?
8. Что вы используете для работы с таблицами?
9. Примеры в презентации были написаны на Objective-C. Используете ли вы эту архитектуру в Swift проекте? Если да, то как собираете модули?
В продолжение 3 — То есть не было моментов, когда разработчик закончил story, а тестировщик не успел вернуть ни одного бага, но спринт еще не закончился?
4. А TDD практикуете? Насколько помогает?
2. Как оцениваются задачи? В story points?
3. Бывает ли у разработчиков простой в конце спринта? Когда ты отдал тестировщику свои задачи, а взять из бэклога уже нечего.