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