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

Сейбел:Пока грамматика не меняется, все в порядке.

Норвиг:Да, так что мы поставили программу, заказчики были счастливы, а потом, разумеется, грамматика изменилась. У нас больше не было доступа к машинам с UNIX. Мне пришлось править грамматику, роясь в таблицах, и я решил: если вот здесь у нас переход в новое состояние, я создам свое состояние, и переход будет к нему.

Сейбел:Это было правильное решение? Вы не думали о том, чтобы просто написать новый парсер?

Норвиг:Наверное, так и надо было поступить. Но ведь я сделал лишь одну небольшую правку.

Сейбел:А не получилось так, что им каждые три недели приходилось сталкиваться с очередным изменением в грамматике?

Норвиг:Я тогда уже ушел в магистратуру, и это уже была не моя проблема.

Сейбел:Уже не ваша... Итак, вы защитили диссертацию. Вы бы хотели, чтобы ваше обучение программированию шло по-другому?

Норвиг:В конце концов я занялся промышленной разработкой ПО. Возможно, стоило заняться этим раньше. Постепенно я всему научился, но много времени провел в колледже и магистратуре. Правда, мне нравилось, так что ни о чем не жалею.

Сейбел:А чему вам пришлось учиться, если говорить о промышленной разработке ПО?

Норвиг:Планировать работу и делать так, чтобы довольны были все - разработчики, клиенты, менеджеры. В магистратуре ведь все это не нужно - просто приходи к своему руководителю время от времени.

Важнейший шаг - переход от индивидуальной работы к командной: начинаешь понимать, как люди взаимодействуют друг с другом. Этому тоже не учат в колледже. Сейчас в некоторых колледжах обратили на это внимание, но в мои времена к командной работе относились плохо - считали ее жульничеством.

Сейбел:Какие навыки, кроме умения писать код, нужны тем, кто приходит в индустрию ПО?

Норвиг:Надо уметь уживаться с другими. Уметь понимать заказчика: знать, что именно ты создаешь и правильным ли путем идешь. Уметь взаимодействовать с клиентами и со своими коллегами. Уметь взаимодействовать с клиентом и своим начальством в одно и то же время. Это все разные социальные отношения, требующие разных навыков.

Сейбел:Программирование стало более социальным?

Норвиг:Думаю, да. Компьютерщики были больше обособлены от всех остальных. Раньше в основном шла пакетная обработка, интерфейсы были куда проще. Можно было работать по модели “водопада”: ввод - колода карт, вывод - отчет с таким-то номером в такой-то колонке.

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

Сейбел:А были особенно памятные случаи, которые подчеркивают разницу между одиночной и командной работой?

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

Сейбел:Освоение командного подхода позволяет самому браться за вещи большего размера, чем раньше? Вы как бы сам себе команда, только растянутая во времени?

Норвиг:Это так. И я наблюдаю это у молодых программистов. Еще одна разница между “тогда” и “сейчас”: программирование больше похоже на сборку из готовых модулей, чем на создание чего-то с нуля. Сейчас, делая домашнее задание - скажем, сайт, - школьник возьмет для одной части Ruby on Rails, для другой - Drupal, для третьей - скрипт на Python, а потом скачает статистическую программу. И все это связывается между собой с помощью скриптов, а не пишется с нуля. Сегодня важнее понимать интерфейсы и уметь их соединять, чем знать в деталях, что делается внутри ПО.

Сейбел:Значит ли это, что успешный программист сегодня — человек другого склада?

Норвиг:Успешные люди, по-моему, не изменились, насколько я вижу. Но в целом - да, в наши дни лучше уметь быстро понять, что тебе нужно, чем досконально знать все процессы. Тут, конечно, есть этакая бравада: “Я просто беру и делаю это”. Человек смело признается: “Я не понимаю, что тут внутри, но я залез в документацию и нашел там эти три штуки. Попробовал - работает. Значит, вперед”.

Да, такой подход приносит свои плоды, но мне кажется, только за счет этого не станешь хорошим программистом. Надо знать немного больше. Безопасно ли то, что я делаю? В каких случаях это сломается? Попробовал один раз, работает - хорошо, но это должно работать всегда. Как написать тесты, чтобы проверить программу и самому лучше разобраться в ней? А когда они написаны, не взять ли мне то, что я сделал, и не опубликовать ли новый инструмент, чтобы другие им тоже пользовались?

Сейбел:Какие у вас были предпочтения в плане командной работы? Взять задачу и разделить ее между программистами? Или везде применять парное программирование с коллективным владением кодом?

Норвиг:Скорее первое. Стив Йегг написал статью “Good Agile, Bad Agile” (Agile-проектирование: хорошее и плохое), и думаю, в ней он прав. Десять процентов времени имеет смысл уделять коллективной работе, поскольку программисту необходимы понимающие слушатели. Больше - вряд ли стоит.

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

Иногда полезно собираться вместе для мозгового штурма, когда надо определить и задачу, и средства ее решения. Вы даже не знаете, что за продукт вам нужен, и об этом стоит подумать совместно. Затем вы определяетесь с задачей, и надо решить, как разбить ее на части. Но вот после этого, когда идея пришла, лучше работать по отдельности. Нужна обратная связь, нужен другой человек, который внимательно просмотрит ваш код, - но только не в режиме реального времени, не в процессе написания.

Помнится, у IBM была модель “программиста-мастера” - глупее никто еще ничего не придумал. Кто захочет быть на побегушках у опытного программиста?

Сейбел:Удивительно, что вы считаете эту идею настолько глупой. В своей статье “Teach Yourself Programming in Ten Years” (Как самому научиться программировать за десять лет) вы утверждаете, что программирование - навык, который, как и многие другие, требует десятилетнего оттачивания, чтобы человек стал мастером. Во многих ремеслах работает модель мастер/подмастерье/ученик. Может, никому не нравится быть учеником, но что ужасного в том, что человек с десятилетним опытом будет выполнять другую работу, нежели желторотый новичок?