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

Работая над своей первой большой программой, системой разделения времени для PDP-1, я был рядовым программистом, решающим проблемы на уровне выпускника колледжа. После этого, в больничном проекте, я быстро прошел все стадии от написания приложений до уровня системного программирования. Имея полугодичный стаж работы, я уже мог уверенно сказать: «Вот этот кусочек своппинга удаленного процесса выглядит неправильно, и я должен его переписать».

Сейбел: Кроме опасности добавления новых ошибок есть еще одна — можно неправильно понять, что программа должна делать.

Козелл: Да, действительно. Надо сказать, что свой путь я избрал когда-то не из малодушия. Когда мне было 19, такое поведение казалось мне единственно возможным. У меня было два отлично служивших мне убеждения: одно говорило, что в программе должен быть смысл, другое — что по-настоящему сложных задач очень и очень мало. Если программа выглядит слишком сложной, то, скорее всего, это значит, что ее автор не вполне понял свою задачу и после долгих мучений получил результат, который только выглядит приемлемым.

Не знаю, с чего это я взял. Я пришел в BBN фактически неопытным новичком, не имея необходимых навыков, но почему-то твердо держался за эти две идеи. Я верил, что могу разобраться во всем и что для меня нет ничего невозможного. И выяснилось, что даже для программ такого уровня, как система разделения времени и система IMP, это работает. Обычно, как только я разбирался, для чего нужна программа, остальные кусочки головоломки сами вставали на место. Ненужная информация просто оставалась за бортом, как детали не того цвета в пазле.

Другой мой принцип состоял в том, что код всегда должен быть ясным и понятным. Я хотел, чтобы все было на своем месте. Исправляя баг в программе, я никогда не исправлял только ту ее часть, где он находился. Правило такое: «Если бы ты знал раньше то, что знаешь сейчас об этом участке кода — а именно то, что тут ошибка, — как бы ты тогда написал его?» Почему ты тогда допустил ошибку? Исправь код так, чтобы это больше не повторилось. Когда ты закончишь, каждый переписанный тобой участок должен выглядеть как новый, только что написанный. Я не хочу видеть признаки исправлений или следы ошибок, или загадочные участки кода, говорящие: «Эта подпрограмма каждый раз выдавала неверные значения, и поэтому я должен был ее исправить». Я не хочу видеть ничего из этого, а хочу видеть код, написанный так, будто озарение снизошло на тебя с самого начала.

Плюс к этому у меня есть еще один трюк. Я научился ему, когда работал над проектами министерства обороны. Они никогда не финансируют новые проекты. И правительство, и BBN уже вложили слишком много в текущий проект, хотя, возможно, он ужасен и его надо исправлять. Назначение программы, требования к ней или что-то еще стало другим — и вот то, что ты на первых этапах сделал совершенно правильно, теперь, в новых условиях, лучше будет переделать. Ты к этому готов, но начальство спрашивает: а зачем нужны исправления? Там какая-то ошибка? Никакой ошибки, отвечаешь ты, просто это сделает программу лучше. Будь уверен, что разрешения ты не получишь.

Мне пришлось придумать довольно хитрый метод борьбы с такими ситуациями, который ни разу меня не подводил. Суть его в том, чтобы всегда продумывать заранее будущую версию программы. Через какое-то время понимаешь, что именно так программа и должна выглядеть — на уровне общей структуры, а не подпрограмм. Теперь, когда исправляешь ошибки, исправляй их так, чтобы приближать программу к этому будущему образу. Не иди кратчайшим путем. Вместо этого развивай программу так, чтобы несколько месяцев спустя она представляла собой не устаревшую основу, пестрящую заплатками, а реализацию нового подхода к ее написанию. Обычно в какой-то момент в программе остается всего несколько мест, работающих по старому принципу, так что ты можешь спокойно заменить их, не причиняя вред программе в целом.

Так что на вопрос «Сколько времени потребуется, чтобы внести изменения?» есть три ответа. Первый — это кратчайший путь, когда заменяешь одну строку кода. Второй путь основан на моем простом правиле: перепиши кусок так, как будто ты с самого начала не собирался ошибаться. Третий же и самый длинный путь — это переписать кусок так, будто пишешь его для уже усовершенствованной программы. Ищешь разумную середину между вторым и третьим вариантами и в результате получаешь дополнительное время для совершенствования программы. Думаю, это очень важно. Так программа может развиваться постепенно. Здорово, конечно, иметь дело с программой, которая всегда остается в одной и той же самой первой версии, но это как жить в каменном веке. Зато в моем варианте мы в итоге получаем новенькую с иголочки программу, причем без разрешения менеджера проекта на эти работы.

Сейбел: Вы когда-нибудь слышали о рефакторинге?

Козелл: Нет, а что это?

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