Введение

Многие считают, что переход от эффективного разработчика уровня Junior к разработчику среднего уровня — это всего лишь вопрос времени и опыта.
Правда в том, что грань, разделяющая эти два типа разработчиков, очень тонкая и субъективная. Эта статья не станет продолжением бесконечных дебатов на тему «Что именно определяет разработчика среднего уровня».

Честно говоря, я твердо верю, что что-то, что может изменить мышление и помочь в переходе от младшего к среднему или старшему разработчику, — это привычки:

Привычка — это то, что вы начинаете делать систематически, пока это не перестанет быть для вас чем-то странным, а станет естественным.

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

Давайте посмотрим список повседневных привычек, которые, освоив их, обязательно помогут вам выйти на новый уровень и плодотворно развиваться:

1. Пишите небольшие методы

В идеале не более 20–30 строк кода (LoC). Эта привычка чрезвычайно важна. Это не только заставит вас писать компактный код, но и поможет вашему аналитическому мышлению, когда дело доходит до модульности вашего кода.
Наличие больших методов с высокой степенью отступа (много if, циклов for и т. д.) — это кошмар. Это может показаться простым и понятным, когда вы пишете такой метод, но через несколько дней даже вам будет трудно понять, что вообще делает этот метод.

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

2. Дайте осмысленные имена

Как к методам, так и к переменным. Для разработчика среднего уровня неприемлемо иметь переменные с именами «x», «xyz» или даже «object». Цель именования переменных английскими словами состоит в том, чтобы они имели значение.

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

Цель комментариев — объяснить «почему», а не «как» в коде.

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

Пытаясь назвать вещи, сделайте шаг назад и подумайте о возможности того, что компонент, который вы пытаетесь назвать, слишком сложен и нуждается в рефакторинге.

3. Не загромождайте свои методы множеством параметров

Наличие большого количества параметров в методе является признаком рефакторинга. Чаще всего написание такого рода методов нарушает SRP (принцип единой ответственности), что означает, что они делают слишком много вещей.
Эффективный, чистый метод делает одну вещь, хорошо.
Как сказал дядя Боб, три аргумента — это максимальное количество допустимых аргументов. Хотя это может быть и не строго. Он дает вам обзор желаемого количества аргументов в методе.

Боритесь с желанием изменить некоторые локальные параметры вашего метода на поля класса. Рассмотрите возможность рефакторинга кода, чтобы метод выполнял меньше действий, или разбейте метод на два отдельных.

Цитата Роберта К. Мартина:
«Функции должны иметь небольшое количество аргументов. Нет лучшего аргумента, за которым следуют один, два и три. Больше трех очень сомнительно, и его следует избегать с предубеждением».

4. Избегайте слишком большого количества методов в классе

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

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

5. Используйте LTS/стабильные версии при использовании сторонней библиотеки.

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

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

6. Научитесь определять наиболее распространенные шаблоны проектирования

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

Имея возможность идентифицировать шаблон проектирования в базе кода, можно также расширить его или добавить к нему дополнительные функциональные возможности, зная, в каких местах искать определенные классы и объекты.

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

7. Всегда думайте о следующем разработчике

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

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

Выделите время, чтобы анализировать свою работу каждые пару часов. Добавьте необходимую документацию в файлы README, удалите неиспользуемый код и файлы, которые вы временно добавили в проект. Если вы не уверены в принятом вами архитектурном или программном решении, поговорите с кем-то более опытным на вашем рабочем месте.
Вы не только улучшите состояние написанного вами кода, но и научитесь лучше справляться с такими ситуациями в будущее и привыкнуть к тому, что ваша гордость задета. (Это то, что будет происходить постоянно, когда ты уже не джуниор :D )

Вывод

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

Пожалуйста, оставьте свои комментарии ниже об этих привычках и следите за обновлениями для части 2! :-)

Эта статья изначально появилась в моем личном блоге.