Эти правила помогают мне быстрее писать корпоративное программное обеспечение.

Этот документ находится в стадии разработки. Определенная версия будет, когда я перестану учиться.

Правило: Производственные приложения всегда нуждаются в многоуровневой архитектуре.

Причина: Многоуровневая архитектура — это проверенная в боевых условиях архитектура, которая существует уже несколько десятилетий. Архитектура хороша тем, что позволяет отделить логику предметной области, логику приложения, пользовательский интерфейс и инфраструктуру друг от друга. В многоуровневой архитектуре код отделен друг от друга с помощью инверсии зависимостей, код в каждом слое легко тестируется. Примеры хорошо спроектированных многоуровневых архитектур: луковая архитектура, порты и адаптеры, CQRS…

Правило: Никогда не создавайте то, что вам не нужно прямо сейчас.

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

«Что, если эта функция не будет реализована в ближайшее время? Ответ: мы банкротимся».

Хотя это кажется абсурдом. Это так. Если вы слишком медленно внедряете новые функции, конкуренты выставят вас из бизнеса.

Правило: сначала решить счастливый путь

Причина: при реализации нового варианта использования делайте его максимально простым. Сначала решите для одного очень конкретного случая. Не рассматривайте крайние случаи. Не учитывайте полиморфизм, масштабируемость, производительность или что-то еще. Ваша единственная задача - реализовать счастливый путь.

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

Правило: используйте разработку через тестирование

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

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

Правило: используйте фреймворки на уровне инфраструктуры

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

Правило: заботьтесь об изменениях, когда они необходимы

Причина: Хороший код — это код, который легко изменить. Однако не переусердствуйте. Когда вы уже используете многоуровневую архитектуру, вы, вероятно, применяете принципы SOLID, не зная об этом. Применение принципов SOLID уже упрощает изменение кода. Многоуровневая архитектура делает за вас большую часть тяжелой работы. Не переусердствуйте!

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

Правило: сделайте свой код легко читаемым

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

Правило: если прикоснешься, сделай лучше

Причина: если вам трудно понять фрагмент кода, вам придется приложить много усилий, чтобы понять его. Когда вы это сделаете, не забудьте реорганизовать код, чтобы его было легко понять. Таким образом, в следующий раз, когда разработчику потребуется изменить его, ему потребуется меньше времени для изменения кода. Часто такой рефакторинг можно сделать за считанные минуты. Повторное понимание часто занимает намного больше времени. Кроме того, это заставляет разработчика беспокоиться о внесении изменений в существующий код. Они могут в конечном итоге структурировать сложный код, написав адаптеры. Иногда это хорошая идея, даже если код легко читается. Но трудности с пониманием кода никогда не должны быть причиной для этого.

Правило: будьте последовательны

Причина: согласованность является ключом к пониманию кодовой базы. Это ускоряет поиск кода и упрощает его понимание.

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

Кроме того, не используйте синонимы.

Правило: используйте ограниченные контексты для структурирования кода

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

Поищите в Интернете слова: «вездесущий язык». Я очень рекомендую книгу Эрика Эванса «Domain Driven Design».

Правило: используйте имена, которые соответствуют словам, используемым в бизнесе.

Причина: говоря о фичах с бизнесом, все (разработчики и люди, работающие в бизнесе) должны знать, что под чем подразумевается. Если вы столкнулись со смешением языков в разговоре, то спросите: «Что вы имеете в виду под ….?». Лучше задавать этот вопрос слишком часто, чем слишком редко.

Иногда слова в бизнесе и слова в ИТ звучат одинаково. Например: «стручок» и «бот». Если вы сталкиваетесь со словами, которые звучат похоже, и вам часто приходится использовать эти слова в разговоре, это помогает также обогатить словарный запас бизнеса и ввести новое слово (слова), чтобы заменить одно (или оба) слова. В идеале это новое слово должно быть в кодовой базе и в бизнесе. Где последнее может быть трудно реализовать.

Этот документ находится в стадии разработки. Упомянутые правила основаны на более чем 15-летнем опыте, но я стараюсь узнавать больше и становиться лучше с каждым днем! Вам не хватает правила, которое помогло вам писать лучшее программное обеспечение? Поделитесь своими знаниями и оставьте комментарий.