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

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

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

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

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

Примерно так же отслеживается ошибка. Когда я приступал к делу, мне помогала интуиция, чутье на то, что могло вызвать данную ошибку в данной ситуации. В тот раз, к примеру, я думал по меньшей мере сутки. Когда у меня наконец все получилось, я был просто в восторге, и мой сын, которому тогда было, кажется, четыре года, вручил мне «Приз великого отладчика».

Сейбел: Это было, полагаю, на Smalltalk. У вас был символический отладчик или вы смотрели шестнадцатеричные дампы памяти?

Ингаллс:

Это был отладчик более низкого уровня, чем тот прекрасный отладчик Smalltalk. Деталей сейчас не приведу, но если находишь ошибку, она приводит к низкоуровневым отладчикам. То есть смотришь на память как на восьмеричные значения. И потом видишь, что один объект указывает на другой, а этого быть никак не может. И начинаешь думать: «Как такое могло случиться?» Там были закономерности, были догадки по поводу того, что именно могло вызвать ту или иную неполадку, так что на их основе и нужно было работать.

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

Ингаллс: Честно говоря, не знаю никого, кто бы так делал, имея возможность пользоваться хорошим отладчиком. Потому что куда вы помещаете print? Туда-то. А не лучше ли самому быть

там-то и посмотреть все, а не распечатывать? Сейчас я довольно часто применяю отладку с помощью вывода на печать, но это потому, что нередко у меня нет под рукой хорошего отладчика для JavaScript.

Сейбел: Чем так хорош отладчик для Smalltalk?

Ингаллс: Можно остановиться на любом месте программы и посмотреть на все связывания всех переменных. Можно исполнять фрагменты кода и вычислять выражения прямо в контексте.

Сейбел:

В любом месте стекового фрейма?

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

Сейбел: Инварианты — это другой тип инструментов отладки. Многие очень озабочены формальными входными и выходными условиями всех их методов и инвариантами классов. Некоторые относятся к этим вопросам проще. Каково ваше мнение относительно инвариантов?

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

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

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

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

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

Питер Сейбел

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

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

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

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

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

Пит Гудлиф

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

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