Читаем Кодеры за работой полностью

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

Сейбел: Понятно. А проверяющим нужны какие-то навыки?

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

Сейбел:

Чем отличаются хорошие проверяющие?

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

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

Норвиг: У всех разные умения. Один из лучших наших специалистов по поиску не очень хорошо программирует — код выходит средний. Но, допустим, его спрашиваешь: «Вводится новый фактор — сколько раз человек щелкает на этой странице, сделав то и то. Как учесть его в наших результатах поиска?» И он отвечает: «В строке 427 есть альфа-переменная, возьмите новый фактор, возведите в квадрат, умножьте на 1,5 и прибавьте к переменной». Через несколько месяцев экспериментов с разными подходами выясняется, что он был прав, только умножать надо, скажем, на 1,3.

Сейбел:

Значит, он четко представляет работу программы.

Норвиг: Он прекрасно понимает код. Другие пишут лучше, но он сразу прикидывает все последствия изменений в коде.

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

Норвиг: Да, не исключено.

Сейбел:

Итак, проверки у вас не такие формальные, как в НАСА. Что еще скажете о разнице между культурой «инженеров» и «хакеров», в лучшем смысле обоих слов?

Норвиг: Разница есть в организационной структуре и в отношении к ПО. Google начинался как компания, производящая ПО, и в те времена были наняты исполнительный директор — PhD компьютерных наук из Беркли, вице-президент по продажам — бывший компьютерный инженер, и так строилась вся фирма. А в НАСА все они специалисты по ракетам! Они мало соображают в программах, считая их необходимым злом. «Линейный код я еще понимаю, но вот циклы — это уже подозрительно. А если там еще и условие внутри цикла — о, это уже слишком далеко от того, что я могу решить через дифференциальное уравнение из теории управления!» Там все настроены очень недоверчиво.

Сейбел: Но так и нужно.

Норвиг:

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

Дон Голдин пришел на административную работу в НАСА и сказал: «Лучше, быстрее, дешевле — вот что нам нужно. Запуски обходятся слишком дорого. Лучше делать больше запусков, пусть некоторые будут неудачными, но все равно мы сделаем больше за те же деньги». И поспорить было сложно. К сожалению, политически решение оказалось неверным. Потерять спутник — совсем не здорово, потому что люди запоминают только одно: НАСА потеряла спутник. Разницы между спутником за 100 миллионов и за 1 миллиард они не видят. Так что потерять десять стомиллионных спутников и один миллиардный — разные вещи. Поэтому решение оказалось не совсем верным.

Сейбел: Какова худшая ошибка из всех найденных вами?

Норвиг: С самыми большими ошибками (не моими) я имел дело, когда участвовал в чистке после программных сбоев на Марсе в 1998 году. Первый — из-за того, что вместо ньютонов были указаны футофунты. И второй — преждевременное отключение двигателей из-за сбоя программы, — мы так думали, но без полной уверенности.

Сейбел: Помню один из отчетов по Mars Climate Orbiter — как раз ту историю с футофунтами и ньютонами. Вы там были единственным специалистом по компьютерам. Вы тоже участвовали в разговоре с производителями ПО, выясняя проблему?

Перейти на страницу:

Все книги серии Профессионально

Кодеры за работой
Кодеры за работой

Программисты — люди не очень публичные, многие работают поодиночке или в небольших группах. Причем самая важная и интересная часть их работы никому не видна, потому что происходит у них в голове. Питер Сейбел, писатель-программист, снимает покров таинственности с этой профессии. Он взял интервью у 15 величайших профессионалов: Кена Томпсона, создателя UNIX, Верни Козелла, участника первой реализации сети ARPANET, Дональда Кнута, Гая Стила, Саймона Пейтон-Джонса, Питера Норвига, Джошуа Блоха, Брэда Фицпатрика, создателя Живого Журнала, и других. Все они «подсели» на программирование еще в школе. Тогда, на заре зарождения отрасли, лишь в немногих учебных заведениях читались курсы по компьютерным наукам. Поэтому будущим гуру приходилось покорять профессиональные вершины самостоятельно, но всех их отличает творческое горение и полная самоотдача любимому делу.Вы узнаете, что они думают о будущем программирования и как сами научились программировать, как, по их мнению, нужно проектировать ПО, как выбор языка программирования влияет на продуктивность и можно ли облегчить выявление труднонаходимых ошибок.

Питер Сейбел

Биографии и Мемуары / Программирование / Прочая компьютерная литература / Документальное / Книги по IT
Человеческий фактор
Человеческий фактор

Немногие книги о компьютерах оказали такое заметное влияние на управление разработкой программного обеспечения, как «Человеческий фактор». Уникальное озарение этой книги, долгие годы сохранявшей свое положение в списке бестселлеров: самые сложные проблемы разработки ПО носят не технологический, а социальный характер. Эти человеческие проблемы решать не просто, однако, решив их, вы увеличите шансы на успех до верхнего предела.В третьем издании появилось шесть новых глав и внесены многочисленные правки в основной текст, так что теперь книга лучше соответствует современным средам разработки и современным проблемам. В частности, обсуждаются патологии лидерства, которые раньше за патологии не считались, эволюционирующая культура собраний, а еще растущее понимание того, что некоторые наши инструменты служат скорее якорями, а не двигателями. Каждый, кому необходимо управлять проектом по разработке ПО или целой организацией такого рода, найдет на страницах этой книги множество ценных советов.

Тимоти Листер , Том ДеМарко

Деловая литература
97 этюдов для программистов. Опыт ведущих экспертов
97 этюдов для программистов. Опыт ведущих экспертов

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

Пит Гудлиф

Программирование, программы, базы данных

Похожие книги