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

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

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

На другом уровне, со стороны Мака, начинаем все с самого начала. Как расположить окно на экране? Затем в какой-то момент приходится прибегать к Xcode. При этом сложнее всего понять, как поднять и заставить работать систему сборки нормальным образом. Приходится экспериментировать, крутить то так, то сяк. Потом думаешь, может поместить этот кусок кода выше, чтобы он обращался вот к этому куску? А может быть, стоит вывернуть это наизнанку? Приходится перетасовывать немало кода, пока в голове не сформируется разумный поток управления. Потом я чищу код, перемещаю его в более подходящие файлы, так чтобы вот этот кусок кода был вместе с вот этим куском.

Это как рисовать жирные стрелки на схеме. Потом я перехожу к следующему скринсеиверу, а он использует другие три функции, которых не было в предыдущем, поэтому мне их тоже нужно реализовать. Каждая из этих задач достаточно проста. Но над некоторыми из них приходится попотеть, потому что в API для X11 есть миллион настроек для отображения текста на экране или для поворота прямоугольника. Постепенно этот кусок кода становится все сложнее. Но большинство задач довольно просты.

Сейбел: Итак, для каждого обращения к X11 вы пишете свою реализацию. А вам никогда не казалось, что у вас набирается куча практически одинакового кода?

Завински: Конечно. После двух-трех раз вырезания и вставки похожего кода думаешь: ага, пора остановиться и поместить этот код в подпрограмму.

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

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

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

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

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

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

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

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

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