четверг, 31 декабря 2009 г.

Почему я нарушаю правила? И кто может меня остановить?

Очень мне понравился один пост — как раз в тему моим размышлениям о человеческой, и в частности студенческой, лени. Собственно это и есть перевод так понравившегося мне поста. Программирование — довольно формальный процесс. И от увеличения формализма, он, как правило (не всегда), только выигрывает — багрекеры, системы контроля версий, совмещенные багтрекеры и системы контроля версий, системы управления проектами (они-то относятся не только к программистам, но подавляющее большинство примеров управления проектом — программирование или другое IT) и прочая, прочая, прочая. Об этом и не только об этом рассуждения Java-программиста.


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

Разработка через тестирование (TTD)

Я даже не задаюсь таким вопросом - я просто уверен, что лучший способ написания любого куска кода - это написание тестов для функционала этого куска кода и только потом самого кода. Этот подход концентрирует усилия программиста, как никакой другой. При этом, когда Вы начинаете новый проект, Вы переполнены самыми лучшими побуждениями, Вы всегда начинаете с написания тестов. По мере продвижения вглубь и вширь, времени начинает не хватать, Вам приходится чем-то жертвовать — обычно жертвуют тестами. Этому не может быть никаких извинений. Все IDE имеют встроенную поддержку JUnit, и любой опытный программист знает, что этот подход работает. Все, кто думает, что можно опустить тесты в каких-то случаях, просто обязаны прочитать Pragmatic Unit Testing. 1 Автор этой книги прекрасно сказал: "использование юнит-тестов означает, что Вам никогда не придется говорить, как же Вам жаль, что..."

Игнорирование сломанных окон

Один из самых главных уроков, проходящих через всю серию Pragmatic Programmer (Программист-прагматик) - никогда не оставляйте "сломанных окон". Сломанное окно — это кусок плохо написанного кода в Вашем проекте. Если его не исправить сразу — само его присутствие приведет к появлению всё новых и новых сломанных окон. Даже, если я не первый оставляю что-то неработающее в проекте, я виновен ничуть не меньше первопроходца, который не исправил что-то, или по крайней мере не описал это подбровно в баг-трекере. Я даже не знаю, сколько раз, когда я пролистывал файлы какого-нибудь проекта в поисках чего бы исправить, я пропускал строки с такими сломанными окнами.
Опять таки, этому нет никаких оправданий — я знаю об этом правиле, я знаю, что оно очень важное, но часто я слишком занят своими задачами и не обращаю внимания на огрехи других.

Спагетти-код

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

Бросание в код очертя голову

Приходит новый проект. Приходит радостное осознание, что можно будет использовать классные новые технологии для его реализации. А даже если технологии и те же самые, всё равно приятно начать всё с чистого листа. Ни одна из предыдущих трёх ошибок не повторится в этом проекте. Не повторится?
Желание отложить анализ и сразу нырнуть в написание кода свойственно всем программистам. Это естественно, так как мы любим состояние, когда всё хоть как-то работает. Это даже извинительно, если мы очень быстро пробежаться по всему будущему проекту, обнаружить какие-то неизвестные ранее сложности и вернуться к этапу анализа. Но это возвращение часто оказывается проблематичным — у нас ведь уже есть код прототипа, и мы счастилвы - осталось только доработать его. Иногда это называют agile-разработкой, но разве это она?


Решение

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


1. На русском языке можно посоветовать что-нибудь такое, или универсальный совет - "погуглить".
blog comments powered by Disqus