Alan Carter - The Programmers' Stone (Программистский камень)

Эти идеи определения и исполнения автоматизированных тестов особенно важны для очень сложных проектов, где динамическое управление конфигурацией и средства инкрементной компиляции из научно-фантастических книг позволяют сотням разработчиков работать как проклятым мартышкам на кокаине без сна и отдыха. (Сказанное -- авторская риторика).

Контрольные проверки и прогон автоматизированных тестов снизу доверху не следует рассматривать как помеху в работе -- это очень дешевый путь получения подтверждения прочности фундамента. Как дополнительное преимущество, такие события становятся праздниками команды, по мере того как модуль за модулем, уровень за уровнем говорят об успешной компиляции и прохождении теста на рабочей станции менеджера. На таких праздниках команда может естественным образом взглянуть на все, чего они достигли к этому моменту, поскольку самый первый праздник может состоять просто в компиляции и запуске программы `Hello, world!' и доказательстве, что компилятор работает правильно, а последний дает в результате работающий продукт, который поставляется заказчику и в котором достигнуты все цели.

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

Тот же подход применим и к временным зонам. Ваши пользователи могут прекрасно работать по всему миру и желать использовать местное время, но ваша сеть повсеместно должна использовать гринвичское время (GMT, или UTC), и все даты и времена файлов должны проставляться соответственно. Проблемы упорядочивания по дате файлов, созданных на компьютерах с по-разному установленными часами, поглощают у программистов много часов. Однажды менеджер международной сети пошла в магазин и купила сорок отвратительных, в стиле 50-х годов, одинаковых часов и коробку батареек. Весь следующий год, при посещении очередного удаленного офиса, она устанавливала на часах правильное время по Гринвичу (GMT) и вешала их на стену. В конце того года постоянные проблемы, связанные с трудностями упорядочения файлов, магически исчезли, поскольку у каждого оператора перед глазами было огромных размеров напоминание, какое время нужно установить на системных часах при перезагрузке.

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

Трудности, ассоциирующиеся с проблемой 2000 года, постоянно создают порог, о который то и дело вновь и вновь спотыкаются программисты. Языки программирования предоставляют типы данных, поскольку внутри типа имеется произвольный набор операций, которые можно использовать или нет, и если приходится читать код, а операции там встречаются, то их можно увидеть. Объектно-ориентированные языки расширяют эти средства для любых данных, которыми мы желаем таким образом управлять, предоставляя Абстрактные Типы Данных (ADT). Реальная трудность с 2000 годом не в том, что многие программисты кодировали год двумя цифрами -- в те времена требовалось экономить память, а многие дошедшие до 2000 года программы очень старые. Проблема в том, что некоторые программисты берут эти две цифры и вставляют их где ни попадя без использования подходящей подпрограммы, макроса или даже фрагмента кода, чтобы сделать поправку. Это означает, что для того, чтобы решить проблему 2000 года в этих ужасно переплетенных старых программах требуется прочитать и понять каждую отдельную строку.