Инженерная зрелость
Инженерная зрелось — это показатель высокого уровня подготовки, глубины опыта и широты кругозора.
Мои коллеги, работавшие и работающие со мной, знают, что для характеристики уровня инженерной зрелости я использую три термина:
- Единообразие
- Системность
- Воспроизводимость
Давайте обсудим, какой смысл я вкладываю в каждый из них. Я приведу примеры из моей предметной области и буду рад вашим в комментариях.
Единообразие
Единообразие — это способность подбирать подходящее обобщённое решение для целых классов задач.
Пример
Вы разрабатываете несколько (микро)сервисов усилиями одной команды разработчиков. Эти сервисы связаны между собой, и разработчики хорошо ориентируются в предметной области, поэтому возложить ответственность на одну команду вполне уместно.
Вместо того чтобы писать каждый сервис с чистого листа, вы определяете:
- будете ли вы брать популярный фреймворк или напишите код, используя средства стандартной библиотеки;
- будет ли, и, если будет, то какой
IoC-контейнер подойдёт для вашего решения; - каким образом будут обрабатываться запросы к сервису и другие решения, встающие перед командой.
Ответом на эти вопросы будет паттерн микросервисной архитектуры Service Template. Именно шаблон сервиса станет
фундаментом, на котором будут построены ваши решения. А это означает, что:
- у всех членов команды будет одно и то же понимание кода;
- задачи по разным сервисам можно будет разделять между всеми членами команды, а не только между экспертами в отдельных вопросах предметной области;
- разработчикам не потребуется решать одни и те же вопросы по-разному в разных сервисах; это снизит когнитивную нагрузку, время на ревью кода и “усталость от принятия решений” (“decision fatigue”).
Системность
Системность — это способность поддерживать единообразие при росте и развитии продукта.
Пример
Сервисы из предыдущего примера использовали для обработки REST-запросов функционал стандартной библиотеки. Эндпоинтов
было не много и поддерживать их было просто.
По мере роста и развития проекта вы поняли, что более оптимальным решением будет использовать библиотеку,
специализирующуюся на работе с REST.
Вместо того чтобы оставить старые эндпоинты “как есть”, а для новых использовать выбранную библиотеку, вы:
- вносите изменение в шаблон сервиса, фиксируя выбранное решение в коде;
- переводите все существующие эндпониты на это решение.
Теперь в ваших сервисах вопрос обработки запросов REST решен единообразно и системно.
Ещё пример
В части унаследованного кода обработка бизнес-сценариев могла происходить непосредственно в контроллерах/хэндлерах. Было
это сделано по незнанию, непринятию DDD или для экономии времени, мы сказать не можем.
Примером системности подхода здесь будет вынесение всех сценариев в отдельные сервисы и фиксация намерения описывать их только там.
Воспроизводимость
Воспроизводимость — это способность переносить принятые решения из продукта в продукт, повторяя ожидаемый результат в предсказуемые сроки.
Пример
Оценив ваши успехи, руководство расширило вашу ответственность ещё на несколько проектов и усилило команду новыми разработчиками.
Имея предыдущий опыт, вы используете ваши проверенные временем наработки для создания новых сервисов, передавая опыт новым членам команды, расширяя и укрепляя общую экспертизу.
Чуть более приземленный пример
В моих предыдущих заметках вы могли заметить, что я придаю большое значение простоте переноса опыта коллегам. Например,
говоря о настройке локального https1, мне было важно, чтобы тот же набор действий мог быть легко
автоматизирован и
перенесен на рабочие машины моих коллег, таким образом, чтобы результат был одинаков (воспроизводим) у всех.
Такого же воспроизводимого и переносимого результата мне было важно добиться, когда речь шла о настройке
локального DNS2.
Будет не лишним напомнить, что решая проблему переносимости я описал свой подход к контейнеризации используемых инструментов в отдельной заметке3.
В конце хочу добавить две вещи.
Во-первых, многие из вас спросят, а почему Service Template распространяется на одну команду одного направления? Я
работал в разных компаниях и командах с разным уровнем инженерной зрелости. Где-то шаблон или шаблоны на разных языках,
используемых в компании, действительно распространяются на всех. В других местах этому не придают значения или же просто
не обладают должным уровнем опыта и экспертизы.
Во-вторых, за эти три термина, к выводу и формулировке которых я пришёл самостоятельно, я хочу поблагодарить Н.В. Максимова, читавшего курс по информационным технологиям на третьем (или втором?) курсе. Это, вероятно, единственный преподаватель, который значительно и позитивно повлиял на становление моего собственного инженерного образа мыслей.
Паттерн Service Template я обещаю разобрать в отдельной заметке и постараюсь с ней не затягивать.