Здравствуйте, Gaperton, Вы писали:
L>>Понять поведение незнакомого кода значительно проще, если ты имеешь представление об общей структуре оного. "UML-квадратики" в этом очень помогают.
G>Неужели?
G>"Квадратики" не помогают тебе понять общую структуру. Ты можешь свое понимание, когда оно у тебя уже есть, выразить в терминах квадратиков, это да. А когда оно у тебя уже есть — тебе лично с этого никакого толку не будет.
Т.е. вариант, когда диаграмма есть и написана кем-то другим до тебя у тебя выпал из рассмотрения?
G>И нет никакого смысла тратить время на создание "сокровища" в виде диаграмм классов, которые при помощи розы строятся за минуту в любой момент. И будут при этом актуальны.
За минуту строится треш, а не диаграмма. На создание таких диаграмм действительно тратить время не стоит.
Но построив даже трешевую диаграмму, можно начать с ней играться, перетасовывая туда-сюда "кубики", пытаясь в этой мешанине выискать структуру. С кубиками это делать куда проще, чем исключительно по коду.
Здравствуйте, Gaperton, Вы писали:
G>"Квадратики" не помогают тебе понять общую структуру.
Если тебе лично квадратики не помогают, это не означает, что они не помогают другим.
Мне помогают. Я точно не уникум.
Код, кстати, я пишу и читаю в большом количестве.
Что со мной будешь делать?
AN>С другой стороны, заказчик проекта не ставит задание разработать успешный продукт, он заказывает конкретный продукт и хочет получить "успешный проект" — разработанный в срок, при запланированных ресурсах, с приемлемым количеством ошибок, удобный в сопровождении/развитии и пр. Мне думается, что непродуманный "спагетти проект" никак не пойдет на звание такого "успешного проекта", что однако не запрещает ему выступать в роли успешного продукта.
Не надо вводить сущностей сверх необходимого. Продукт, проект — все это давно уже научились выражать в финансовом смысле. Если поддержка написанного начинает становиться убыточной — поддержку прекращают, проект закрывают. Вы пишете о том, что в свое время ваш (теперь уже ваш!) проект разрабатывали непродуманно — иными словами, работали в ущерб качеству, увеличивая другие показатели (например, брали разработчиков подешевле, и требовали от них работать побыстрее). Видимо, в тот момент компромисс был именно таким. Сейчас компромисс другой — проект, видимо, перестал приносить достаточно прибыли и его скинули вам на поддержку (возможно, еще более удешевив). На что вы жалуетесь?
SD>>Более того, сами правки станут значительно более быстрыми. Поверьте, всякие там TDD не на пустом месте возникли. AN>Весьма тяжело это представить. Это что то типа алгоритма как из Г. сделать конфетку?
Это, скорее, алгоритм, рекомендующий завернуть какашку в пакетик, чтобы при переноске до места утилизации не испачкаться и не провонять. Для вас сейчас существующая система — "черный ящик", поскольку вы вряд ли осилите понять 120 человеко-лет какокода. Если осилите — значит, код-то неплох!
Вот и обложите ее тестами так, чтоб можно было относительно смело вносить правки. Может даже и рефакторить. Кто знает, вдруг вы проект оживите.
SD>>Здорово! В принципе, вы могли бы эту "картинку" получить от первоначальных разработчиков. Просто попросили бы объяснить. Вам бы нарисовали, на доске ли, или на бумажке. AN>Для это нужно как минимум иметь подобную возможность.
Вас не пущают к изначальным разработчикам? Плохо. Самому понять чужую логику 10-летней давности редко когда получается. Может, попробуете договориться с начальством, чтобы вам, к примеру, выделяли хотя бы 2-4 часа в неделю на интервью с теми разработчиками?
Здравствуйте, SkyDance, Вы писали:
AN>>С другой стороны, заказчик проекта не ставит задание разработать успешный продукт, он заказывает конкретный продукт и хочет получить "успешный проект" — разработанный в срок, при запланированных ресурсах, с приемлемым количеством ошибок, удобный в сопровождении/развитии и пр. Мне думается, что непродуманный "спагетти проект" никак не пойдет на звание такого "успешного проекта", что однако не запрещает ему выступать в роли успешного продукта.
SD>Не надо вводить сущностей сверх необходимого.
с одной у меня ничего не получается. Я не ограничиваюсь простыми исключительно софт. продуктами. SD>Продукт, проект — все это давно уже научились выражать в финансовом смысле. Если поддержка написанного начинает становиться убыточной — поддержку прекращают, проект закрывают.
Не обязательно, продукт может быть успешным, а поддержка софта слишком дорогой SD>Вы пишете о том,
Вы точно помните что я это писал? SD> что в свое время ваш (теперь уже ваш!) проект разрабатывали непродуманно — иными словами, работали в ущерб качеству, увеличивая другие показатели (например, брали разработчиков подешевле, и требовали от них работать побыстрее). Видимо, в тот момент компромисс был именно таким. Сейчас компромисс другой — проект, видимо, перестал приносить достаточно прибыли и его скинули вам на поддержку (возможно, еще более удешевив). На что вы жалуетесь?
Мне кажется, Вы меня с кем то путаете.
SD>>>Более того, сами правки станут значительно более быстрыми. Поверьте, всякие там TDD не на пустом месте возникли. AN>>Весьма тяжело это представить. Это что то типа алгоритма как из Г. сделать конфетку?
SD>Это, скорее, алгоритм, рекомендующий завернуть какашку в пакетик, чтобы при переноске до места утилизации не испачкаться и не провонять. Для вас сейчас существующая система — "черный ящик", поскольку вы вряд ли осилите понять 120 человеко-лет какокода. Если осилите — значит, код-то неплох! SD>Вот и обложите ее тестами так, чтоб можно было относительно смело вносить правки.
и сколько понадобится тестов на 120 человеко-лет какокода?
Но мне непонятно как написание теста ускоряет правку кода. Видимо тут у нас опять разные понятия. SD> Может даже и рефакторить. Кто знает, вдруг вы проект оживите.
Ну разве что действие будет происходить в голливудском фильме. SD>>>Здорово! В принципе, вы могли бы эту "картинку" получить от первоначальных разработчиков. Просто попросили бы объяснить. Вам бы нарисовали, на доске ли, или на бумажке. AN>>Для это нужно как минимум иметь подобную возможность.
SD>Вас не пущают к изначальным разработчикам? Плохо.
Часто их просто уже нет в доступности. SD>Самому понять чужую логику 10-летней давности редко когда получается. Может, попробуете договориться с начальством, чтобы вам, к примеру, выделяли хотя бы 2-4 часа в неделю на интервью с теми разработчиками?
И кстати, вопрос задавал не я, мне договарится не к чему.
Здравствуйте, bkat, Вы писали:
B>Если же вернуться к топикстартеру, то если он хочет понять как работает система, B>то он будет рисовать картинки.
Много раз приходилось разбираться в коде проектов разной сложности. Ни разу картинки не рисовал.
В моем представлении, картинка — это всегда иллюстрация к самодостаточному объяснению, для кристаллизации мысли.
Если вы из одной лишь картинки можете все понять, 100% вы сможете это понять и без картинки.
А что касается проектов огромных, то я ни разу не видел, чтобы кто-нибудь взял вот так и, с кондачка, накорябав пару картинок, разобрался во всем коде. В больших проектах разбираются постепенно, иногда годами.
А зачем, собственно, разбираться во всем сразу-то? Чтобы пофиксить конкретный баг, достаточно разобраться в небольшой конкретной части кода. По мере работы над конкретными задачами и приходит знание всего кода.
А вы думаете, каждый из тех, кто над этим проектом работал, знал весь код? Скорее всего, каждый программист имел представление лишь о частях, над которыми он лично работал.
Да это глупо даже, на мой взгляд, так задачу формулировать. Вот вам проект, над которым 12-14 человек работали 10 лет. Разберитесь в нем во всем! Ха.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, bkat, Вы писали:
B>>Если же вернуться к топикстартеру, то если он хочет понять как работает система, B>>то он будет рисовать картинки.
А>Много раз приходилось разбираться в коде проектов разной сложности. Ни разу картинки не рисовал.
Я рисовал и делаю это постоянно. Мне лично нарисованные мною картинки действительно ничего нового не дают,
поскольку внятную диаграмму я могу нарисовать только когда понимаю, как работает система.
Нарисованная диаграмма экономит время и силы коллегам.
Проверенно многократно.
Картинки рисуешь не для себя. Картинки — это средство коммуникации.
Если нет необходимости делиться знаниями с другими, то конечно ничего рисовать не нужно.
Но картинки рисуют не только чтобы понять как работает уже готовая система.
Разработка нового кода — это оффтопик, но именно при разработке картинки весьма и весьма полезны.
вы не понимаете в данный момент пользователей, не чувствуете их потребностей и следовательно все ваши действия будут бестолковыми и ненужными
забудьте на полгода-год о юнит-тестах, рефакторинге и прочей дребедени. Вы не знаете пользователей -> не знаете что и как тестировать, -> не знаете как улучшать продукт.
Сейчас вы можете только поддерживать то что есть, фиксить баги.
Через пол года окажется что код не такое уж и говно как казалось поначалу, а кривенькая архитктура таки есть
У тебя взаимоисключающие параграфы.
B>поскольку внятную диаграмму я могу нарисовать только когда понимаю, как работает система.
Здесь ты все правильно говоришь, и, что характерно, именно это тебе объясняли выше по ветке — в частности я. Как и остальное — про то, что диаграммы не более чем иллюстративный материал к объяснениям, и обладают нулевой самостоятельной ценностью.
B>Но картинки рисуют не только чтобы понять как работает уже готовая система.
А вот с этого момента интересно. Ты бодро сам себе возражаешь. "Но" значит "нет". И действительно — здесь пресуппозиция (скрытое предположение), что "картинки" в частности рисуют для того, чтобы понять, как работает уже готова система.
Видишь указанное мной противоречие? Наверное, ты не видишь в этом проблем, не так ли?
А вот мне при таком уровне аргументации разговаривать не о чем. Не интересно.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, bkat, Вы писали:
G>У тебя взаимоисключающие параграфы.
B>>поскольку внятную диаграмму я могу нарисовать только когда понимаю, как работает система.
G>Здесь ты все правильно говоришь, и, что характерно, именно это тебе объясняли выше по ветке — в частности я. Как и остальное — про то, что диаграммы не более чем иллюстративный материал к объяснениям, и обладают нулевой самостоятельной ценностью.
B>>Но картинки рисуют не только чтобы понять как работает уже готовая система.
G>А вот с этого момента интересно. Ты бодро сам себе возражаешь. "Но" значит "нет". И действительно — здесь пресуппозиция (скрытое предположение), что "картинки" в частности рисуют для того, чтобы понять, как работает уже готова система.
До сих пор мне приходилось и приходится работать в команде.
"Понять как работает система" — это не про меня лично, а про команду.
Топикстартер тоже кстати, говорит о трех девелоперах, которым дали систему на поддержку.
Можно конечно разобраться с кусом кода, а сук (пардон, коллег) послать читать тот же самый код.
Но можно нарисовать что-то и поделиться сокровенным знанием с коллегами.
G>Видишь указанное мной противоречие? Наверное, ты не видишь в этом проблем, не так ли?
Противоречий не вижу...
Вижу кучу негативной энергии, которая напрочь убивает конструктив.
R>забудьте на полгода-год о юнит-тестах, рефакторинге и прочей дребедени. Вы не знаете пользователей -> не знаете что и как тестировать, -> не знаете как улучшать продукт.
О юнит-тестах может и можно забыть, но хотя бы высокоуровневые тесты и тестовую систему сделайте. Хотя бы какой-никакой continuous integration system введите. В таких больших проектах CI оказывает незаменимую помощь.
Здравствуйте, bkat, Вы писали:
G>>А вот с этого момента интересно. Ты бодро сам себе возражаешь. "Но" значит "нет". И действительно — здесь пресуппозиция (скрытое предположение), что "картинки" в частности рисуют для того, чтобы понять, как работает уже готова система.
B>До сих пор мне приходилось и приходится работать в команде. B>"Понять как работает система" — это не про меня лично, а про команду.
Ты вкладываешь слишком необычный смысл в свои слова, чтобы тебя можно было понять. "Не про тебя лично" звучит совсем по другому — "объяснить, как работает система".
Извини, я не верю, что ты настолько плохо владеешь русским языком. Все-таки, не первый год тебя знаю по форуму. Ты сейчас просто выкручиваешься.
B>Топикстартер тоже кстати, говорит о трех девелоперах, которым дали систему на поддержку.
Не понимаю, в каком месте это "кстати". Хоть три, хоть пять — смысл простых речевых оборотов русского языка от этого меняться не должен.
B>Но можно нарисовать что-то и поделиться сокровенным знанием с коллегами.
Ты выше написал "понять", а не "поделиться". И во всей ветке обсуждалось именно это.
G>>Видишь указанное мной противоречие? Наверное, ты не видишь в этом проблем, не так ли?
B>Противоречий не вижу... B>Вижу кучу негативной энергии, которая напрочь убивает конструктив.
Вот-вот. А я очень сильно не люблю, когда собеседники начинают врать и выкручиваться. Это неуважение к собеседнику. Типо, ты его очень конструктивно за дурачка держишь.
Здравствуйте, AlexNek, Вы писали:
TSP>>>>А UML и автогенерация только инструмент. AN>>>Нужно только знать какими инструментами и как пользоваться. AN>>>Можно ведь и исключительно нотепадом пользоваться, просто каждый решает это для себя сам в каждом конкретном случае.
G>>Диаграмма это не "инструмент", а нотация. Язык. AN>Я "прочитал" высказывание где то так AN>"А софт для автогенерация UML только инструмент."
Софт позволяет тебе сократить время на построение диаграмм. То есть, этот "инструмент" не более, чем немного экономит тебе время на само рисование. И все.
G>>Никакой существенной разницы, нарисуешь ты классы квадратиками, или будешь читать их определения в .hpp файлах, AN>Кстати, разница есть и весьма существенная. На первом этапе меня интересуют исключительно взаимосвязи между классами информация об отдельном классе практически не интересует. И взаимосвязи из кода уловить не так уж и просто чисто просмотрев его.
Простой факт наличия взаимосвязи, выраженный стрелкой на UML-диаграмме, либо наличием указателя в hpp файле (что примерно один хрен), тебе также ничего не даст. Тебе надо знать не это, а какой поток данных идет по каждой из взаимосвязей, что из UML диаграммы вообще вытащить невозможно. И, кстати, в UML в принципе отсутствует нотация для того, чтобы это показать (такая нотация была в диаграммах Буча, если интересно).
Глобально для понимания системы тебе важно знать основной поток данных, который цепочкой своего прохождения и выделяет те немногие "центральные" классы из сотен остальной требухи. Это также может быть извлечено только из кода.
В результате, на первом этапе тебя должны не "связи" интересовать, а вопрос, какие 6-7 из каждой сотни классов являются "центральными". По UML-диаграммам это понять невозможно. Только анализ кода.
G>>по сути, нет, кроме того, что в диаграмме будут убиты комментарии. AN>нафиг не нужны на этапе обзора проекта (имея в виду построчные комменты кода). Потом можно просто просмотреть интересующие части.
Ты лучше комментарии в хедерах имей в виду, где определяются твои классы. Их иногда, в отличии от документации, все-таки пишут.
G>>Чтобы понять поведение незнакомого кода, надо анализировать этот код, а не заниматься игрой в пятнашки, двигая UML-квадратики. AN>Каждый выбирает свой путь в конкретном случае.
Ага. Только некоторые пути ведут в никуда.
G>>Не, оно конечно понятно, что в код смотреть страшно. AN>Все равно в него смотреть нужно, так что страха быть не может. А вот получить обзор из кода несколько затруднительно.
Это просто надо уметь делать. Когда тебе достается легаси-система, не существует никакого другого способа получить обзор, кроме как из кода.
Здравствуйте, bkat, Вы писали:
G>>"Квадратики" не помогают тебе понять общую структуру.
B>Если тебе лично квадратики не помогают, это не означает, что они не помогают другим. B>Мне помогают. Я точно не уникум.
Определенно, уникум. Ибо в структурных моделях, к которым относятся диаграммы классов, объективно слишком мало для этого информации — они не содержат в себе информации ни о времени, ни о функциональной связности. Поэтому, увидев готовую диаграмму классов по не знакомой тебе системе (в которой до кучи названия классов и методов строятся из убогого словаря английских терминов в пару сотен слов, а часть вообще названа неправильно), в реальности ты ничерта по ней не поймешь.
B>Код, кстати, я пишу и читаю в большом количестве. B>Что со мной будешь делать?
Здравствуйте, Gaperton, Вы писали:
B>>Если тебе лично квадратики не помогают, это не означает, что они не помогают другим. B>>Мне помогают. Я точно не уникум.
G>Определенно, уникум. Ибо в структурных моделях, к которым относятся диаграммы классов, объективно слишком мало для этого информации — они не содержат в себе информации ни о времени, ни о функциональной связности. Поэтому, увидев готовую диаграмму классов по не знакомой тебе системе (в которой до кучи названия классов и методов строятся из убогого словаря английских терминов в пару сотен слов, а часть вообще названа неправильно), в реальности ты ничерта по ней не поймешь.
Главное часто-часто это повторять, приправить словами поумнее и писать уверенно, тогда тебе обязательно поверят.
Но только те, кто не пробовал предмет обсуждения на практике.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AlexNek, Вы писали:
TSP>>>>>А UML и автогенерация только инструмент. AN>>>>Нужно только знать какими инструментами и как пользоваться. AN>>>>Можно ведь и исключительно нотепадом пользоваться, просто каждый решает это для себя сам в каждом конкретном случае.
G>>>Диаграмма это не "инструмент", а нотация. Язык. AN>>Я "прочитал" высказывание где то так AN>>"А софт для автогенерация UML только инструмент."
G>Софт позволяет тебе сократить время на построение диаграмм. То есть, этот "инструмент" не более, чем немного экономит тебе время на само рисование. И все.
Ну для меня не все, он мне еще позволяет скажем, "оптимизировать" диаграмму. По крайней мере я нашел несколько "проблем" в текущем проекте. Обрабатываю диаграмму, и смотрю, есть связи которые "мешают" выстроить все "красиво" и точно, они были лишними. (Нежелательная связь модулей)
G>>>Никакой существенной разницы, нарисуешь ты классы квадратиками, или будешь читать их определения в .hpp файлах, AN>>Кстати, разница есть и весьма существенная. На первом этапе меня интересуют исключительно взаимосвязи между классами информация об отдельном классе практически не интересует. И взаимосвязи из кода уловить не так уж и просто чисто просмотрев его.
G>Простой факт наличия взаимосвязи, выраженный стрелкой на UML-диаграмме, либо наличием указателя в hpp файле (что примерно один хрен), тебе также ничего не даст. Тебе надо знать не это, а какой поток данных идет по каждой из взаимосвязей, что из UML диаграммы вообще вытащить невозможно. И, кстати, в UML в принципе отсутствует нотация для того, чтобы это показать (такая нотация была в диаграммах Буча, если интересно).
G>Глобально для понимания системы тебе важно знать основной поток данных, который цепочкой своего прохождения и выделяет те немногие "центральные" классы из сотен остальной требухи. Это также может быть извлечено только из кода.
"Поток данных" я также люблю и рисую его в "Диа" когда нужно объяснить концепт работы. Но простым просмотром кода "выловить его", думаю не получится.
G>В результате, на первом этапе тебя должны не "связи" интересовать, а вопрос, какие 6-7 из каждой сотни классов являются "центральными". По UML-диаграммам это понять невозможно. Только анализ кода.
Я же говорю, у каждого свой подход к разбору проекта. Мне вначале важны именно связи, потому как из них образуются "кластеры". И я не анализирую, что либо исключительно одно. Получили допустим "кластер", смотрим как там внутри него "живут" исходники (принадлежат ли они одному проекту или нескольким и т.п.) Хотя точно все описать видимо не получится.
G>>>по сути, нет, кроме того, что в диаграмме будут убиты комментарии. AN>>нафиг не нужны на этапе обзора проекта (имея в виду построчные комменты кода). Потом можно просто просмотреть интересующие части.
G>Ты лучше комментарии в хедерах имей в виду, где определяются твои классы. Их иногда, в отличии от документации, все-таки пишут.
Мне лично это все-таки попадается настолько редко, что о нем можно и забыть.
G>>>Чтобы понять поведение незнакомого кода, надо анализировать этот код, а не заниматься игрой в пятнашки, двигая UML-квадратики. AN>>Каждый выбирает свой путь в конкретном случае.
G>Ага. Только некоторые пути ведут в никуда.
Это выясняется после первого эксперимента, при этом результаты могут кардинально отличаться для каждого конкретного человека. Один может считать данный путь ошибочным, другому он может быть полезен
G>>>Не, оно конечно понятно, что в код смотреть страшно. AN>>Все равно в него смотреть нужно, так что страха быть не может. А вот получить обзор из кода несколько затруднительно.
G>Это просто надо уметь делать. Когда тебе достается легаси-система, не существует никакого другого способа получить обзор, кроме как из кода.
Для начального этапа мне достаточно глянуть связь модулей. Вот хотя бы как мне из кода это именно все сразу "увидеть"? (Пример взят просто из — за того, что это опен соурсе "под рукой")
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Gaperton, Вы писали:
B>>>Если тебе лично квадратики не помогают, это не означает, что они не помогают другим. B>>>Мне помогают. Я точно не уникум.
G>>Определенно, уникум. Ибо в структурных моделях, к которым относятся диаграммы классов, объективно слишком мало для этого информации — они не содержат в себе информации ни о времени, ни о функциональной связности. Поэтому, увидев готовую диаграмму классов по не знакомой тебе системе (в которой до кучи названия классов и методов строятся из убогого словаря английских терминов в пару сотен слов, а часть вообще названа неправильно), в реальности ты ничерта по ней не поймешь.
L>Главное часто-часто это повторять, приправить словами поумнее и писать уверенно, тогда тебе обязательно поверят. L>Но только те, кто не пробовал предмет обсуждения на практике.
А что делать с теми, кто тоже пробовал и кому помогает?
Происходит примерно так, как описано в "Аквариуме". Из места А посылается определенная радиограмма, а из места Б через 15 минут вылетает бомбардировщик. Если изучать исключительно радиограммы, то это найти практически невозможно, но проведя анализ и систематизацию одного типа информации и другого, вполне можно заметить связи "неизвестные раннее".
Уже даже та информация, что построенная мной диаграмма ни о чем не говорит, является полезной.
AN>Для начального этапа мне достаточно глянуть связь модулей. Вот хотя бы как мне из кода это именно все сразу "увидеть"? (Пример взят просто из — за того, что это опен соурсе "под рукой")
(диаграмма)
Гм, вы меня аж заинтриговали. Что нового и важного открыла вам диаграмма? Какую пользу вы извлекли из нее? Ну, кроме того, что связано все как попало?
Здравствуйте, Lloyd, Вы писали:
G>>Определенно, уникум. Ибо в структурных моделях, к которым относятся диаграммы классов, объективно слишком мало для этого информации — они не содержат в себе информации ни о времени, ни о функциональной связности. Поэтому, увидев готовую диаграмму классов по не знакомой тебе системе (в которой до кучи названия классов и методов строятся из убогого словаря английских терминов в пару сотен слов, а часть вообще названа неправильно), в реальности ты ничерта по ней не поймешь.
L>Главное часто-часто это повторять, приправить словами поумнее и писать уверенно, тогда тебе обязательно поверят. L>Но только те, кто не пробовал предмет обсуждения на практике.
О, я понял сарказм. Ты хочешь сказать, что главное — это делать ровно наоборот. Часто-часто повторять словами поглупее, ссылаясь на собственную таинственную практику, и не забыть перевести разговор с темы на личность собеседника. Это же так интересно, правда Lloyd?
Я не ограничиваюсь простыми исключительно софт. продуктами.
А надо?
