Продукт инженерной деятельности (в разработке ПО)

Материал из CustisWiki
Перейти к: навигация, поиск

В конце книги Мартинов «Принципы, паттерны и методики гибкой разработки на языке C#» я наткнулся на перепечатку прелюбопытнейшей статьи 1992 года «Что такое проектирование программного обеспечения» («What is software design»), Jack W.Reeves, C++ Journal.

Я хотел всего-лишь сослаться на эту статью на русском языке и только привести несколько примечательных фраз, но о ужас:

  • я не смог найти электронной версии этой книги (ни yandex, ни google не помогли — неужели совсем стали лавочки прикрывать :O, да простят меня блюстители всего лицензионного)
  • я не смог найти этой статьи на русском языке. Есть лишь ужасный перевод в Computerra.

Пришлось отсканировать, ибо оно того стоит.

Для тех, кто не ленится учить родной язык IT индустрии (а таких, к сожалению, немного), статья в оригинале: http://www.developerdotstar.com/mag/articles/reeves_design.html


Похоже, объектно-ориентированные методики, и язык С++ в частности, покоряют мир программного обеспечения. Появились многочисленные статьи и книги о применении новых технологий. Вопрос о том, не является ли ООП очередной рекламной шумихой, сменился обсуж­дением, как извлечь из этой технологии максимум выгоды с мини­мальными усилиями. Объектно-ориентированные методики появились не вчера, но этот взрыв популярности представляется не совсем обыч­ным. Откуда такой внезапный интерес? Предлагались самые разные объяснения. По правде говоря, нельзя назвать какую-то единственную причину. Возможно, сочетание различных факторов достигло критиче­ской массы и началась реакция. Тем не менее похоже, что самым зна­чимым фактором на этом последнем этапе революции в мире ПО стал сам язык С++. У этого явления, наверное, тоже есть много причин, но я хочу взглянуть на него под несколько иным углом зрения: С++ при­обрел популярность потому, что облегчает как проектирование ПО, так и программирование.

Возможно, мое замечание показалось вам странным, и это неслучайно. В этой статье я как раз и хочу рассмотреть связь между программирова­нием и проектированием ПО. Уже почти 10 лет меня не оставляет ощу­щение, что индустрия программного обеспечения в целом не улавливает тонкого различия между разработкой проекта программы и тем, что на самом деле представляет собой такой проект. Я полагаю, что из ра­стущей популярности С++ можно извлечь важный урок о том, что нам нужно сделать, чтобы стать лучшими инженерами-программистами. А заключается он в том, что суть программирования — не изготовление программного обеспечения, а его проектирование.

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

Конечной целью любой инженерной деятельности является та или иная документация. По завершении проектирования вся проектная документация передается на производство. Там работают совершенно другие люди, обладающие принципиально иными навыками, чем про­ектировщики. Если проектная документация действительно полна, то производственники могут приступить к изготовлению изделия. И даже целых партий изделий — вмешательства проектировщиков уже не тре­буется. Проанализировав жизненный цикл разработки программного обеспечения так, как я его понимал, я пришел к выводу, что единствен­ная документация, которая хоть как-то удовлетворяет критериям ин­женерного проектирования, — это листинги с исходным кодом.

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

У взгляда на код как на проект программы есть одно следствие, затме­вающее все остальные. Оно настолько важно и очевидно, что для по­давляющего большинства организаций, занимающихся программным обеспечением, оказывается мертвой зоной. Речь идет о том, что изго­товление ПО стоит очень дешево. Его даже нельзя назвать недорогим; оно дешево настолько, что уже почти бесплатно. Если исходный код - это проект программы, то ее изготовлением занимаются компилято­ры и компоновщики. Мы часто называем процесс компиляции и ком­поновки полной программной системы «сборкой». Капитальные вло­жения в оборудование для изготовления ПО низки — требуется лишь компьютер, редактор текстов, компилятор и компоновщик. Если все необходимое имеется, то для сборки программы требуется лишь немно­го времени. Может показаться, что компиляция программы на С++ из 50 ООО строк занимает вечность, но подумайте, сколько времени ушло бы на изготовление аппаратной системы такой же сложности, как про­грамма на С++ из 60 ООО строк?

