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

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

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

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

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

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

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

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

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

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