Правильная ссылка на эту страницу
http://az-design.ru/Support/SoftWare/l/GlassRob/04h1032.shtml

3.2. Достаточно хорошее программное обеспечение

       Все вышесказанное носило довольно философский характер. Теоретически, я думаю, почти все с этим согласятся. Разумеется, “достаточно хорошее” решение можно улучшить, потратив дополнительное время на его мелкие усовершенствования, но только закоренелый перфекционист сочтет нужным улучшать “достаточно хорошее”.
       Но лет десять назад эти вопросы перестали быть философскими и стали достаточно конкретными. Сторонники принципов “разумной достаточности” и “лучшее — враг хорошего” начали пропагандировать то, что они назвали “достаточно хорошим ПО”. Хотя в свое время масса сил была потрачена на определение “достаточно хорошего”, в контексте наших рассуждений в нем, как мне кажется, нет нужды. Договоримся считать, что “достаточно хорошее” = “разумно достаточное”.
       Наверное, неудивительно, что многие заняли жесткую позицию по этому вопросу. Одни заявляли, что нет смысла стремиться к совершенству в таком деле, где достаточно трудно просто заставить что-либо работать. Другие, наоборот, видели опасность в том, что якобы снижаются стандарты в профессии программиста и поощряется написание низкокачественных программ, и это в такие времена, когда на рынке вообще трудно найти удовлетворительно работающую программу. Трудно было надеяться на смягчение разногласий.
       И пока все это происходило, издания вроде “Cutter IT Journal” подливали масла в огонь, посвящая данной теме специальные выпуски и стимулируя публичные дискуссии. Честно говоря, мне кажется, что “IT Journal” поступал в этом случае правильно. Такие темы, если не откладывать их разбор, имеют тенденцию незаметно тлеть и ярко вспыхивать в самый неожиданный момент.
       В каком-то роде все это, конечно, свелось к буре в стакане. Одни действительно пытались определить методологии и технику, которые позволили бы делать “достаточно хорошие” программы. Другие продолжали бороться с этими технологиями по изложенным выше мотивам. Но факт то, что по большей части результаты нашего труда оказываются “достаточно хорошими”, нравится нам это или нет, потому что добиваться чего-то большего обременительно как в финансовом, так и в умственном отношении. Подход “лучшее — враг хорошего” вполне прижился в мире программирования, и критика принципа “достаточно хорошего” стихла сама собой.
       Чтобы этот спор не казался вам слишком философским, приведу пример, на мой взгляд, неплохо иллюстрирующий проблему. В некие времена одному блестящему специалисту по компьютерным наукам, работавшему в аэрокосмической фирме, предложили написать прикладную программу. Требовалось создать ассемблер для одноразового бортового компьютера, устанавливаемого на космическом корабле. Все приложение в целом было, конечно, уникальным, как и большинство приложений в космонавтике, в отличие от данной конкретной задачи. Всякий, кто разбирается в системном программировании, может написать ассемблер, и с этой задачей можно было справиться достаточно быстро.
       Но не в характере этого блестящего специалиста было делать что-либо на скорую руку. Работающую версию ассемблера он изготовил весьма скоро, что неудивительно. Но то, что за этим последовало, поразило всех остальных участников этого проекта.
       Своего часа ожидали другие программные задачи, для которых не были еще назначены исполнители. Но наш блестящий специалист все работал над своим ассемблером, постепенно превращая его в произведение искусства. Он усовершенствовал интерфейс пользователя; он разукрасил вывод данных; он осуществил рефакторинг кода, сделав решение более элегантным.
       Шли недели. Все остальные участники завершили свои задачи и перешли к следующим. Но совершенствование ассемблера все продолжалось. Разумеется, без всякой в том необходимости. Но результат становился все лучше.
       Впервые услышав поговорку “лучшее — враг хорошего”, я уже знал, чем это оборачивается на деле, поскольку вполне усвоил уроки того конкретного случая. Правда, тогда мы называли такую ситуацию иначе — “наведение лоска” (goldplating). И начальники зорко следили за тем, чтобы их подчиненные этим не занимались. (Думаю, начальник того блестящего компьютерного специалиста просто не понимал, что для создания ассемблера не нужно столько времени. Вспомните островолосого босса из комиксов Дилберта!)
       И когда заходит речь о принципе “лучшее — враг хорошего”, я мысленно переношусь в те времена, когда последствия его нарушения были весьма печальными. С тех пор я твердо встал на сторону тех, кто поддерживает идею “достаточно хороших” программ.




<<< Пред. Оглавление
Начало раздела
След. >>>

Дата последнего изменения:
Thursday, 21-Aug-2014 09:10:55 MSK


Постоянный адрес статьи:
http://az-design.ru/Support/SoftWare/l/GlassRob/04h1032.shtml