Перевод статьи «The 14 habits of highly effective developers (часть 1).
Многие думают, что переход эффективного разработчика-джуниора на более высокий, средний уровень это лишь вопрос времени и опыта. Но дело в том, что линия разграничения между этими двумя уровнями очень тонкая и субъективная. Эта статья не ставит своей целью подлить масла в огонь бесконечных дебатов на тему «Как именно определить, что разработчик вышел на средний уровень».
Честно говоря, я считаю, что переключить что-то в сознании разработчика и поспособствовать его переходу от уровня джуниора до уровня мидла или сеньора могут определенные привычки.
Привычка это действие, которое вы начинаете делать систематически, пока оно не станет для вас естественным, перестав быть чем-то необычным.
Формирование привычек, касающихся программирования и работы вообще, является критически важным для профессионального и личностного роста.
Давайте рассмотрим список ежедневных привычек, которые могут помочь вам подняться на следующий уровень в своей карьере.
1. Пишите маленькие методы
В идеале, они не должны занимать больше 20-30 строк кода. Это чрезвычайно важная привычка. Она не только будет заставлять вас писать компактный код, но и поможет вам мыслить аналитически, когда речь зайдет о модуляризации вашего кода.
Крупные методы с высокой степенью вложенности (много if-ов, циклов for) это кошмар. Сразу, когда вы пишете этот метод, все может казаться понятным, но спустя несколько дней даже вам, автору кода, будет сложно разобраться, что этот метод делает.
Вдобавок, крупные методы часто непригодны к повторному использованию. Они пишутся в связи с какой-то конкретной необходимостью и их будет сложно использовать где-нибудь еще.
2. Давайте содержательные имена
Это касается и методов, и переменных. Для разработчика-мидла недопустимо иметь переменные с именами «x» или «xyz», или даже «object». Мы даем имена переменным с помощью слов английского языка, чтобы эти имена имели определенное значение.
Коммуникация с вашим кодом намного важнее, чем коммуникация с документацией или комментариями.
Назначение комментариев – отвечать на вопрос «почему», а не «как».
Осмысленные имена переменных помогают вам лучше коммуницировать с любым читателем вашего кода. Благодаря им вы сможете обойтись без чрезмерного количества комментариев.
Все сказанное касается как переменных, так и методов.
Если вы чересчур долго не можете придумать хорошее имя для метода, возможно, стоит сделать рефакторинг вашего кода, чтобы этот метод стал более простым. Имя для хорошего, чистого метода всегда легче приходит на ум.
Испытывая трудности с выбором имени для какого-нибудь компонента, отступите на шаг и подумайте, не является ли этот компонент слишком сложным, не нуждается ли он в рефакторинге.
3. Не загромождайте ваши методы множеством параметров
Наличие множества параметров в методе это сигнал к рефакторингу. В большинстве случаев написание методов такого рода нарушает принцип единственной ответственности, т.е., такие методы делают слишком много всего. Эффективный, чистый метод выполняет одно действие, но хорошо.
Как сказал Дядя Боб, приемлемо иметь максимум три аргумента. И хотя это не строгое правило, оно дает вам представление о том, к чему нужно стремиться в плане количества аргументов в методе.
Подумайте, как изменить ваш код, чтобы метод выполнял меньше действий, или разбейте этот метод на два отдельных.
Цитата Роберта Сесила Мартина (из книги «Чистый код. Создание, анализ, рефакторинг» – «Питер», 2013):
«В идеальном случае количество аргументов функции равно нулю. Далее следуют функции с одним аргументом и с двумя аргументами. Функций с тремя аргументами следует по возможности избегать. Необходимость функций с большим количеством аргументов должна быть подкреплена очень вескими доводами — и все равно такие функции лучше не использовать».
4. Избегайте слишком большого количества методов в классе
Число методов в классе столь же важно, как и число параметров.
Большие классы со множеством методов обычно являются признаком компонента, который слишком много знает или слишком много делает. Такие компоненты называют божественными классами; это антипаттерн написания кода.
Если в вашем классе много методов, подумайте, как часто вам нужно будет менять его поведение по мере развития вашего кода. Это может нарушать принцип открытости/закрытости, устанавливающий, что «сущности программ (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения».
5. Используя сторонние библиотеки, пользуйтесь LTS / стабильными релизами
Всегда имейте в виду, что разработчику, который придет вам на смену, нужно будет использовать ваш код и перекомпилировать проект.
Использование LTS-версий (Long Term Support, версий с долгосрочной поддержкой) библиотек, плагинов и фреймворков может быть не лучшим вариантом, если вы хотите получить их новейший функционал. Однако, если в будущем вам нужно будет перестраивать или перекомпилировать ваш код, лучше всего вам подойдут именно стабильные версии сторонних библиотек.
Боритесь с желанием использовать самые новые версии инструментов: придерживайтесь самых безопасных и более стабильных. В будущем вы (и ваши коллеги тоже) поблагодарите себя за это.
6. Научитесь идентифицировать самые распространенные шаблоны проектирования
Да, большинство крупных проектов созданы с использованием одного или больше шаблонов проектирования. Вам не нужно знать их все или хорошо разбираться во всех, но знание самых необходимых будет полезным не только для обдумывания и проектирования вашего кода, но и для идентификации их в кодовой базе.
Если человек может идентифицировать шаблон проектирования в кодовой базе, он также способен расширить ее или добавить в нее больше функционала, поскольку знает, куда нужно смотреть, чтобы найти определенные классы и объекты.
Хорошо реализованный шаблон проектирования приводит к тому, что все люди, занятые в проекте, начинают говорить на «одном языке» и более эффективно коммуницировать друг с другом касательно кода.
7. Всегда помните о разработчике, который придет вам на смену
Это можете быть вы сами, ваш коллега, новый сотрудник или даже разработчик из другой компании – любой человек, которому будет нужно расширить ваш код или добавить в него новый функционал.
Привыкнуть думать о следующем разработчике действительно сложно. Большинство разработчиков-джуниоров существуют в типичной парадигме университетского проекта: когда вы пишете необходимый код, к которому никто больше не будет иметь никакого отношения.
В профессиональной разработке дело обстоит иначе. Вам нужно будет писать код для проекта, написанного много лет назад, и этот ваш код должен быть готов для «следующего разработчика», который может прийти вам на смену спустя несколько лет.
Поэтому, каждый раз, когда вы:
- готовы написать временный «хак» просто для того чтобы что-то заработало,
- добавляете что-то в процесс сборки и не документируете это,
- пропускаете рефакторинг,
– вы просто добавляете технический долг, с которым кому-то придется разбираться в будущем.
Отводите время, чтобы каждые пару часов пересматривать свою работу. Добавляйте необходимую документацию в файлы README, удаляйте неиспользуемый код и файлы, которые вы временно добавляли в проект. Если вы не уверены относительно принятого вами архитектурного или программного решения, обсудите это с кем-то более опытным.
Благодаря такому подходу вы не только улучшите состояние кода, который пишете, но также сможете лучше справляться с подобными ситуациями в будущем. А еще вы привыкнете к ударам по вашей гордости (а это происходит постоянно, когда вы перерастаете уровень джуниора :D).
Заключение
Переход с уровня джуниора на уровень мидла это не то, что случается за одну ночь. Продвижение по карьерной лестнице и повышение профессионального уровня связаны с формированием хороших привычек. Часть из них мы рассмотрели в этой статье.
Продолжение читайте здесь.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]