Что знают старшие разработчики

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

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

Старшие разработчики понимают, что ясность - это король

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

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

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

Ясность кода также достигается за счет написания кода, который не нуждается в комментариях. Если разработчик чувствует необходимость комментировать свой код, он должен остановиться и спросить, почему. Она должна очень сильно задуматься о том, что причина, по которой она чувствует эту необходимость, заключается в том, что код не понятен.

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

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

Сложности легко избежать. Просто перестаньте заставлять какую-то одну вещь делать больше, чем одну. Это своего рода определение сложности в программном обеспечении: сущности, которые делают несколько вещей. Если каждая сущность в вашей кодовой базе делает только одну вещь, то исправление чего бы то ни было включает в себя исправление только этой одной вещи, которая сломана.

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

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

Старшие разработчики не поддаются искушению работать быстро

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

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

Они знают, что спешка не приносит ничего хорошего. Отличные программы получаются, если писать код обдуманно, осторожно и вдумчиво.

Старшие разработчики готовы терпеть краткосрочную боль ради долгосрочной выгоды

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

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

Хороший старший разработчик знает, как противостоять этому, насколько это возможно, и ограничить ущерб, когда это происходит.

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