Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста
- Название:Кодеры за работой. Размышления о ремесле программиста
- Автор:
- Жанр:
- Издательство:Символ-Плюс
- Год:2011
- Город:Санкт-Петербург
- ISBN:978-5-93286-188-2
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста краткое содержание
Программисты - люди не очень публичные, многие работают поодиночке или в небольших группах. Причем самая важная и интересная часть их работы никому не видна, потому что происходит у них в голове. Питер Сейбел, писатель-программист, снимает покров таинственности с этой профессии. Он взял интервью у 15 величайших профессионалов: Кена Томпсона, создателя UNIX, Верни Козелла, участника первой реализации сети ARPANET, Дональда Кнута, Гая Стила, Саймона Пейтон-Джонса, Питера Норвига, Джошуа Блоха, Брэда Фицпатрика, создателя Живого Журнала, и других. Все они “подсели” на программирование еще в школе. Тогда, на заре зарождения отрасли, лишь в немногих учебных заведениях читались курсы по компьютерным наукам. Поэтому будущим гуру приходилось покорять профессиональные вершины самостоятельно, но всех их отличает творческое горение и полная самоотдача любимому делу.
Вы узнаете, что они думают о будущем программирования и как сами научились программировать, как, по их мнению, нужно проектировать ПО, как выбор языка программирования влияет на продуктивность и можно ли облегчить выявление труднонаходимых ошибок.
Кодеры за работой. Размышления о ремесле программиста - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
По-моему, худшие ошибки - это ошибки, происходящие в реальном времени при взаимодействии нескольких потоков. Мой подход к исправлению таких ошибок: постараться их избегать. Поэтому я не люблю мно-гопоточность - я считаю, что это жуткая модель программирования. Можно допустить ее как необходимое зло, но в большинстве случаев без многопоточности можно обойтись.
Одна из вещей, которая мне нравится в модели броузеров, как раз связана с тем, что поток всегда один. Некоторые жалуются на то, что если этот поток будет заблокирован, то заблокируется и весь броузер. Так не допускайте этого! Нас постоянно просят добавить потоки в JavaScript. Пока что нам удается отбиваться, и я очень этому рад.
Событийно-ориентированная модель - та, что применяется в броузере, - работает отлично. Она плохо работает только в том случае, если у вас появляется процесс, который требует много времени. Мне нравится, как Google решил эту проблему в Gears: они используют отдельный процесс, полностью изолированный от остальных, которому можно послать программу для выполнения. По окончании выполнения этот процесс сообщит о результате, и этот результат будет возвращен в качестве события. Просто блестящая модель.
Сейбел:Вас когда-нибудь интересовали формальные доказательства корректности ПО?
Крокфорд: В 1970-е я следил за ними с интересом, ожидая, чем все это закончится. Но особого результата так и не увидел. Программное обеспечение - сложная штука, и что-то может пойти не так по разным причинам.
Программное обеспечение - это прежде всего спецификация того, как программа должна работать. И ничто, кроме полной спецификации, не объяснит вам, каким должно быть поведение в конечном итоге. Именно это делает разработку программного обеспечения настолько сложным.
Сейбел:Как вы тестируете код? Вы заражены тестированием, как сейчас говорят?
Крокфорд:Я скорее стараюсь действовать по обстоятельствам. Это еще один аспект, который я хотел бы изменить в своей работе, но полностью этого еще не сделал.
Сейбел:Речь о JsUnit?
Крокфорд:Да. Тестирование кода пользовательского интерфейса - непростое дело, поскольку он зависит от множества других вещей, так что разбивать его на модульные тесты не слишком эффективно. Кроме того, я заметил, что тот стиль разработки, который я применяю в работе с JavaScript, не разбивает системы на модули, как это делается при создании классов и последующего их тестирования изолированно друг от друга.
В JavaScript тестировать отдельную функцию не слишком разумно, поскольку для ее работы требуется некоторое состояние. Так что я пока не нашел разумный подход к модульному тестированию в JavaScript.
Сейбел:Если в компании есть отдельная группа тестировщиков, то как она должна взаимодействовать с командой разработчиков?
Крокфорд:Я работал в компаниях, где существовало противостояние между командами разработчиков и тестировщиков; по-моему, это нездоровое явление. Там исходили из принципа, что те и другие должны “стучать” друг на друга. Мне кажется, это кошмарная модель.
Гораздо эффективнее, когда две эти команды сидят вместе, и тестеров-щики помогают разработчикам улучшить программу, а не грызутся с ними. Это влияет на способ отчетности, и работа идет куда результативнее. Кроме того, разработчики участвуют в тестировании, так что нельзя сказать, что вы исключительно разработчик или тестировщик.
Но эффективнее всего, как я считаю, устроить тестирование у клиента. В начале карьеры программиста мне приходилось заниматься этим - бесценный опыт! Вы живете с клиентом целую неделю, помогаете ему установить новую систему и решать с ее помощью задачи.
Это дало мне возможность взглянуть изнутри на то, как используются наши программы, и понять, что можно сделать для облегчения их использования. Разработчики, не имевшие подобного опыта, всегда казались мне непростительно высокомерными. Поразительное неуважение к людям, которые пользуются нашим продуктом! А все потому, что они этих людей попросту не видели.
Сейбел:Кем вы себя считаете - ученым, инженером, художником, ремесленником или кем-нибудь еще?
Крокфорд:Скорее писателем. Иногда я пишу на английском, иногда на JavaScript.
В конце концов все сводится к коммуникациям и к структуре, призванной их облегчить. Естественные и компьютерные языки функционируют во многом по-разному, но в конечном счете я сужу о компьютерной программе по ее способности взаимодействовать с человеком, читающим эту программу. В этом смысле различий нет.
Сейбел:И если программа хорошо взаимодействует с человеком, то в части ее взаимодействия с компьютером проблемы почти отпадают?
Крокфорд:Можно надеяться. Компьютер капризен и не слишком умен, поэтому нужно приложить дополнительные усилия, чтобы он понял все правильно. Поскольку это так сложно, легко упустить из виду другую часть, не менее важную, с моей точки зрения.
Сейбел:У Дейкстры есть известная статья “On the cruelty of really teaching computing science” (О сложности практического обучения компьютерной науке), где утверждается, что программирование - ветвь прикладной математики. Вы согласны с этим?
Крокфорд:Математика важна для программиста, но это лишь одна из множества других важных вещей. Мне кажется, что преувеличение значения математики может привести к недооценке значения чего-то другого, возможно, более важного, например грамотности.
Как я уже говорил, мне хотелось, чтобы одним из требований при приеме на работу было знакомство с книгами Кнута, и я от него отказался, поскольку не мог найти достаточного количества людей, отвечающих этому требованию. Другое качество, которого я требовал от кандидатов, - нормальная грамотность в том языке, на котором они общаются с другими людьми. Я хотел, чтобы люди умели писать, ведь мы тратим очень много времени на переписку друг с другом: мы пишем электронные письма или документацию, планы, спецификации. Я хотел, чтобы все члены моей команды могли делать это, но оказалось, что это очень редкий навык. Поэтому сейчас я предпочитаю кандидатов с дипломом по английскому языку, а не по математике.
Сейбел:Кажется, у Дейкстры есть примерно такое утверждение: “Если не можешь писать на своем родном языке, лучше не берись за программирование”.
Крокфорд:Совершенно согласен.
Сейбел:Сейчас мы все чаще сталкиваемся вот с чем: программирование, освобождаясь от физических ограничений, становится все больше зависимым от исторических случайностей. Многие ваши предложения по выделению некоторого подмножества языка JavaScript и ваша версия HTML5 кажутся попытками исправить эти исторические случайности.
Читать дальшеИнтервал:
Закладка: