Re[9]: Опять поднимают про low-code и помоечку для средняков
От: landerhigh Пират  
Дата: 23.09.21 15:17
Оценка: +1 -1
Здравствуйте, vdimas, Вы писали:

V>Учу читать:


Себя поучи.

V>В переводе на русский — начальство не уверено в том, что это им вообще надо, но выделить немного денег на эксперименты не проч.

V>Когда что-то действительно надо — там сценарии всегда другие.

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

L>>и ожидаемо пролетела, ушлые дельцы загнали аналог Rational Rose как вундерфавлю.

V>Так "за обеды" или задорого?

Учу читать. Дорого.

V>Т.е., если бы эти утилиты позволяли, например, связать метод статической диаграммы с блок-схемой алгоритма или с параметризируемым шаблоном проектирования (из GoF или кучи еще библиотечных), позволял бы запускать это всё на симуляцию, задавая/играя параметрами алгоритмов — это был бы полноценный САПР.

V>А так нет.

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

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

V>В этом смысле программистские недо-САПР типа Rational Rose и Together позволяли строить разве что, скажем, "проволочную модель", которая прозрачна и статична, не обладает параметрами или свойствами, не допускает симуляции работы, т.е. примерно бесполезна.


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

L>>А что, дотком — это только веб? У меня для тебя новости.

V>Бум и затем кризис доткомов (о котором периоде ты упоминал) — это бум и последующий кризис интернет-компаний, ес-но.

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

L>>Не надо всех по себе судить, ладно?

V>Я сужу не по себе, а по всем окружающим ровесникам, при том, что я был из "молодой" обоймы во второй половине 90-х — тот самый вчерашний студент.
V>ООП включили в программы ВУЗ-ов для 3-го курса моей специальности в год, когда я ВУЗ заканчивал.

Да, а еще в вузах преподавали иностранные языки. С известно каким результатом.

V>Если джава, плюсы, дельфи — то да.

V>И то — плюсы и дельфи с натяжкой, бо в 90-е компонентный подход был более популярен, чем объектный с махровой иерархией наследования, тут только джава резвилась в полный рост, бгг...

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

V>>>А что, сложно потратить пол-часа и запомнить, что означают символы UML? ))

L>>Запоминать бессмысленные сущности? Ну, мне попадались такие люди. Полные бессмысленных сущностей.
V>Это называет "эрудиция".

Некоторые и умение "ботать по фене" эрудицией называют.

Нет смысла запоминать изначально ущербную вымученную нотацию. Ее и читать-то порой с экрана или распечатки невозможно — поди разбери это открытая стелочка, или закрытая, но не заштрихованная.

V>Она "выстреливает" не на конкретной "бессмысленной сущности", а на большом комплексе их, экономя специалисту время в каждой мелочи, встречающейся по работе.




L>>В UML есть две полезные вещи — Sequence Diagram (и то я уверен, что ее скопипастили туда откуда-то еще) и State Diagram.

V>Разве ты не проходил их в ВУЗ-е?

Я собирался написать в "UML тулзах". И да, за брать на слабо иди в детский сад, ок?

V>Кружочков, ромбиков, трапеций, стрелок и т.д.

V>Твой пренебрежительный тон должен означать некое превосходство над этим всем? ))

Не некое, а подавляющее.
Диаргамма должна быть понятна всем без исключения участникам процесса. Поэтому ты либо учишься делать визуализацию, которая понятна и заказчикам, и твоей команде, либо всю жизнь "учишь UML нотацию".
Это как с иностранным языком. Можно всю жизнь учить, что такое past perfect continuous, но так и не продвинуться дальше "читаю со словарем".
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.