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

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

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

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

Завински: Обычно я достаточно хорошо представляю это. Очень мало таких случаев, когда я говорил себе: “Да я же сделал все шиворот-навыворот! Придется все переставить”. Но иногда это происходит.

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

И потом, начав писать код, внезапно понимаешь: “Нет, это глупая идея. И почему я решил, что этот модуль сделать легко, когда на самом деле это гораздо сложнее?” Это такие вещи, которые не понять, пока не начнешь писать код и не почувствуешь, как они от тебя ускользают.

Сейбел: Каковы признаки того, что какие-то вещи от тебя ускользают?

Завински: Когда погружаешься во что-нибудь с мыслью “Так, здесь я за полдня напишу кусок кода такой-то длины”, а потом приступаешь к работе и постепенно начинаешь чуять недоброе: “Ага, нужен еще кусок, надо бы и за него взяться. Да тут работы выше крыши!”

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

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

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

Сейбел: Мы немного говорили об ужасных ошибках, с которыми вы сталкивались, например та история с GNB. Но давайте еще немного поговорим о процессе отладки. Для начала, какие инструменты вы предпочитаете? Инструкции печати отладочной информации? Отладчики исходного кода (symbolic debugger)[13]? Формальные доказательства корректности?

Завински: За последние годы многое изменилось. Когда я работал на Лиспе, процесс отладки заключался в запуске программы, ее остановке и последующем изучении данных. Был специальный инструмент, который позволял копаться в памяти, и я изменил его таким образом, что все эти функции стали доступны через цикл Чтение-Вычисление-Печать (то есть через Lisp Listener). Когда этот инструмент выводил содержимое объекта, появлялось контекстное меню, щелкнув на котором, можно было получить значение этого объекта. Все это упрощало следование по цепочкам объектов и всякое такое. Я уже тогда думал о подобных вещах: погрузиться в середину кода, искать, экспериментировать.