Как писать код понятно и удобно для дальнейшей работы. Часть 1

Узнайте, какую задачу вы решаете

Начиная работать над новой задачей, выясните, какой итоговой цели нужно достичь, для чего вы пишете код. Кажется, что всё понятно: нужно взять данные из источника, слегка преобразовать и положить в место назначения. Но это способ решения задачи, а не цель. Реальная цель может быть такой: показать пользователю точное расстояние до ближайшей пиццерии. Или отправить человеку уведомления о появившемся в магазине товаре.

Зная цель, для которой пишется код, вы будете понимать, что требуется не просто переложить JSON, а сделать так, чтобы всё работало без ошибок и больших затрат на сопровождение.

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

Определитесь с терминологией в задаче

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

Названия объектов и методов расползаются по системе, прорастают в API. Если при изначальном наименовании допустили опечатку или выбрали неподходящее слово, хочется изменить название. Но из-за частого использования и связей с другими системами сделать это проблематично: нужно дублировать методы и объекты для постепенного перехода со старых названий на новые или переименовывать везде одномоментно.

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

Используйте ранее принятые в проекте названия объектов. Например, вы уверены, что называть покупателя в коде лучше customer, но в проекте повсеместно используют client. Стоит подчиниться или договориться с командой об исключении: например, отделить ваш код в обособленное приложение.

Узнайте свои возможности

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

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

Договоритесь об интеграциях

Очень часто разработчик занимается задачей не в одиночку, у него есть коллеги, которые параллельно делают свою часть, например фронтенд. Стоит заранее договориться о способах интеграции. Определите http-методы, их входные и выходные структуры данных, коды ответов. Но имейте в виду, что эти договорённости в процессе разработки могут поменяться.

Отложите принятие решений, не касающихся бизнес-логики

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

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

Определите сущности доменной модели

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

Валидация значений в большинстве случаев производится внутри доменной модели. Исключения — случаи, обусловленные требованиями производительности.

У вас уже есть понимание ожидаемого результата, автоматизируемого бизнес-процесса и объектов, задействованных в нём. Эти объекты и будут составлять основу доменной модели. Запишите их в отдельный список.