Flutter — Создание идеального проекта Boilerplate с нуля. Часть 2: болевая точка

Предоставлено: Нгуен Тхань Минь (разработчик Android)

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

1. Пять болевых точек в прошлом

1.1. Сложные решения лидера

Источник: Unsplash

Боль каждого лидера или архитектора связана с необходимостью принимать решения.

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

1.2. Во время обслуживания проекта исправление 1 ошибки создаст 10 новых ошибок.

Источник: Unsplash

Это не редкость для разработчиков, когда им приходится рефакторить или исправлять ошибки в проекте с «чрезвычайно липкой архитектурой». Классы и функции настолько тесно связаны друг с другом, что достаточно исправить одну маленькую функцию, чтобы взорвать весь проект. В некоторых сценариях после исправления 1 ошибки тестировщик найдет еще 10 ошибок, поэтому на исправление 1 ошибки могут уйти месяцы. Это делает стоимость обслуживания проекта очень высокой, поэтому нам нужна архитектура, которая помогает максимально разделить зависимости. Так что каждый раз, когда мы редактируем класс или функцию, вся система не будет затронута, и вам не придется исправлять код вручную.

1.3. Болевые точки разработчика FE могут исходить от разработчика BE

Разработчик FE, чей код класса Model основан на ответе API, определенном разработчиком BE, будет иметь 4 риска:

1. Если BE плохо спроектирован, это также повлияет на FE, код очень сложно сопоставить с пользовательским интерфейсом, для сопоставления с пользовательским интерфейсом требуется много вычислений. Как и на картинке выше, Json Response находится справа, в модели Booking есть модель Room; а в модели Room есть модель Booking, которая просто повторяется без конца.
2. FE придется адаптировать к BE, но классы Model импортируются во многие классы, такие как UI и Bloc. Его исправление приведет к массовому изменению классов, которые от него зависят.
3. Два BE-разработчика в команде могут иметь два разных стиля кодирования, поэтому они могут возвращать очень разные UserDataответы в зависимости от API. Например, в fetchUsersAPI возвращают ageполе типа int?, а в fetchUserDetailAPI — типа String?. Что, если я объявлю поле age типа int?? Мое приложение будет аварийно завершено при вызове fetchUserDetailAPI. Таким образом, мы должны объявить ageполе типа dynamic, даже если этот тип считается небезопасным, поскольку он может легко привести к ошибкам во время выполнения. Этот случай очень распространен при работе фрилансером, когда члены команды BE ранее не работали друг с другом, а руководителей нет и никто не ревьюирует код.
4. В целях безопасности все поля в классах модели данных всегда должны быть типами, допускающими значение NULL, такими как int?, String?. Однако это может привести к сбою нашего приложения из-за NullPointerException.

1.4. Сделайте мобильное приложение и ТВ-приложение в одном репозитории

Ранее я участвовал в проекте по разработке как мобильных приложений, так и телевизионных приложений, таких как Youtube. В то время мне нужно было создать 2 модуля приложения: mobile_app, и tv_app. Здесь стоит упомянуть, что эти два модуля используют один и тот же API запросов, например fetchVideos, fetchVideoDetail. Таким образом, чтобы повторно использовать код запроса API для обоих модулей, нам нужно спроектировать архитектуру так, чтобы часть API была отделена от другого модуля для внедрения в эти два модуля приложения.

1.5. История черепахи и зайца и классическое заблуждение разработчиков

Глядя на две статистические диаграммы выше. Разработчики могут считать это нормальным, поскольку мы часто сталкивались с этим. Но для менеджеров они, безусловно, будут обеспокоены. Они хотят тратить больше денег, чтобы получать более высокий доход и более высокую производительность после каждого выпуска, но жизнь не идеальна. На самом деле проектам нужно всего 20% от общей стоимости, чтобы создать 80% основных функций программного обеспечения. Однако в следующих релизах добавление нескольких функций понемногу может дорого стоить, а в некоторых случаях может даже вызвать инциденты с крайне серьезными последствиями. Архитектура, безусловно, сыграла большую роль в возникновении этой проблемы.

Давайте вспомним урок про Зайца и Черепаху, который мы выучили в детстве. Мы можем провести для себя три урока:

• Тише едешь - дальше будешь
• Победа не зависит от того, насколько вы сильны или быстры
• Чем больше спешки, тем меньше скорость

Распространенное заблуждение разработчиков: «Приближается крайний срок проекта, кодируйте что хотите, а потом рефакторинг». Подобные размышления приведут к двум основным проблемам:

1. Нет времени на рефакторинг. Лично я также видел, а также был свидетелем того, как многие другие разработчики тратили свое свободное время по выходным на рефакторинг новых функций, выпущенных в последнем спринте. Это нездоровая рабочая привычка.
2. Нет никакой гарантии, что рефакторинг сработает и не создаст новых ошибок.

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