Основываясь на всём моём многолетнем опыте разработчика и техлида, я могу с уверенностью назвать одну конкретную вещь, которая наиболее сильно повышает продуктивность работы программиста: это прочтение абсолютно всего кода разрабатываемого командой продукта. Это «простое» действие (хотя оно и займёт некоторое время, а также потребует внимания для понимания прочитанного), но удивительно, как мало людей в командах делают это. А ведь разработчики, которые никогда не читали всего кода, всегда будут зависеть от тех, кто сделал это.
Понимание общих архитектурных принципов и взаимосвязей компонентов — шаг в правильном направлении, но то, что советую проделать я, это шаг ещё дальше. Детали реализации часто определяют поведение системы в не меньшей мере, чем высокоуровневая архитектура. Рутинные низкоуровневые операции на самом деле рано или поздно сложатся в вашем сознании в пазл, на котором яркими линиями проступят высокоуровневые связи компонентов и подсистем. Вы больше никогда не попадёте в ситуацию «а я думал это делается вот в той подсистеме...» или «я выполнял данную операцию здесь, поскольку не знал, что она должна быть выполнена раньшепозже». Вы окажетесь на том уровне «просветления», который позволит вам обсуждать с любым вашим коллегой или руководителем детали взаимодействия подсистем или потенциальные способы реализации будущего функционала.
После того, как вы прочитаете весь код вашей системы, то заметите как изменится ваш взгляд на задачи по разработке новых функций:
- Вы станете быстрее понимать, какие именно части системы будут затронуты новой функциональностью. Вы сможете лучше оценить сложность и время на разработку новой фичи. Общий взгляд на систему даже позволит вам высказывать рекомендации разработчикам отдельных её компонентов по поводу того, как будет лучше их состыковать вместе
- Поскольку вы понимаете работу всей системы, то можете предвидеть проблемы в некоторых ситуациях, на которые не обратили внимание разработчики отдельных подсистем
- Ваш менеджер сможет полагаться на вас в плане оценки сложности проблем и выбирать те из них, решение которых в данный момент может принести наибольший результат при наименьших трудозатратах. В принципе, менеджер мог бы обращаться за подобными оценками к разработчикам конкретных подсистем, но это хорошо работает лишь для очень небольших команд (человек до пяти). Но вам нужно стараться соблюдать баланс: не давайте вашим коллегам почувствовать себя забытыми. Ваши глубокие знания и понимание системы не принесут пользы, если остальные члены команды станут вас сторониться.
- Ваши коллеги, отвечающие за отдельные подсистемы, начнут сами спрашивать совета у вас (и ценить его). Когда вас просят помочь советом, это либо признак того, что вы начинаете заниматься микроменеджментом чужой работы (не очень хорошая вещь), либо того, что вы проходите фазу ситуативного лидерства в данной команде/проекте (ещё не являетесь официальным лидером команды, но уже являетесь одним из лидеров мнений).
Вне контекста разработки новых фич, вы, возможно, заметите также ещё несколько вещей:
- Вас официально назначат техлидом проекта, что откроет перед вами совершенно новые горизонты проблем
- Вам придётся просматривать всё больше и больше пул-реквестов. Их качественная обработка займёт много времени
- Вас будут приглашать на большее количество стратегических совещаний
- Вас будут чаще привлекать к разработке архитектуры
- У вас появится собственное виденье того, куда должна двигаться вся система для достижения долгосрочных целей
- Вам придётся консультировать внешних клиентов
- Ваши контакты с менеджером станут более частыми, на ваши суждения будут полагаться всё чаще и всё сильнее
- Вам будет редко удаваться найти время для написания кода самому
- К вам будут приходить высказывать свои идеи и просить их оценку
- Ваша зарплата вырастет
- В названии вашей должности появится слово “senior”
- Люди начнут видеть в вас своего лидера
- Ваши коллеги будут впечетлены вашей способностью предвидения проблем и «узких мест». Хотя они, в общем-то, тоже находятся на том же расстоянии протянутой руки до такой проницательности (всего-то нужно взять и прочесть весь код своего продукта)
- Каждая новая фича будет рассматриваться вами как ход в шахматной игре (так много позиций, угроз, возможностей).
- Вы осознаете, что весь проделанный труд дал вам лишь одномоментный снимок знаний о состоянии системы на какой-то момент. Ваши представления о коде будут устаревать с каждым пул-реквестом, и вам придётся день за днём сражаться с устареванием ваших знаний. Ну, знаете, «бежать со всех ног просто чтобы остаться на месте».
Так вот, знаете… Лучше уж вы не читайте весь этот код. Жизнь значительно проще без этого :)
Автор: tangro
