От джуна до сеньора: Как стать востребованным разработчиком

Общий код

При совместной работе над проектом код почти никогда не бывает написан кем-то одним. Чаще всего код, который вы видите, – результат работы множества людей. Над одной небольшой функцией могли работать десятки человек, и каждый из них имел свое видение кода, свой опыт, свои предпочтения в организации логики.

Общий код проекта – это вопрос договоренностей и соглашений. Код ваших коллег не всегда будет вас радовать. Вы разные люди с разным опытом и подходом к разработке. Возможно, вы в восторге от «условий Йоды», но это совсем не значит, что коллеги разделяют ваши предпочтения. Возможно, вас не восхищает коллега, который предпочитает оформлять в функцию даже небольшие блоки кода, используемые только в одном месте.

Какие-то из этих вопросов вы сможете обсудить на код-ревью, если в вашей компании есть такая практика. Но обычно то, что не относится к корректной работе кода, не служит поводом для обсуждения. Вы, как разработчик, должны уметь читать и воспринимать любой код, даже если он вам не особо нравится.

Проработав в коллективе какое-то время, вы с коллегами так или иначе придете к негласной (или очень даже гласной) договоренности о том, что возможно допускать при работе над кодом, а что – нет. Не расстраивайтесь, если оказались в меньшинстве, и не прыгайте от радости, если ваш стиль приняло большинство. Вы же не станете ловить коллегу в коридоре только для того, чтобы прижать к стене и пытаться убедить, что любить котиков неправильно и он должен срочно завести собаку, а кота выставить за порог.

Старайтесь относиться к чужим предпочтениям с пониманием, этот навык очень пригодится, когда со временем вы станете старшим разработчиком или руководителем отдела. Тогда вам придется постоянно иметь дело с десятками людей, каждый из которых будет писать код так, как нравится ему. И каждый код будет хорош по-своему. Единственным исключением будет такой код, в котором нарушены правила оформления, принципы работы компании или он просто запутан настолько, что понять его может только автор. Да, у всех разработчиков есть собственный стиль, и он не должен становиться препятствием для других.

Тезисы

■ Код проекта – это совместный труд его разработчиков.

■ Вам не обязан нравиться чужой код, равно как и ваш код не обязан нравиться вашим коллегам.

■ Умейте читать и воспринимать любой код.

■ Договаривайтесь с коллегами, как должен выглядеть и работать код вашего проекта.

Задание

Возьмите любой проект и проанализируйте его код. Попробуйте угадать непосредственно по коду, какие части были написаны разными людьми. Используйте git blame, чтобы узнать, правы ли вы. Найдите код, который вам визуально не нравится: он может быть написан с использованием необычных нотаций из прошлого (да, Венгерская нотация, я никогда тебя не забуду), иметь нетипичный подход к размещению блоков и т. д. Попробуйте хотя бы немного привыкнуть к нему.

Представьте, что разработчик, написавший этот код, – ваш подчиненный. Достаточно ли у вас оснований сказать, что код не работает, и отправить его на доработку?

История из жизни

Помню, на одном из проектов мы долго обсуждали с коллегой, как именно должен выглядеть код на языке программирования, на котором мы в тот момент писали. Спустя некоторое время в обсуждение вовлекся весь отдел. До ссоры не доходило, но и общего согласия на горизонте видно не было. В итоге мы решили вопрос анонимным голосованием (и да, для этого быстро написали маленькое приложение, с чего бы нам просто кидать бумажки в шляпу!); принятое решение пошло на пользу всем.