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

Сейбел Питер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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