UML-модели и чертёжи дома - неправильная аналогия
От: Кодёнок  
Дата: 05.07.05 05:53
Оценка:
Вот подумалось. Есть такая профессия — архитектор ПО, который в конечном счёте выдает множество схем и диаграмм, описывающих архитектуру систему. И эти схемы сравнивают с чертежами дома, а написание программы без (детального) проектирования сравнивают с построением дома в лоб, без чертежей.

Таким образом,

проектирование = рисование чертежей
кодирование = строительство
тестирование,
внедрение.

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

Правильная аналогия такая:

проектирование = рисование эскиза (архитектура, выраженная UML-схемами = ПРИМЕРНЫЙ образ готовой системы)
кодирование = рисование чертежа (исходный код = чертёж)
сборка = строительство
тестирование,
внедрение.

Разница такая, что при каждой сборке программа строится заново, в отличие от дома. Вы видели дом, который разрушается и строится опять, в улучшенном варианте, каждый месяц? И правильной аналогией чертежу архитектра является именно исходный код, потому что из одного исходного кода получается одна программа (машинный код). А некомпилирующаяся программа — это якобы чертёж, который на самом деле нельзя построить.

Таким образом, сравнение написания программы без проектирование со строительством без чертежей (проекта) неверное. Если вы когда-нибудь строили, то знаете, что без проектирования можно построить только собачью будку, и то вряд-ли — мерять и сверять придётся не раз А вот небольшие и даже средние программы миллионы программистов успешно создают в одиночку.

Архитектура системы строится так, что менять её потом нельзя. (По крайне мере, в одной фирме, где главной частью процесса было проектирование, мне несколько раз сказали именно так). Если обнаруживается, что какая-то иерархия классов ненужная и её можно значительно упростить, то это ошибка архитекторов, за которую их бьют Если сравнивать проект системы с эскизом, то всё понятно — никакой рефакторинг, ни изменение набора фич, не превратят дворец в стадион — это принципиально разные продукты. А если сравнивать проект с чертежом? Мне почему-то трудно представить систему, которую нельзя рефакторить вообще. Имеется ввиду, существенно рефакторить — изменить архитектуру классов, удалять и вводить сущности.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.