Сначала научитесь играть по правилам, потом придумывайте свои | Так не сойдет

Сначала научитесь играть по правилам, потом придумывайте свои

Это татуировка #1 из книги «45 татуировок менеджера» Максима Батырева. Книга - своеобразный сборник афоризмов и жизненных уроков, вынесенных автором из работы менеджером.
В контексте книги данная «татуировка» про то, как входить в новый коллектив и приступать к новым обязанностям. Сначала разобраться как все устроено, а уже после пытаться что-то менять. Зачем это нужно? Чтобы пропустить через себя имеющуюся ситуацию и понять, почему ваше новое окружение устроенно именно так, как устроенно. Понимая как устроен мир вокруг вас и почему именно так, вы наломаете меньше дров внося какие-либо изменения.

Этот принцип мне особенно запомнился, больше чем другие. Мне нравится примерять идеи из разных областей на разработку. Тимлид - это и менеджер и разработчик одновременно, поэтому взимное опыление в этих областях очень сильное. «Татуировка #1» хороший пример.

Разработчики - не глупые люди, как правило очень сильно не глупые. В то же время, изменить код гораздо проще, чем изменить какой-то объект в офлайн мире. Инженеру-физику не изменить законы физики, ему приходится учитывать их как данность. Разработчик же может менять фреймворки и подходы как перчатки.
Иногда простота изменения и наш пытливый ум играют с нами злую шутку - нам начинает казаться, что мы уже достаточно опытные и изучили все, что только можно. А дедовский метод написания кода устарел и необходимо затащить новый модный XYZ в продакшен вот прямо сегодня.
Только вот старые подходы и фреймворки, которые годами применялись в индустрии, никуда не деваются. Любая область знания накапливает best practices со временем.

- Дак что, получается надо использовать best practices и не смотреть по сторонам?
Конечно нет! Расширять кругозор обязательно нужно. Но подход, которого я стараюсь придерживаться, это «расширять best practices исключениями, а не заменять их».

Несколько примеров:
SOLID и GoF patterns. Сначала надо научиться писать понятный и структурированный ООП код, а уже потом добавлять элементы функционального программирования там, где они уместны.
DRY. Сначала надо научиться качественно обобщать код, а уже после начинать замечать ситуации где лучше этого не делать. И в них вносить дублирование, причем делать это осознанно.
Структурирование кода и распределение обязанностей. Сначала надо научиться писать качественные функции, потом классы, потом модули, научиться структрировать код на "слои". И уже тогда приступать к SOA и микросервисам.

Этот же подход хорошо ложится на условные грейды:
junior не знает best practices и только изучает их;
middle знает и «втыкает» их везде где только можно, следует им фанатично;
senior знает исключительные ситуации, когда от best practices надо отойти и почему.
Разработчик, который вдумчиво анализирует используемые подходы, скорее всего не будет переворачивать проект с ног на голову, а будет итеративно внедрять улучшения сохраняя то, что работает хорошо.

В общем, я «набил» себе эту татуировку, как универсальную и работающую почти в любой ситуации.