Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, Merle, Вы писали:
AR>>>А в чужом? M>>А в чужом тем более.
AF>И ты в состоянии по коду понять что имелось в виду при его написании? Какая идея за этим стояла? AF>Тогда ты не только телепат, но ещё и медиум в придачу...
Нет ничего невозможного Достигается упражнениями Вообще-то мир, в котором приходится вести разработку, неидеален. Большую часть времени приходится не разрабатывать новый функционал, а исправлять ошибки. А ошибки большей частью завязаны на технические особенности, не отраженные в UML. Так что от исходников в любом случае никуда.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, AndreyFedotov, Вы писали:
AF>>И ты в состоянии по коду понять что имелось в виду при его написании? Какая идея за этим стояла? M>Если код написан так, что его понять невозможно, то и UML не спасет.
Если я проектировщик/архитектор, то я не рассуждаю на уровне кода ... а напрягаться чтолы восстановить все из сырцов как-то не очень хочеться.
Но верно то, что для кода в стиле "спагетти" бесполезно восстанавливать дизайн/архитектуру хоть в UML хоть в чем угодно ... ее там просто нет ... Я уже это не раз тут говорил.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Никто и не говорит, что ты должен пользоваться UML диаграммами. Более того, всё зависит от библиотеки. Если это библиотека обёрток над простыми типами — от UML тут толку ноль. А если это API к сложной телекоммуникационной системе? Ты уверен, что тебе проше будет вычитывать описания каждой из 250 функций, для того, что бы выяснить, что запрос определённых данных делается с помощью десятка из них, причём в определённой последовательности? Или всё-таки проще посмотреть на диаграмму последовательностей, что бы всё это увидеть на одном экране за 5-10 секунд?
В API больше функций. Тут рулят exapmles. И русский (английский) язык. А вообще 250 функций это мало И как я разбирался с подобными вещами без UML??? Просматриваешь названия функций, отбрасываешь 95% тех, что уже не подходят, бегло читаешь то, что тебе надо...
M>>Символический язык, используемый в математике и физике, гораздо ближе к языкам программирования, нежели к UML. А вот картинки... но в серьезных книгах их не так уж и много... AF> Но ты же книги берёшь, а не исходный код! Ты же в книге читаешь тескст с формулами, а не просто голые формулы! А если речь идёт о пространственных интегралах или графиках смотришь на картинки и разбираешься — что там нарисовано.
А что есть исходный код в математике? Формулы. Я с друдом представляю книгу поматематике без формул... А картинки... они только в самом начале нужны, потом ты оперируешь формализмами. Если полистать Ландау и Ливщица, Общую алгебру (под ред. Скорнякова), Введение в теорию супрструн (Каку), того же Д. Кнута, то формулы там преобладают над рисунками, которые в большинстве случаем просто разбавляют текст.
Здравствуйте, Merle, Вы писали:
M>ВНЕШНИМ участникам не составит никакого труда все объяснить так же как и внутренним, если они именно работать дальше с проектом собираются.
Кто будет объяснять, если все "попали под грузовик" (были перекуплены конкурентами, уволены, ушли сами ... )?
M>Ну здрасьте, исходный код полностью самодостаточен.
Это позиция. Тут сложно спорить. Я только поясню свою точку зрения. С одной стороны, исходный код вроде и содержит всю информацию об архитектуре системы. Но довольно часто она представлена в трудной для быстрого восприятия форме. Вы же предлагаете отказаться от графических средств описания архитектуры системы (диаграммы) в пользу исключительно текстовых (комментарии в коде). Здравый смысл говорит за то, что вы искуственно сужаете свои возможности в доходчивой форме представить информацию (ИМХО).
AR>>Сегодня удобно использовать именно UML для представления в проектной документации той информации, которую нельзя или не наглядно представлять в исходном коде. M>Да неудобен UML в этом качестве, голые исходники зачастую удобнее.
А как же моя фраза "которую нельзя или не наглядно представлять в исходном коде". Вы полагаете, что такой информации быть не может или она недостойна того, чтобы попасть в документацию?
Здравствуйте, byur, Вы писали:
B>Если я проектировщик/архитектор, то я не рассуждаю на уровне кода ... а напрягаться чтолы восстановить все из сырцов как-то не очень хочеться.
Не приведи Господь работать под таким архитектором, который не рассуждает на уровне кода... Оно то может и красиво, если если не ложится на существующие технические решения, библиотеки, API, то пиши пропало.
B>>Классика, это когда заказчик вообще не знает UML , и в классике он ему и не нужен ... ему нужен работающий продукт. M>Это не классика — это идеал, а идеала не существует.
Может поспорим? Есть ложь а есть статистика ... нука скажите из вашего личного опыта сколько заказчиков, при разработке для них систем автоматизации бизнеса (i.e. не софтверные конторы), требовали от вас UML? Мой опыт ... из 11 заказчиков -- НИ ОДИН! А это 2 банка, транспортная контора, почтовая служба, медучереждения, религиозные организации, Мосэнерго и др. региональные АО Энерго, Росэнергоатом, ...
Дернул своего товарища по аське -- тоже нет ... а там... 7-й континент, Ашан, аптечная большая сеть.
Во, вспомнил, один мой знакомый на американов работает -- используют и отправляют им UML! более того даже юзкейсы пишут (правда не совсем правильно, но это детали)!... стоп, они аутсорсеры, на софтверную контору работают ...
А какие данные у вас? Просто сопставим данные .
Контор в России, которые могут потребовать UML (повторюсь, не софтверных!) я насчитал максимум 10, и сможет оценить его качество .
B>> А на счет приведенного случая -- если это так происходит ... скорее всего означает, что компания-разработчик имеет слабую квалификацию в области UML как такового, так и в зрелости процессов разработки M>Очень далеко идущие выводы из неверных предпосылок.
ОК, сколько в этой компании сертифицированных спецов именно по UML, и чьи сертификаты? Есть специалисты, скажем по RUP, тоже сертифицированные? У кого в нашей стране учились? Я знаю практически всех сертифицированных по RUP спецов в России ... инетерсно кто ж у вас работает ?
B>> (только не нужно связвать зрелость процессов с UML, это не верно). M>Но Вы же только что это сделали.
С каких это пор в русском языке связка "как ..., так и .." эквивалентна логическому "И"???
B>> Вот только не корректно из этого конкретно примера/нескольких примеров делать всеобъемлющие выводы. M>Ой, золотые слова. Вот когда в следующий раз будете приводить пример успешного проекта с использованием, UML вспомните их пожалуйста.
А я ни кого не убеждаю использовать UML ... я просто опрвергаю утверждение, что он бесполезен и непрактичен .
Здравствуйте, Mystic, Вы писали:
M>А что есть исходный код в математике? Формулы. Я с друдом представляю книгу поматематике без формул... А картинки... они только в самом начале нужны, потом ты оперируешь формализмами. Если полистать Ландау и Ливщица, Общую алгебру (под ред. Скорнякова), Введение в теорию супрструн (Каку), того же Д. Кнута, то формулы там преобладают над рисунками, которые в большинстве случаем просто разбавляют текст.
Разные разделы математики по-разному воспринимаются без картинок. Например дифгеометрию довольно трудно понять без этого. А теория супструн, основанная, кстати, во многом именно на дифгеометрии, — книга отнюдь не понятная. Возможно именно из-за того, что авторы местами пренебрегают графическим средствами иллюстрации своих мыслей. Тому, кстати, есть довольно банальные причины, в корне которых лежит нестандартность этих картинок. Рисование нестандартных (а в теории супструн и дифгеометрии таких стандартов нет) картинок и графических элементов отнимает уйму времени и требует достаточно высокой квалификации от верстальщика (и издатели обычно перекладывают эту работу на самих авторов, а авторы, где могут, избегают это делать).
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, byur, Вы писали:
B>>Если я проектировщик/архитектор, то я не рассуждаю на уровне кода ... а напрягаться чтолы восстановить все из сырцов как-то не очень хочеться.
M>Не приведи Господь работать под таким архитектором, который не рассуждает на уровне кода... Оно то может и красиво, если если не ложится на существующие технические решения, библиотеки, API, то пиши пропало.
Выдержка из вашего сайта о вас же ...
"Образование — среднее
...
Увлечение №1 — программирование.
В число моих знаний в области программирования я отношу Delphi (это мой любимый язык), C++, Assembler "
...
"Понятно (увлечение №1), что я пишу программы, но ничего путного я за свою жизнь так и не написал. Так, курсовые, дипломные ..."
Конечно программируя в Дельфи вы врядли используете UML ... ... воистину воинствующее незнание! И при этом вы пытаетесь рассуждать об архитектуре???? И аппелируете к своему опыту ... ! И небось еще за Ющенка голосовали (это шутка ...).
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Никто и не говорит, что ты должен пользоваться UML диаграммами. Более того, всё зависит от библиотеки. Если это библиотека обёрток над простыми типами — от UML тут толку ноль. А если это API к сложной телекоммуникационной системе? Ты уверен, что тебе проше будет вычитывать описания каждой из 250 функций, для того, что бы выяснить, что запрос определённых данных делается с помощью десятка из них, причём в определённой последовательности? Или всё-таки проще посмотреть на диаграмму последовательностей, что бы всё это увидеть на одном экране за 5-10 секунд?
M>В API больше функций. Тут рулят exapmles. И русский (английский) язык. А вообще 250 функций это мало И как я разбирался с подобными вещами без UML??? Просматриваешь названия функций, отбрасываешь 95% тех, что уже не подходят, бегло читаешь то, что тебе надо...
И это быстрее, чем посмотреть на одну диаграмму?
Да, но далеко не всегда это хорошо. Особенно когда речь заходит о сложных вещах. В API в большинстве случаев рассматриваются примеры очевидных вещей, в основном демонстрирующие правильную передачу аргументов функциям, нежели протоколы.
А вот когда не ясно, почему написанный по API код не работает — приходится или искать чей то работающий исходник и по нему выяснять протокол вызова, или книжки читать, или вообще методом тыка разбираться ...
M>>>Символический язык, используемый в математике и физике, гораздо ближе к языкам программирования, нежели к UML. А вот картинки... но в серьезных книгах их не так уж и много... AF>> Но ты же книги берёшь, а не исходный код! Ты же в книге читаешь тескст с формулами, а не просто голые формулы! А если речь идёт о пространственных интегралах или графиках смотришь на картинки и разбираешься — что там нарисовано.
M>А что есть исходный код в математике? Формулы. Я с друдом представляю книгу поматематике без формул... А картинки... они только в самом начале нужны, потом ты оперируешь формализмами. Если полистать Ландау и Ливщица, Общую алгебру (под ред. Скорнякова), Введение в теорию супрструн (Каку), того же Д. Кнута, то формулы там преобладают над рисунками, которые в большинстве случаем просто разбавляют текст.
Это так, но смысл то не в этом. Что бы понять математическую модель, ты пользуешься её описанием, а не только самой моделью. Если описание хорошее — сама модель (конкретные выкладки, то есть реализация) — может вообще не понадобиться. А вот без описания понять, что имелось в виду — часто вообще не возможно. Свёртка например используется как в обработке сигналов, так и в экономике. Но по уравнению — для чего оно — не понять.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, byur, Вы писали:
B>> рекоммендую восполнить пробелы в ваших знаниях, а потом дискутировать ... M>Рекомендую не рекомендовать...
На вашем же сайте про вас вы сами все и написали ... так что на правах более опытного товарища таки рекоммендую ... За сим с вами прекращаю дискуссию и другим советую тоже.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, AndreyFedotov, Вы писали:
AF>> Аргументируй — что есть более полезное? M>Код более полезен, UML не имеет ничего общего с кодом, особенно если разработчик недоступен. В такой ситуации он не просто бесполезен — он вреден.
Если речь идёт о правке ошибок в данном конкретном коде — то это так. А вот если речь идёт о реализации исходной идеи — самой модели — то вреден как раз код.
AF>> Ты интересно и математику и физику только по исходным кодам учил? M>Я уже говорил об излишнем увлечении ложными аналогиями?
И кто определяет ложность аналогий?
AF>> Но опять-таки оно нужно не им лично, а тем спецам, которых они наймут. M>Спецам он тем более не нужен, как тут уто-то совсем не давно очень убедительно доказал..
Хорошо. Как спец по микроэлектронике — могу легко подсунуть тебе схемку на пару десятков процов и FLEX кристаллов. Разбирайся как с ней работать по этой самой схемке
Не поможет — предложим VHDL модель. Это кстати иходный код. То-то смешно будет...
Может в этой ситуации твоя уверенность что код всё немного поубавится...
Ну а если ты джедай, который всё это знает — то не совсем понятно — ты от всех остальных стало быть требуешь вступления в джедайский орден?
Здравствуйте, byur, Вы писали:
B>Здравствуйте, Merle, Вы писали:
M>>Здравствуйте, byur, Вы писали:
B>>> рекоммендую восполнить пробелы в ваших знаниях, а потом дискутировать ... M>>Рекомендую не рекомендовать...
B>На вашем же сайте про вас вы сами все и написали ... так что на правах более опытного товарища таки рекоммендую ... За сим с вами прекращаю дискуссию и другим советую тоже.
Сорри, не вам адресовано ... а Mistik ... ошибся в запале ... еще раз прошу прощения.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, AndreyFedotov, Вы писали:
AF>>И ты в состоянии по коду понять что имелось в виду при его написании? Какая идея за этим стояла? M>Если код написан так, что его понять невозможно, то и UML не спасет.
Дело не в том, как написан код. Дело в том, что в коде написано не все. А если в коде только половина из того, что должно быть? А если код написан не верно — отражает не ту модель, что должна была быть? И как ты это поймёшь по коду?
Здравствуйте, byur, Вы писали:
B>Здравствуйте, AndreyFedotov, Вы писали:
B>Андрей, посмотри что этот господин про себя пишет на своем же сайте сайте ... не стоит с ним спорить (см. http://mystic2000.newmail.ru/)
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, AndreyFedotov, Вы писали:
AF>>Здравствуйте, Merle, Вы писали:
AR>>>>А в чужом? M>>>А в чужом тем более.
AF>>И ты в состоянии по коду понять что имелось в виду при его написании? Какая идея за этим стояла? AF>>Тогда ты не только телепат, но ещё и медиум в придачу...
M>Нет ничего невозможного Достигается упражнениями Вообще-то мир, в котором приходится вести разработку, неидеален. Большую часть времени приходится не разрабатывать новый функционал, а исправлять ошибки. А ошибки большей частью завязаны на технические особенности, не отраженные в UML. Так что от исходников в любом случае никуда.
Ну а если в коде реализована не вся необходимая функциональность?
Здравствуйте, byur, Вы писали:
B>Если я проектировщик/архитектор, то я не рассуждаю на уровне кода ...
А следовало бы. Все беды как раз от аритекторов, которые забыли что такое программировать.
Архитектор — он как хирург, как совсем не давно кто-то очень метко заметил, без практики программирования стремительно теряет квалификацию.
B> а напрягаться чтолы восстановить все из сырцов как-то не очень хочеться.
Но при внятном коде напрягаться приходится меньше, чем восстанавливать все из UML.
Здравствуйте, byur, Вы писали:
B>Контор в России, которые могут потребовать UML (повторюсь, не софтверных!) я насчитал максимум 10, и сможет оценить его качество .
Может я по русски разьяснять разучился, но смысл моих постингов заключался в том, что качество UML-я никого не интересуют, интересуют лишь три буквы.
B>ОК, сколько в этой компании сертифицированных спецов именно по UML, и чьи сертификаты?
Слава байту ни одного, ибо нафиг не нужен.
B>С каких это пор в русском языке связка "как ..., так и .." эквивалентна логическому "И"???
С очень давних.
B> я просто опрвергаю утверждение, что он бесполезен и непрактичен .
Пока не удается..
Здравствуйте, Alexey Rovdo, Вы писали:
AR>Кто будет объяснять, если все "попали под грузовик" (были перекуплены конкурентами, уволены, ушли сами ... )?
Исходный код и комментарии к нему.
AR> Здравый смысл говорит за то, что вы искуственно сужаете свои возможности в доходчивой форме представить информацию (ИМХО).
А что говорит здравый смысл в ситуации когда графическое представление не синхронизировано с тестовым?
И в ситуации, когда графическое представление понять не менее сложно чем текстовое?
И какого мнения здравый смысл придерживается по поводу затрат на формирование графического представления, и на его понимание, учитывая два предыдущих фатальных недостатка?
AR>А как же моя фраза "которую нельзя или не наглядно представлять в исходном коде". Вы полагаете, что такой информации быть не может или она недостойна того, чтобы попасть в документацию?
Я полагаю, что нет такой информации о проекте, которая не выразима исходным кодом.
Вообще-то мир, в котором приходится вести разработку, неидеален. Большую часть времени приходится не разрабатывать новый функционал, а исправлять ошибки. А ошибки большей частью завязаны на технические особенности, не отраженные в UML. Так что от исходников в любом случае никуда.
Мы уже победили, просто это еще не так заметно...
