Здравствуйте, vdimas, Вы писали:

L>>Это означает, что изначально идея подхода неправильная. Ее сделали исходя из примера других индустрий, где сначала — проект, а потом — реализация. Только вот мозгов не хватило понять, что в разработке софта технический проект — это собственно код программы на ЯП а реализация изначально автоматизирована компиляторами.
V>Забавная ахинея в стиле Шарикова. ))

От Швондера слышу!

V>Изачально ведь был автокод.
V>Это и был "технический проект"?
V>А одни из первых вменяемых ЯП — Фортран и Лисп, компилятор только первый.

И? Они до сих пор оба используются. Кое-где.
Только какое они имеют отношение к осбуждаемой теме?

L>>То, что архитекторы рисуют квадратиками — это уже градостроительный план, а проект реализации конкретного модуля — это собственно код программы.
V>Программа точно так же без проблем разбивается на любые "квадратики" в любом своём слое.

Совершенно верно. И в большинстве случаев — совершенно бессмысленно.

V>Тут речь, скорее, о глубине иерархий сущностей проектирования, без проблем воспринимаемых человеком.
V>По моим наблюдениям, до глубины иерархии слоёв проектирования примерно 3 человек более-менее справляется.
V>Относительно алгоритмов — примерно до 7 шагов воспринимается на ура, а если больше — уже не помешает "подсказка" в том или ином виде.
V>Т.е., когда больше/глубже — начинаются сложности с восприятием.

Если разработчику при работе над конкретным модулем нужно держать в голове 7 уровенй иерархий проектирования, то вы проектируете что-то не то. Или не так. Или все вместе.

V>Поэтому, графические представления никогда из программирования не уйдут.
V>И не важно, по какой нотации они выполнены.

Натравливаешь на код doxygen, он рисует достаточное графическое представление.

V>Даже псевдокод, отбрасывающий детали — тоже разновидность нотации, ведь "это" живёт в независимом от проекта виде.
V>Мы не молимся на UML в своей конторе ни разу, но расписать в различных графических нотациях роли и поведение основных сущностей мне как-то пришлось, потому что из кода не понималось.

Так согласно одной довольно известной догме программирования, это означает, что код — говно-с
А если серьезно, то никаких проблем в комментариях описать диаграмму поведения модуля на языке plantuml, и доксиген тебе ее интегрирует прямо в документашку.

V>Туда же псевдокод для обяснения сущности применённых "трюков".

А не надо применять "трюки".

L>>Короче, для кода САПР — это IDE со всеми плюшками.
V>САПР в программировании — это примерно такое:

Ага, вот именно вот так и продавались аналоги RR в начале нулевых. Как пылесосы Кирби.

L>>Не примерно, а не просто бесполезна, но еще и вредна.

V>В нашем деле вредна лишь категоричность и прочие проявления узости ума.

Категоричность?
Софтовые конторы сейчас рисуют подробные UML модели примерно... ээ, да никогда.
Затраты времени на их построение себя не оправдывают.
Вот набросать квадратиков за 15 минут — да.

L>>Интернет-компании были только вершиной айсберга. Тогда же почти все конторы обратили внимание на автоматизацию и появившиеся новые технологии, которые позволяли творить разнообразную дичь. Этот бум дал начало куче современных систем.
V>Увы для тебя, бум автоматизации не совпал с бумом доткомов — он начался примерно на 7 лет раньше.

Увы, но ты опять не умеешь читать.

L>>Еще в начале 90-х на чистых сях писали ООП код. С таблицами виртуальных функций вручную, естественно. В начале нулевых я сам такой проект на плюсы переводил
V>Но без махровых ООП-иерархий наследования — читай внимательней.

Махровые ООП иерархии — это такой же карго-культ, как и любая другая дичь.

V>>>Это называет "эрудиция".
L>>Некоторые и умение "ботать по фене" эрудицией называют.
V>Угу, тоже порой помогает понять собеседника.

Чтобы понять, что с "собеседником" беседы не получится, не обязательно обладать такой "эрудицией".

L>>Нет смысла запоминать изначально ущербную вымученную нотацию.
V>"Запоминать" её надо для писательства, а для читательства она интуитивно понятна и так.
V>Ну вот разве что запомнить отличие закрашенного ромбика начала связи от незакрашенного.
V>И то, в некоторых языках эти два вида связи неотличимы, т.е. эта инфа не принципиальна.

Иными словами — это лишняя сущность. Вымученная. О чем я тебе и говорю.

V>Я для случая писательства не помню всех тонкостей UML, ес-но, но когда пришлось пару раз поупражняться — открыл описание нотации, открыл примеры, нарисовал за 15 мин.
V>Всё, вопрос исчерпан.

Ага. No Hire


L>>>>В UML есть две полезные вещи — Sequence Diagram (и то я уверен, что ее скопипастили туда откуда-то еще) и State Diagram.
V>>>Разве ты не проходил их в ВУЗ-е?
L>>Я собирался написать в "UML тулзах". И да, за брать на слабо иди в детский сад, ок?

V>Как-то странно ты скипнул часть вопроса:
V>Резьба по цитатам — это способ юления такой или как понимать?

Если ты собрался брать меня на слабо, то ты опоздал на сорок лет.
Конечные автоматы — моя любимая фишка в принципе. Наличие state diagram в любом UML редакторе лично мне помогает вбивать в голову юным падаванам правильные инженерные практики.

V>Разумеется, в этих моих рассуждениях суть была не конкретно в диаграмме состояний, а в твоей категоричности.
V>Про диаграмму состояний — это лишь очередной пример, демонстрирующий нелепость феномена упоротости.

Пока что только ты показываешь узость кругозора и приписываине собеседнику своих домыслов.

L>>Не некое, а подавляющее.
V>Пока что ты подзалетел в обсуждении несколько раз, так шта, назовём это как оно и называется — самомнением.

Скажем так, оно довольно обоснованное. В отличие от.

L>>Это как с иностранным языком. Можно всю жизнь учить, что такое past perfect continuous, но так и не продвинуться дальше "читаю со словарем".

V>Да ладно, многие коллеги прекрасно читают без словаря.

А ты сам?

V>Загвоздка чаще в том как стиллистически грамотно писать, какой оборот речи каким понятиям/ситуациям или даже комбинациям слов больше подходит — вот тут требуется выход на следующий уровень владения языком. ))

И чтобы на этот уровень выйти, нужно на языке общаться, читать и писать. А не пытаться запомнить синтетические правила, натужно натягиваемые на живой язык.

V>В UML примерно так же, как и в любой другой области.
V>Например, понимать уже готовые электрически схемы гораздо проще, чем проектировать их.
V>Понимать принципы действия ДВС со всеми новомодными "трюками" тоже проще, чем эти трюки изобретать/проектировать, и т.д. и т.п.

Какая-то у тебя каша в голове, честное слово.