The Programmers' Stone (Программистский камень)
Шрифт:
План тестирования
План Тестирования -- наиболее чувствительный к контексту тип документа, но очень полезно руководствоваться следующими наблюдениями в рамках требований ситуации. Стратегическая цель тестирования -- напрячь систему. Не будет никакой пользы, если делать тестирование хаотично, поэтому необходимо найти одну или несколько моделей системы, которые могут дать нам индикатор для типичных и стрессовых ситуаций. Таким образом, полезная структура -- описать модель, выяснить стрессовые условия и затем перечислить их.
Снова и снова в этой работе мы видим эхо глубокой структуры, которую мы
Этот паттерн настолько важен, что мы хотим сфокусировать на нем внимание. Хотя мы стараемся избегать замысловатого жаргона без стоящего за ним реального смысла, мы хотим ввести термин, "Ход конем" ("Вилка"), чтобы обозначить этот паттерн. Мы позаимствовали этот термин из шахмат. Там конь стоит на доске и может совершать последовательность L-образных перемещений. Другие фигуры могут перемещаться только по горизонтали, вертикали или диагонали, а L-образные ходы коня позволяют напасть сразу на две фигуры, каждая из которых ограничена своим собственным миром, и таким образом добиться чего-нибудь полезного в любом случае.
Такого вида паттерн появляется снова и снова, но мы всегда можем свести его к написанию простейшей программы. Компьютерная система может находиться во многих состояниях и развиваться в соответствии со своей собственной внутренней логикой. Окружающий мир, за которым следит компьютер, также может находиться во многих состояниях и изменяться (эволюционировать). Используя интуицию, дизайнер может абстрагировать и внести в компьютер критические аспекты проблемы, применяя одну и ту же структуру в обоих случаях, поэтому компьютер и реальность будут согласованы. Тестовые ситуации, формируемые моделью проблемы и системы, будут охватывать допустимые (и, вероятно, недопустимые) состояния пространства входных воздействий, в соответствии с интуицией автора, таким образом, что в любом случае можно будет проверить изменение состояния системы. Проектировщик, при необходимости выполнения манипуляций с данными, будет использовать свойства самих данных, определяемые структурой данных, и отражать эти свойства на свойства языка, как в каноническом:
while((c = getchar) != EOF) putchar(f(c));
Все проектирование архитектуры заключается в прощупывании проблемы, рассматривая требования с максимально возможного числа направлений, до тех пор, пока в ней не обнаружится структура, которую архитектор системы сможет использовать для решения проблемы.
"Ход конем" всегда использует внутреннюю (присущую ей) глубокую структуру проблемной области. Проверка того, что эта глубокая структура реальна, а не плод воображения и случайных совпадений, очень важна. Если дизайнер использует случайные совпадения, результат будет скорее "заумным", чем "элегантным", и все будет хрупким, полагающимся на специальные меры предосторожности по всему результирующему коду системы, с потерей целостности проекта. Вайнберг (Weinberg) приводит пример программиста, пишущего
Дзенская притча говорит о мудром монахе, пришедшем к старому учителю. Он вошел в комнату учителя и сел перед ним. "Когда ты входил, с какой стороны двери ты оставил свой посох?" - спросил учитель. Монах не знал. "В таком случае, ты потерял свой Дзен".
После того, как вы рассмотрели структуру своей программы и готовы реализовать ее, все еще остается важная задача сохранить над ней контроль. Даже если вы уже написали критические строки кода, еще нужно написать много других. Требующаяся для этого дисциплина гораздо важнее, чем любой формальный процесс, и в каждой новой ситуации его нужно применять разумно.
Ваш процесс будет разбивать задачу на подзадачи, а затем вы должны собрать все вместе. Как машина-укладчик железнодорожного полотна, вы должны должны выстраивать структуру своей работы по мере ее развития. По прошествии времени вы достигнете способности делать это в своей голове, и на самом деле очень быстро, поскольку задачу можно упростить двумя способами.
Вы можете разворачивать только часть вашего плана, над которым вы работаете. Вот как можно спланировать изменения некоторой программы в своей голове:
1. Идентифицировать все файлы, которые включают функции:
ModelOpen,
ModelRead,
ModelWrite,
ModelClose.
2. Отключить контроль версий этих файлов.
3. Внести изменения.
3.1. Изменить modread.c
3.1.1. Исправить ModelOpen
3.1.2 Исправить ModelRead
3.1.3. Исправить ModelWrite
3.1.4. Исправить ModelClose
3.2. Изменить appfile1.c
3.3. Изменить appfile2.c
4. Обратно включить контроль версий
5. Перекомпилировать
Тот факт, что это описание процесса может не описывать каждый маленький шажок и поэтому не перегружает ваш интеллект бесполезными попытками это делать, не освобождает вас от обязанности делать эту работу самому. И это позволяет устанавливать необходимый порядок в собственной голове по своему усмотрению -- так, как вам удобнее. Некоторым людям нравится записывать небольшие списки файлов, которые нужно модифицировать, на клочках бумаги и рвать их, когда дело сделано, оставляя остальной процесс в своих головах. Они могут помнить, где они находятся на большой картине, но если их прервать посредине большого списка, они могут растеряться.
Другой важных метод -- вы можете изменять свои планы. Ключевая концепция TQM заключается в том, что мы должны понимать, чего мы хотим достигнуть, если уж мы хотим знать, когда мы этого достигнем. Это значит, что нам нужно оказаться в состоянии сказать честно, что, как мы думаем, мы делаем в любой момент времени, но это не остановит нас, если мы передумаем! Например, мы могли бы добавить в вышеприведенный пример
3.1.5. Разобраться со всеми заголовочными файлами :-(
в любой момент, поскольку мы изменяем определения функций и наши бедные маленькие умишки блуждают туда-сюда и выясняют, что прототипы тоже потребуют корректировки.