Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста
Читая программу, я одновременно думаю, как бы я решил связанную с ней задачу. То есть ищу те места, в которых смогу сказать: “О, вот тут программа делает то-то”. Нередко после этого я со свойственной мне самоуверенностью могу сказать, что автор написал эту часть неправильно. Или, по крайней мере, понимаю, что было сделано не так, как сделал бы я.
Итак, я двигаюсь от общего к частному. Но я знал и тех, кто поступал наоборот, добиваясь отличных результатов. Они начинали читать мелкие подпрограммы и наконец находили среди них нужную. Но я, повторюсь, делал иначе. А именно, смотрел на программу и стремился понять, что ее авторы хотели сделать. Зачастую это позволяло исправлять ошибки, даже не понимая, какие именно ошибки я исправляю. Я доходил до определенного места и говорил себе: “Этот участок кода - как я сейчас понимаю - должен делать то-то”; и после этого выяснялось, что либо он этого не делает, либо слишком запутан и дополнительно нагружен другими задачами.
В обоих случаях нормальная реакция - исправить этот участок кода в соответствии со своими представлениями о том, как он должен работать в программе. Очевидно, что это опасная затея, потому что всегда есть много способов организовать работу программы, и мой выбор может не совпадать с выбором автора. В итоге я рискую разрушить структуру программы и похоронить себя под лавиной багов. Но мне необычайно везло. Обычно, когда я говорил: “Тут ошибка и я ее исправлю”, - мне действительно это удавалось. Причем с самого начала моей карьеры.
Работая над своей первой большой программой, системой разделения времени для PDP-1, я был рядовым программистом, решающим проблемы на уровне выпускника колледжа. После этого, в больничном проекте, я быстро прошел все стадии от написания приложений до уровня системного программирования. Имея полугодичный стаж работы, я уже мог уверенно сказать: “Вот этот кусочек своппинга удаленного процесса выглядит неправильно, и я должен его переписать”.
Сейбел: Кроме опасности добавления новых ошибок есть еще одна - можно неправильно понять, что программа должна делать.
Козелл: Да, действительно. Надо сказать, что свой путь я избрал когда-то не из малодушия. Когда мне было 19, такое поведение казалось мне единственно возможным. У меня было два отлично служивших мне убеждения: одно говорило, что в программе должен быть смысл, другое - что по-настоящему сложных задач очень и очень мало. Если программа выглядит слишком сложной, то, скорее всего, это значит, что ее автор не вполне понял свою задачу и после долгих мучений получил результат, который только выглядит приемлемым.
Не знаю, с чего это я взял. Я пришел в BBN фактически неопытным новичком, не имея необходимых навыков, но почему-то твердо держался за эти две идеи. Я верил, что могу разобраться во всем и что для меня нет ничего невозможного. И выяснилось, что даже для программ такого уровня, как система разделения времени и система IMP, это работает. Обычно, как только я разбирался, для чего нужна программа, остальные кусочки головоломки сами вставали на место. Ненужная информация просто оставалась за бортом, как детали не того цвета в пазле.
Другой мой принцип состоял в том, что код всегда должен быть ясным и понятным. Я хотел, чтобы все было на своем месте. Исправляя баг в программе, я никогда не исправлял только ту ее часть, где он находился. Правило такое: “Если бы ты знал раньше то, что знаешь сейчас об этом участке кода — а именно то, что тут ошибка, — как бы ты тогда написал его?” Почему ты тогда допустил ошибку? Исправь код так, чтобы это больше не повторилось. Когда ты закончишь, каждый переписанный тобой участок должен выглядеть как новый, только что написанный. Я не хочу видеть признаки исправлений или следы ошибок, или загадочные участки кода, говорящие: “Эта подпрограмма каждый раз выдавала неверные значения, и поэтому я должен был ее исправить”. Я не хочу видеть ничего из этого, а хочу видеть код, написанный так, будто озарение снизошло на тебя с самого начала.
Плюс к этому у меня есть еще один трюк. Я научился ему, когда работал над проектами министерства обороны. Они никогда не финансируют новые проекты. И правительство, и BBN уже вложили слишком много в текущий проект, хотя, возможно, он ужасен и его надо исправлять. Назначение программы, требования к ней или что-то еще стало другим - и вот то, что ты на первых этапах сделал совершенно правильно, теперь, в новых условиях, лучше будет переделать. Ты к этому готов, но начальство спрашивает: а зачем нужны исправления? Там какая-то ошибка? Никакой ошибки, отвечаешь ты, просто это сделает программу лучше. Будь уверен, что разрешения ты не получишь.
Мне пришлось придумать довольно хитрый метод борьбы с такими ситуациями, который ни разу меня не подводил. Суть его в том, чтобы всегда продумывать заранее будущую версию программы. Через какое-то время понимаешь, что именно так программа и должна выглядеть - на уровне общей структуры, а не подпрограмм. Теперь, когда исправляешь ошибки, исправляй их так, чтобы приближать программу к этому будущему образу. Не иди кратчайшим путем. Вместо этого развивай программу так, чтобы несколько месяцев спустя она представляла собой не устаревшую основу, пестрящую заплатками, а реализацию нового подхода к ее написанию. Обычно в какой-то момент в программе остается всего несколько мест, работающих по старому принципу, так что ты можешь спокойно заменить их, не причиняя вред программе в целом.
Так что на вопрос “Сколько времени потребуется, чтобы внести изменения?” есть три ответа. Первый - это кратчайший путь, когда заменяешь одну строку кода. Второй путь основан на моем простом правиле: перепиши кусок так, как будто ты с самого начала не собирался ошибаться. Третий же и самый длинный путь - это переписать кусок так, будто пишешь его для уже усовершенствованной программы. Ищешь разумную середину между вторым и третьим вариантами и в результате получаешь дополнительное время для совершенствования программы. Думаю, это очень важно. Так программа может развиваться постепенно. Здорово, конечно, иметь дело с программой, которая всегда остается в одной и той же самой первой версии, но это как жить в каменном веке. Зато в моем варианте мы в итоге получаем новенькую с иголочки программу, причем без разрешения менеджера проекта на эти работы.
Сейбел: Вы когда-нибудь слышали о рефакторинге?
Козелл: Нет, а что это?
Сейбел: Как раз то, что вы сейчас описали. Думаю, сейчас такой подход получил большую популярность даже среди менеджеров проектов.
Козелл: О, это замечательно, потому что мне всегда нужен был баг в качестве предлога для изменения какой-либо части программы. Получить разрешение на доработку, если все в порядке, было нереально. Так что приходилось ждать, пока будет обнаружена ошибка или сверху придет запрос на внесение изменений, затрагивающих именно эту часть кода, и тогда можно было улучшить программу легально. Думаю, в рефакторинге главное - правильно понять, к какой цели нужно двигаться. Если люди, придерживающиеся разных точек зрения на этот вопрос, будут одновременно вносить в программу изменения, ничего хорошего не получится.
