13.1.3. Необходимая, необязательная и случайная сложность

13.1.3. Необходимая, необязательная и случайная сложность

В идеальном мире Unix-программисты создавали бы только небольшие, совершенные "жемчужины программирования", каждая из которых была бы минимальной, изящной и безупречной. Однако одной из негативных черт реальности является то, что она часто ставит сложные проблемы, требующие сложных решений. Невозможно управлять реактивным лайнером с помощью изящной процедуры из десяти строк кода. Существует слишком много блоков оборудования, множество каналов и интерфейсов, множество различных процессоров, т.е. слишком много различных подсистем, определенных независимыми разработчиками, которые часто не согласны друг с другом даже в фундаментальных вопросах. Даже если предположить, что разработчик добился успеха в изящной реализации всех отдельных частей программного обеспечения для авиационной электронной системы управления, в ходе их интеграции, вероятно, будет создан большой, сложный и нечеткий код с одним достоинством — он действительно будет работать.

Реактивные самолеты обладают необходимой сложностью. Существует довольно четкая грань, за которой невозможно принести в жертву функции в обмен на простоту, поскольку самолет должен оставаться в воздухе. Благодаря самому этому факту, разработчики авиационных электронных систем управления не склонны втягиваться в "религиозные войны" в вопросе сложности, Unix-программисты также часто избегают их.

Конечно, реактивные авиалайнеры не застрахованы от системных сбоев, возникающих из-за чрезмерной сложности. Но вопросы проектирования проще распознать и проанализировать в программном обеспечении, для которого требования более гибкие, а поиски компромисса между предполагаемыми функциями и сложностью просты. (Здесь и далее в настоящей главе понятие "функции" используется в весьма широком смысле, который включает в себя различные элементы, такие как прирост производительности или общая степень изысканности интерфейса.)

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

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

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

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

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

35 Сложность и прогрессирующий функционизм

Из книги Человеческий фактор в программировании автора Константин Ларри Л

35 Сложность и прогрессирующий функционизм Я ненавижу переезжать. Я ненавижу заниматься апгрейдом программного обеспечения. Я ненавижу пересаживаться на новую машину. В принципе, переход к другой платформе или версии прост и эффективен. На практике это приводит мою и без


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

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

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


13 Сложность: просто, как только возможно, но не проще

Из книги Объектно-ориентированный анализ и проектирование с примерами приложений на С++ автора Буч Гради

13 Сложность: просто, как только возможно, но не проще Все следует делать так просто, как только возможно, но не проще. —Альберт Эйнштейн В конце главы 1 философия Unix была сведена к общему принципу — K.I.S.S. (Keep It Simple, Stupid! Будь проще!). В части "Проектирование" данной книги одной


13.1. Сложность

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

13.1. Сложность Как и в случае рассмотренных выше вопросов модульности и проектирования интерфейсов, Unix-программисты воспринимают ряд отличий, которые они часто усваивают из опыта, даже не зная, как их назвать. Поэтому начинать следует с изложения некоторых


Глава 1 Сложность

Из книги Удвоение продаж в интернет-магазине автора Парабеллум Андрей Алексеевич

Глава 1 Сложность Врач, строитель и программистка спорили о том, чья профессия древнее. Врач заметил: "В Библии сказано, что Бог сотворил Еву из ребра Адама. Такая операция может быть проведена только хирургом, поэтому я по праву могу утверждать, что моя профессия самая


1.1. Сложность, присущая программному обеспечению

Из книги Новый ум короля [О компьютерах, мышлении и законах физики] автора Пенроуз Роджер

1.1. Сложность, присущая программному обеспечению Простые и сложные программные системы Звезда в преддверии коллапса; ребенок, который учится читать; клетки крови, атакующие вирус, - это только некоторые из потрясающе сложных объектов физического мира. Компьютерные


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

Из книги Разработка ядра Linux автора Лав Роберт

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


13 Сложность: просто, как только возможно, но не проще

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

13 Сложность: просто, как только возможно, но не проще Все следует делать так просто, как только возможно, но не проще. —Альберт Эйнштейн В конце главы 1 философия Unix была сведена к общему принципу — K.I.S.S. (Keep It Simple, Stupid! Будь проще!). В части "Проектирование" данной книги одной


13.1. Сложность

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

13.1. Сложность Как и в случае рассмотренных выше вопросов модульности и проектирования интерфейсов, Unix-программисты воспринимают ряд отличий, которые они часто усваивают из опыта, даже не зная, как их назвать. Поэтому начинать следует с изложения некоторых


13.1.3. Необходимая, необязательная и случайная сложность

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

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


Случайная цена

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

Случайная цена Помимо обычного тестирования цен в рамках тестовой категории можно попробовать такой прием: всякий раз, когда кто-то из посетителей заходит на страницу с товаром, вы «случайно» показываете ему новую цену из заранее подобранных значений и «запоминаете»


Приложение В Сложность алгоритмов

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

Приложение В Сложность алгоритмов В компьютерных и связанных с ними дисциплинах полезно выражать сложность, или масштабируемость, алгоритмов с помощью количественных значащих характеристик (в отличие от менее наглядных характеристик, таких как быстрый или медленный).