Еще одно следствие взгляда на код, как на проект программы — тот факт, что создать проект программы относительно легко, по крайней мере, если говорить о механическом труде. На написание (то есть проектиро­вание) типичного программного модуля длиной от 50 до 100 строк обыч­но уходит всего пара дней (его отладка — совсем другое дело, но об этом ниже). Так и хочется спросить, есть ли еще какая-нибудь инженерная дисциплина, позволяющая порождать проекты такой сложности, как программы, в такое же короткое время. Однако сначала надо понять, как измерять и сравнивать сложность. Но в любом случае очевидно, что программные проекты довольно быстро становятся очень большими. Учитывая, что программные проекты относительно легко выпускать, а изготовление ПО практически бесплатно, неудивительно, что проекты оказываются невообразимо большими и сложными. На первый взгляд факт тривиальный, но при этом часто игнорируют размер задачи. Учеб­ные проекты часто насчитывают несколько тысяч строк кода. Есть от­крытые программные продукты размером 10 ООО строк. Но мы давно уже прошли тот этап, когда простые программы могли представлять значительный интерес. Проекты типичных коммерческих продуктов состоят из сотен тысяч строк, а есть немало таких, где строк миллио­ны. К тому же проекты программ почти всегда постоянно изменяются. Даже если текущий проект насчитывает всего несколько тысяч строк кода, на протяжении жизни продукта могло быть написано во много раз больше.

Конечно, есть примеры проектов оборудования, не менее сложных, чем проекты программ, но отметим два факта, касающихся современно­го оборудования. Во-первых, сложные проекты оборудования вовсе не всегда свободны от ошибок — вопреки уверениям критиков ПО. Основ­ные микропроцессоры поставлялись с логическими ошибками, мосты рушились, плотины прорывало, самолеты падали, а уж количество отзывов автомобилей и других потребительских продуктов и вовсе ис­числяется сотнями; и все эти факты, еще не изгладившиеся из пам­ти, — результат ошибок проектирования. Во-вторых, сложным проектам оборудования соответствует не менее сложное и дорогостоящее произ­водство. В результате количество компаний, способных производить такие системы, ограничено располагаемыми ресурсами. В области про­граммного обеспечения таких ограничений нет. Существуют сотни ор­ганизаций, занимающихся выпуском программ, и тысячи очень слож­ных программных систем. Их количество и сложность ежедневно воз­растают. Это означает, что индустрия программного обеспечения вряд ли сможет отыскать решения своих проблем, подражая разработчикам оборудования. Скорее уж наоборот, поскольку системы автоматизиро­ванного проектирования и производства помогают конструкторам обо­рудования создавать все более сложные проекты, то это проектирование оборудования становится все более похожим на проектирование ПО.

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

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

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

Открытие номер два: дешевле и проще всего воплотить проект в жизнь и протестировать его. Неважно, сколь раз придется повторить процесс изготовления, — с точки зрения времени он почти ничего не стоит, а за­траченные на неудачный проект ресурсы полностью восстановимы. От­метим, что тестирование — это не только доказательство правильности проекта, но и часть его уточнения. Инженеры, конструирующие слож­ные аппаратные системы, часто строят модели (или хотя бы визуаль­но воспроизводят их средствами машинной графики). Это позволяет им «почувствовать» те аспекты проекта, которые невозможно уловить путем одного лишь анализа документации. При проектировании про­грамм такое моделирование невозможно и не нужно. Мы просто изготавливаем само изделие.

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

Это реалии сегодняшнего процесса разработки ПО. Все более сложные программные проекты создаются все большим числом людей и орга­низаций. Проекты кодируются на каком-то языке программирования, а затем проверяются и уточняются в цикле сборки/тестирования. Этот процесс изначально подвержен ошибкам и не отличается особой стро­гостью. Тот факт, что очень многие разработчики программ не желают поверить, что именно так он и работает, безмерно осложняет задачу.

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

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

Если уж заимствовать что-то из японских методик управления, то пре­жде всего то, что наказание рабочих за ошибки приводит к обратному результату. Вместо того чтобы силой заставлять разработчиков при­держиваться неверной модели процесса, мы должны пересмотреть сам процесс и сделать так, чтобы он помогал, а не препятствовал созданию более качественного ПО. Это лакмусовая бумажка в инженерном про­ектировании ПО. Когда мы говорим «инженерный», то имеем в виду организацию процесса, а не то, что для получения окончательного про­ектного документа необходима САПР.

