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