Comments 195
откуда столько классов…
Даже подумал что враньё если бы не видел своими глазами в мелкой немецкой (!!!) фирме:
- использование своего генератора java кода, генератор с глюкавым GUI, без нормальной возможности вставить свой код, примитивного без рассмотрения графа обьектов и без реиспользования
- обращение к БД когда выбираются все ряды, становятся java обьектами и потом в ПРОГРАММЕ цикл который ищет в списке один объект
надо сказать, не так уж давно, особо не было альтернатив С++.
ява для десктопа стала пригодна довольно недавно, а GUI устаканилось вобще в 2010+ году(скорее в 2014, когда javafx8 вышел).
до 2000 года С++ был почти единственным вариантом для крупных проектов.
хотя были некоторые интересные экзотические штукенции, например Centura
ну почему, если С++, то сразу зло?
не С++ зло а то что он позволяет делать.
удалить бы ему этак 80% синтаксиса)))
P.s. надеюсь вы поймёте, что здесь сарказм! И не понимаю как связана моя компетенция и ваше сравнение? То что я может не понял, так это ваши проблемы, или к вашим коментам нужно «доложить несколько сотен стайлгайдов», чтобы въезжать в design вашего изречения? Design имеется в смысле замысел, как и С++ который пилился с определённым замыслом, который описан уже давно и ныть по поводу его дизайна в 2к18 — о боже, акстись!
Так тут не столько про дизайн идёт речь, а про неумелость пользователя использовать объект. Простая аналогия!
Delphi позволял делать отличный GUI вообще не напрягаясь ещё в конце 90х.
.Net появился в 2001 и к 2004 был вполне годен для создания GUI (WinForms), а с выходом в 2006 году WPF стало ещё красивее и удобнее.
C++ конечно не зло, но он требует наличия опытных программистов в команде, потому что по сравнению с другими языками выше порог входа и проще выстрелить себе в ногу. Поэтому-то в Enterprise стандартом стали C# и Java, а не C++.
кстати С++ в дельфях тоже был.
.Net — ограничен платформой. а тут писали похоже под какую то экзотику
Вы не правы. Я работал когда-то с ОЧЕНЬ большим проектом на Delphi. Думаю, не сильно ошибусь, если скажу, что там было порядка 20 млн. строк кода. И никаких особых проблем не было. Главное — разделить код на логические слои, которые, в свою очередь, раскидать по отдельным dll. Причем каждая dll — это отдельный COM-объект, то есть он загружается в память только если пользователь обратился к соответствующему куску функциональности. Проблема не в Delphi, а в очень низком пороге входа в него, что приводило к говно-софту с бизнес-логикой в OnClick. Вот в чем реально проблема Delphi, это отсутствие библиотеки коллекций. StringList и все. По крайней мере так было в те далёкие времена, когда я работал с Delphi.
Вот в чем реально проблема Delphi, это отсутствие библиотеки коллекций. StringList и все. По крайней мере так было в те далёкие времена, когда я работал с Delphi.
Это какая же версия Delphi была?
Сейчас глянул самую древнюю из доступных (5.5). Tlist и TCollection на месте, и очередь со стеком в наличии.
Да и сторонние библиотеки рпзнообразные коллекции предоставляли.
А позже и Tintegerlist добавили непосредственно в VCL (или RTL?).
А проекты на Delphi неслабые делались. Это да.
TIntegerList тогда ещё точно не было. Про остальное не помню. Помню боль, связанную с этим, а детали выветрились. Ещё помню, очень активно использовали TClientDataSet, но за него отдельно платить надо было.
В хорошей половине — ARC для комовских интерфейсов и строк; проверки диапазонов и переполнений, унаследованные от Turbo Pascal. На хорошей половине работают mORMot и CVariants, может, кому-то пригодится.
Версия, по-моему, Delphi 2007
Помню ад на одном своём проекте на D7 из-за коллекций, 30+ модулей с {$I ...} реализаций базовых коллекций.
Да, с сахаром в паскале плохо, а с бойлерплейтом хорошо. Но тем не менее, можно писать хороший, объектно или компонентно ориентированный код. Который к тому же близок к машинному. Т.е. выполняется тоже очень быстро (если программист не накосячил).
Ну и компоненты из коробки позволяли быстро накидывать прототипы. Главное было не увлекаться лишней юзабилити, по крайней мере на начальном этапе.
Был есть еще Lazarus win/linux, Delphi не был таким ограниченным, сейчас продукт стал кросплатформеным.
до 2000 года С++ был почти единственным вариантом для крупных проектов.
Delphi
Порог вхождения с С++ очень высок. А менеджмент, очень любит в место одного синьера брать на работу 3-4 джуниура. И можно только представить, что наделают их шаловливые, любознательные ручки, использую всю мощь С++.
Это ни о чем не говорит, и за этим вполне может скрываться разумное распределение ресурсов — сервис поиска хорошо масштабируется (а ДБ индекс может не использоваться вовсе). Вторая причина: сплошь и рядом фильтрация в списках до 10 000 записей, перекладывается на клиента, чтобы время отклика между нажатием клавиши и обнавлением списка было максимально коротким (без сетевых задержек), те клиенту передается весь список, а потом «в ПРОГРАММЕ в ЦИКЛЕ» фильтруется.
Что плохого априори в собственном генераторе кода?
подумай с точки зрения банальной эрудиции, если генератор кода хорош то его можно продавать за хорошее бабло, так как есть спрос на упростители разработок, если они юзают это просто так то это сродни быдлокода, что подтверждалось его фичами. Одна фича что в генерированый java исходник нельзя было вносить изменения, они стирались при повторной генерации, что по моему мнению — лютое быдло так как запомнить внесённое изменение в текст легче лёгкого. Генератор был тупой и не рассматривал декларированое как граф то есть возможные ссылки в разных местах на одни и те же обьекты из за чего возможны были глюки. Кроме того просто глюки GUI (он был в качестве плагина Netbeans) и надо было аккуратно соблюдать последовательность операций которые их обходили.
и за этим вполне может скрываться разумное распределение ресурсов
просто так прописали в утилиты которые обращались к БД. Было некритично так как таблицы сравнительно малы. Ещё в проэкте были также некритичные бессмысленные if несколько раз подряд, но был один глубокий глюк который никак не находился — причём при дебаггинге его не наблюдалось за счёт остановки на точке — хрен найдёшь.
Java проэкт без Spring. Это конечно маленькие звоночки по сравнению с громовым колокольным звоном описанного в статье. Предположу чрезмерную типизацию что обьясняет столько классов и ненужного кода, расширение CORBA своими утилитами но даже при таком оверхедле можно сделать сравнительно вменяемый (в производительности) проэкт… автор не написал откуда фантастический перформенс по компиляции и прочее…
«обращение к БД когда выбираются все ряды, становятся java обьектами и потом в ПРОГРАММЕ цикл который ищет в списке один объект»
Это ни о чем не говорит, и за этим вполне может скрываться разумное распределение ресурсов
Может, наверное… Но врядли…
Однажды рефакторили одну программку которая выгружала данные из БД в специальном формате. Объем данных ~1-2 сотня Мб, время действия ~2000 года.
Программа работала ~1.5суток.
Первое что обнаружилось при внимательном рассмотрении, это что единственный SQL запрос выполняемый программой выглядел как «SELECT * FROM ».
Дальше шла функция выбора одной строчки из этой таблицы, поверх нее была написана функция поиска, которая вызывала функцию выбора одной строчки в цикле и т.д. и т.п.
Чисто замена этого «творчества», на нормальные SQL запросы сократило время работы программы до нескольких часов.
Однажды мне попал в руки код, который для отрисовки справочника ОКВЭД делал что-то в районе 1760 запросов к БД (в двух вложенных циклах — отрасли и подотрасли).
Оптимизация свелась к SELECT * и обработке полученных 1760 строк в скрипте (ну и еще там были кое-какие мелкие фиксы)
Тоесть вроде как и индекс есть, и sql знал человек который писал. Но 1000 запросов по индексу база переварить не в состоянии за разумное время. После чего человек клиент ложит трубку и повторяет
Я переписывал пару лет веб-проект за «американской» компанией. На самом деле, в США сидят менеджеры, нанимающие неграмотных филиппинцев буквально за еду. Сама компания клиентам разумеется выставляет счета по американским расценкам.
Филиппинцы везде вытаскивали из базы все строки, и затем уже фильтровали их в коде. Нам нужна одна запись? Ничего, вытащим всю таблицу в 10,000 строк, а потом в цикле будем искать нужную. Нужна самая новая запись? Загрузим всю таблицу в список, отсортируем его в коде, затем возьмем первый элемент.
Ну это помимо массы других приколов, и копирования огромных кусков примеров со StackOverflow прямо в код (потом я даже находил исходные ответы с этими кусками).
Спасло только то, что проект небольшой, и щедрый заказчик позволил мне потихоньку за пару лет переписать его по частям. В итоге, от старого кода не осталось ничего, потому что там реально не было ни строчки, которую стоило бы оставить.
Американские менеджеры продолжают существовать, если вбить название компании в поиск, находятся только положительные отзывы. Я предлагал заказчику подать на них в суд или написать отрицательные отзывы, везде, где можно, он решил этого не делать, причинами своего решения со мной не поделился.
Софт версия 2.1 условно работает нормально.
Версия 2.5 в одном месте исправили баг, во всех местах, где работа с базой, все начало тормозить.
Декомпилили обе версии программы, софт написан на C#.
Старая версия формирует SQL-код сама.
Новая версия переписана с использованием LINQ, в результате из базы начали забираться десятки тысяч записей и фильтроваться на клиенте через сам LINQ
Ваш комментарий звучит так, как будто виноват LINQ, а не программист который написал IEnumerable вместо IQueryable...
да там, действительно IEnumerable. Но по сравнению со старой версией появилась куча какого-то синтаксического сахара, и если в старой версии сразу было понятно, что делает код, то в новой без пол-литра не разобраться.
pastebin.com/qGvkRqsj
pastebin.com/E7SGA1pv
Причем разработчик софта игнорирует жалобы на медленную работу софта, что для старых версий, что для новых. В версиях регулярно отсутствуют индексы в базах.
О каком синтаксическом сахаре речь? Если вы о вот этом:
(from i in ... select i.get_FileName()).ToList<string>()то это декомпилятор постарался. Я практически уверен что в оригинале там стоял простой вызов
.Select(i => i.FileName).ToList()Поскольку весь синтаксический сахар при компиляции теряется — декомпилятор в режиме декомпиляции LINQ-выражений пытается преобразовать в такое выражение любой вызов методов с именами Select, Where и т.п.
При описанном подходе проблема как правило совсем не в одной отдельно взятой конкретной отдельной технологии. Загрузка с CD за семь суток — в этом что, тоже CORBA виновата? Да ладно…
На уровне протокола, сериализации и т.п. можно назвать скажем Avro, или AMQP, и на этом вполне можно делать работающие решения, но вот чего-то инфраструктурного полностью аналогичного корбе — такого я не знаю.
zeroc.com/products/ice
BlackBox — генератор исходного кода (JAVA, C#, C) обработки бинарного протокола Вашего распределенного приложения
Красиво… спасибо.
Versioning is simple. Old software is version 1, today’s software is version 2, software in the future is version 3. Nobody can actually tell which version has been delivered to the customer.
Это гениально, это просто гениально!
Excellent, but you didnt get the whole picture: what we have here is a typical “détournement d’argent public” case.
In english: spending public administration money on fake project to transfer it in the pocket of a few (usually the one who signs check -or above- is family related – or very good friend – to the one who receives it, more or less).
There are numerous projects likes this in France, and it continues as long as there is money collected to spend.
One of the biggest illustration of this is the software called “Louvois” which was supposed to manage all salary of military department. This project is still failing at paying thousand of military worker for months, creating real life crisis, was delivered with many year of late, and costs almost double of first pricing to the administration.
The private company developping it is a little protegee of politicians, although the project is a complete disaster, no external audit was requested in the use of public money.
Ну а кто вспомнит идею государственной электронной почты за 31 лимард?
Вот свежий (несколько дней) пост на реддите с ее обсуждением для тех, кто хочет еще перлов:
www.reddit.com/r/programming/comments/862f7j/article_project_from_hell
Но я лично знаю пару крупных (более чем пол года) проектов, которые делались исключительно чтоб потратить бюджет подразделения (иначе потом бабок не дадут).
Знаю проекты которые длятся на столько долго, что все уже давно забыли про их цели, но они все равно двигаются по инерции.
Знаю с десяток людей, которые вообще ничего не делают (реально ничего) т.к их проекты заморозили и о них забыли.
К чему это я — в такой ад может вступить любой проект (не зависимо от происхождения), в коммерческих структурах этот риск минимизирует тот факт что люди зарабатывают деньги, а не питаются с кормушки. Вот и все, демократия тут не причем.
Знаю с десяток людей, которые вообще ничего не делают (реально ничего) т.к их проекты заморозили и о них забыли.
О, у нас тоже такая история была! Была команда в трех городах из десятка человек. Проект закрыли, из двух городов народ перевели на другие проекты/уволили и тп, а в третьем городе сидел один человек и про него просто забыли. Девять (!) месяцев чувак каждый день ходил на работу, получал зарплату и совсем абсолютно ничего не делал. Потом новый начальник отдела проверял своих новых подчиненных и вдруг его и нашел.
В стране со столь развитой демократией и такое возможно?
p.s. ваше «откровение» в любом американском фильме очень ярко расписано, только вот придание этому факту сатирического окраса с попыткой оправдать тот ужас, что происходит в нашей стране — сам ужасен не меньше, так, что позвольте мне, списать это на разрушенные розовые грёзы.
Тут дело в том, что в России и других странах б.СССР люди сами провоцируют коррупцию. Потому что не хотят делать всё по правилам, а хотят побыстрее и подешевле. Платя взятку полицейскому помните, что если вы заплатите штраф, то он пойдёт в бюджет (и хотя бы часть его может пойти вам во благо), платя взятку, вы спонсируете стоитесьство коттеджа для гаишника и его начальства, а также приучаете их брать взятки в ещё больших объёмах…
В развитых странах коррупция есть на уровне компаний и бюджета, обычные люди с ней не сталкиваются совсем.
Из чего вы исходите? Из того, что наши СМИ об этом не пишут?
Или вы читаете в оригинале их местные СМИ о местячковых новостях, они вам интересны?
Вы имеете ввиду — наши обычные люди ничего не знают об их коррупции.
Разумеется. Потому что это только их локальные местные новости.
По миру транслируют какого там ребенка по счету завела Анжелина Джоли, это да.
А то что там же в Калифорнии что то химичат с мед.страховками — по миру не повторяют, это не интересно, это только местным интересная новость.
Я участвовал в таких проектах несколько раз в жизни. Правда масштабы несколько меньше, но остальное то же самое. В последний раз вляпался ровно год назад. На третий день, после знакомства с исходниками просто сказал руководству: «Извините, можете применять ко мне какие хотите штрафные санкции, но я ухожу. Ни за какие деньги работать над этим не готов».
Можно сказать, что я сдался, и не первый раз в жизни. Но жизнь большая, проектов много. Всегда можно найти интересный и продуктивный проект за те же деньги, а иногда и больше.
И потом я рассказываю упрощенную версию событий. Часто в этой ситуации понимаешь, что рыба гниет с головы, и что как ты не бейся, все будет упираться в главного человека, который не хочет никаких перемен. Или ты видишь, что по каким-то причинам главным разработчиком/архитектором сделали человека без опыта или вообще без способностей программиста. Который, например, заявляет: «В нашем проекте не должны использоваться исключения, потому что это опасно и неэффективно». И что делать — каждый день идти на конфликт? А переставлять стулья на титанике… Я не для этого родился на Земле, и второй жизни у меня не будет.
В первый раз в такой ситуации было очень тяжело сказать буквально сразу: я увольняюсь. Это была одна социальная сеть, которая влачит какое-то существование до сих пор.
Но я не жалею, хотя каждый раз корю себя за то, что не сумел распознать такую ситуацию сразу (например, исходники часто можно увидеть лишь после того, как официально принят на работу).
Кстати, знаю как минимум одну крупную организацию в РФ, которая до сих пор пользуется Rational ClearCase. Это хоть из не из Швеции, но это такая же убогая VCS со стоимостью в $5000+ на рабочее место (в компании не менее нескольких тысяч сотрудников, хотя не все пользуются VCS, но многие). По всем возможностям и «удобству» (это слова неприменимо к CC вообще) она проигрывает даже древнему забытому CVS. Тем не менее, каждый год лицензии продлеваются, компания работает.
Rational ClearCase. Это хоть из не из Швеции, но это такая же убогая VCS
Вот не надо. «Вы просто не умеете их готовить (с)»
CC одна из крутейших VCS… была… в свое время… Другое дело, что с ней надо уметь обращаться, а то при неправильном использовании легко можно сделать хуже, а не лучше.
Это как те-же C/C++ возможностей больше, но в том числе возможностей выстрелить себе в ногу…
Когда я работал в той конторе, уже существовал и активно использовался по всему миру Git. Думаю, никто не станет спорить, что Git по всем параметрам, включая удобство использования, превосходит CC. Да мне кажется, что даже Subversion тоже, а ведь тогда уже был закат Subversion.
Может CC и крутая теоретически. А по факту, выбранные решения настолько странные, что во всей конторе за время работы я не увидел человека, понимающего на самом деле, как с ней работать. У нее настолько инопланетный и сложный интерфейс, что осиливают его в полной мере единицы.
И я еще раз напоминаю про цену… $5000+ за рабочее место (такая цена на сайте, она там то появляется, то исчезает, то колеблется в пределах ±500$ около этой отметки)
что Git по всем параметрам, включая удобство использования, превосходит CC
Я не видел CC, но каждый день пользуюсь Git и крайне недоволен его "удобствами". Особенно git cli. Особенно, когда читаю лекции джуниорам. Как бы я уже давно привык к Git, но объяснить новичку, почему команда checkout напоминает швейцарский нож тяжко. Были и есть более вменяемые системы. Тот же hg, но его популярность падает каждый день и git сейчас реальный стандарт де факто.
Идеального инструмента быть не может в принципе. Всегда во-первых, будут какие-то шероховатости, во-вторых, все люди разные и всем людям не может нравиться одно и то же по определению.
Например, я долго пользовался Mercurial, мне он до сих пор кажется очень удобным и логичным. После него пришлось перейти на git, так как почти во всех рабочих проектах используется git. В общем, никаких сложностей не возникло, хотя первое время было несколько тяжело привыкать.
Но поверьте, все это меркнет по сравнению с ClearCase. Во-первых, CC — не distributed VCS, как Git или Mercurial (хотя там вроде бы появились сбоку какие-то пришлепки для distributed разработки, но я их, к счастью, не успел увидеть). Во-вторых, она настолько неинтуитивная, что для начала работы придется прочесть талмуд. И потом на каждый чих обращаться к невнятным талмудам официальной документации снова и снова, потому что запомнить все это невозможно (все эти versionspec или как их там).
Возможно, есть в мире 0.01% проектов, которые исключительно хорошо ложатся на workflow, предлагаемый CC. Я с такими проектами не сталкивался. Зато я вижу, что 99.9% real-world проектов совершенно никак не выигрывают от замороченности CC.
Все эти сложности CC кажутся вещью в себе, придуманы просто какими-то индийскими архитекторами в вакууме, причем эти архитекторы никогда не работали над реальными проектами… К этому выводу приходишь потому что ну просто не может человек с опытом разработки придумать такое инопланетное чудище, в котором все приходится делать через одно место...
Ах да. И CC тоже требует нескольких специально выделенных админов для обслуживания! То есть, в штате всегда должно быть минимум 1-2 человека только для обслуживания работы CC!
То есть, в штате всегда должно быть минимум 1-2 человека только для обслуживания работы CC!
Ну если разработка закрытая и нужен внутренний репозиторий Git, то и там придется потеть. Хотя Gitlab нынче работает гораздо лучше, чем 5-6 лет назад.
Ах да. И CC тоже требует нескольких специально выделенных админов для обслуживания! То есть, в штате всегда должно быть минимум 1-2 человека только для обслуживания работы CC!
Если у вас нет хотя-бы одного человека занимающегося Configuration Management, то одно из двух: или у вас маленький проект, или вы что-то делаете не так…
И это независимо от используемого инструментария.
Git появился в 2005, SVN в 2000, а CC в 1992.
Конечно в CC есть такие косяки, которые в новых системах поправили, например то что каждый файл имеет свое дерево версий. Но вместе с тем там было больше гибкости. И продумана система была неплохо. То что она довольно сложна для настройки и в обслуживании — согласен. То что она сложна для пользователей-разработчиков — нет, помоему (при правильной настройке) еще и попроще некоторых современных.
Насчет платности, так кто-же будет раздавать за бесплатно то, за что люди готовы платить? Старых проектов еще много…
Ну, дело было 10 лет назад, я уже не помню многие детали про CC. К счастью, с тех пор сталкиваться не приходилось. Но вот периодически спрашиваю тех, кто до сих пор там работает… Последний раз два года назад спрашивал, кажется. До сих пор так на ClearCase и сидят.
Да и вообще, статья не об этом, а об адских проектах. В той организации таких проектов вроде бы не было, во всяком случае, я с ними не столкнулся. А вот CC в память врезался.
А что за VCS из Швеции?
Это было более 10 лет назад. Один хостинг-провайдер делал свою панель управления для хостинга (во-первых, тогда их было еще немного, во-вторых, хостинг был несколько специфический, поэтому готовые решения не подходили).
Код был на Perl, главный человек, ответственный за разработку, плохо его знал, мне кажется, поэтому он нагородил какую-то адскую систему, чтобы каждый модуль при возникновении ошибки, создавал объект с кодом ошибки, сообщением, и информацией о строке, в которой она произошла. Получилось в итоге, какая-то эмуляция исключений вручную.
Насколько я понимаю, все это было для того, чтобы в случае ошибки иметь максимально полную информацию о месте, в котором произошла ошибка для максимально понятного вывода в панели.
То ли он не понимал исключения, и что они уже содержат traceback, то ли не знаю что.
Человек был тяжелый, я был новичком и не знал как с ним коммуницировать. Но в один из первых дней я делал задачу, в которой было очень удобно использовать исключения. Детали уже не помню за столько лет. Для того, чтобы не нарушать его правила, весь модуль был завернут в обработчик исключений, который в случае исключения возвращал код ошибки, как и все остальные модули в проекте. Наружу исключения никак попасть не могли. Однако, он увидел, что исключения используются внутри модуля, психанул, и заставил переписать.
Ну, это только один эпизод. В общем и целом, мне не понравилась обстановка в отделе, в частности, пресечение любых дискуссий при помощи аргументов "Я начальник, ты — дурак». Например, про исключения он мне не потрудился объяснить причины запрета, но глядя на код я сам сделал вывод, что он просто их не понимал, и вместо того, чтобы напрячься и подучиться, решил закатывать солнце вручную и всех подчиненных заставить делать то же самое.
Например, про исключения он мне не потрудился объяснить причины запрета
Если джунам все подробно объяснять, то можно забыть о том, чтобы делать свою собственную работу — времени на свою работу уже не хватит.
В самом первом комментарии я написал, что обрисовываю ситуацию в самых общих чертах, опуская множество деталей, в том числе значимых.
Конкретно, в этой ситуации я не был джуниором. Я был новым человеком в компании, но не джуниором.
Кроме того, отдел, в котором мы работали, не был завален работой, скорее наоборот. Времени для объяснений и всего другого было достаточно.
Видимо, методы управления командой из той же глубины веков, что и сам проект)
2 ляма строк кода, непонятные структуры базы, ТЗ, которое ты пишешь сам, нереальные сроки, несоблюдение собственных правил, половина сотрудников постоянно курит\пьет кофе или вообще играет в телефон на рабочем месте, у меня просто нет слов.
Когда я попытался что-то привести в порядок и даже тимлид был согласен — продержались ровно месяц и все вернулось на круги своя…
Правильно написали, там тоже была проблема в верхах т.е. в руководстве.
Блин, как знакомо! Почти то же самое, только в одной крупной испанской транснациональной корпорации. Инструменты разработки — стек пропиетарных говнопродуктов нескольних крупных производителей со всеми вытекающими маразмами: BPM, ESB, MQ, Unix, Spark. Специалистов разработки нет. Организационная структура — перевернутая пирамида (продукт надо задвинуть в несколько стран, соответственно на каждую страну свой менеджер с командой дармоедов и т.д.). Постоянные трения, борьба за влияние и выяснение кто главный. Коммуникаций между командами никаких — каждый ревностно защищает свой огород, чтобы казаться незаменимым. Команда постоянно пухла, но вместо специалистов нанимались новые руководители, которые были даже не в курсе, кто и над чем работал в их команде. Проект переживал постоянные реорганизации, только за мое время сменилось 5 начальников. Специалисты вместо кодинга собирались в комнате и неделями обсуждали концептуальность того или иного решения, рисуя на доске бесконечные ящики и стрелочки.
В итоге проект зашевелился, когда наступил кризис, закончилось бабло и уволили 90% команды.
Из плюсов: платили хорошо, бабла было немеряно, кормили на убой, сортиры мыли несколько раз за день, кофе бесплатный, работа начиналась в 10:30.
Архитектор? Не, не слышали. В лучшем случае вся архитектура — это tutorials + best practices от производителя.
Насчет полезности ESB, лично моя практика показывает, что это не работает даже в компаниях с низким уровнем раздолбайства. По задумке команда ESB должна быть ответственна за все корпоративные интерфейсы: за дизайн, разработку, сопровождение, версионирование. Реально же получается, что системщики каждый раз умоляют их замепить уже задизайненные нужные им интерфейсы или изменить какой-то меппинг, а сами ESB-шники никогда ни о чем не вкурсе, тупо сидят на продукте и постоянно отнекиваются. В итоге ESB превращается в рудиментарную вещь, которая тупо мешает сразу всем.
И да, продукты дерьмо!
Если же поставить ESB в центре системы — то в стадию legacy стремительно переходит все что пытается через нее взаимодействовать :-)
Разработчик говорит: не вопрос, щас, работы на 15 минут. Ну ок, на 45.
Все это тестируется и выводится в релиз. А через два месяца прибегает сопровождение системы приемника (а точнее, еще одной системы, которая стоит где-то посередине), и шумят: «А-а-а, у нас в очереди ошибок ваши сделки!!!». Оказывается, что условия фильтрации сделали слишком слабыми, и под них попали некие производные сделки, типа, про которые никто не подумал. Так вот после этого аналитики с двух сторон еще пару месяцев обсуждали, как же эту ситуацию исправить — потому что в сообщениях не было такого атрибута, который позволил бы идентифицировать те из них, которые нужно отфильтровать. А добавить его — это не быстро.
ESB реально дает гибкость. Но это промежуточное звено, оно не должно решать, какие там «меппинги» должны быть. Даже если там дел на 15 минут )))
Ну это какой-то очень специфический пример. В реальных процессах взаимодействие между системами сводится к двум типам операций: когда одна система должна либо вызвать другую и получить от нее какие-то данные (request-reply), либо оповестить ее о событии (one-way). В теории ESB преподносят как решение следующих задач:
- Роутинг. Системы ничего не должны знать об инфраструктуре, вместо этого они имеют single connection point с ESB, которая осущесвляет доставку месседжей до получателя.
- Assured delivery. Абстрагирование от транспорта, защита от сбоев сети, остановов систем, перегрузки, etc...
- Версионирование и адаптация. Позволяет системам иметь разный релизный цикл. Для каждого получателя ESB может адаптировать формат сообщения и обеспечить совместимость.
- Мониторинг.
Однако это в теории. А на практике:
- Инфраструктура меняется редко, есть более простые решения service discovery, начиная от DNS и заканчивая Consul-ами. К тому же с современной тенденцией контейнеризации и клаудизации это становится неактуальным. А single connection point усложняет взаимодействие 1-N, когда producer должен отвечать одному из N consumer-ов, который послал запрос. Появляется таблица правил роутинга, и прочая ненужная фигня.
- Ребята, которые сидят на ESB, иногда не слыхивали самого термина QoS, и уж тем более какие параметры установлены. Например ситуация, когда клиент уже устал ждать запрос и благополучно отвалился с ошибкой, а ESB все еще пытается задвинуть request в удаленную систему, вызывая тем самым рассинхронизацию общего состояния. О существовании DLQ узнают только, когда она вдруг переполняется.
- Иногда необходимо только для интерфейсов 1-N. Но как правило service consumers без посторонней помощи сами адаптируются к изменениям интерфейса producer-ов, а producer-ы зачастую сами версионируют свои интерфейсы, либо поддерживают обратную совместимость. Большинство же корпоративных интерфейсов 1-1, и оба — producer и consumer синхронно эволюционируют в рамках затронувшего изменения. Так что ESB тут пятым колесом.
- Серьезно? У вас че-то не работает — ваши проблемы. А эти ребята из ESB всегда с краю. Пока их мордой не ткнешь в косяк. А когда начинают теряться месседжи, так вообще футбол: A: "мы все отправили", B: "мы ничего не получили", ESB: проблемы где-то у вас, мы ничего не знаем.
А вот реальный пример как работает эта ваша ESB в корпоративном секторе. Система TOA должна списывать расходный материал в инвентаре, хранящемся в SAP. Посредник — Oracle Service Bus, через который посылается месседж о расходе. Временами SAP подглючивает, либо валится, и месседж не проходит (их светлость не соблаговолила разобраться с проблемой). ESB оказались не в состоянии обеспечить deferred re-delivery (или попросили за эту фичу круглую сумму — история умалчивает). В итоге дешевле и проще оказалось написать демона, который в конце рабочего дня лезет в TOA и аптейдит неучтеные расходы в SAP.
И вот на том и стоит весь корпоративный сектор: мажорные говнопродукты + куча скрепляющего самопального говна.
Я не знаю ваш юзкейс, поэтому не могу судить о резонности применения ESB. В нашей среде практически все системы общаются через SOAP и Rest в рамках установленных бизнес-процессов. ESB здесь лишняя.
По поводу выбора инструментов: разобраться с Camel-ом не составит труда любому компетентнорму джависту. А вы попробуйте сделать то же самое на каком-нибудь пропиетарном продукте типа IBM Message Broker или Oracle Service Bus. Сначала встанет проблема найти соответствующих специалистов, затем вы ужаснетесь их ценам, и, наконец, разочаруетесь в их профессиональной компетентности. В итоге любое изменение в ESB выходит гораздо дороже и больнее, чем в системах.
> Редактирование файлов не разрешалось без разрешения менеджеров среднего звена. Вы должны заранее сообщить своему менеджеру, какие файлы хотите отредактировать, а затем отправить официальный запрос на получение разрешения, который команда управления версиями может рассмотреть в течение нескольких дней.
Не верю. Либо что-то не так написано, либо преувеличено, либо вообще длинная цепочка испорченного телефона, но я не верю, что можно так работать — «посылать официальный запрос на разрешение редактирования файлов».
Если интересно, почитайте мой рецепт, как в таких проектах писать самодиагностирующиеся программы.
habrahabr.ru/post/342302
Редактирование файлов не разрешалось без разрешения менеджеров среднего звена. Вы должны заранее сообщить своему менеджеру, какие файлы хотите отредактировать, а затем отправить официальный запрос на получение разрешения, который команда управления версиями может рассмотреть в течение нескольких дней.
Здесь забыли (упомянуть?) внедрение системы документооборота.
Отсутствие динамического связывания библиотек: размеры исполняемых файлов начинаются с нескольких сотен мегабайт
Это спорный минус. Особенно на фоне всего остального кошмара.
У Google, например, на backend-е всё статически слинковано. Их стометровые бинарники пугают меньше, чем DLL Hell. А в Go — это вообще mainstream.
Если бы оберонщики понимали эту тему, от них бы шли обратные ссылки на эту статью (оригинал на английском), а я таких обратных ссылок не наблюдаю, поэтому скептичен насчёт того, если ли вообще такое понимание там.
Тему замяли, а так-то наработки в прошлом были (см. таблицу по первой ссылке).
Кстати, по обтекаемому описанию («привязана к компилятору, который распространяется только с одной (не поддерживаемой) операционной системой» и «CORBA») напрашивается, что, может быть, там VisualAge для OS/2 в режиме DirectToSOM? Вообще-то под Windows он тоже есть, я его даже запускал, но штука редкая, может, просто некому было рассказать. Если мои предположения верны, то именно таких проблем, как когда dll совмещается с ООП, там и не должно быть.
Но к совмещению dll и ООП это отношения не имеет: обе версии проекта, и старая и новая, должны иметь совместимые между собой наборы библиотек.
Но наблюдая за развитием языка Perl, я обнаружил, что там предлагается практически самому сделать «машину классов» из более мелких кирпичиков на ходу. Там такие ошибки можно обрабатывать и включать рефлексию подсоединяемого модуля.
Максимум что тут можно придумать в плане обработки — это запретить загрузку модуля и работать без него. Но это применимо только для необязательных модулей.
В Delphi коде
Contents := Definition.contents('all', False);это вызов метода, унаследованного от Container, а
Modifiers := Definition.somModifiers;чтение свойства, унаследованного от Contained, соответственно.
Если делать новые SOM классы на Delphi, то только вручную, так как я автоматизировал только импорт.
Для других языков программирования, где поддержка SOM двусторонняя, все эти служебные структуры генерятся автоматом из IDL, а разработчик только вписывает содержимое методов.
Тут есть 3 варианта:
1) Как в старом
продолжать тянуть этот проект;
2) Закрыть проект и разогнать всех;
3) Выбросить все наработки, заново сформировать ТЗ, команду. И перезапустить весь проект с актуализированными требованиями и на современных технологиях.
Плюс обычно этот говнокод где-то нужен 24/7 вместе с пятью терабайтами криво хранящихся накопленных данных, так что даже одна мысль о миграции этого всего на новый проект приводит всех в неописуемый трепет.
И команду тоже разогнать не получится, ибо новая команда вообще не будет знать как к этому монстру подступиться.
3) Выбросить все наработки, заново сформировать ТЗ, команду. И перезапустить весь проект с актуализированными требованиями и на современных технологиях.
Это возможно, если требования и люди стоят на месте. А в большой конторе, пока будешь собирать требования, уже успеется несколько новых законов выйти, смениться коллектив и перетусоваться бизнес структура. Очень трудно собрать требования для «бурлящего нечто».
три месяца. Это минимальный срок, чтобы иметь право уволиться во Франции.
Могли бы просто опоздать на минуту...
Рассказывает, что чуть ли не социализм и ваш пример показателен.
В результате к ним во Францию слетаются просто толпы халявщиков.
Эти ладно работали. А можно и не работать. Он и рецепт рассказал. Главное — посещать все те занятия, которые тебе назначены для твоей переквалификации. Не пропускать. И тебе все это время будут неплохо платить пособие.
Я сейчас живу в одной из стран ЮВА. Снял комнату через AirBnB у вьетнамца. Вьетнамец с детства жил во Франции. Говорит, что вернулся в Азию, потому что во Франции невозможно вести бизнес: душат огромными налогами. Еще не успел толком начать зарабатывать, а уже должен огромные суммы государству. По его словам, во Франции хорошо жить либо очень богатым людям, либо на пособии.
Он же сделал так: приехал в Азию, арендовал здание, которое ремонтирует и сдает через AirBnB. Но при этом получает еще пособие по безработице из Франции (точную сумму не помню, около 1500 евро). Я не поверил, и спросил: неужели не надо появляться на бирже труда. Он мне ответил, что не надо, они ему иногда звонят, но он не берет трубку. Деньги продолжают поступать. Говорит, если вдруг перестанут приходить, прилетит во Францию, и вновь встанет на учет на бирже труда.
Так что даже посещать ничего не надо.
И до этого я видел множество таких европейских хитрых товарищей в Индии. В ЮВА на 1500 евро можно очень хорошо жить, здесь во многих странах зарплаты редко превышают 200 евро. В Индии, если не жить на раскрученном курорте Гоа, можно вообще жить на такое пособие как король. Да и в Гоа вполне комфортно будет.
На С++ много удачных проектов, далеко за 6 млн. строк. Судьбу MS Office можно пожелать любому проекту. Дело не столько в миллионах, сколько в их структуре. CORBA — красивая промышленная технология, позволявшая работать с хайповыми нынче «микросервисами» еще 20 лет назад. Коррупция во Франции, разумеется, есть, только автор не вполне разобрался с ситуацией распределения крупных заказов проектным конторам. 3 месяца — срок уведомления о желании уволиться для ИТР и управленцев, несложно договориться о его сокращении. Для техников-программистов — 1 месяц. В общем, все не так плохо, хотя мы все, конечно, умрем.
Адский проект