Основная проблема разработки ПО заключается в том, что все являет­ся частью процесса проектирования. Кодирование — это проектирова­ние; тестирование и отладка — тоже часть проектирования. И то, что мы привычно именуем проектированием ПО, — всего лишь часть про­ектирования. Да, изготовление программного обеспечения обходится очень дешево, зато его проектирование невероятно дорого. ПО настоль­ко сложно, что существует множество аспектов проектирования, а зна­чит, и способов взглянуть на него. Проблема в том, что все эти аспек­ты взаимосвязаны (как, впрочем, и в проектировании оборудования). Как было бы здорово, если бы проектировщики верхнего уровня могли игнорировать детали алгоритмов модулей. Или если бы программи­сты могли забыть о проекте верхнего уровня, когда проектируют вну­тренние алгоритмы модуля. Увы, аспекты одного уровня проекта про­никают в другие. Выбор алгоритмов работы отдельного модуля может оказаться для общего успеха системы столь же важным, сколь и любая из сторон проекта верхнего уровня. Не существует иерархии важности аспектов проекта программы. Ошибка в проекте модуля самого нижне­го уровня может оказаться такой же фатальной, как и на самом верх­нем уровне. Проект программы должен быть полным и правильным во всех отношениях, иначе программа, построенная по этому проекту, будет содержать ошибки.

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

Но в действительности все работает не так, и теперь мы начинаем по­нимать, почему. Проект программы нельзя считать законченным, пока он не закодирован и не протестирован. Тестирование — это неотъемлемая часть процесса проверки и уточнения проекта. Проект структуры верхнего уровня — еще не полный проект программы, а лишь каркас, на который насаживается детальный проект. Наши возможности строго подтвердить правильность проекта верхнего уровня крайне ограниче­ны. Детальный проект в конечном счете влияет (по крайней мере, это не следует запрещать) на проект верхнего уровня точно так же, как все остальные факторы. Уточнение всех аспектов проекта — это процесс, ко­торый должен пронизывать весь цикл проектирования. Если какой-то аспект проекта замораживается и исключается из процесса уточнения, то следует ли удивляться, что окончательный проект получился пло­хим или даже неработоспособным?

Было бы прекрасно, если бы проектирование верхнего уровня ПО мож­но было сделать более точным инженерным процессом, но реальность мира программных систем далека от точности. Программное обеспече­ние слишком сложно и зависит от слишком многих внешних факторов. Бывает, что оборудование работает не совсем так, как предполагали проектировщики. Бывает, что в библиотечной процедуре есть недо­кументированное ограничение. С такого рода проблемами рано или поздно сталкивается любой программный проект. И выявляются они только при тестировании, просто потому, что выявить их раньше негде. А когда проблема обнаружена, приходится вносить изменения в про­ект. Если нам повезло, то изменения будут локальны. Но чаще рябь от них расходится по значительной части всего проекта (закон Мэрфи). Если какую-то часть проекта по той или иной причине изменить не­возможно, то прочие части приходится подстраивать. Нередко это при­водит к тому, что руководители воспринимают как «трюкачество», но таковы реалии разработки программ.

Например, недавно я работал над проектом, где между модулями А в В была обнаружена временная зависимость. К сожалению, внутренний механизм модуля А был скрыт абстракцией, не позволявшей вызывать модуль В в нужной последовательности. Естественно, к моменту обна­ружения этой проблемы было уже поздно изменять абстракцию модуля А. Как и следовало ожидать, далее последовал сложный набор «исправ­лений» внутренней структуры А. Еще до того, как мы закончили рабо­ту над версией 1, у всех появилось чувство, что проект разваливается. Каждое новое исправление грозило разрушить предыдущие. Это нор­мальное явление в проекте разработки ПО. В конце концов мы с кол­легами решились изменить проект, но, чтобы уговорить руководство, пришлось согласиться на неоплачиваемую переработку.

Такие проблемы гарантированно возникают в любом программном проекте типичного размера. Как ни старайся, что-то существенное обя­зательно упустишь. Здесь мы видим разницу между ремеслом и инже­нерным подходом. Опыт может подсказать нужное направление. Это ремесло. Но идти, полагаясь на опыт, можно лишь до тех пор, пока не вступишь на неизведанную территорию. А дальше нужно взять то, с чего мы начали, и улучшить его путем контролируемых уточнений. Это инженерный подход.

Небольшое замечание — все программисты знают, что проектная доку­ментация, составленная после, а не до написания кода, гораздо точнее. Теперь понятна и причина этого. Лишь окончательный проект, будучи отраженным в коде, является уточненным в ходе цикла сборка/тести­рование. Вероятность того, что первоначальный проект останется неиз­менным на протяжении этого цикла, обратно пропорциональна коли­честву модулей и программистов, участвующих в проекте. И она очень быстро становится неотличимой от нуля.

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

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

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

Рано или поздно проект программы должен быть представлен на не­коем языке программирования, а затем проверен и уточнен с помощью цикла сборки/тестирования. Притворяться, что это не так, просто глу­по. Подумайте сами, какие средства и методы разработки программ получили наибольшее распространение. В свое время прорывом счита­лось структурное программирование. Его популяризовал язык Pascal, который и сам приобрел популярность. Объектно-ориентированное проектирование — новое повальное увлечение, и в центре него находит­ся С++. А что не сработало? CASE-средства? Популярны, но не универ­сальны. Структурные диаграммы? То же самое. А также и диаграммы Уорнера-Орра, диаграммы Буча, диаграммы объектов — список може­те продолжить сами. У каждой технологии есть свои сильные стороны и один общий недостаток — это не настоящий проект программы. На самом деле единственной нотацией для проектирования ПО, которую можно назвать распространенной, является язык PDL и все, что на него похоже.

Это говорит о том, что коллективное подсознательное индустрии ПО инстинктивно сознает, что совершенствование техники программирования и особенно языков программирования для реальных задач не­измеримо важнее всего остального в отрасли. Это также говорит о том, что программисты заинтересованы в проектировании. Когда появится более выразительные языки программирования, разработчики примут их с радостью.

Посмотрим также на изменение процесса разработки ПО. Когда-то был популярен процесс водопада. Теперь мы говорим о спиральной разра­ботке и быстром прототипировании. Хотя для обоснования этих мето­дик в ходу такие выражения, как «снижение рисков» или «сокращение сроков поставки продукта», на самом деле в их основе лежит завуали­рованное желание начать кодирование на ранних стадиях жизненно­го цикла. И это хорошо. Это позволяет быстрее приступить к проверке и уточнению проекта с помощью цикла сборки/тестирования. Заодно повышается вероятность того, что проектировщики, разработавшие проект верхнего уровня, никуда не делись и могут принять участие в детальном проектировании.

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

И последнее: цель любого инженерного проектирования — получение некоторой документации. Понятно, что наиболее важны сами проект­ные документы, но ими дело не должно ограничиваться. Ведь кто-то же будет пользоваться программой. И весьма вероятно, что впоследствии система будет модифицироваться и совершенствоваться. И, следова­тельно, для программного проекта вспомогательная документация не менее важна, чем для «железного». Даже если забыть пока о руковод­стве пользователя, инструкции по установке и прочих документах, на­прямую не связанных с процессом проектирования, остается еще две важных задачи, которые должны быть решены с помощью вспомога­тельных проектных документов.

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

Во-вторых, вспомогательные документы нужны для того, чтобы доку­ментировать те аспекты проекта — как верхнего, так и нижнего уров­ня, — которые трудно извлечь из самого проекта. Многие такие аспек­ты лучше всего изображать графически, что затрудняет их включение в виде комментариев к исходному коду. Это не значит, что графическая проектная нотация лучше языка программирования. Относитесь к гра­фическим комментариям как к пояснительным надписям на чертежах оборудования. Никогда не забывайте, что именно исходный код, а не вспомогательная документация, определяет, что в действительности делает проект. В идеале хотелось бы иметь программные средства, спо­собные генерировать вспомогательные документы на основе исходного кода, но не будем требовать слишком многого. Пусть будут хотя бы ин­струменты, позволяющие программисту (или техническому писателю) извлекать из исходного кода определенную информацию для дальней­шего документирования. Без сомнения, поддерживать такую докумен­тацию в актуальном виде вручную нелегко. И это еще один аргумент в пользу более выразительных языков программирования, а также в пользу сведения вспомогательной документации к минимуму и окон­чательного оформления ее на как можно более поздней стадии проекта. И конечно же, хорошо бы располагать более совершенными инструмен­тами, чтобы не скатиться к карандашу, бумаге и грифельной доске.

Подведем итоги:

  • Реальная программа выполняется на компьютере. Это последова­тельность нулей и единиц, записанная на каком-то магнитном носи­теле. Это не листинг программы на С++ (или каком-то другом языке программирования).
  • Листинг программы — это проектный документ. А сам проект изготавливается компилятором и компоновщиком.
  • Изготовить реальную программу очень дешево и по мере увеличе­ния быстродействия компьютеров становится все дешевле.
  • Спроектировать реальную программу безумно дорого, поскольку программы невероятно сложны и практически все этапы создания программного продукта — это части процесса проектирования.
  • Программирование — это разновидность проектирования. Хорошие проектировщики поняли это и, не колеблясь, кодируют, когда необходимо.
  • Кодировать имеет смысл чаще, чем многим кажется. Зачастую про­цесс представления проекта в коде выявляет упущения и влечет за собой дополнительное проектирование. Чем раньше это случится, тем лучше окажется проект.
  • Коль скоро изготавливать ПО так дешево, формальные инженерные методы проверки работоспособности проектов не слишком востребо­ваны. Гораздо легче и дешевле изготовить, а потом протестировать проект, чем тратить усилия на доказательство его корректности.
  • Тестирование и отладка — эквивалент проверки и уточнения проекта в других инженерных дисциплинах. В правильном процессе разра­ботки важность этих этапов не принижается.
  • Есть и другие виды проектирования ПО — можете называть их про­ектированием верхнего уровня, проектированием модулей, струк­турным проектированием, проектированием архитектуры или как-то еще. В правильном процессе проектирования они учитываются и осознанно включаются соответствующие шаги реализации.
  • Все виды проектирования взаимосвязаны. Правильный процесс разработки предусматривает — порой радикальные — изменения про­екта, если на каком-то этапе проектирования выясняется, что это необходимо.
  • В процессе проектирования потенциально полезны разнообразные нотационные системы — в качестве вспомогательной документации или средства для упрощения проектирования. Однако они не явля­ются частью проекта программы.
  • Разработка ПО по-прежнему является скорее ремеслом, нежели ин­женерной дисциплиной. В основном это объясняется недостатком строгости в критически важных процессах проверки и улучшения проекта.
  • В конечном счете достижения в области разработки ПО зависят от успешного развития методов программирования, что, в свою оче­редь, означает дальнейшее совершенствование языков программи­рования. С++ можно считать таким совершенствованием. Он завое­вал популярность потому, что оказался основным языком програм­мирования, непосредственно поддерживающим проектирование ПО.
  • С++ — шаг в правильном направлении, но этого недостаточно.

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


Вуаля! А вот и продолжение, 13 лет спустя: http://www.developerdotstar.com/mag/articles/reeves_13yearslater.html

Вкратце, Джек Ривз только убедился в своей точке зрения. Однако, (да обратят внимания поклонники test-first programming concept, и слепо верящие в то, что итеративность и гибкость в agile решают все проблемы!) значимость архитектуры, или проекта верхнего уровня, серьезно возросла.

«Проектировать ПО 'в целом' трудно, и ни новые языки программирования типа Java или C#, ни графическая нотация типа UML не помогут человеку, который не знает, как за это взяться. … Отсюда следует, что важно делать правильно с первого раза, причем тем важнее, чем крупнее задача.»

«Из других вопросов, которым следовало бы уделить больше внимания, отмечу вспомогательную документацию, особенно относящуюся к архитектуре. … Но я по-прежнему считаю, что готовить её лучше после написания исходного кода, но никак не заранее.»


Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Блог:Роман Корешков/Продукт инженерной деятельности (в разработке ПО)»

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.