Джозеф Фокс - Программное обеспечение и его разработка

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

Цикл, размером в три страницы, это логический кошмар. Это еще более сложное образование, чем Литота — двойное или множественное отрицание, как в предложении Гарольда Ласки: «Я до конца не уверен в том, будет ли правдой утверждение, что Мильтон, который прежде не казался не похожим на Шелли семнадцатого века, не стал, в противовес опыту даже более горьких лет, более близким основателю иезуитской секты, которая вряд ли способствовала развитию в нем терпимости» [43] David Hackett Fischer, Historians Fallacves — Towards Logic of Historical Thought (New York: Harper & Row, Publischers INC., 1970). .

Разумеется, циклы размером в три страницы могут прекрасно работать. И, если речь идет о программах типов «зубочистки» или «молотка», проблемы не возникнет. Программиста можно за это похвалить. Но если нам придется несколько раз возвращаться к этой программе и модифицировать ее, лучше сразу покончить с программистом. Прежде, чем мы сможем модифицировать и расширить эту программу, нам придется распутать невероятный логический клубок.

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

Обычно сама идея введения стандартов на программное обеспечение отвергается руководителем разработки программного обеспечения. Отказ от стандартов обычно сопровождается такими высказываниями: «Я уже делал нечто подобное», или «Мы не нуждаемся в подобных накладных расходах». Такой начальник просто отстал от жизни. Дело здесь осложняется тем, что он все же остается руководителем! Теми или иными средствами он выполняет свою работу. Он стал боссом, лидером, добился успеха, а эти новые методы очень странны, они таят в себе опасность. Они могут лишить его действия некоторой таинственности, которой они раньше обладали. Очень вероятно, что благодаря этим новым методам ему с новой силой придется вести конкурентную борьбу за руководящую должность.

«Высокое начальство» мало что знает о всех этих новшествах. Даже если есть выбор, он предпочитает соглашаться с руководителем, ретроградом или сторонником новых идей! И может статься, что применение новейшей технологии будет отложено до лучших времен.

Сопротивление новшествам — это не всегда плохо. Мы уже видели, что в этой новой отрасли имеется тенденция принятия осторожных решений. Предусмотрительное руководство не стремится к поспешным решениям, связанным с принятием новейших методов, разработанных сравнительно недавно. Но предусмотрительное руководство не отвергает новые, проверенные методы, которые уже устоялись и использовались в течении двух или трех лет.

Рассуждая о значении слов, Шалтай Болтай сказал: «Вопрос в том, кто за это отвечает?» Его слова вполне могли относиться к разработке программного обеспечения — кто за это отвечает? Руководство или подчиненные? Из-за новизны нашей отрасли, малочисленности практических работников ключевые решения часто принимаются подчиненными.

Можно ли разрешить сумасшедшим управлять психиатрической лечебницей? Для внедрения новых проверенных методов необходимо жесткое руководство. Старые методы сопротивляются новым. Эти новые методы пугают всех. Кому нужны эти нововведения? Они еще не проверены. «Начальство в этих вещах не разбирается!» (См. табл. 6.7.)

Таблица 6.7. Естественная борьба между программистами и их руководством

В начале 1970-х годов мы издали приказ, по которому все новые программы, создаваемые с участием 4400 сотрудников Центра федеральных систем фирмы IBM, должны разрабатываться с применением методов структурного программирования. Мы обнаружили, что должны переучить примерно 2600 программистов и их руководителей. Это означало 5200 человеко-недель или 100 человеко-лет напряженных усилий, не считая планирования, затрат на подготовку преподавателей, материальное обеспечение.

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

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

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

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