Когда я слышу фразу “Работает — не трогай”, мне хочется превратиться в большое зеленое существо и крушить все вокруг! Тот факт, что код работает, еще не значит что он хорош. В идеале, “код работает” — это только первая стадия, черновик, начало работы. Для большинства же, если код выполняет текущую бизнес-задачу — закоммитим и забудем.
Рабочий код написать не так уж сложно — нужно иметь немного мозгов и знать синтаксис языка. Для того, чтобы написать хороший код, нужно приложить куда больше усилий, однако, именно качество кода выделяет профессионалов среди огромного количества обычных кодеров. Под катом несколько субъективных советов о том, как писать хороший код.
Тестирование
Печально, но программисты, и тем более руководители, предвзято относятся к юнит-тестированию, не говоря уже о тестировании интеграционном. В большинстве компаний оно необязательное, на усмотрение программиста. Время на тестирование не выделяется, а какой рефакторинг без тестов? Да и вообще:
Черт возьми, если мы столько платим этим программистам, пусть пишут хороший, не требующий постоянного тестирования код!!! Время им надо еще… На тесты...
К тому же, имеем список вполне обоснованных причин не писать тесты:
Это занимает время.
А времени всегда мало и сроки всегда горят. Поверьте, в итоге, вы только выиграете, если конечно будете писать настоящие тесты, а не для галочки. Дело в том, что имея хорошо написанный тест, вы в любой момент времени уверены, что код работает правильно. Не знаю как для вас, а для меня это бесценное свойство. Я не трачу время на перепроверку кода после его модификации, я запускаю тесты и через несколько секунд я спокоен и готов писать новый функционал, а вы все еще тыкаете на кнопочки?
Мало толковой информации.
И это правда. Большинство статей в интернете по тестированию — это обзор методов фреймворка на примерах функции сложения двух чисел. Есть очень хорошая книга “Искусство автономного тестирования с примерами на С#” (Не стоит бояться C#, я на этом языке никогда не писал, что совсем не мешало мне читать книгу).
Я в состоянии отловить свои баги быстрее, чем напишу тест.
Допустим, хотя обычно тесты пишутся очень быстро. Допустим даже, что вы пишете какой-то небольшой модуль или набор классов и отлично представляете себе всю логику, что позволяет легко вносить изменения. Но я представляю работу вашего модуля только в общих чертах и не хочу углубляться ради небольшого изменения, у меня нет столько времени. Мне нужно понять работу конкретного метода, модифицировать его, и быть уверенным, что ничего не сломалось. Тесты дают мне эту уверенность.
Чистый код.
Код должен быть понятным. Я должен посмотреть в листинг и прочитать алгоритм метода без каких-либо проблем. Назначение каждой переменной и функции должно быть ясно из названия. Методы должны быть короткими и …
кажется я начал пересказывать “Чистый код” Роберта Мартина чуть ли не слово в слово. Прочитайте эту книгу, если еще не читали, а если читали — перечитайте.
Потратьте немного времени на архитектуру. Может стоит использовать какой-то известный паттерн, прежде чем изобретать велосипед? Может можно разбить логику на составляющие, а не писать полотном метод на 150 строк? Наверняка вот эти условия будут изменяться. Давайте вынесем их реализацию, тогда при модификации будет затронуто минимальное количество кода. Или черт с ним, напишем как быстрее, потом кто-нибудь другой будет разбираться! Твори бардак, мы здесь проездом!
Дело в том, что вы можете написать код, который будет вам понятен. Более того, вы можете написать код, который будет понятен вам через пол года после создания, но этого мало. Ваш код должен быть понятен не только вам, но и всем остальным. Ваш код должен быть понятен мне, когда я его посмотрю. Если я решу его доработать, а вас не будет рядом — я не должен терять время на осознание кода, я не должен смотреть на него вашими глазами и прикидывать, что творится у вас в голове. Не пишите код для себя! Пишите код, который сможет понять любой программист.
Пусть VCS помнит
Трудно найти проект, над котором работают без системы контроля версий. Все к ним давно привыкли, но тем не менее многие продолжают мыслить понятиями XX века. Все помнят такие комменты в начале файлов?
////////////////////////////////////////////////////////////////
// CowInvert.php
// author Vasiliy Pupkin
// 20.12.2004
//
// Changelog:
// 22.12.2004: Добавил функционал инвертирования коров
// 23.12.2004: Исправил баг с коровами в нестандартной цветовой гамме
// …
Я до сих пор часто встречаю такие вот истории изменений и практически постоянно встречаю название файла информацию об авторе, и дату создания.
В любой системе контроля версий вы сможете без труда узнать кто и когда создал файл, даже больше того, кто и когда написал/изменил конкретную строчку файла. А такие комменты только портят качество вашего кода. Они не нужны.
Также, я постоянно вижу эти ужасные огромные куски закомментированного кода. По принципу “Авось пригодится”. Не пригодится, это мертвый код. Как только вы закоментировали код — вы его убили. Если вы захотите его воскресить — больше времени потратите на определение его актуальности, чем на написание нового. Можете смело его удалять, а если что, он останется там где ему и место, в истории VCS.
И еще на заметку: никто не читает закоментированный код.
Вывод
Чистый и понятный код, наличие тестов и отсутствие кусков закомментированного кода — вот, пожалуй, топ три моих признаков профессионального программиста. Это не значит, что все остальные ламмеры и нубы. Если пройтись по моим проектам, можно найти огромное количество кода, требующего рефакторинга, а про процент покрытия тестами — я вообще промолчу. Однако, я этот процент знаю, он для меня важен, и я пытаюсь его улучшать. И меня очень огорчают многие коллеги, которые программируют по принципу “Ну главное вроде работает, когда будут проблемы — тогда и будем думать”.
Автор:
