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

ФАКТ 29

Факт 29
       Программисты переходят от проектирования к кодированию тогда, когда задача разобрана до уровня "примитивов", которыми владеет проектировщик. Если кодировщик и проектировщик — это разные люди, то примитивы проектировщика, вероятно, не будут совпадать с примитивами кодировщика и это приведет к неприятностям.

Обсуждение
       В целом считается, что переход от проектирования к кодированию проходит гладко. И зачастую это так и есть - до тех пор, пока код пишет тот же человек, который проектировал приложение. Но в некоторых организациях существует довольно четкое разделение труда. Системные аналитики или системные инженеры выполняют работу по сбору требований. Проектировщики занимаются проектированием. А кодировщики пишут код. (Потом в таких организациях тестеры выполняют тестирование, но это уже другая история.) Иногда эти задачи решаются собственными группами. Временами в дело вступают внешние ресурсы (аутсорсинг).
       При таком разделении труда важно обсудить, как лучше всего осуществить переход от фазы проектирования к фазе написания кода. Обычно от проектировщика ожидают, что он спустится на тот уровень, где единицы кодирования представляют собой так называемые примитивы - фундаментальные программные единицы, которые хорошо известны и легко программируются. Это звучит очень просто. Но на самом деле это упрощенный взгляд. Трудности обусловлены тем, что у разных люди разные наборы примитивов. Что является фундаментальной программной единицей для одного, может не быть таковой для другого.
       Помните историю из Факта 18 о том, как я в первый раз писал программу генератора отчетов? Для меня самой сложной задачей было понять, как поступить с тем, что я называл циклическими суммами. Я потратил много усилий на проектирование этой задачи, прежде чем начал писать код. Но для тех, кто создал миллион генераторов отчетов (а это большинство программистов бизнес-систем), это была бы тривиальная задача. Для этих квалифицированных специалистов примитив есть нечто, в корне отличное (на гораздо более высоком уровне абстракции) от того, что есть примитив для меня, человека неискушенного. Квалифицированный, опытный программист бизнес-систем закончил бы проектирование и перешел к написанию кода гораздо раньше, чем это сделал я.
       Вот в чем все дело. Если проектировщик оперирует примитивами, уровень которых выше уровня примитивов, которыми оперирует кодировщик, то результаты проектирования не будут адекватной отправной точкой для последнего. Из-за этого ему придется потратить некоторое время, чтобы добавить дополнительные уровни проектирования, прежде чем он сможет приступить к кодированию. Переход от одной стадии к другой будет в лучшем случае неуклюжим, а может быть и неприятности, ведь кодировщик может и не прийти к тому законченному проектному решению, какого ожидал проектировщик
       Такие же трудности вызывает и противоположная ситуация. Если проектировщик неопытен (в упомянутой истории в этом качестве выступал я), то он дойдет до очень детализированного уровня проектирования А кодировщик, обладающий большим опытом, будет склонен отвергнуть этот чрезмерно доскональный уровень проектирования, отказаться от тщательно продуманной работы проектировщика и заменить ее на собственные проектные идеи. Это не означает, что проектировщики должны быть умнее или квалифицированнее, чем кодировщики. Надо, чтобы оба имели одинаковый набор базовых примитивов.
       Задача, казавшаяся на первый взгляд простой, - разделить проектирование и кодирование и организовать передачу хорошо известных примитивов, чтобы ликвидировать этот разрыв, - внезапно стала сложной. И если проектировщик и кодировщик не оперируют примитивами приблизительно одного уровня (случай маловероятный, особенно если учесть данные о том, что для большинства задач не существует единственного лучшего проектного решения), то передача дел может проходить далеко не гладко.
       По моему мнению, вследствие этого обстоятельства, разделение проектной работы и кодирования обычно является ошибкой. Мак-Брин [МсВreen, 2000] вторит мне, говоря, что "традиционное разделение труда неэффективно в разработке ПО". Конечно, если задача очень велика, то выбора может и не быть.

Полемика
       Как и многие другие факты из данной книги, этот не вызывает больших споров, поскольку он плохо усваивается. Я никогда не слышал, чтобы те, кто попытался разделить работы по проектированию и кодированию, обсуждали данную конкретную проблему Пожалуй, это происходит из-за того, что в большинстве подобных организаций проектировщики и кодировщики имеют примерно одинаковый уровень подготовки. Или из-за того, что проектировщики так хорошо знакомы с уровнем примитивов программистов, что результаты их работы удовлетворяют потребности последних.
       Там, где проектирование отделено от кодирования, это могут делать из-за того, что действует фактор "роста". В больших проектах обычно маленькая команда высокопрофессиональных специалистов выполняет начальную работу по сбору требований и проектированию, и только тогда, когда проектная архитектура хорошо вырисовывается, в дело вступает команда программистов. (Обратите внимание, что при данных обстоятельствах мотивом скорее является не разделение труда, а контроль трудовых затрат.) Поэтому данное явление гораздо чаще наблюдается в больших проектах, чем в малых. При таких обстоятельствах рассогласования между проектировщиком и кодировщиком не избежать, поэтому во многом неправильно (и вредно для боевого духа участников) вводить в штат проекта группу программистов, если для них еще нет работы.
       Мир веб-приложений породил целую новую культуру программирования. Проекты, обитающие в ней, малы (3x3- три человека на три месяца) и сильно ограничены временем. В этих условиях этап проектирования зачастую отсутствует вовсе - малые проекты имеют малые проектные нужды, и данная проблема возникает редко. Вот почему в мире гибкой разработки ПО и экстремального программирования не найти упоминания о ней - сторонники этих концепций в некоторых случаях даже подвергают сомнению необходимость какого бы то ни было проектирования.

Источник
       Как я уже говорил, данный факт редко обсуждается в литературе. Единственный источник, с которым я знаком, это моя собственная книга.
       — Glass, Robert L. 1995. "Ending of Desiga" In Software Creativity, pp. 182-83. Englewood Cliffs, NJ: Prentice-Hall.

Ссылка
       — McBreen, Pete. 2002. Software Craftsmanship. Boston: Addison-Wesley.


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



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

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


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