13.1.1. Три источника сложности

13.1.1. Три источника сложности

Вопросы о простоте, сложности и верном размере программного обеспечения вызывают бурные споры в Unix-сообществе. Unix-программисты развили такое мировоззрение, согласно которому простота — это красота, изящество и добро, а сложность — уродство, абсурдность и зло

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

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

Что конкретно автор называет "сложностью"? Этот момент достоин точного определения ввиду своей важности.

Unix-программисты (как и остальные программисты) склонны фокусировать внимание на сложности реализации — по существу, степени трудности, с которой столкнется программист, пытаясь понять программу, для того чтобы создать ее ментальную модель или отладить.

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

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

Размер кодовой базы, сложность интерфейса и реализации могут возрастать одновременно, что является обычным результатом сползания функций и причиной особенных опасений программистов. Преждевременная оптимизация не склонна увеличивать сложность интерфейса, но оказывает негативное влияние (часто крайне негативное) на сложность реализации и размер кодовой базы. Однако эти доводы против сложности сравнительно просты. Более серьезные трудности начинаются, когда приходится искать компромисс между тремя данными критериями.

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

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

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

Выше описаны три вида сложности, а также некоторые ловушки, в которые попадают разработчики, пытающиеся избежать сложности[110]. Примеры рассматриваются далее в настоящей главе.