1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами

1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами

Как однажды заметил Браян Керниган, "управление сложностью является сущностью компьютерного программирования" [41]. Отладка занимает большую часть времени разработки, и выпуск работающей системы обычно в меньшей степени является результатом талантливого проектирования, и в большей — результатом должного управления, исключающего многократное повторение ошибок.

Трансляторы, компиляторы, блок-схемы, процедурное программирование, структурное программирование, "искусственный интеллект", языки четвертого поколения, объектно-ориентированные языки и бесчисленные методологии разработки программного обеспечения рекламировались и продавались как средство борьбы с этой проблемой. Все они потерпели неудачу, если только их успех заключался в повышении обычного уровня сложности программы до той точки, где (вновь) человеческий мозг едва ли мог справиться. Как заметил Фред Брукс [8], "серебряной пули не существует".

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

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами Как однажды заметил Браян Керниган, "управление сложностью является сущностью компьютерного программирования" [41]. Отладка занимает большую часть времени разработки, и выпуск


1.6.3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами

Из книги Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ автора Мейерс Скотт

1.6.3. Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами Если разрабатываемые программы не способны взаимодействовать друг с другом, то очень трудно избежать создания сложных монолитных программ.Традиция Unix


1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей В разделе "Что в Unix делается неверно" отмечалось, что разработчики системы X Window приняли основное решение о реализации "механизма, а не политики". Такой подход был направлен на


1.6.5. Правило простоты: необходимо проектировать простые программы и "добавлять сложность" только там, где это необходимо

Из книги Деловая e-mail переписка. Пять правил успеха автора Воротынцева Тамара

1.6.5. Правило простоты: необходимо проектировать простые программы и "добавлять сложность" только там, где это необходимо Многие факторы приводят к усложнению программ (а следовательно, делают их более дорогими и более уязвимыми относительно ошибок). Программисты — это


1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой

Из книги автора

1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой Даже простейшую процедурную логику трудно проверить, однако весьма сложные структуры данных являются довольно простыми для моделирования и


1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы

Из книги автора

1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы Данное правило также широко известно под названием "Принцип наименьшего удивления" (Principle of Least Astonishment).Простейшими в использовании


1.6.11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить"

Из книги автора

1.6.11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить" Одно из старейших и наиболее постоянных правил проектирования в Unix гласит: если программа не может "сказать" что-либо интересное или необычное, то ей следует


1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути"

Из книги автора

1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути" Даже наилучшие программные инструменты ограничены воображением своих создателей. Никто не обладает умом, достаточным для оптимизации всего или для предвидения всех возможных


Правило 12: Копируйте все части объекта

Из книги автора

Правило 12: Копируйте все части объекта В хорошо спроектированных объектно-ориентированных системах, которые инкапсулируют внутреннее устройство объектов, копированием занимаются только две функции: конструктор копирования и оператор присваивания. Назовем их


1.6.3 Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами

Из книги автора

1.6.3 Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами Если разрабатываемые программы не способны взаимодействовать друг с другом, то очень трудно избежать создания сложных монолитных программ.Традиция Unix


1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей

Из книги автора

1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей В разделе "Что в Unix делается неверно" отмечалось, что разработчики системы X Window приняли основное решение о реализации "механизма, а не политики". Такой подход был направлен на


1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой

Из книги автора

1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой Даже простейшую процедурную логику трудно проверить, однако весьма сложные структуры данных являются довольно простыми для моделирования и


1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы

Из книги автора

1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы Данное правило также широко известно под названием "Принцип наименьшего удивления" (Principle of Least Astonishment).Простейшими в использовании являются


1.6.11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить"

Из книги автора

1.6.11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить" Одно из старейших и наиболее постоянных правил проектирования в Unix гласит: если программа не может "сказать" что-либо интересное или необычное, то ей следует


1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути"

Из книги автора

1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути" Даже наилучшие программные инструменты ограничены воображением своих создателей. Никто не обладает умом, достаточным для оптимизации всего или для предвидения всех возможных