[Перевод] Полезные разработчику привычки
Благодаря которым вы станете лучше как программист
Привычки, относящиеся к написанию кода, есть у каждого разработчика — и вредные, и полезные. Но если завести правильные привычки, это поможет серьезно повысить эффективность работы с кодом. Такие привычки повлияют не только на вас, но, скорее всего, и на ваших коллег.
Как сказал Денис Уэйтли, «нельзя избавиться от вредной привычки, но можно заменить ее полезной». Поэтому я предлагаю вам список из семи привычек, которые, как мне кажется, помогут вам стать лучше как программист.
Переведено в Alconost
1. Не повторяйтесь
Наверняка у вас не однажды бывало такое: вы смотрите на кусок кода и видите, что он очень похож на фрагмент, который вы уже когда-то писали.
Это — плохая примета: повторения следует избежать. Дублирование кода — плохой тон, ведь такой код со временем становится всё труднее поддерживать, так как исправления приходится вносить в нескольких местах. В итоге повышается вероятность того, что в код закрадутся ошибки.
Хорошим тоном считается следовать принципу «НЕ ПОВТОРЯЙСЯ», или DRY (англ. «Don«t repeat yourself»): если вы начинаете писать код, который уже есть в другой части системы, то, скорее всего, нужно провести рефакторинг. Разделите код и логику на более мелкие повторно используемые блоки и вызывайте их там, где нужно.
2. Написал — отрефакторь
Большинство программистов, особенно те, у кого опыта немного, думают, что если поставленная задача выполнена, это значит, что код работает так, как задумано. Но чтобы «выполнить» задачу, недостаточно просто набросать код, реализующий новую функцию.
Но если код работает, чего ещё нужно?
Ну да, работает. Но прежде чем переходить к следующей задаче, нужно провести рефакторинг: это улучшит читабельность кода. Ведь наверняка этот фрагмент — не самый аккуратный и очевидный из написанных вами: что-то может быть с ходу понятно вам, но как этот код будет видеть другие? Будьте критичны к своему творению.
Кроме того, рефакторинг помогает снизить сложность кода, что упрощает сопровождение. И в перспективе это окупится.
3. Сосредоточьтесь на задачах бизнеса
Разработчики, как правило, настолько погружены в изучение технологического стека, что упускают из виду задачи бизнеса — однако о них забывать нельзя. Вспомните, какая цель у разрабатываемого вами проекта?
Некоторые разработчики интересуются лишь техническими аспектами своей работы. Их не волнуют деловые и экономические факторы, наличие которых, по сути, и дает им работу.
На что уходит ваше рабочее время? Прино́сите ли вы пользу бизнесу — или слишком много времени тратите на то, что по факту не очень-то и важно? Задавайте себе этот вопрос почаще.
4. Небольшие коммиты
Если охват у коммита небольшой, это позволяет дать ему внятное описание. Все же понимают, что «исправлено пару ошибок» — это плохое описание, да?
Небольшие коммиты упрощают отладку: можно откатиться до предыдущего коммита и проверить, была ли ошибка в нем. А если в коммите кода немного, то и ошибку искать будет легче.
Если же коммиты большие, следствием могут быть различные неприятности и неудобства. Если изменения в одном коммите затрагивают много всего, то становится непонятно, что конкретно изменилось.
А ведь кому-то придется делать проверку этого кода, и ему (или ей) будет страшновато делать слияние, потому что слишком многое в коммите может потенциально нарушить работу остального кода.
Поэтому в случае небольших коммитов проверка кода существенно упрощается: проверяя одно изменение за раз, легко разобраться, что изменилось фактически.
5. Главное — единообразие
Если вы решили именовать переменные в Верблюжьем Стиле, не отступайте от этого правила. Хотите использовать пробелы вместо табуляции? Вперед! Но что бы вы ни выбрали, придерживайтесь этого везде.
С течением времени разобраться в написанном ПО становится всё сложнее: чем дольше существует проект и чем больше людей над ним работает, тем больше в коде беспорядка. Поэтому отсутствие единообразия порождает проблемы.
Что же предпринять, чтобы сохранить единообразие?
Во-первых, нужно выбрать определенный стиль оформления и придерживаться его. Можно использовать анализаторы кода — линтеры, — который будут проверять написанное на соответствие выбранному стилю.
Во-вторых — придерживаться единообразного именования переменных, методов и классов. Подробнее о том, как давать хорошие имена, — в моей статье.
Главное — помните: удобство сопровождения кодовой базы очень сильно зависит от единообразия кода!
6. Не оставляйте «на потом»
«Ладно, это я поправлю позже», — звучит знакомо? Все мы знаем, что такое «позже» часто превращается в «никогда». Если вы видите комментарий «TODO», это значит, что кто-то оставил что-то на неопределенное «потом».
Работайте над фрагментом кода или пользовательской историей с нуля и до полного завершения.
Но что значит «до завершения»?
В первую очередь это означает, что код прошел рефакторинг, как говорилось выше. Кроме того, код нужно протестировать. А тестирование для большинства разработчиков — пожалуй, самая нелюбимая часть работы. При этом недостаточно пройти по сценарию, включающему лишь предусмотренные действия — обязательно проверяйте и другие варианты. А можно приложить чуть больше усилий и написать парочку автоматических тестов.
И последнее — документация. Нужна ли для этой конкретной функции документация? Объяснили ли вы тестировщику, как проверять эту функцию? Нужно ли ему (или ей) знать о каких-то предварительных условиях?
7. Не переставайте учиться
Новые технологии появляются каждый день. Иногда может показаться, что успевать за всеми тенденциями невозможно. Тем не менее, нельзя прекращать изучать новое: как только вы перестанете учиться, вы перестанете расти профессионально.
Изучение нового — единственный способ оставаться актуальным на рынке труде в нашу технологическую эпоху постоянных перемен.
«Вы не будете расти, если не будете пытаться совершить что-то за пределами того, что уже знаете в совершенстве»
— Ральф Уолдо
О переводчике
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.
→ Подробнее
