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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Норвиг: Отчасти да, есть. Лучший, наверное, пример — проверка моделей, которой Intel не уделила достаточно внимания, и на отзыве ПО из-за найденной ошибки в умножении они потеряли много денег. Тогда они всполошились и пошли на поклон к ученым. Теперь проверка моделей обязательно входит во все их программы. Другой пример, пожалуй, чуть менее яркий - языки программирования. В этой сфере идет напряженная работа, но она мало отражается на новых языках. Операционные системы, в какой-то мере. Мы финансируем лабораторию RAD в Беркли с Дэйвом Паттерсоном и другими. У них есть хорошие идеи относительно надежности систем. Но это тот случай, когда у индустрии есть куда более серьезные проблемы. Не каждую из них удается решить, но поиски здесь идут более интенсивно, чем в университетах.

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

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