От джуна до сеньора: Как стать востребованным разработчиком - Владимир Швец Страница 4

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

Тезисы

■ Регулярный рефакторинг обязателен.

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

■ Планируйте рефакторинг и его границы.

■ Проверяйте, проверяйте и проверяйте код после рефакторинга; он должен работать точно так же, как и до него.

■ Не позволяйте перфекционизму утянуть вас на дно, вовремя останавливайтесь.

Задание

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

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

Однажды я сорвал запуск проекта, потому что неверно оценил время рефакторинга в 2–4 часа. В итоге на него ушло 2,5 недели.

Работает – не трогай

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

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

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

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

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

Тезисы

■ Работает – не трогай.

■ В попытке сделать лучше можно все сломать.

■ Обновляйте систему постепенно, взвешивая плюсы и минусы.

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

Задание

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

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

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

Новый код

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

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

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

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

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

Тезисы

■ Читайте и анализируйте код нового проекта.

■ Используйте время ознакомления с новым проектом по максимуму.

■ Спрашивайте, спрашивайте и спрашивайте.

■ Не бойтесь допускать ошибки; разработчиков, которые приходят на новый проект и моментально пишут идеально подходящий код, не существует.

Задание

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

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

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

Код как документация

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

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

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

В вашем проекте должно быть соглашение о том, что и насколько подробно надо документировать при работе над кодом. Если