1. Пишите маленькие методы
В идеале, они не должны занимать больше 20-30 строк кода. Это чрезвычайно важная привычка. Она не только будет заставлять вас писать компактный код, но и поможет вам мыслить аналитически, когда речь зайдет о модуляризации вашего кода.
2. Давайте содержательные имена
Это касается и методов, и переменных. Для разработчика-мидла недопустимо иметь переменные с именами «x» или «xyz», или даже «object». Мы даем имена переменным с помощью слов английского языка, чтобы эти имена имели определенное значение.
3. Не загромождайте ваши методы множеством параметров
Наличие множества параметров в методе это сигнал к рефакторингу. В большинстве случаев написание методов такого рода нарушает принцип единственной ответственности, т.е., такие методы делают слишком много всего. Эффективный, чистый метод выполняет одно действие, но хорошо.
4. Избегайте слишком большого количества методов в классе
Большие классы со множеством методов обычно являются признаком компонента, который слишком много знает или слишком много делает. Такие компоненты называют божественными классами; это антипаттерн написания кода.
5. Используя сторонние библиотеки, пользуйтесь LTS / стабильными релизами
Боритесь с желанием использовать самые новые версии инструментов: придерживайтесь самых безопасных и более стабильных.
6. Научитесь идентифицировать самые распространенные шаблоны проектирования
Да, большинство крупных проектов созданы с использованием одного или больше шаблонов проектирования. Вам не нужно знать их все или хорошо разбираться во всех, но знание самых необходимых будет полезным не только для обдумывания и проектирования вашего кода, но и для идентификации их в кодовой базе.
7. Всегда помните о разработчике, который придет вам на смену
Это можете быть вы сами, ваш коллега, новый сотрудник или даже разработчик из другой компании – любой человек, которому будет нужно расширить ваш код или добавить в него новый функционал.
каждый раз, когда вы:
готовы написать временный «хак» просто для того чтобы что-то заработало,
добавляете что-то в процесс сборки и не документируете это,
пропускаете рефакторинг,
– вы просто добавляете технический долг, с которым кому-то придется разбираться в будущем.
8. Привыкайте к ударам по вашей гордости
Это определенно не моя вина! Мог ли я допустить такую ошибку? Они что, идиоты? Они меня ненавидят? Почему они не понимают, как трудно заново реализовывать функционал?
Не давайте гордыне охватить вас (и синдрому самозванца – тоже Почему синдром самозванца — это хорошо).
Ваша работа заключается не только в том чтобы быть отличным аналитиком, программистом и технарем. Вы должны быть отличным профессионалом.
9. Оставьте «кемпинг» более чистым, чем вы его нашли
Мы сидим и думаем, не стоит ли тут прибраться, раз уж мы работаем с этим проектом. Когда лучше чистить код: сейчас, позже, никогда
Определить, какой уровень рефакторинга нужен проекту, бывает нелегко.
10. Не бойтесь заниматься вещами, не связанными с написанием кода
… важно заниматься и не-техническими задачами, погружаясь в волшебный мир soft skills.
Общение с менеджерами, тестировщиками и клиентами может казаться пугающим и утомительным, но оно тоже имеет большое значение.
11. Будьте фанатом документации
Добавление/удаление плагинов и сторонних библиотек, какие-то предположения в коде, дополнительные шаги в настройках или процессе сборки, использование специфической версии инструмента командной строки – все это, если не будет должным образом задокументировано, может обернуться сильной головной болью в будущем.
12. Оставляйте себе время на отдых и физическую активность
Конечно, 8-часовой сон и (особенно) физические упражнения днем это необычно для среднего разработчика. После работы мы склонны расслабиться, посмотреть сериал, поиграть в видеоигры. И даже не начинайте насчет здорового питания.
Но истина в том, что здоровая диета и регулярные упражнения окажут огромный эффект на ваш рабочий настрой и производительность вашего труда.
13. Учитесь отстраняться от личных чувств
Это тесно связано с правилом № 8, касающимся гордости. Но важно не только уметь смиряться, когда задевают ваше эго разработчика. Нужно учиться быть эффективным профессионалом и стараться не давать личным проблемам тревожить вас на работе.
Учитесь принимать мнение других людей (даже если вы лично с ними не согласны) и делать то, что будет хорошо для работы и проекта.
14. Давайте хорошие советы
Между джуниором и сеньором есть огромная разница в их способности давать хорошие советы и делать ревью кода. Когда вас просят дать совет или просмотреть код, старайтесь не смотреть на вещи «со своей колокольни», а концентрироваться на картине в целом и общем благе.