От: | Сергей Губанов | http://sergey-gubanov.livejournal.com/ | |
Дата: | 05.12.05 16:01 | ||
Оценка: | 13 (2) +1 |
Перевод на русский язык выполнен здесь.Хорошо известно, что определение ошибки тем более затруднено и дороже обходится, чем позже она обнаруживается, т.е. чем дальше разнесены источник и его эффекты. Это позволяет сформулировать правило:
Позволяйте ошибкам заявлять о себе как можно раньше.
В компонентно-ориентированных системах дефекты всегда должны содержаться в их компонентах
и не распространяться на другие компоненты. Другие компоненты даже могут быть черными ящиками и не иметь исходных текстов, что делает отладку на уровне исходных текстов невозможной. Более того, поток передачи управления в больших объектно-ориентированных программных системах настолько запутанный, что нереально, и это пустая трата времени, проследить его за пределами границ компонентов для целей отладки.
Единственный жизнеспособный отладочный подход есть проектирование всего, от языка программирования до библиотек, до компонентов и приложений, используя оборонительный стиль программирования. В частности, входные точки в компоненты (вызовы процедур/методов) должны останавливать исполнение, если их предусловия не обеспечены:
Никогда не позволяйте ошибкам проникать сквозь границы компонентов.
К счастью, большинство проверок предусловий недорого и поэтому их отключение при исполнении не имеет смысла. Это важно, поскольку в компонентно-ориентированной системе проверки периода исполнения не могут быть выключены в конечной (готовой) системе, поэтому разрабатываемая и готовая системы не различаются. На практике большинство компонентов уже отлажено в режиме черного ящика ("продукция"), а другие отлаживаются в режиме белого ящика. Готовые компоненты должны взаимодействовать, чтобы доказать приверженность сформулированному выше правилу, которое означает «никогда не отключать проверки периода исполнения».