|
Страница 2 из 19
Предсказуемый или адаптивный? Проектирование и конструирование Традиционным образцом для методологий программирования являются инженерные дисциплины, такие, например, как гражданское строительство и машиностроение, где особое внимание уделяется планированию, которое предшествует непосредственному строительству. Инженеры разрабатывают целый ряд чертежей, в которых точно указывается, что именно должно быть построено, и как соединить все составляющие в единое целое. Во время работы над этими чертежами принимается много различных проектных решений - например, как распределять груз на мосту и т.п. После этого чертежи передаются другой группе людей, чаще всего, вообще в другую компанию, которая будет заниматься собственно строительством. Принято считать, что строители в точности воспроизводят все, что было обозначено на чертежах. В действительности, строители сталкиваются при этом с некоторыми проблемами, однако, как правило, они несущественны. Чертежи, где представлены отдельные элементы строительства, ложатся в основу подробного чертежа, который позволяет определить конкретные задачи и зависимости между ними. А это, в свою очередь, дает возможность рассчитать стоимость и временные рамки строительства. Кроме того, здесь же подробно описывается, каким образом строители должны делать свою работу. Благодаря этому работа строителей становится еще менее интеллектуальной, хотя, разумеется, нередко требует очень хороших навыков ручного труда. Итак, в данном случае перед нами два совершенно разных вида деятельности. С одной стороны, проектирование, которое является трудно прогнозируемым процессом, и для которого требуются дорогостоящие творческие специалисты, с другой - конструирование, которое прогнозировать гораздо легче. Как только проект готов, можно планировать конструирование. Как только готов план, конструирование становится вполне предсказуемым процессом. В гражданском строительстве фаза конструирования гораздо масштабнее, нежели проектирование и планирование - как с точки зрения бюджета, так и по времени. Подобным образом выглядит и подход к разработке программного обеспечения, принятый во многих методологиях: считается, что необходимо иметь предварительный план работ, по которому могут работать люди более низкой квалификации. Для этого проектирование должно быть отделено от конструирования. Следовательно, нужно спроектировать процесс создания программного продукта таким образом, чтобы работа по непосредственному конструированию (при наличии плана) стала несложной. Итак, какую же форму должен иметь такой план? Многие считают, что роль плана должна играть нотация, созданная, например, при помощи языка UML. Если с помощью UML можно отобразить все существенные проектные решения, значит, можно создать нужный план и передать его затем кодировщикам, которые выполнят задачу по конструированию. Однако здесь возникает важный вопрос: можно ли создать такой план, который превратит кодирование в относительно несложную работу? И, если да, то является ли кодирование настолько дорогим и долговременным процессом, чтобы подобный подход оправдывал себя? Все это заставляет задуматься еще над несколькими вопросами. Во-первых, насколько сложно довести проект, выполненный на языке UML, до такого состояния, когда его можно передавать программистам. Проблема состоит в том, что нотация на языке UML может выглядеть очень хорошо на бумаге и при этом содержать в себе серьезные дефекты, которые проявятся только тогда, когда начнется работа по непосредственному программированию. В гражданском строительстве создатели моделей опираются на многолетний опыт, зафиксированный в целой системе правил. Кроме того, базовые положения модели (например, проектирование взаимодействия различных сил) поддаются математическому анализу. В отличие от таких моделей, UML и подобные им диаграммы можно проверить только одним образом - с помощью экспертной оценки. Конечно, такая проверка приносит свои плоды, однако при этом кое-какие ошибки могут остаться, и вы узнаете о них только в процессе кодирования или тестирования. Даже опытные проектировщики (каковым я считаю, к примеру, себя) нередко испытывают удивление, видя как их план воплощается в программном продукте. Теперь относительно сравнительной стоимости. При строительстве моста на работы по проектированию уходит около 10% от всей стоимости работ. Остальное - затраты на конструирование. В программных разработках время, которое тратится на кодирование намного меньше (Макконнелл (McConnell) предположил, что в большом проекте на кодирование и написание тестового кода приходится всего 15%, то есть цифра, с точностью до наоборот повторяющая соотношение планирования и конструирования при постройке моста. Даже если считать тестирование частью конструирования, то все равно проектирование займет не менее 50% работ.) Отсюда вопрос о сущности проектирования при разработке программных продуктов и его отличиях от проектирования в других областях инженерной деятельности. Наличие подобных вопросов заставило Джека Ривза (Jack Reeves) предположить, что на самом деле проектным документом является исходный код, а вся фаза конструирования сводится к использованию компилятора и компоновщика. И в самом деле, все, что можно отнести к конструированию, может и должно быть автоматизировано. Размышляя обо всем этом, можно прийти к следующим выводам: - При разработке программного обеспечения конструирование обходится настолько дешево, что расходы на него можно вообще не учитывать
- При разработке программного обеспечения основной объем работ приходится на проектирование, для которого нужны талантливые творческие специалисты
- Любой творческий процесс труднопредсказуем, поэтому прогнозируемость в данном случае может стать недостижимой целью
- При разработке программного обеспечения принципы гражданского строительства и машиностроения нужно использовать очень осторожно. Это совершенно другой вид деятельности, для которого необходим другой процесс
|