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

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

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

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

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

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

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

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

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

Далее, существует два вида угроз безопасности: злонамеренные и по небрежности. Вашему продукту может потребоваться защита от злонамеренных угроз, но если вам требуется защита вашей собственной среды разработки от злонамеренных угроз изнутри (мы предполагаем, что вы растете и у вас уже есть брандмауэр), то у вас гораздо большие проблемы, и они не решаются просто установкой запрета доступа к нескольким файлам. Поэтому забудьте о злонамеренных угрозах на работе. Что касается угроз по небрежности, типа случайного уничтожения всего дерева исходных текстов проекта, то ведь у вас есть резервная копия, не правда ли? Навязывание дорогостоящих накладных расходов на безопасность каждой операции в среде разработки для защиты от «катастроф», которые, если произойдут, оказываются пустяками — это ложный путь. По мере того, как программисты все лучше осваивают персональный послойный процесс, даже эти незначительные ошибки происходят все реже, а разработка совместно используемых мысленных моделей и картостроительный жаргон в команде означают, что неформальный «этикет» разработки уже усвоен, как возглас «Реинициализация тестовой базы данных — все в порядке?» перед очисткой засоренных тестовых данных. Эти вопросы как элементы этикета — единственный приемлемый возглас в ненавистных офисах с открытой планировкой, и это единственный разумный довод их существования. Но, тем не менее, это недостаточный довод.