Кодеры за работой. Размышления о ремесле программиста

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

Сейбел: Значит, вы против предварительного объявления ?

Крокфорд: Да, против. Или, по крайней мере, предварительное объявление должно быть явным. Я против того, чтобы код располагался в произвольном порядке, кроме случаев литературного программирования (literate programming), когда я изменяю порядок кода для его наглядности, отказываясь от привязки к требованиям языка, - и мне это очень нравится. Но без специальных инструментов лучше это не делать.

Сейбел: В одном из интервью вы цитировали Исход, 23:10-11: “Шесть лет засевай землю твою и собирай произведения ее, а в седьмой оставляй ее в покое”, - утверждая, что каждый седьмой цикл следует посвятить чистке кода. Какой разумный временной промежуток вы имели в виду?

Крокфорд: Шесть циклов - это циклы между выпусками чего-либо. Если вы выпускаете новую версию ежемесячно, то каждые полгода следует пропускать один цикл выпуска, посвятив это время чистке кода.

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

Крокфорд: Обычно команда знает, когда пора этим заняться. Руководитель проекта понимает это гораздо позже. Работа замедляется, ошибок становится слишком много, код становится слишком большим и медленным, команда не укладывается в сроки. И все знают, почему. Не потому, что все внезапно поглупели или обленились, а потому, что кодовая база больше не отвечает своим задачам.

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

Ошибочно считать, что во второй раз будет затрачено столько же времени, сколько и в первый раз, хотя есть и противоположные примеры. Это так называемая проблема второй системы: когда те, кто уже чего-то достиг, получают задание начать все с чистого листа и делать то, что считают нужным. Обычно это ведет к провалу, поскольку люди становятся слишком амбициозными в своих целях и не видят границ. В результате вы не получаете ничего. Нужна невероятная дисциплина, чтобы можно было сказать: “Нет, мы не начинаем с чистого листа, а заново реализуем то, что уже сделали ранее; давайте делать то, что мы уже знаем”.

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

Сейбел: Под “классической” методикой вы подразумеваете применение классов?

Крокфорд: Да. Мне кажется, что в мире прототипирования проблем гораздо меньше, поскольку там делается акцент на экземплярах. Найдешь экземпляр, типичный с точки зрения решаемой задачи, и готово. В таком случае решение не приходится адаптировать. Но в классических системах это невозможно - там всегда идешь от абстракций к экземплярам. И очень непросто создать правильную иерархию. Так что зачастую приходится возвращаться и перерабатывать свое решение, когда в конце концов лучше поймешь проблему. Но это может серьезно повлиять на код, особенно если он разросся по сравнению с первоначальной концепцией. Поэтому не делаешь ничего серьезного, пытаясь прикрутить что-то новое поверх уже существующей иерархии, и все еще больше запутывается и ухудшается.

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

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