Список в хронологическом порядке вы можете легко скопировать.

Основываясь на своем опыте разработки и эксплуатации приложений, я расскажу, что вы можете сделать с самого начала разработки приложения до выпуска, что будет полезно в будущем.

Я предположил, что вы прикладной инженер с небольшим опытом работы с сервисами (я думаю, что контент вызывает сильное чувство дежа вю для тех, у кого есть опыт). Выбор — это догма и предубеждение. Если вы делаете что-то еще, я был бы признателен, если бы вы могли прокомментировать, если есть что-то, что вы считаете полезным.

1. Узнайте цель проекта.

Во-первых, спросите планировщика, чего он хочет достичь с помощью приложения и какие проблемы он хочет решить.

  • Какие неудобства пользователи будут испытывать без этого приложения?
  • Какие приложения есть у ваших конкурентов?
  • Какова ваша ситуация объективно, например SWOT?

Это позволяет определить, что следует делать/чего не следует делать, а на что следует делать акцент/чего не следует вводить при создании функций и пользовательского интерфейса.

2. Наведите порядок в своем коде «Дизайн»

Выберите свой шаблон проектирования из MVC, MVP, MVVM, чистой архитектуры, VIPER и других. Решение о том, как структурировать код, что и где размещать и какие классы поведения и ответственности могут (или не должны) навести порядок в коде и сделать его более модифицируемым.

Посылка заключается в том, что в дизайне не существует абсолютного решения. Я рассмотрю то, что является наиболее подходящим с разных точек зрения, таких как требуемая скорость роста бизнеса, возможность изменений в бизнесе, количество и квалификация вовлеченных участников разработки, а также техническая мотивация.

После того, как вы приняли решение, задокументируйте свой мыслительный процесс. В iOS MVC и MVVM кажутся наиболее популярными.

3. Наведите порядок в своем коде «Соглашения о кодировании».

Нагрузку на понимание можно уменьшить за счет унификации стиля написания кода в команде. Существуют соглашения по кодированию, такие как Google. Также эффективно полагаться на такие инструменты, как SwiftLint, который сообщает вам о коде, нарушающем правила, и SwiftFormat, который автоматически исправляет код.

4. Создайте глоссарий вместе со своей командой

Давайте создадим глоссарий, чтобы все, кто занимается планированием, разработкой, проектированием и эксплуатацией, могли использовать точные слова для обозначения одних и тех же вещей. Если все будут называть друг друга, непонимание уменьшится. DDD также называет его вездесущим языком.

Кроме того, благодаря унификации выражений разработчикам интерфейсов, серверных частей и приложений будет легче понимать код друг друга. Как ни странно, код отражает организационную структуру и регулярное общение.

Например, когда команды организованы по компонентам, таким как приложения и серверы, работа имеет тенденцию быть автономной, и каждая команда развивается независимо, называя одну и ту же концепцию отдельно. У меня есть. Общение имеет большое значение в развитии.

5. Внедрите непрерывную интеграцию (CI)

CI — это механизм, который автоматически создает и тестирует с отправкой в ​​репозиторий и созданием PR в качестве триггеров. Внедрение приведет к более быстрому обнаружению ошибок из-за изменений кода. Bitrise занимает лидирующие позиции в области разработки приложений.

6. Введем механизм тестового распространения приложения.

Придет время, когда вы захотите, чтобы вовлеченные люди проверили разрабатываемое вами приложение. Я сделал функцию и хотел бы, чтобы PO/PdM проверил ее. Пожалуйста, свяжитесь с отделом контроля качества. Я хочу получить обратную связь от людей за пределами компании.

В таком случае подключение смартфона к машине для разработки и сборка для нескольких человек — тяжелая работа. Создание механизма распространения, такого как Firebase App Distribution или загрузка с Bitrise, может избавить вас от этих хлопот.

7. Откройте меню разработчика

Было бы удобно создать меню разработчика, отображаемое только во время разработки, что упрощает переключение статуса выставления счетов, пунктов назначения подключения API и пакетного изменения данных БД из графического интерфейса.

8. Создайте механизм принудительных обновлений и обслуживания

Приложения, в отличие от Интернета, принадлежат пользователю. Когда я работаю с ним, я замечаю, что определенное количество пользователей не обновляет версию приложения. В связи с развитием службы наступит время, когда такие пользователи захотят принудительно устанавливать обновления.

Давайте введем механизм принудительного обновления и направим целевых пользователей в App Store/Google Play. Кроме того, создайте механизм для уведомления об обслуживании сервера и т. д. (или механизм для блокировки использования в некоторых случаях). Если вы этого не сделаете, вас завалят вопросами: «Отображается ошибка. Вы не можете использовать его».

9. Внедрите инструменты аналитики

Для роста сервиса необходимо иметь дело с журналом поведения пользователя.
Давным-давно приложение работало около двух лет без внедрения инструмента анализа.

Внедрение инструментов анализа выявило полную противоположность тому, что сказал PO: «Я могу понять движения пользователей!» Пользователи безжалостно обходят поток действий, который мы ожидаем, и функцию толчка великого человека.

С другой стороны, они могут быть рады предложить свои решения. Это момент, который делает меня счастливым с управлением услугами. Что касается инструментов, в наши дни популярна Firebase Google Analytics. Анализ будет более доступным, если дизайн журнала будет одинаковым для Web, Android и iOS. Здесь также важно общение.

10. Внедрите инструмент для создания отчетов о сбоях.

Даже если вас завалят отзывами вроде «Не заводится, это 1 звезда», вам ничего не остается, как отчаиваться, если подсказок нет. Внедрение инструмента отчетов о сбоях значительно облегчит расследование причины.

Установив User ID, становится возможным понять, кто вызвал сбой, при каких условиях устройства, конкретно в какой строке в каком файле и какая ошибка вызвала сбой. Его также можно использовать в качестве монитора ошибок сразу после выпуска. Firebase Crashlytics пользуется популярностью.

Выше с сайта разработки приложений. Если ты сделаешь что-то еще, я пойму. Я просто хотел поделиться тем, что, по моему мнению, будет полезно другим.

Дополнительные материалы на PlainEnglish.io.

Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .