The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
Вот вопрос, который я постоянно слышу, когда выступаю на конференциях по объектно-ориентированному программированию и моему нетрадиционному пониманию этой темы: “Как убедить всю команду начать делать все совершенно иначе?” (задан здесь недавно). Действительно, легко изменить свои привычки при написании кода и проектировании программного обеспечения, если вы одни. Что делать, если вы работаете в большой команде, где все очень довольны Spring Framework и процедурным программированием? Как изменить их привычки? Еще более важный вопрос: Как не быть уволенным, делая это?
Короче говоря, одному вы не победите, вам нужна команда; соберите ее.
Я помню, несколько лет назад я присоединился к команде Java в качестве архитектора, и мой босс сказал мне, что в команде есть очень талантливые программисты, но им нужна помощь. Он также сказал мне, что архитектура отличная, но ее нужно улучшить, чтобы стать еще лучше. И он также сказал мне, что я здесь для внесения изменений, на которые они с нетерпением ждали.
Через несколько недель я понял, что реальность была совсем другой. Большинство из этих 30 программистов на самом деле были новичками и едва могли отличить метод объекта от статического. Я также узнал, что архитектуры вообще не было, только набор .java файлов, созданных разными людьми в разное время. И, конечно, стало очевидно, что независимо от того, насколько я старался, мои идеи не будут приняты, просто потому что они показались слишком страшными для этих “талантливых” людей.
Правда, если бы я сам был одним из этих программистов, сидящих там несколько лет, пишущих код на Java и получающих зарплату два раза в месяц, я был бы рад встрече с кем-то, кто скажет мне, что я ошибался все эти годы и теперь пришло время переписать все заново? Независимо от того, насколько логичным является мнение этого человека, я просто бы подорвал его, чтобы защитить себя. Независимо от того, насколько мы признаем ценность индивидуализма и независимого мышления, большинство людей очень социальны и зависят от сообщества вокруг них. Другими словами, они делают то, что делают все остальные. Это безопаснее.
Эти 30 человек не были исключением. Они шли по течению, использовали Spring, MyBatis, Singleton’ы, геттеры, сеттеры и все остальное, что мы, настоящие ООП программисты, так ненавидим. Но я должен был что-то сделать с этим, ведь за это мне платили. Однако, просто сказать им, что начиная сегодня мы должны избавиться от Spring, потому что он противоречит ООП, означало бы для меня только одно: расторжение контракта, рано или поздно.
Такая революция была бы серьезной угрозой как для программистов, так и для продукта. Во-первых, большинство программистов вернулись бы на младшие должности, вынуждая их изучать новые парадигмы с нуля, в то время как они хотят продолжать наслаждаться своей работой “старшего разработчика” и зарплатами. Во-вторых, радикальные архитектурные изменения всегда подвергают опасности стабильность существующего программного обеспечения.
Сначала я выбрал самых молодых и самых талантливых (одновременно). Я поговорил с каждым из них и выяснил, у кого был наибольший потенциал. Обратите внимание, я выбрал не самых лучших, а тех, в которых я верил, что больше всего заинтересованы в обучении и профессиональном росте. Неудивительно, что они были самыми молодыми (по карьере, а не по возрасту). Было очевидно, что у них не было достаточного профессионального наставничества и стратегии развития. Ведь была весна, о каком росте мы можем говорить, не так ли?
Во-вторых, я неофициально стал их наставником. Именно это нужно младшим и амбициозным инженерам больше всего: учитель. Кто-то, кто может показать им путь обучения и направление к новым знаниям. Мое наставничество заключалось просто в обзоре написанного ими кода и указании на ошибки, подкрепляя свою критику своими собственными блог-постами и множеством других статей/книг, которые я мог найти о “хорошем” проектировании программного обеспечения.
Третье, я организовывал регулярные еженедельные лекции для всей команды. Я проводил один час каждый понедельник, выступая перед ними и объясняя, почему NULL - это плохо, а юнит-тесты - хорошо, и так далее. Все могли свободно посещать. Неудивительно, что мои “студенты” всегда были на месте.
Четвертое, я проводил рефакторинг кодовой базы в некоторых критических местах и просил моих “студентов” рассматривать мои запросы на слияние. Эти небольшие сложные задачи дали нам хороший материал для обсуждения и еще больше объединили нашу подкоманду. Моя конечная цель заключалась в том, чтобы собрать команду, согласную со мной. Обзор кода друг друга был идеальным способом для этого.
Всем стало очевидно всего за несколько месяцев, что вся команда уже не является такой единой. У нас было большинство, придерживающееся основных взглядов, и меньшинство, настаивающее на чистом ООП, собравшееся вокруг меня. Статус-кво начало трястись. Меньшинство было недовольно архитектурой и перестало бояться говорить об этом. Архитектура все еще была плохой, но уже не являлась “нашей” архитектурой. Это было что-то, что мы унаследовали из прошлого, и мы были решены изменить ее… в конечном итоге.
Моя первоочередная задача заключалась не в исправлении архитектуры, а в создании коалиции сторонников, и это было достигнуто. Мне не удалось получить большинство. В моей банде было всего 7 человек. Но этого было достаточно, чтобы изменить направление всей команды из 30 программистов. Другие позже пассивно присоединились к нам.
Я покинул этот проект менее чем через год (меня не уволили). Однако, когда я уходил, проект двигался в правильном направлении: покрытие тестами росло, объекты становились неизменяемыми, новые DTO больше не создавались и так далее. Spring Framework все еще продолжал использоваться.
Вы можете сделать то же самое в своей команде, даже если ваша должность все еще “младший” разработчик. Не ждите, пока ваш начальник изменит вашу должность, начните наставлять людей вокруг вас и создавать команду сторонников. Когда она станет достаточно большой, изменения начнут происходить даже без вашего желания.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-17 at 16:03
