Книга: Искусство программирования для Unix
1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути"
1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути"
Даже наилучшие программные инструменты ограничены воображением своих создателей. Никто не обладает умом, достаточным для оптимизации всего или для предвидения всех возможных вариантов использования создаваемой программы. Разработка негибкого, закрытого программного обеспечения, которое не будет сообщаться с остальным миром, является болезненной формой самолюбия.
Поэтому традиция Unix включает в себя здоровое недоверие к использованию "единственного верного пути" в проектировании или реализации программного обеспечения. В Unix допускается использование множества языков, открытых расширяемых систем и необходимой доработки.
Оглавление книги
Оглавление статьи/книги
- 1.6.1. Правило модульности: следует писать простые части, связанные ясными интерфейсами
- 1.6.2. Правило ясности: ясность лучше, чем мастерство
- 1.6.3 Правило композиции: следует разрабатывать программы, которые будут взаимодействовать с другими программами
- 1.6.4. Правило разделения: следует отделять политику от механизма и интерфейсы от основных модулей
- 1.6.5. Правило простоты: необходимо проектировать простые программы и "добавлять сложность" только там, где это необходимо
- 1.6.6 Правило расчетливости: пишите большие программы, только если после демонстрации становится ясно, что ничего другого не остается
- 1.6.7. Правило прозрачности: для того чтобы упростить проверку и отладку программы, ее конструкция должна быть обозримой
- 1.6.8. Правило устойчивости: устойчивость — следствие прозрачности и простоты
- 1.6.9. Правило представления: знания следует оставлять в данных, чтобы логика программы могла быть примитивной и устойчивой
- 1.6.10. Правило наименьшей неожиданности: при проектировании интерфейсов всегда следует использовать наименее неожиданные элементы
- 1.6.11. Правило тишины: если программа не может "сказать" что-либо неожиданное, то ей вообще не следует "говорить"
- 1.6.12. Правило исправности: когда программа завершается аварийно, это должно происходить явно и по возможности быстро
- 1.6.13. Правило экономии: время программиста стоит дорого; поэтому экономия его времени более приоритетна по сравнению с экономией машинного времени
- 1.6.14. Правило генерации: избегайте кодирования вручную; если есть возможность, пишите программы для создания программ
- 1.6.15. Правило оптимизации: создайте опытные образцы, заставьте их работать, прежде чем перейти к оптимизации
- 1.6.16. Правило разнообразия: не следует доверять утверждениям о "единственно верном пути"
- 1.6.17. Правило расширяемости: проектируйте с учетом изменений в будущем, поскольку будущее придет скорее, чем кажется
Похожие страницы
- Восстановление "безнадежных" баз данных. InterBase Surgeon
- Основные "рычаги" управления производительностью
- Using Double Quotes to Resolve Variables in Strings with Embedded Spaces
- 1.5. Потренируйте свою интуицию: что следует запомнить
- 10.5. Транзакции и пути доступа меню
- 3. Null-значения и общее правило вычисления выражений
- Когда следует задавать проясняющие вопросы
- Правило 16. Группируйте связанные между собой элементы
- Файлы без расширения, как правило, текстовые. Как сделать, чтобы при двойном щелчке кнопкой мыши они открывались в Блокн...
- 4.11.4. Правила "все кроме"
- 5.5. ПРИМЕР РАЗРАБОТКИ ОПИСАНИЯ ПРОЦЕССА "КИПЯЧЕНИЕ ВОДЫ В ЧАЙНИКЕ"
- Рис. 201. Выберите "Через высокоскоростное подключение, запрашивающее имя пользователя и пароль"