Инженерная зрелость

Инженерная зрелость — это показатель высокого уровня подготовки, глубины опыта и широты кругозора.

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

• Единообразие
• Системность
• Воспроизводимость

Давайте обсудим, какой смысл я вкладываю в каждый из них. Я приведу примеры из моей предметной области и буду рад вашим в комментариях.

Единообразие

Единообразие — это способность подбирать подходящее обобщённое решение для целых классов задач.

Пример

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

Вместо того чтобы писать каждый сервис с чистого листа, вы определяете:

• будете ли вы брать популярный фреймворк или напишите код, используя средства стандартной библиотеки;
• будет ли, и, если будет, то какой IoC-⁠контейнер подойдёт для вашего решения;
• каким образом будут обрабатываться запросы к сервису и другие решения, встающие перед командой.

Ответом на эти вопросы будет паттерн микросервисной архитектуры Service Template. Именно шаблон сервиса станет фундаментом, на котором будут построены ваши решения. А это означает, что:

• у всех членов команды будет одно и то же понимание кода;
• задачи по разным сервисам можно будет разделять между всеми членами команды, а не только между экспертами в отдельных вопросах предметной области;
• разработчикам не потребуется решать одни и те же вопросы по-⁠разному в разных сервисах; это снизит когнитивную нагрузку, время на ревью кода и “усталость от принятия решений” (“decision fatigue”).

Системность

Системность — это способность поддерживать единообразие при росте и развитии продукта.

Пример

Сервисы из предыдущего примера использовали для обработки REST-⁠запросов функционал стандартной библиотеки. Эндпоинтов было не много и поддерживать их было просто.

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

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

• вносите изменение в шаблон сервиса, фиксируя выбранное решение в коде;
• переводите все существующие эндпониты на это решение.

Теперь в ваших сервисах вопрос обработки запросов REST решен единообразно и системно.

Ещё пример

В части унаследованного кода обработка бизнес-⁠сценариев могла происходить непосредственно в контроллерах/хэндлерах. Было это сделано по незнанию, непринятию DDD или для экономии времени, мы сказать не можем.

Примером системности подхода здесь будет вынесение всех сценариев в отдельные сервисы и фиксация намерения описывать их только там.

Воспроизводимость

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

Пример

Оценив ваши успехи, руководство расширило вашу ответственность ещё на несколько проектов и усилило команду новыми разработчиками.

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

Чуть более приземленный пример

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

Такого же воспроизводимого и переносимого результата мне было важно добиться, когда речь шла о настройке локального DNS².

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

В конце хочу добавить две вещи.

Во-⁠первых, многие из вас спросят, а почему Service Template распространяется на одну команду одного направления? Я работал в разных компаниях и командах с разным уровнем инженерной зрелости. Где-⁠то шаблон или шаблоны на разных языках, используемых в компании, действительно распространяются на всех. В других местах этому не придают значения или же просто не обладают должным уровнем опыта и экспертизы.

Во-⁠вторых, за эти три термина, к выводу и формулировке которых я пришёл самостоятельно, я хочу поблагодарить Н.В. Максимова, читавшего курс по информационным технологиям на третьем (или втором?) курсе. Это, вероятно, единственный преподаватель, который значительно и позитивно повлиял на становление моего собственного инженерного образа мыслей.

Паттерн Service Template я обещаю разобрать в отдельной заметке и постараюсь с ней не затягивать.