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

1.8. Индекс сложности

       В этой книге мы уже познакомились со множеством разнообразных проблем и решений в области разработки программного обеспечения. В этой главе мы уже обсуждали два важных, но очень разных подхода к решению этих проблем. Один из них предполагает дисциплину, а другой — гибкость. Как постепенно выясняется, допутимо и сочетать эти два подхода.
       Все это звучит несколько абстрактно и загадочно. Но чего мне хотелось избежать, так это скучно-абстрактного и скучно-загадочного обсуждения предмета, который в действительности не является ни слишком скучным, ни слишком абстрактным, ни слишком загадочным. Вот почему я был несказанно рад, когда П.Дж.Плогер (P.J.Plauger), один из моих любимых авторов, пишущих на компьютерные темы, изобрел удачный термин для обсуждения всех этих тонких различий [Plauger 1992]. Все это он весьма неформально называет “индексом сложности” (“the falutin' index”).
       Термин “falutin'” (как в “high-falutin'” и “low-falutin'”) он применяет к разным связанным понятиям, означающим сложность проблемы и ее решений. На американском сленге словом high-falutin' характеризуют нечто сложное и изощренное. Напротив, low falutin' означает нечто простое и безыскусное.
       К чему же Плогер применил свой “индекс сложности”? К целому ряду вещей:
       1. Задачи могут иметь высокую или низкую сложность. Иными словами, они могут быть невообразимо сложными или совершенно простыми.
       2. Решения тоже могут иметь высокую или низкую сложность.
       3. Люди тоже могут характеризоваться высокой или низкой сложностью.
       4. Наконец, программные проекты могут иметь высокую или низкую сложность.
       Все это могло бы остаться просто игрой в слова, но Плогер высказал более серьезные мысли. Он считает, что крупнейшие катастрофы в разработке программ происходят при несоответствии разных аспектов проекта по степени сложности. Например, когда для решения сложных задач предлагаются простые методы (или наоборот). Либо программисты высокой сложности работают над проектами низкой сложности (или наоборот).
       Он привел несколько известных ему случаев такого несоответствия. “Однажды я увидел встроенную систему, которая работала просто-напросто как торговый автомат, — пишет он. — Ее функции ограничивались тем, чтобы подсчитать опущенные монеты, отпустить товар и дать сдачу”. Далее Плогер пишет, что разработчик применил здесь подход высокой сложности для решения задачи низкой сложности. “В предложенном конструктивном решении обработка данных осуществлялась с помощью шести отдельных процессов, выполняемых под управлением коммерческой операционной системы реального времени. Не сомневаюсь, что разработчик с удовольствием применил свои специальные знания, но он явно перестарался”.
       В итоге проект высокой сложности пришлось отвергнуть. Финальная система применяла обычный цикл с опросом и гораздо меньше аппаратуры, чем требовало громоздкое, изощренное решение. Иными словами, сложный программист попытался решить простую проблему в простом проекте сложным способом. А это нехорошо. Совсем нехорошо!
       Проблемы могут возникать и в случае обратного несоответствия. Плогер рассказывает о важном проекте, в котором сложные задачи пытались решить с помощью простых средств. Он пишет: “Это болезнь больших программистских компаний, управляемых “вертикально”, где руководству удобно считать программистов товаром. Там нанимают неквалифицированных программистов... которых потом если и обучают, то очень мало”.
       “Руководство пытается управлять процессом, — пишет он далее, — требуя частых отчетов о ходе работ, рецензируя код и организуя такого рода контроль качества, при котором еще более неквалифицированные программисты пишут простые контрольные примеры для проверки простого поставляемого кода. Результат нетрудно предвидеть. Наверняка вы сами или кто-то из ваших знакомых наблюдали подобную катастрофу либо читали о подобной финансовой неудаче”. Как только заходит речь о сложном решении простой проблемы, или наоборот, ждите крупных неприятностей. К тому, что рассказал Плогер, многие программисты наверняка добавят собственные истории о несоответствии сложности задач и решений.
       Отмечу еще один важный вывод, сделанный Плогером в этой связи. Не существует единого подхода с “правильной” сложностью. Реальный мир ставит задачи как высокой, так и низкой сложности. Литература по программированию предлагает как простые, так и сложные методы (и программисты должны осознавать степень их сложности). Одни программисты предпочитают работать в условиях низкой сложности, другие — наоборот, высокой. Здесь нет правых и виноватых. Есть лишь различия, и эти различия нужно учитывать, привлекая людей к работе над проектом, чтобы обеспечить наилучшее решение задачи.
       “К чему нужно стремиться, — говорит Плогер где-то, — так это к согласованности”. По его мнению, применяемые методы должны соответствовать естественной сложности проблемы, которую вы пытаетесь решить.
       Выберете неоправданно упрощенный подход — и не уложитесь в отведенные сроки. Или даже вообще не справитесь с проектом. И это классический случай бедствий, случающихся в программировании: сначала существенно заниженная оценка времени, затем неадекватный выбор методов управления и технологий, а после — лихорадочные попытки завершить проект, гонка на выживание. “Любой достаточно крупный проект, — говорит Плогер, — это, главным образом, испытание методов управления. От технологий программирования конечный результат зависит лишь в незначительной мере”.
       А что будет, если выбрать неоправданно усложненный подход? Вы потеряете деньги и время — и немало. Составление документации и отчетов поглотят вас настолько, что трудно будет определить, решена ли задача удовлетворительным образом.
       Итак, применение “индекса сложности” — не гладкий процесс. Какой же итог всему этому подводит Плогер? Он заключает: “С учетом всех аспектов количество различных комбинаций степеней сложности практически бесконечно. Вспомните проекты, в которых вы участвовали. Были ли они успешными? Хорошо ли при этом согласовывались показатели сложности? Мой личный опыт показывает, что ответы на эти два вопроса прочно связаны между собой... Успешные проекты гармоничны, иначе они не были бы успешными”.

Ссылки
       Plauger 1992 — “The Falutin' Index”, Embedded Systems Programming, May 1992, pages 89-92; P.J. Plauger.




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

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


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