Все мы имеем как хорошие, так и плохие привычки в программировании. Однако, как только вы начинаете вырабатывать правильные привычки, ваша эффективность существенно возрастает. Причем они оказывают положительное влияние не только на вас, но и на окружающих.
Как сказал Денис Вэйтли: “Правда в том, что вы не устраняете плохую привычку, а замещаете ее хорошей”. Именно поэтому я подготовил для вас список из семи привычек, которые, на мой взгляд, повысят ваш уровень как программиста.
Вы наверняка неоднократно сталкивались с ситуацией, когда, глядя на некий участок кода, думали: “Где-то я это уже недавно писал”.
Воспринимайте это как звоночек, поскольку подобных ситуаций следует избегать. Код становится сложнее поддерживать: правки повторяющегося участка делаются во многих местах. Кроме того, повышается вероятность появления багов.
Как только вы начинаете повторяться, следует задуматься о рефакторинге. Разделите код и его логику на более мелкие, переиспользуемые части, и затем используйте их, вызывая там, где потребуется.
Большинство программистов, особенно начинающих, думают, что их работа выполнена, как только код работает как планировалось. Однако слово “выполнена” означает больше, чем просто написание куска кода для добавления какой-то функциональности.
“Так все же работает, в чем тут смысл?”: спросите вы.
Да, вы правы. Но прежде, чем переключаться на следующую задачу, вам следует отрефакторить код. Таким образом вы повысите его читаемость. Высока вероятность того, что ваше произведение не является чистейшим образцом кода. Некоторые моменты могут быть вполне ясны вам, но подумайте о том, как их воспримут другие программисты. Отнеситесь к этому критически.
Рефакторинг может также помочь упростить код и дальнейшее его обслуживание.
Большинство программистов изучают только технические аспекты и не учитывают реальную необходимость выполненной работы. Но если вы хотите стать преуспевающим программистом важно также удерживать во внимании и последний аспект. Почему вы создаете что-либо?
Является ли то, над чем вы работаете, действительно ценным для бизнеса или вы тратите слишком много времени на то, что в действительности не играет существенной роли? Это важный вопрос, который стоит себе задать.
Небольшие коммиты позволяют разработчику передавать описательное сообщение. Прошу прощения, но “исправил кое-какие проблемы” — это не информативное сообщение.
Ваш код гораздо легче поддается отладке, когда ваши коммиты маленькие. Становится легче откатиться к предыдущему коммиту и проверить, когда появился баг. Также благодаря небольшим коммитам влияние этого бага ограничится небольшим участком кода.
Большие коммиты приводят ко многим негативным последствиямй. Бывает сложно с ходу обнаружить баг среди целого ряда внесенных изменений.
То же касается и ревью. Тот, кто его делает, может просто побояться производить слияние, поскольку коммит содержит слишком много всего, что потенциально может нарушить работу кода.
Если вы решили использовать “верблюжий” стиль для переменных, то придерживайтесь его. Хотите использовать пробелы вместо табуляции? Отлично! Что бы вы ни делали в коде, хотя бы делайте это постоянно.
Проблема непостоянства неизбежно возникает с течением времени и постепенно губит софт. Чем дольше существует ПО и чем больше людей над ним работает, тем больше в нем хаоса.
Как же выработать постоянство?
Одна из первых задач — это добыть себе руководство по стилю и придерживаться его. Можно дополнительно использовать линтер для проверки кода на предмет отклонения от стиля.
Второе — это единообразное именование. Имена переменных, методов и классов должны назначаться по одному принципу. Помните, что постоянство оказывает огромное влияние на обслуживаемость вашей кодовой базы.
Мы все не раз слышали: “Я исправлю это позже”. Мы также все прекрасно знаем, как часто это “исправлю позже” в итоге случается. Как правило, никогда. Каждый раз, когда вы видите комментарий “Сделать …”, вы понимаете, что кто-то “отложил на завтра”. Прорабатывайте часть кода или истории пользователя от ноля и до полного завершения. Но как понимать полное завершение?
Для начала это означает, что ваш код прошел рефакторинг. Затем его нужно протестировать. Для большинства разработчиков этот процесс наименее интересен. Однако тестирование — это больше, чем просто прохождение одного успешного сценария. Уделите время проверке других. Помимо этого, вы можете написать автоматизированные тесты.
Остался лишь вопрос с документацией. Нужна ли она какой-то функциональности? Дали ли вы пояснение тестеру о том, как можно её протестировать? Есть ли еще какие-либо предварительные условия, о которых ему стоит сообщить?
Новые технологии внедряются каждодневно, поэтому иногда может быть непросто поспеть за всеми последними трендами. Тем не менее нельзя останавливаться на достигнутом. Остановившись в этом процессе, вы перестанете развиваться.
Изучение нового — это единственный способ продолжать соответствовать нашей постоянно меняющейся технологической эпохе.
“Вы не будете расти, если не будете пытаться совершить что-то за пределами того, что вы уже знаете в совершенстве.” Ральф Уолдо Эмерсон.
Перевод статьи Daan: Programming Habits You Should Adopt
Комментарии