Здравствуйте, Сомов Александр, Вы писали:
AF>>Цели у анализа могут быть самые разные — от выявления понятий предметной области до построения как полной модели предметной области, так и модели системы — включая как статику, так и динамику.
СА>Я просто имел в виду, что тот анализ, про который вы говорите, он же к предметной области относится, а реализация — уже строится по результатам анализа. Или я опять не угадал?
В целом верно. Правда, что именно имел в виду byur лучше спросить у него.
Правда уточню, что в крупном проекте — сначала строится модель предметной области — происходящих в ней бизнес-процессов. Замечу — она не имеет ничего общего с кодом и по ней код писать нельзя.
Затем на её основе строится модель проектирования. Она может разительно отличаться и более того — отличается от модели предметной области, хотя бы тем, что в ней вводятся сущности, обычно, начисто отсутствующие в пердметной области — например контейнеры, базы данных, потоки и т.д. и т.п. — то есть сущьности программной системы. Эти сущьности необходимы для того, что бы можно было перейти к написанию кода.
Наконец по построению модели проетирования переходят к реализации — написанию кода в соответствии с моделью.
Соответственно при изменении пользовательских требования начинают с изменения модели предметной области, затем вносят изменения в модели проетирования и лишь затем — в исходный код.
Причём не важно — делается ли это формально и "правильно" — следуя методологии разработки или этот процесс происходит незаметно, подсознательно — в голове разработчика.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Угу. То есть и все ВАШИ анологии — тоже ложны
А я ни одной и не приводил. Только ваши же интерпретировал...
AF>Это повседневная практика некоторых проектов.
Софтверных?
AF> Объясняли миллион раз. Что бы описать некоторые аспекты модели общяпринятым, стандартным образом.
Миллион раз ответил, не нужен для этого UML, а в некоторых случаях даже вреден.
Вообщем спор очевидно бестолковый, вы все время почему-то скатываетесь записывая меня в ярые противники UML-я и строя свои доказательство на том что "... вот в больших проектах!..", что само по себе не серьезно, особенно учитывая, по Вашему же признанию, отсутствие у Вас опыта участия в этих самых больших проетах.
Байт с ним, с UML-ем используйте его как хотите, если Вам удобно что я — зверь какой? Я просто попытался объяснить, почему его неудобно использовать мне и почему я, его использования, по возможности, буду избегать. Однако в ходе спора принципиальных противоречий выяснилось два.
Мое глубокое убеждение состоит в том, что:
1. Архитектор обязан уметь программировать на языке проекта, который разрабатывает. И к этому заключению подталкивает и весь мой опыт, и опыт тех людей, которые обладают хотя бы небольшим авторитетом для меня в этой области, и чье мнение я учитываю при формировании собственного.
2. UML абсолютно бесполезен только в качестве документирования готового проекта. Собственно ради донесения этой мысли я и влез в этот спор.
Здравствуйте, Merle, Вы писали:
AF>>Это повседневная практика некоторых проектов. M>Софтверных?
Да и не только.
AF>> Объясняли миллион раз. Что бы описать некоторые аспекты модели общяпринятым, стандартным образом. M>Миллион раз ответил, не нужен для этого UML, а в некоторых случаях даже вреден.
Вы забыли сказать — с моей точки зрения. А вот с моей точки зрения — без UML можно было бы обойтись, но он там бывает весьма полезен, хотя и не всегда.
M>Вообщем спор очевидно бестолковый, вы все время почему-то скатываетесь записывая меня в ярые противники UML-я и строя свои доказательство на том что "... вот в больших проектах!..", что само по себе не серьезно, особенно учитывая, по Вашему же признанию, отсутствие у Вас опыта участия в этих самых больших проетах.
И сделали спор бестолковым именно те, кто вместо того, что бы исследовать те конкретные условия когда UML полезен или удобен — фанатично настаивали на том, что он бесполезен. Те кто защищали использование UML во-первых неоднократно говорили о том, что да без UML можно обойтись, а во-вторых говорили и о том, что процесс разработки, с использованием моделей на UML достаточно дорогой и оправдан только при определённых условиях.
M>Байт с ним, с UML-ем используйте его как хотите, если Вам удобно что я — зверь какой? Я просто попытался объяснить, почему его неудобно использовать мне и почему я, его использования, по возможности, буду избегать. Однако в ходе спора принципиальных противоречий выяснилось два.
В том то и дело, что не пытались. Для того, что бы это понять требуется следующее — какими проектами вы занимаетесь, сколько людей задейстовано в проектах, каковы требования заказчиков по части документирования, вопроизводимости, прогнозируемости вашей работы. Какого объёма требования заказчика, как часто вносятся модификации — и т.д. то есть конкретика. По этой конкретике можно будет понять ваши мотивы, а так же какие технологии можно было бы применить и с какими результатами.
Вы наверняка пришли к вашей технологии разрабоки совершенно закономерно и обоснованно, исходя из ваших конкретных условий. Но понять это возможно лишь если вы опишите причины, обусловившие ваш выбор.
M>Мое глубокое убеждение состоит в том, что: M>1. Архитектор обязан уметь программировать на языке проекта, который разрабатывает. И к этому заключению подталкивает и весь мой опыт, и опыт тех людей, которые обладают хотя бы небольшим авторитетом для меня в этой области, и чье мнение я учитываю при формировании собственного. M>2. UML абсолютно бесполезен только в качестве документирования готового проекта. Собственно ради донесения этой мысли я и влез в этот спор.
Я уважаю вашу точку зрения, но замечу, что по обоим пунктам существуют различные точки зрения. У меня свои взгляды на эту тему, я ими уже поделился.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Да и не только.
Скорее только не.
AF>Вы забыли сказать — с моей точки зрения.
Я ничего не забыл.
AF> А вот с моей точки зрения — без UML можно было бы обойтись, но он там бывает весьма полезен, хотя и не всегда.
Скорее далеко не вегда.
AF> И сделали спор бестолковым именно те, кто вместо того, что бы исследовать те конкретные условия когда UML полезен или удобен — фанатично настаивали на том, что он бесполезен.
Спор сделали бестолковым те, кто уверял что он где-то удобен, хотя сами его удобства так и не ощутили.
AF>Те кто защищали использование UML во-первых неоднократно говорили о том, что да без UML можно обойтись,
Не можно, а нужно.
AF> а во-вторых говорили и о том, что процесс разработки, с использованием моделей на UML достаточно дорогой и оправдан только при определённых условиях.
Этих определенных условий, реально нашлось только два.
AF> В том то и дело, что не пытались. Может просто кто-то не внимательно читал?
AF> Для того, что бы это понять требуется следующее — какими проектами вы занимаетесь, сколько людей задейстовано в проектах, каковы требования заказчиков по части документирования, вопроизводимости, прогнозируемости вашей работы. AF> Какого объёма требования заказчика, как часто вносятся модификации — и т.д. то есть конкретика.
Это, уж простите, лабуда, а не конкретика.
Я не однократно в своих сообщениях писал, что требования заказчика мы не рассматриваем, что если UML нужен заказчику, я его завалю этим UML-ем, и он будет доволен, хотя с реальным проектом этот UML будет иметь очень мало общего, это вообще не критерий. Это первое.
Второе, пргнозируемость к UML-ю не имеют никакого отношения, об этом я тоже писал.
Здравствуйте, Merle, Вы писали:
AF>>Вы забыли сказать — с моей точки зрения. M>Я ничего не забыл.
Вообще то на форуме принято помнить о том, что ваша точка зрения не является единственной...
Правда обычно участники команды RSDN напоминают об этом, а не наоборот.
Кстати, во избежания недоразумений, всё что я писал, пишу или буду писать — отражает сугубо мою точку зрения и моё восприятие действительности, так что всякие совпадения с чьими то ещё воззрениями, особенно умными, просьба считать случайными...
AF>> И сделали спор бестолковым именно те, кто вместо того, что бы исследовать те конкретные условия когда UML полезен или удобен — фанатично настаивали на том, что он бесполезен. M>Спор сделали бестолковым те, кто уверял что он где-то удобен, хотя сами его удобства так и не ощутили.
А с чего вы решили, что его удобство другие не ошущали? Просто приняв за критерий удобства то, что UML должен ипользоваться для непосредственной кодогенерации (а именно это и было в приведённых примерах) — естественно вы не смогли увидеть от него другой пользы. Ну а лично мне пришлось оценить все преимущества грамотно составленной документации, где широко и, главное, грамотно применялся UML. Это было огромное подспорье. Тем более, что было с чем сравнивать — другие документы, написаные в стиле слюни и карандашей — тоже содержали ценную информацию, но без автора она практически не извлекалась, да и с автором — зачастую тоже
AF>>Те кто защищали использование UML во-первых неоднократно говорили о том, что да без UML можно обойтись, M>Не можно, а нужно.
Вот в этом и проблема. Вы очень убедительно доказываете, что всегда умеете найтись и знаете, что ответить, только ответ даёте на уровне начинающего софиста. Кому можно? Кому нужно?
Вы бы хотя бы написали, почему его не нужно применять, к каким конкретно последствиям это привело бы. А так это простой обмен любезностями.
AF>> а во-вторых говорили и о том, что процесс разработки, с использованием моделей на UML достаточно дорогой и оправдан только при определённых условиях. M>Этих определенных условий, реально нашлось только два.
AF>> В том то и дело, что не пытались. M> Может просто кто-то не внимательно читал? Таки читали и очень внимательно. Кроме ряда голословных утверждений, вроде UML нужен только что бы пудрить мозги заказчику — конкретной аргументации было довольно мало. В итоге Вы (и другие противники UML) сумели привести следующие аргументы против UML:
1. Обойтись можно без него.
Да, можно. Как и без C#, C++, Java и программирования вообще. Но обычно смотрят не на то, можно ли обойтись, а на то, что же даёт применение технологии.
2. UML не гарантирует правильности построения модели
Конечно. А то, что вы пишете код на C#, С++ или чём угодно другом, ещё не гарантирует, что полученная программа будет делать то, что нужно заказчику, а не что-то другое — то есть тоже не гарантирует соответствие модели.
3. UML не гарантирует соответствие кода модели.
Естественно. А вы видели, что бы чертежи гарантировали, что бы дом им соответствовал? Что бы строители соблюдали строительные технологии и применяли именно те материалы, а не другие? Вот потому то за ними и нужен глаз да глаз.
В тех компаниях и организациях, где налажена дисциплина — почему то соответствует (если такая задача была поставлена). То есть это просто вопрос выбора и организации процесса разработки.
Но в том то и преимущество UML — что его можно применять гибко — от набросков, которые далеки от получившегося кода, до строго описания модели, по которому код можно генерировать. Обычно полезнее всего его применять в промежуточном варианте.
4. UML диаграммы гораздо дольше рисовать, чем рисовать на бумаге и объяснять словами.
Совершенно согласен. Толковую документацию вообще сложно и долго писать. Иногда — это большая работа, чем собственно написания кода. Что бы в этом убедиться достаточно написать алгоритм сортировки, например, а потом — его же грамотно описать. А главное — документация нужна далеко не всегда. Ну если она не нужна — так и не используйте. Модель — чем бы она не описывалась, тоже далеко не всегда нужна. Ведь никто и не утверждал, что вы обязательно должны использовать UML или обязательно должны писать документацию.
Опыт любого из нас это подтверждает, думаю и повседневная работа — тоже.
5. UML является далеко не полным описанием модели.
Так и есть. Никто и не говорил о том, что UML является полным описанием модели, даже более того — подчёркивали что он является не полным описанием. UML и задумывался, как единая система диаграмм, которая для получения качественного описания модели и тем более документации — дополняется текстовыми описаниями. Особенно хорошо это видно в случае с UseCases — которые являются текстовыми описаниями и которые лишь иногда (редко) имеет смысл описать в виде диаграммы — кружочков с названием внутри. И первая же ошибка, которую называют при описании UseCases — увлечение диаграммами вместо текста.
UML является всего лишь некоторой унифицированной системой описания части процессов, структур и явлений в графической форме. Не более того. И только в таком качестве и может быть полезен. Он не задумывался даже как графический язык, в отличие от SDL
6. UML понятен далеко не всем
7. UML требует обучения
И это так. Но я не видел ещё ни одного разработчика, даже начинающего, кто не мог бы научиться понимать диаграммы на UML более, чем за день. Этот результат по выразительности не достижим почти ни для одного языка программирования. Что же до рисования диаграмм — то во-первых оно нужно далеко не всем, а во-вторых проще, чем изучение большинства ЯВУ.
8. UML нужен лишь для оболванивания заказчика.
По-моему лучше чем написал byur здесь
написать будет сложно.
AF>> Для того, что бы это понять требуется следующее — какими проектами вы занимаетесь, сколько людей задейстовано в проектах, каковы требования заказчиков по части документирования, вопроизводимости, прогнозируемости вашей работы. AF>> Какого объёма требования заказчика, как часто вносятся модификации — и т.д. то есть конкретика. M>Это, уж простите, лабуда, а не конкретика.
Очень конкретно. M>Я не однократно в своих сообщениях писал, что требования заказчика мы не рассматриваем, что если UML нужен заказчику, я его завалю этим UML-ем, и он будет доволен, хотя с реальным проектом этот UML будет иметь очень мало общего, это вообще не критерий. Это первое.
Я имел в виду не то, требует ли заказчик применения UML (это выражденный случай, потому не интересен), а о том, в каком виде вы работаете с требованиями заказчика — как-то их описываете, формализуете — то есть вообще как-то ими управляете или же как у нас бывает в большинстве случаев принимаете к сведению (в уме) и двигаетесь дальше?
M>Второе, пргнозируемость к UML-ю не имеют никакого отношения, об этом я тоже писал.
Если UML используется как часть процесса, обеспечивающего прогнозируемость — то, вероятно, всё-таки имеет.
Здравствуйте, AndreyFedotov, Вы писали:
AF> Вообще то на форуме принято помнить о том, что ваша точка зрения не является единственной...
Я где-то утверждал обратное?
AF> А с чего вы решили, что его удобство другие не ошущали?
Из Ваших же признаний, в том, что Вы его не используете.
AF> Вы бы хотя бы написали, почему его не нужно применять, к каким конкретно последствиям это привело бы.
В очередной раз говорю — все наоборот. Вы вводите дополнительную сущность, Вам и доказывать, зачем она нужна.
AF> Кроме ряда голословных утверждений, вроде UML нужен только что бы пудрить мозги заказчику — конкретной аргументации было довольно мало.
Аргументация должна быть с вашей стороны и выглядит она довольно бледно, сводясь к "...вот в некоторых проектах..."
AF>В итоге Вы (и другие противники UML) сумели привести следующие аргументы против UML:
Мы не приводили аргументации против UML, мы приводили аргументацию против ваших утверждений.
AF> Да, можно. Как и без C#, C++, Java и программирования вообще. Но обычно смотрят не на то, можно ли обойтись, а на то, что же даёт применение технологии.
Так вот что она дает внятно никто не объяснил.
[skip]
Далее Вы насчитали восемь пунктов против использования UML-я и с семью из них согласились, однако тем не менее продолжаете настаивать на использовании UML-я аргументируя это оптяь какими-то мало имеющими отношения к делу аналогиями и весьма спорными утверждениями. Выглядит довольно странно.
Может хватит по кругу ходить?
Во-первых я ипользую UML — в тех случаях, когда мне это нужно.
Во-вторых, UML придумал не я, так что доказывать мне лично ничего не нужно.
В-третьих я так же как и вы пытался объяснить, для чего он мне нужен, где я им пользуюсь, а так же для чего он нужен другим и где им пользуются они.
Наконец, поскольку обсуждение приняло характер религиозного спора, предлагаю воздержаться от продолжения дискуссии.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, Сомов Александр, Вы писали:
СА>>>> Однако, это верно для очень квалифицированного программиста. M>>>Естественно, но лично я с турдом себе представляю архитектора, который не является квалифицированным программистом... СА>>А я об этом и говорю. Да здравствует код! Долой UML!
AF>Гениально. Правда я где то видел обратный лозунг: AF>Долой код! Да здравствует UML!
Где угодно, только не у меня.
AF>Да и денег у них поболее будет...
А там эти лозунги — маркетинг. Нужно же UML продавать. Книги, ПО и т.д.
AF>А как с быть с оптимизацией по производительности? AF>В итоге вы следуя своей, изначально неверной идее, просто напишете код низкого качества. Вот и весь результат. AF>Это тоже самое, если в телевизоре, холодильнике или автомобиле на каждой детали, даже самой маленькой детали — приклеивать том с описанием технологии её производства.
А ведь вам неизвестно, какой код я пишу. А код вполне качественный. Это уверено показывает год успешного сопровождения работающего проекта.
СА>>К тому (можно я тоже попередёргиваю ) — в предметной области, как правило и стрелочек с рамочками нет. AF>В том то и проблема, что сначала требуется построить адекватную модель предметной области — что бы потом по ней можно было построить модель программной системы.
Так не нужны стрелочки для построения модели.
B>>>Выдержка из вашего сайта о вас же ... СА>>Я, хоть во многом с Mystic'ом не согласен, но, всё же, это уже переход на личности. Вам что, кроме этого, больше нечего сказать по содержанию? B>Просто это аргументация бессмысленности дискусси конкретно с этим участником ... и все.
Так бы сразу и написали. Ну право же, гораздо корректнее было бы.
СА>>В любом случае, до определённых пределов можно соблюдать такую коммуникацию, что UML не нужен. Обычный язык достаточно эффективен. Следом, по эффективности, идёт код. А затем только формальные картинки. И вот архитектор должен хорошо владеть этими средствами в перечисленном порядке. B>Что есть эффективность? Эффективность эффективности рознь ...
Скатимся сейчас в формализм, а толку не прибавится. Я ведь понятно выразил свою точку зрения.
AF> Прямо как классики марксизма-ленинизма. Коммунизм должен быть построен. Есть большая разница между "должен" и что есть на самом деле. Вы и картинки в код поместите?
Вообще говоря, следование какой-нибудь методологии лучше, чем не следование ничему вообще. А если картинки очень нужны будут (ни разу не встретилось таких) — да, в код помещу.
AF>И что? Как это связано с документированием или не документированием модели (с использованием или без использования UML)?
Очень просто связано. Документирование модели вовсе не всегда нужно (с использованием или без использования UML).
AF> Почему то вы забыли о том, что бывают весьма интересные и оригинальные решения — от алгоритмов до архитектуры — ценность которых гораздо выше, чем того (часто кривого) кода, который их реализует?
Ценность работающего кода состоит только в том, какие результаты он приносит от использования. А framework'остроительство ради "интересных и оригинальных решений" мне уже надоело. Если вы хотите, чтобы команда высококвалифицированных разработчиков два года занималась чепухой, заставьте их писать какой-нибудь красивый framework.
AF> И помещать туда тонны текста, картинок, диаграмм?
Ничего не помещать, так как эти тонны не нужны.
AF> Да что вы в код то вцепились?! Прям как дети! "Вася смотри какой я класс состряпал". Половина оболтусов на форуме так и выступает.
А что же вы в картинки вцепились?! "Смотри, Петя, какие стрелочки". Вот — оставшаяся половина оболтусов.
AF> Поймите, часто бывает ситуация, когда есть проект, который тянется годами, когда изначально не ясно, что делать, а делать что-то надо.
Это нездоровая ситуация.
AF>И в этой ситуации — система пишется, притом, естественно, весьма далеко от идеала, но это всё хозяйство сертифицируется и отправляется клиентам — ибо бизнес не ждёт. И вот проходит 2-3-4 года за которые наконец-то становится ясно, что и главное как нужно делать.
Можно достичь такого понимания и за 2-3 месяца, причём без всяких картинок. Достаточно дать пользователям первую версию программы вообще с минимумом функциональности (и возможно даже вы не угадаете и вообще эта функциональность не будет нужна, но вам об этом скажут).
AF>Если всё это время строилась модель — на уровне бизнес-процессов, на уровне UML моделей, на уровне толковых описаний, то это даёт возможность переписать систему грамотно — с использованием более современных технологий. Так вот эта модель — квинтэссенция опыта — стоит гораздо дороже, чем весь написанный код.
А в моём случае вы будете не только модель иметь, но и работающий по ней код. Причём гораздо быстрее.
AF> В чём здесь роль UML? Да в том, что опыт накапливается годами, времени писать романы нет. А вот накидать диаграммку с пояснениями возможно. Люди приходят и уходят. И через 2-3 года найти концы почти не реально. И если не использовать UML (или любую другую общепринятую систему обозначений) — то у кого потом спрашивать, что имел в виду автор диаграммки 3 года назад?
У нас в проекте после 5 лет развития концы находятся очень просто, в том числе и потому, что мы не дорожим вещами даже 2-хлетней давности. Опыт накапливается, а они теряют ценность. В результате мы имеем не 5-летней давности картинки, а годовой давности (что гораздо лучше по качеству) код.
AF> Придумать систему обозначений, да ещё её задокументировать (по сути разработать стандарт) — эта работа может быть сопоставима по объёму с самим проектом. И ради чего? Ради фанатичного нежелания учить UML? Или ради высокомерного самомнения — что всё сделаем лучше?
Ничего кроме некоторого набора общих терминов, да описания функциональности, достаточно неформального, не требуется. Для пятилетнего проекта с размером команды разработчиков в 25 человек это описание по объёму и содержимому вполне таково, что пишется одним человеком за выходные. А большего просто не требуется.
СА>>Мы же не говорим о том, как быть с уже написанной лапшой, мы говорим, как писать код так, чтобы он не требовал (или требовал минимум) подобных дополнений. AF> Ещё раз. Часто код сразу пишется для мусорной корзины — потому, что его просто не возможно сразу писать хорошо. И его единственное предназначение — выработать модель, которая будет нужна в дальнейшем.
Правильно. А что — я не о том же? И разве ваши картинки точно также не попадут в мусорную корзину. Или их-то вы сразу хорошо пишите?
AF> Если код среднего качества — тем более не завершённый, то в этом случае (если нет информации об архитектуре) — его проще выкинуть или по частям переписать — в соответствии с требованиями.
А картинки среднего качества не бывают?
СА>>Ну этот десяток стрелочек (уж если захотелось что-то рисовать, а не использовать великий и могучий) — описать совсем не проблема. На это уйдёт час. А на освоение UML? B>Хм ... а сколько у Вас лично ушло времени на освоение собственно UML????
До сих пор осваиваю. Правда вяло очень, так как для работы не требуется. Исключительно из интереса.
Здравствуйте, Сомов Александр, Вы писали:
AF>>А как с быть с оптимизацией по производительности? AF>>В итоге вы следуя своей, изначально неверной идее, просто напишете код низкого качества. Вот и весь результат. AF>>Это тоже самое, если в телевизоре, холодильнике или автомобиле на каждой детали, даже самой маленькой детали — приклеивать том с описанием технологии её производства. СА>А ведь вам неизвестно, какой код я пишу. А код вполне качественный. Это уверено показывает год успешного сопровождения работающего проекта.
В этом я ни высказывал ни малейших соменений. Я указал лишь, что требование инкапсуляции противоречит до некоторой степени производительности кода, потому пытаясь повысить читаемость кода вы можете легко понизить его эффективность. Что бы бороться с этим были придуманы inline функции, например, но они спасают положение далеко не всегда.
Я ни в коем случае не имел в виду вас или кого-либо из участников дискуссии. Я всего лишь указал на последствия доведения идеи излишеней читабельности кода до её логического финала — падения эффективности кода.
СА>>>К тому (можно я тоже попередёргиваю ) — в предметной области, как правило и стрелочек с рамочками нет. AF>>В том то и проблема, что сначала требуется построить адекватную модель предметной области — что бы потом по ней можно было построить модель программной системы. СА>Так не нужны стрелочки для построения модели.
А вот это зависит от самой модели. Если это модель потоков — данных ли, товаров, денег или чего угодно другого — стрелочки будут в этой модели основными действующими лицами...
Здравствуйте, Сомов Александр, Вы писали:
AF>> Прямо как классики марксизма-ленинизма. Коммунизм должен быть построен. Есть большая разница между "должен" и что есть на самом деле. Вы и картинки в код поместите? СА>Вообще говоря, следование какой-нибудь методологии лучше, чем не следование ничему вообще. А если картинки очень нужны будут (ни разу не встретилось таких) — да, в код помещу.
И после этого какова будет читабельность этого кода?
Не говоря о том, что как вы сумеете это сделать чисто технически?
AF>>И что? Как это связано с документированием или не документированием модели (с использованием или без использования UML)? СА>Очень просто связано. Документирование модели вовсе не всегда нужно (с использованием или без использования UML).
О том, что документирование нужно далеко не всегда (как и UML) я написал уже минимум раз двадцать. Юрий Иванович по-моему тоже...
AF>> Почему то вы забыли о том, что бывают весьма интересные и оригинальные решения — от алгоритмов до архитектуры — ценность которых гораздо выше, чем того (часто кривого) кода, который их реализует? СА>Ценность работающего кода состоит только в том, какие результаты он приносит от использования. А framework'остроительство ради "интересных и оригинальных решений" мне уже надоело. Если вы хотите, чтобы команда высококвалифицированных разработчиков два года занималась чепухой, заставьте их писать какой-нибудь красивый framework.
А фреймворки то тут причём???! Это уже какие то эротические фантазии...
Я писал о разных ситуациях. На вскидку: я видел вариант базы данных оптимизированной под очень высокую производительность и большие объёмы данных. Её разработка заняла довольно много времени и там было очень много оригинальных и не тривиальных решений как на уровне архитектуры, так и на уровне алгоритмов. А вот качество кода по разным причинам — хромало. Несколько позже она была переписана с нуля по модели и достигла совсем другого уровня качества и производительности.
AF>> И помещать туда тонны текста, картинок, диаграмм? СА>Ничего не помещать, так как эти тонны не нужны.
А что нужно?
AF>> Поймите, часто бывает ситуация, когда есть проект, который тянется годами, когда изначально не ясно, что делать, а делать что-то надо. СА>Это нездоровая ситуация.
Это реальная ситуация.
AF>>И в этой ситуации — система пишется, притом, естественно, весьма далеко от идеала, но это всё хозяйство сертифицируется и отправляется клиентам — ибо бизнес не ждёт. И вот проходит 2-3-4 года за которые наконец-то становится ясно, что и главное как нужно делать. СА>Можно достичь такого понимания и за 2-3 месяца, причём без всяких картинок. Достаточно дать пользователям первую версию программы вообще с минимумом функциональности (и возможно даже вы не угадаете и вообще эта функциональность не будет нужна, но вам об этом скажут).
Куда мостится дорога благими намерениями — вы и сами знаете. Нельзя этого было сделать. Неужели если вы думаете, что люди, которые вели проект не додумались до столь тривиальной мысли? Но сделать этого было не возможно — по целому ряду причин.
AF>>Если всё это время строилась модель — на уровне бизнес-процессов, на уровне UML моделей, на уровне толковых описаний, то это даёт возможность переписать систему грамотно — с использованием более современных технологий. Так вот эта модель — квинтэссенция опыта — стоит гораздо дороже, чем весь написанный код. СА>А в моём случае вы будете не только модель иметь, но и работающий по ней код. Причём гораздо быстрее.
Код — да. Модель — нет. Потому, что на написание качественной документации времени нужно одинакого. И то, что вы её засовываете в код вам совершенно не поможет. Скорее наоборот.
AF>> В чём здесь роль UML? Да в том, что опыт накапливается годами, времени писать романы нет. А вот накидать диаграммку с пояснениями возможно. Люди приходят и уходят. И через 2-3 года найти концы почти не реально. И если не использовать UML (или любую другую общепринятую систему обозначений) — то у кого потом спрашивать, что имел в виду автор диаграммки 3 года назад? СА>У нас в проекте после 5 лет развития концы находятся очень просто, в том числе и потому, что мы не дорожим вещами даже 2-хлетней давности. Опыт накапливается, а они теряют ценность. В результате мы имеем не 5-летней давности картинки, а годовой давности (что гораздо лучше по качеству) код.
В вашей ситуации это может быть возможно. А в других — нет. Потом, естественно, картинки в модели все эти пять лет постоянно уточнялись — и это были вовсе не исходные наброски пятилетней давности.
AF>> Придумать систему обозначений, да ещё её задокументировать (по сути разработать стандарт) — эта работа может быть сопоставима по объёму с самим проектом. И ради чего? Ради фанатичного нежелания учить UML? Или ради высокомерного самомнения — что всё сделаем лучше? СА>Ничего кроме некоторого набора общих терминов, да описания функциональности, достаточно неформального, не требуется. Для пятилетнего проекта с размером команды разработчиков в 25 человек это описание по объёму и содержимому вполне таково, что пишется одним человеком за выходные. А большего просто не требуется.
Святая наивность. Вы ГОСТы хоть раз в жизни видели? Вы уверены что описание системы, которая должна строго соответстовать ГОСТ'ам могут за выходные написать даже двадцать человек?
СА>>>Мы же не говорим о том, как быть с уже написанной лапшой, мы говорим, как писать код так, чтобы он не требовал (или требовал минимум) подобных дополнений. AF>> Ещё раз. Часто код сразу пишется для мусорной корзины — потому, что его просто не возможно сразу писать хорошо. И его единственное предназначение — выработать модель, которая будет нужна в дальнейшем. СА>Правильно. А что — я не о том же? И разве ваши картинки точно также не попадут в мусорную корзину. Или их-то вы сразу хорошо пишите?
Попадут конечно. Сиграв свою роль. Так же как и мы сами...
Здравствуйте, Сомов Александр, Вы писали:
AF>> Если код среднего качества — тем более не завершённый, то в этом случае (если нет информации об архитектуре) — его проще выкинуть или по частям переписать — в соответствии с требованиями. СА>А картинки среднего качества не бывают?
Бывают. И именно в этом основная проблема. То, что народ не умеет и не хочет рисовать картинки, потому рисует отмазки, которые, естественно, далеки от реальной системы. От таких картинок и правда толку никакого. В таком случае рисование картинок — лишь глупая трата времени. Правда в этом случае прыгнуть выше уровня CMM Level 1 можно и не мечтать. Правда оно не всем и нужно...
AF>> Объясняли миллион раз. Что бы описать некоторые аспекты модели общяпринятым, стандартным образом. M>Миллион раз ответил, не нужен для этого UML, а в некоторых случаях даже вреден.
Это смотря КАК его применять . ...
M>Мое глубокое убеждение состоит в том, что: M>1. Архитектор обязан уметь программировать на языке проекта, который разрабатывает. И к этому заключению подталкивает и весь мой опыт, и опыт тех людей, которые обладают хотя бы небольшим авторитетом для меня в этой области, и чье мнение я учитываю при формировании собственного.
Можно узнать фамилии этих авторитетов?
M>2. UML абсолютно бесполезен только в качестве документирования готового проекта. Собственно ради донесения этой мысли я и влез в этот спор.
Что это значит "абсолютно бесполезен только в качестве документирования"???
M>Я не однократно в своих сообщениях писал, что требования заказчика мы не рассматриваем, что если UML нужен заказчику, я его завалю этим UML-ем, и он будет доволен, хотя с реальным проектом этот UML будет иметь очень мало общего, это вообще не критерий. Это первое. M>Второе, пргнозируемость к UML-ю не имеют никакого отношения, об этом я тоже писал.
Вы же читали мой пост на эту тему ... опять поднимаем вопрос, который уже рассмотрели вроле ...
Здравствуйте, Merle, Вы писали:
AF>> Вы бы хотя бы написали, почему его не нужно применять, к каким конкретно последствиям это привело бы. M>В очередной раз говорю — все наоборот. Вы вводите дополнительную сущность, Вам и доказывать, зачем она нужна.
Позиция несколько странная. К такому примитиву можно любую дискуссию свести. Это знаете, как, к примеру, от разработчиков FireFox требовать каких-то безапеляционных доказательств нужности этого продукта. В том смысле, что вот есть же IE, поэтому зачем нужен еще и FireFox, если он имеет абсолютно такое же назначение? Но тогда и ответ в стиле "А мне вот он нравится и все" можно считать вполне приемлемым. Нет смысла спорить о вкусах, если спор разворачивается исключительно в таком аспекте ...
Здравствуйте, Alexey Rovdo, Вы писали:
AR>Позиция несколько странная.
Какая есть.
AR>К такому примитиву можно любую дискуссию свести.
Не можно, а нужно, это единственный способ выяснить что-то конкретное.
AR>Это знаете, как, к примеру, от разработчиков FireFox <...>
Без аналогий совсем не получается?
Мы уже победили, просто это еще не так заметно...
