#arch Про арх. надзор Одной из основных моих обязанностей в бы | I hate overtime

#arch
Про арх. надзор
Одной из основных моих обязанностей в бытность сис. архом было осуществление арх. надзора. Это означает то, что помимо проработки решения и реализации PoC надо было еще и, каким-то образом, гарантировать, что реализация концептуально не отличается от задумки.
Проблема в том, что "вас много а я одна". Читать внимательно весь код времени нет, свои задачи ждать не будут, да и глаз со временем замыливается, а джуны тем временем не дремлют и в результате все эти ваши воздушные замки на бумажке начинают очень слабо походить на то, что попадает на продуктив.
Серебряной пули тут, к большому сожалению, нет. Но есть несколько способов все-таки снизить вероятность деградации наших любимых НФТ из-за шаловливых ручек.
Первый из них это уже упомянутые фитнесс функции. В результате достаточно плотного покрытия ими, можно получить достаточно неплохую "приемку". К сожалению, не все НФТ можно дешево "зафитить"(как насчет расширяемости и maintainability, например). Тут в дело врываются гексагональная(ну или чистая) архитектура и DDD. При правильной мотивации и сноровке эти 2 инструмента дадут не только достаточно аккуратный код, но и даже уменьшат time to market. Но тут на первый план выходит вопрос мотивации. DDD и clean architecture очень хрупкие и сильно подвержены закону разбитых окон, поэтому вся тима без исключения должна быть единодушна в их использовании. Ведь стоит кому-то одному по незнанию или из-за давящих сроков "наговнякать" и скоро все ваши усилия и человекочасы потраченные на ивент сторминги и проработку модели пойдут прахом. На C# и Go мне удавалось более-менее успешно бороться с этим используя линтеры и статический анализ, но, тем не менее, ревью по прежнему жрало конскую долю моего рабочего времени.
Если вам повезло и у вас есть сильная система типов и HKT(и, конечно же, команда готова к такому повороту событий), то можно попробовать еще сильнее закрутить гайки и зафорсить архитектурный стиль через интерпритаторы. Тут мне, к сожалению, ничего не понятно, но очень интересно, так что сильно рекомендую послушать замечательный выпуск scalalaz'а про TF и джун-пруф девелопмент. Там гуру классно рассказывают, что это и как с этим жить.
В заключение скажу, что как не крути, но код читать придется. Причем много. И, скорее всего, плохого. И свои тикета из-за этого закрывать по ночам тоже придется(в лес не убегут, да). Но в результате, когда общий уровень команды поднимется, процессы устаканятся, вы незаметно перестанете просыпаться от pagerDuty по ночам. А это, как не крути, приятно)))