. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Подсистемы трассировки, работы с ошибками, экранной подсказки,
ограничения доступа и др. могут быть одинаково сделаны в систе-
мах с разной функциональностью и даже с разной архитектурой.
Одинаковость может быть если не в программном коде, то хотя бы в
используемых алгоритмах, правилах, переменных.
Некоторые вещи в программных системах очень трудно заблаговре-
менно спроектировать в деталях. Если попытки проектирования всё-
таки делаются, то принятые решения впоследствии зачастую оказыва-
ются неоптимальными или ошибочными или противоречащими другим
решениям.
Существует некий оптимум детальности проектирования. Он опреде-
ляется используемыми инструментами программирования, сложностью
разрабатываемой системы, а также уровнем способностей, опытом и
навыками проектировщиков и программистов.
Местоположение оптимума -- там, где проектировщику ещё не
слишком тяжело определять детали, а программисту уже более-менее
понятно, какие задачи перед ним стоят.
Бывает, заказчик не может достаточно определённо сказать, какую
систему он ожидает получить, а если и выражает свои требования на
нужном уровне детальности, то, возможно, ошибается в том, что они
для него оптимальны. Такая ситуация -- нормальная: она не свиде-
тельствует о том, что заказчик хуже качеством, чем мог быть. Надо
помогать заказчику уяснять его потребности. Это может достигаться
изготовлением прототипа системы и предоставлением заказчику воз-
можности повозиться с этим прототипом.
На экран пользователя могут посылаться сообщения, предназначен-
ные для пользователя, и сообщения, предназначенные для програм-
миста и ничего не говорящие пользователю кроме того, что в систе-
ме что-то не в порядке. Появление сообщений, предназначенных для
программиста, говорит пользователю только о том, что надо пере-
стать работать с системой и передать её программисту для исследо-
вания и исправления. Иными словами, при нормальной работе системы
сообщения для программиста должны отсутствовать. В сообщениях для
пользователя следует применять только те понятия, которые должны
быть известны пользователю.
* * *
Отсутствие параметра на входе программы и неправильный параметр
на входе -- это две разные ситуации. Различие -- приблизительно
как между NULL и SPACES в поле таблицы в базе данных. Если в про-
грамме делается проверка на то и другое, то "сворачивать" резуль-
тат проверки в сообщение "Неправильный параметр..." вместо того,
чтобы использовать два сообщения -- "Неправильный параметр..." и
"Отсутствие параметра..."-- это нерационально, потому что означа-
ет в будущем потерю времени на распознавание, с какой из двух
ситуаций имеешь дело.
Сообщение "Неправильный параметр" -- неправильное: должно быть,
к примеру, сообщение "Неправильный параметр Q: значение XXX
вместо YYY или ZZZ".
Отладка -- это не однократно переживаемый трудный период в
жизненном цикле программной системы, а регулярное действие на
протяжении всего её существования, предпринимаемое после неиз-
бежных доработок и исправлений ошибок.
Программная система должна строиться так, чтобы было удобно её
отлаживать, иначе чрезмерные сложности будут иметь место уже на
стадии её разработки.
Средства обеспечения удобства отладки:
1. Подсистема трассировки.
2. Средства проверки входящих параметров в программных модулях.
3. Подсистема сообщений об ошибках.
4. Набор отладочных средств: вспомогательных отладочных программ,
отладочных наборов данных.
5. Набор описаний обязательных тестов.
Трассировки и встроенных проверок в системе должно быть не сли-
шком много и не слишком мало. Когда их слишком много, становится
трудно разобраться в функционалитете программы. Кроме того, вспо-
могательный программный код является дополнительным источником
ошибок.
Отладочные программы -- это часть программной системы: необхо-
димая, используемая на протяжении всего жизненного цикла системы.
Качество написания отладочных программ и порядок их учёта должны
быть не хуже, чем для основных программ системы.
* * *
Дебаггеры нужны только тогда, когда имеешь дело с плохо напи-
санными программами. Если программа имеет чёткую и лёгкую для
понимания архитектуру, удобную подсистему трассировки и лишена
"заплат", отыскивать в ней недоделки и описки не составляет
больших затруднений.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Александр Бурьяк.