Загрузка...

Пост

Ошибки которые не стоит совершать при разработке архитектуры приложения

В данной статье я хочу собрать наиболее частые проблемы, которые могут возникать при разработке достаточно крупных мобильных приложений, над которыми могу работать одновременно несколько команд (2-4 команды по 4-6 человек).

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

Организационные проблемы

Не откладывать ревью и исправления плохого кода на потом. В заказной разработке очень часто возникает соблазн пропустить ревью некоторых плохо пахнущих участков кода или вообще целый модуль, аргументируя это тем, что он же вроде как работает и трогать мы его больше не собираемся. Запомните: Независимо от размера проекта, плохой код - это бомба замедленного действия. Она рванет именно в тот момент, когда вы этого не будете ожидать. Если у вас возникает желание пропустить на ревью некоторые оплошности - не стоит этого делать. Это обойдется дорого и для компании и для вас. Чаще всего возможно проблемы:

  • Ушел разработчик который писал это модуль и теперь команде нужно очень много времени чтобы разобраться с тем, что происходит в этом модуле и как это работает
  • Тестирование может выявить такие баги, правка которых будет занимать много времени
  • Тестирование может выявить такие баги, правка которых будет приводить к появлению новых багов
  • Доработка такого модуля может быть невозможна, только полное переписывание

Покрывать тестами хотя бы самый критичный функционал. Лучшие требования для когда (помимо хорошей аналитики) - это грамотно составленные тесты. Не поленитесь для самого критичного и сложного функционала сначала написать тесты, которые будут охватывать все требования, а потом уже реализовывать код. Это позволит решить проблему поломки функционала при правке багов. Особенно это будет актуально через 2-3 месяца, когда возникнет необходимость внести правку в критичный модуль. В этом случае, у вас будут тесты, которые не позволят поломать логику, про которую, вы, вероятно, забыли.


Установите чтекий регламент общения с командами. При работе большого числа человек на проекте все неформальные соглашения и договоренности стоит свести на нет. Сформируйте четкий реглмент взаимодействия команд. Этот регламент должен содержать требования по формату общения, продолжительность общения, ответсвенные стороны при общении, сроки принятия решений, сценарии взаимодействия и зоны ответсвенныости. Помимо этого, дожен быть ежиный инструмент, в котором будут фиксироваться все договоренности и протоколы общений. Это позволит избежать проблем, когда разработчики договорились в личных сообщениях или еще где-либо, но не поставили в известность остальных участников проекта. Так же, такой подход к коммуникации позволит избежать потери результатов договоренностей (потерлась история, невозможно найти историю, договорились на словах и т.д.).


Технические проблемы

Возвращать результат работы сети в main-thread. Не всегда можно понять почему возврат в main thread является проблемой. На самом деле все просто - в большом проекте может быть большое число параллельных запросов. Очень часто, результат работы сети проходит дополнительную обработку в виде маппинга, кэширования, вычисления и т.д. Так как число команд большое, и не всегда присутствует возможность контролировать все команды, лучшим, на мой взгляд, является возврат результата не в главном потоке, где разработчик может выполнить свои сложные операции, вычисления маппинги и так далее, а уже при отображении необходимых данных перейти на главный поток. Стоит заранее обговорить этот момент с командами и явно указать в документации к методам сети информацию о том, что данные возвращается не в основном потоке. Это не должно быть большой проблемой для разработчиков, просто является хорошим тоном.


Пишите максимально гибко. Если вы понимаете, что тот код, который вы пишите будет может быть использован другими командами или в других частях проекта - делайте его максимально простым и гибким. Это позволи использовать ваши наработки без каких-либо правок и внесения изменений. Организуйте себе модуль который будет ядром приложения (это может быть отдельная группа в проекте или отдельный проект), в который вы будете складывать переиспользуемые классы и на работки. Обязательно пишите к таким файлам комментарии, чтобы всем участникам работы было понятно зачем этот файл и как он работает.


Изолируйте код максимально. Все, что не может быть переиспользовано - должно быть скрыто. Не ленитесь помечать методы, свойства, классы как private или fileprivate. Это позволит скрыть функционал, который написан для конкретного модуля или для конкретной логики. Да и компилятор вам за это скажет спасибо. Помимо этого, при генерации документации, такие вещи не будут всплывать как незадокументированные.


Ошибки проектирования

Продумывайте имена методов и классов. Очень внимательно подойдите к неймингу. Заведите какой-либо глоссарий терминов и выражений и используйте единую терминологию между командами.Хороший нейминг позволит избежать серьезных проблемы, когда 2 разные вещи в разных командах называются одинаково.


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



Размещено 3 января 2019 в iOS Development


Поделиться: