миниатюрным фонтаном, роботом или даже подключенной к 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 не найден.

Чтобы выяснить, почему у исполняемого модуля такой размер, взгляните на файл карты (map), который компоновщик может вывести по запросу. Этот файл содержит перечень всех символов в исполняемом модуле с их адресами. Из него вы узнаете, какие модули были взяты из библиотек и их размеры. Теперь станет ясно, почему так раздулась ваша программа. Часто обнаруживаются библиотечные модули, о подключении которых вы и не догадывались. Чтобы разобраться, временно удалите подозрительный модуль из библиотеки и повторите компоновку заново. Ошибка «неопределенный символ» поможет узнать, кто обращается к этому модулю.

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

Долговечность временных решений

Клаус Маркардт

Почему мы создаем временные решения?

Обычно виной тому срочная задача. Бывает, что это внутренняя задача разработчиков — создать недостающий инструмент для цепи разработки. Бывает, что задача внешняя, ориентированная на пользователей, например обходной путь для восполнения отсутствующей функциональности.

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

Однако промежуточные решения обладают инертностью (или моментом инерции, если вам так больше нравится). Временное решение уже есть — крайне полезное и всеми принятое, — так что нет острой необходимости создавать что-то взамен. Решая, какие действия более других повысят ценность продукта, заинтересованный участник проекта найдет множество задач, приоритет которых будет выше, чем доведение до ума временного решения. Почему? Потому что временное решение уже есть, оно работает, и оно принято. Единственный его видимый недостаток — оно не соответствует выбранным стандартам и правилам, но, за исключением некоторых нишевых продуктов, это слабый аргумент в пользу изменений.

Вот так и остается временное решение. Навсегда.

А если временное решение станет источником проблем, маловероятно, что при починке будет также поставлена задача привести его в соответствие с принятыми стандартами качества. Что же делать? Быстрое промежуточное изменение временного решения часто устраняет проблему и всех устраивает. У него те же достоинства, что и у первоначального временного решения, просто оно… новее.

Представляет ли это проблему?

Все