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

• Название: Кодеры за работой. Размышления о ремесле программиста
• Автор: Питер Сейбел
• Жанр: Биографии и Мемуары
• Год: 2011
• ISBN: 978-5-93286-188-2

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

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

---

Я понимаю, почему люди в нем разочаровываются. Если вы попытаетесь писать программу на JavaScript так же, как на Java, язык станет кусаться. Я прошел через это. Первое, что я сделал, - это попробовал найти способ имитировать что-то вроде классов Java, но не смог. Я так ничего и не добился.

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

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

Крокфорд: Все сразу. Это способ держать систему целиком в голове. В конце концов, вы должны разделять и властвовать, приведя ее к такому виду, чтобы с ней можно было справиться. Я берусь сразу за все стороны проблемы и пользуюсь одновременно всеми подходами. Я борюсь с системой до тех пор, пока не прояснится ее структура. А остальное придет само.

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

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

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

Крокфорд: Я работаю в небольшом бесплатном текстовом редакторе. Никаких хитрых функций у него нет, да мне ничего и не надо. Здесь не нужно множество формальных инструментов, как для других языков. Броузеру нужен только файл с исходным кодом, который вы ему посылаете, компилятор встроен в броузер, так что делать-то почти ничего и не надо. Не нужно ничего особенного; весь код запускается в броузере.

Сейбел: И, разумеется, вы используете JSLint.

Крокфорд: Да, причем постоянно. Я стараюсь использовать его каждый раз перед запуском программы, то есть если я что-то изменил, то перед запуском прогоняю код через JSLint.

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

Крокфорд: Зависит от броузера. Если это Firefox, использую Firebug, если IE - отладчик Visual Studio. Оба эти инструмента очень хороши. У нас в броузерах есть на удивление хорошие отладчики.

Я использовал фреймворки, в которые были встроены специальные модули на основе DOM-элементов, позволяющие анализировать содержимое объектов. Но потом понял, что это не нужно и отладчика вполне достаточно.

Сейбел: Вы когда-либо выполняете свой код пошагово просто так, не пытаясь выловить конкретную ошибку?

Крокфорд: Только если имею дело с чем-то очень сложным. Я выполняю код пошагово в процессе тестирования, но в основном делаю это, когда есть конкретная проблема.

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

Крокфорд: Мне нравятся эти методики. Я был разочарован тем, что Eiffel не стал победителем среди объектно-ориентированных языков программирования, уступив первое место C++. По-моему, Eiffel был куда интереснее, мне нравилась его система контрактов на основе предусловий/постусловий. Я хотел бы видеть ее встроенной во все языки, с которыми я работаю. К сожалению, это еще одна из тех идей, которая так и не прижилась.

Сейбел: Какова худшая ошибка из тех, что вам пришлось отлавливать?

Крокфорд: Ошибка в реальном времени, например в видеоигре. Постоянные прерывания, натыканные повсюду, полное отсутствие управления памятью - и программа просто внезапно падает, непонятно почему. Справиться с подобными ошибками очень трудно, и на отладчик рассчитывать не приходится.

На Basic Four мы разработали полностраничный терминал для обработки текста, основанный на процессоре Z80 с 64 Кбайт памяти, чего было недостаточно для экрана такого размера. У нас также было подключение к локальной сети, по которой мы посылали страницы на свой сервер.

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

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

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

Одна из вещей, которая мне нравится в модели броузеров, как раз связана с тем, что поток всегда один. Некоторые жалуются на то, что если этот поток будет заблокирован, то заблокируется и весь броузер. Так не допускайте этого! Нас постоянно просят добавить потоки в JavaScript. Пока что нам удается отбиваться, и я очень этому рад.

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

Сейбел: Вас когда-нибудь интересовали формальные доказательства корректности ПО?

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

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

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

Крокфорд: Я скорее стараюсь действовать по обстоятельствам. Это еще один аспект, который я хотел бы изменить в своей работе, но полностью этого еще не сделал.

Сейбел: Речь о JsUnit?

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

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

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

Крокфорд: Я работал в компаниях, где существовало противостояние между командами разработчиков и тестировщиков; по-моему, это нездоровое явление. Там исходили из принципа, что те и другие должны “стучать” друг на друга. Мне кажется, это кошмарная модель.

Гораздо эффективнее, когда две эти команды сидят вместе, и тестеров-щики помогают разработчикам улучшить программу, а не грызутся с ними. Это влияет на способ отчетности, и работа идет куда результативнее. Кроме того, разработчики участвуют в тестировании, так что нельзя сказать, что вы исключительно разработчик или тестировщик.

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