Контекст наглядности действительно носит ключевую роль. Чем быстрее человек может разобраться в исходном коде приложения — тем легче данный продукт поддерживать.
Мы придерживаемся принципа «один человек — одна пользовательская история».
Таким образом проблемы слияния при использовании VCS не возникает вообще. Теоретически, проектная команда может быть любого соответствующего размера.
Правда, я бы посоветовал ограничиться двумя-тремя разработчиками. Как показывает практика, это даёт наиболее эффективную отдачу на проектах приложений под мобильные платформы, и не приводит к тому, что люди «сталкиваются лбами».
Один — занимается логикой бизнес-уровня, второй — строит UI.
Бизнес-уровень выстраивается довольно быстро, поэтому со временем первый разработчик попросту переключится на оставшийся UI-функционал.
Больше людей подключать нет смысла: проекты слишком мелкие для задействования больших команд.
Как уже было сказано в статье, для динамического объединения storyboard'ов можно использовать сторонние библиотеки.
Тем не менее, storyboard — это всё же не панацея, и, скажем, некоторые виды ячеек — используемые в разных user story — мы держим в отдельных XIB'ах для последующего переиспользования.
И да, за последний год у нас не было ни единого конфликта с вовлечением storyboard'ов (-:
Вероятно, нужно просто аккуратно раздавать задачи в команде.
У меня были мысли следующего характера.
По сути, в приложениях под iOS существует всего три типа переходов: посредством навигационного контроллера, модальный и «custom».
Каждый подобный переход при наличии продуманного дизайна будет обусловлен структурой модели, используемой в приложении.
Список элементов => Детальное представление элемента — явно будет использовать «push».
Детальное представление элемента => контекстное действие над элементом («отослать по почте») — тут явно будет использовано модальное представление.
Таким образом, исходя из модели данных (читай: из той же структуры API) можно было бы вывести некую абстракцию для роутера, которую затем можно было бы расширять и переиспользовать.
На самом деле, изначально у меня была задумка написать обобщённую статью, касающуюся проектирования приложений не только под iOS, но и под Android.
Ведь в действительности большая часть подходов к архитектурному дизайну приложений от платформы не зависит, и все принципы уже давным-давно придумали и проработали.
Поддержка входа по Touch ID — это то, чем озадачились сейчас очень многие, и данный функционал так или иначе уже реализован либо включен в список «хотелок» практически на всех текущих проектах.
На устройствах iPhone 6 (4,7") и iPhone 6 Plus (5,5") Apple придумали функцию Reachability: по двойному прикосновению к кнопке «Домой» экран «едет» вниз, позволяя дотянуться до верхних границ приложения.
Слайдер исключает случайные нажатия на кнопку «Оплатить».
Плюс, отправить деньги, просто проведя по экрану — это формирует определённого рода пользовательский опыт.
Ощущение, как от звука щелчка при отключении экрана на iOS-устройствах.
Щёлк! — экран погас.
Кроме того, на ранних этапах разработки была идея убрать из процедуры оплаты всплывающее уведомление-alert для подтверждения платежа.
Потом от этой идеи отказались, но в случае её внедрения кнопкой «оплатить» точно нельзя было бы ограничиться из-за тех же случайных нажатий.
Проверки средствами HP Fortify отслеживают то, как и куда передаются данные согласно алгоритмам приложения.
В частности, просто хранение пароля на устройстве дало бы критическую уязвимость, а их в мобильном клиенте нет.
Контекст наглядности действительно носит ключевую роль. Чем быстрее человек может разобраться в исходном коде приложения — тем легче данный продукт поддерживать.
Мы придерживаемся принципа «один человек — одна пользовательская история».
Таким образом проблемы слияния при использовании VCS не возникает вообще. Теоретически, проектная команда может быть любого соответствующего размера.
Правда, я бы посоветовал ограничиться двумя-тремя разработчиками. Как показывает практика, это даёт наиболее эффективную отдачу на проектах приложений под мобильные платформы, и не приводит к тому, что люди «сталкиваются лбами».
Один — занимается логикой бизнес-уровня, второй — строит UI.
Бизнес-уровень выстраивается довольно быстро, поэтому со временем первый разработчик попросту переключится на оставшийся UI-функционал.
Больше людей подключать нет смысла: проекты слишком мелкие для задействования больших команд.
Как уже было сказано в статье, для динамического объединения storyboard'ов можно использовать сторонние библиотеки.
Тем не менее, storyboard — это всё же не панацея, и, скажем, некоторые виды ячеек — используемые в разных user story — мы держим в отдельных XIB'ах для последующего переиспользования.
И да, за последний год у нас не было ни единого конфликта с вовлечением storyboard'ов (-:
Вероятно, нужно просто аккуратно раздавать задачи в команде.
По сути, в приложениях под iOS существует всего три типа переходов: посредством навигационного контроллера, модальный и «custom».
Каждый подобный переход при наличии продуманного дизайна будет обусловлен структурой модели, используемой в приложении.
Список элементов => Детальное представление элемента — явно будет использовать «push».
Детальное представление элемента => контекстное действие над элементом («отослать по почте») — тут явно будет использовано модальное представление.
Таким образом, исходя из модели данных (читай: из той же структуры API) можно было бы вывести некую абстракцию для роутера, которую затем можно было бы расширять и переиспользовать.
Вам не приходило ничего подобного в голову?
Ведь в действительности большая часть подходов к архитектурному дизайну приложений от платформы не зависит, и все принципы уже давным-давно придумали и проработали.
Плюс, отправить деньги, просто проведя по экрану — это формирует определённого рода пользовательский опыт.
Ощущение, как от звука щелчка при отключении экрана на iOS-устройствах.
Щёлк! — экран погас.
Кроме того, на ранних этапах разработки была идея убрать из процедуры оплаты всплывающее уведомление-alert для подтверждения платежа.
Потом от этой идеи отказались, но в случае её внедрения кнопкой «оплатить» точно нельзя было бы ограничиться из-за тех же случайных нажатий.
В частности, просто хранение пароля на устройстве дало бы критическую уязвимость, а их в мобильном клиенте нет.