|
 |
Персональные инструменты
Просмотры |
|
Персональные инструменты |
|
||
|
|
Продукт инженерной деятельности (в разработке ПО)Материал из CustisWikiКороткая ссылка: Reeves В конце книги Мартинов «Принципы, паттерны и методики гибкой разработки на языке C#» я наткнулся на перепечатку прелюбопытнейшей статьи 1992 года «Что такое проектирование программного обеспечения» («What is software design»), Jack W.Reeves, C++ Journal. Я хотел всего-лишь сослаться на эту статью на русском языке и только привести несколько примечательных фраз, но о ужас:
Пришлось отсканировать, ибо оно того стоит. Для тех, кто не ленится учить родной язык 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». |
 |
 |
 |
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.