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

Вам нужно дать своему проекту возможность заговорить. Например, с помощью электронной почты или мгновенного обмена сообщениями. Так вы сможете информировать разработчиков о последних ухудшениях или улучшениях показателей. Но еще более эффективно — материализовать проект в офисе посредством оконечного устройства обратной связи (extreme feedback device, XFD).

Идея XFD состоит в управлении физическим устройством — например лампой, миниатюрным фонтаном, роботом или даже подключенной к USB пусковой ракетной установкой — на основе результатов автоматического анализа. Когда нарушаются допустимые границы, устройство сообщает об этом, изменяя свое состояние. Если это лампа, она загорится, яркая и беспристрастная. Невозможно пропустить это сообщение, даже если вы уже идете к двери, направляясь домой.

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

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

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

Компоновщик не таит в себе никаких чудес Уолтер Брайт

Удручающе часто (со мной это снова случилось как раз перед написанием этого текста) встречается следующий взгляд программистов на процесс превращения исходного кода на компилируемом языке в статически скомпонованный выполняемый модуль:

1. Отредактировать исходный код.

2. Скомпилировать исходный код в объектные файлы.

3. Происходит волшебство.

4. Запустить исполняемый файл.

Шаг 3 — это, конечно, компоновка (linking). Почему же я говорю такие возмутительные вещи? Я занимаюсь технической поддержкой уже не первый десяток лет, и ко мне регулярно приходят с одними и теми же проблемами:

1. Компоновщик сообщает, что def определен более одного раза.

2. Компоновщик сообщает, что символ abc не найден (unresolved).

3. Почему мой исполняемый файл такой большой?

Затем следует вопрос «Что мне теперь делать?» с вкраплениями слов «вроде бы» и «как-то там», и все это в атмосфере полнейшей озадаченности. Эти «вроде бы» и «как-то там» свидетельствуют о том, что процесс компоновки воспринимается как некое волшебство, понятное только колдунам и чародеям. Процесс компиляции не приводит к формулировкам такого рода, то есть программисты в целом понимают, как работают компиляторы или хотя бы в чем их назначение.

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

Итак, допустим, что компоновщик сообщает вам, что def определен более одного раза. Во многих языках программирования, включая C, C++ и D, существуют объявления и определения. Объявления обычно помещаются в файлы заголовков, например:

extern int iii;

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

int iii = 3;

Сколько определений может существовать для каждого символа? Как в фильме «Горец», «в живых останется только один». Что произойдет, если определение iii обнаружится более чем в одном файле реализации?

// Файл a.c

int iii = 3;

// Файл b.c

double iii(int x) { return 3.7; }

Компоновщик сообщит о неоднократном определении iii.

Определение может быть только одно, более того, оно должно быть обязательно. Если iii появляется только в объявлении, но для него нет определения, компоновщик сообщит о том, что символ iii не найден.