Несколько лет назад меня пригласили консультантом по одному проекту ПО для крупной французской технологической компании. Увиденное выходит за рамки всего, что я мог представить в разработке. Простое отсутствие профессиональной компетентности оказалось не самым худшим. Гораздо хуже было крайнее презрение к человеческому достоинству, что показалось мне сравнимо с тюрьмой в том виде, как я её представляю. Вот список, проверьте сами.Масштаб
- Разработка программного обеспечения для государственного агентства.
- Сложность низкая, с несколькими вывертами.
Правительство платит авансом несколько миллионов евро. План разработки на два-три года. Для начала компания нанимает несколько разработчиков и продолжает удваивать размер команды каждые три месяца или около того, осваивая бюджет по мере поступления средств.
7 лет спустя проект ещё не оформился. Набегают штрафы по несколько тысяч евро в сутки. Руководство решает сократить расходы и производит увольнения опытных сотрудников, нанимая людей с небольшим или нулевым опытом работы.
10 лет спустя, учитывая катастрофическое состояние проекта, менеджмент среднего звена решает нанять некоторых людей с опытом разработки, чтобы вернуться в график. Средняя текучка среди новичков: три месяца. Это минимальный срок, чтобы иметь право уволиться во Франции.
12 лет спустя проект ещё не закончен. Компания снова попадает на ежедневные штрафы, выставляя новые счета правительству за постоянно растущий поток запросов на изменение. Идёт 2008 год.
Цифры
- 6 миллионов строк кода
- На основе C++
- Более 50 000+ классов
- Конкретная версия C++ устарела, но привязана к компилятору, который распространяется только с одной (не поддерживаемой) операционной системой
- На основе CORBA
- СУБД от компании-банкрота
- Несколько слоёв поверх друг друга для обработки GUI, ни один из которых фактически не поддерживается авторами
- Сборка занимает 48 часов на 32 параллельных машинах
- От 40 до 50 одновременных процессов для запуска только пользовательского интерфейса
- Отсутствие динамического связывания библиотек: размеры исполняемых файлов начинаются с нескольких сотен мегабайт
- Время запуска программы: около 15 минут
- Среднее время между сбоями: от 30 секунд до 30 минут
Ни один разработчик не скажет, что C++ — простой язык. Наоборот, один из самых сложных. На самом деле он настолько сложен, что даже его создатели признаются, что ещё не овладели всем. См. признание Страуструпа в его знаменитом «интервью», которое сочинили как розыгрыш.
Столкнувшись с таким невероятным лабиринтом бездонной сложности, люди реагируют по-разному. Все гики-выскочки слышали о C++ и хотят доказать, что тоже могут на нём программировать. Они бесстрашно погружаются — и получают увечья до неузнаваемости. Тратят бесчисленные часы, пытаясь понять, почему куча абракадабры бесконечно крашится без видимой причины. У кого есть разум — те быстро уходят на другие языки и другие проекты. Жизнь слишком коротка.
Поддерживать крупный проект сложно независимо от языка. Только представьте, что сотрудникам нужно поддерживать 6 МИЛЛИОНОВ СТРОК кода — и вы получите представление о том, как далеко может зайти безумная разработка. Шесть миллионов — большое число. Если читать по одной строке в секунду, то вы просидите перед экраном семьдесят дней без перерыва.
Для понимания масштаба расскажу два случая.
Одному разработчику поставили задачу проверить, почему нажатие правой кнопкой мыши в интерфейсе полностью подвешивает приложение. После нескольких дней тщательного изучения и невероятного количества терпения он обнаружил, что щелчок правой кнопкой мыши работает нормально. Просто контекстное меню появляется примерно через 45 минут. Все меню динамически генерируются из кучи (статического!) контента при каждом нажатии правой кнопкой мыши в главном окне.
В какой-то момент пользователи сообщают, что вообще не работает опция «Загрузить данные с CD-ROM». Потребовалось несколько недель, чтобы разобраться. Но в итоге баг-репорт пометили как «Решён ранее», потому что данные загружались корректно. Разве что загрузка 700 МБ занимала семь суток. Но терпение — это добродетель.
Управление версиями пошло вразнос
Прошло несколько лет, прежде чем одному смышлёному парню в команде пришла идея использовать инструменты для управления версиями. Первая попытка не слишком получилась, так что команда переключилась на другую систему. А через пару лет — на третью, теряя всю историю с каждым переходом.
В итоге выбрали инструмент-катастрофу с GUI. Мерзость, исходящую непосредственно из Швеции. Пришлось выделить на полный рабочий день команду из четырёх человек для выполнения большинства задач в этой системе. Выглядело примерно так:
- Для первого извлечения кода (checkout) следовало назначить встречу с командой контроля версий. Встречу обычно назначали через неделю.
- Редактирование файлов не разрешалось без разрешения менеджеров среднего звена. Вы должны заранее сообщить своему менеджеру, какие файлы хотите отредактировать, а затем отправить официальный запрос на получение разрешения, который команда управления версиями может рассмотреть в течение нескольких дней.
- Каждая модификация кода запускает ветвление. Это значит, что потом нужно объединить все полученные модификации. С таким количеством файлов в хранилище вы можете подумать, что редко встретятся два человека, работающие над одним и тем же файлом. Но оказалось, что бoльшая часть работы идёт над теми же 100 файлами или около того.
- Возврат (check-in) проходит через болезненную процедуру, когда ваш код проверяет автоматическая программа для обнаружения ошибок, а потом менеджеры. Нечего и говорить, что с таким подходом ошибки плодятся быстрее, чем их успевают исправлять. Внимательный взгляд на количество зарегистрированных ошибок показал, что на каждое исправление появлялось две новых ошибки.
- Управление версиями вообще простое. У старой программы — первая версия, у сегодняшней — вторая, у будущей — третья. Никто не может сказать, какую версию отправили заказчику.
В какой-то момент была назначена официальная дата выпуска, совершенно оторванная от планов команды. Когда пришёл день, клиенту фактически отправили пустой компакт-диск с инструкциями по установке, потому что никто не смог собрать софт в течение нескольких недель. Клиент узнал, что ему прислали пустой диск, официально пожаловался — и получил старую версию. Он узнал об этом, потому что отображаемая дата в поле «О программе» оказалась такой же, как и в прошлом году.
Кадры
Платишь крохи — получаешь идиотов
С таким большим количеством народу вообще без опыта разработки ПО разве удивительно, что ошибки плодились в огромном количестве? Какой-то особо одарённый менеджер выяснил, что затраты на персонал — главные затраты в проекте чистой разработки ПО. Совсем не испуганный этим необычайным открытием, он решил уволить всех людей хоть с каким-то опытом, но сохранить всех менеджеров. Было не редкостью видеть книжки «C++ для чайников» на столах многих сотрудников.
Познакомьтесь с командой
55 человек в команде: 20 разработчиков, 35 менеджеров. Вы не ошиблись: менеджеров больше, чем реальных разработчиков.
Менеджеры продолжают организовывать встречи, где они снова и снова показывают одну и ту же презентацию PowerPoint AD до отвращения, в то время как разработчики убивают время, болтая в огромном офисе открытого типа.
Немногие менеджеры имеют опыт работы в индустрии ПО. В то время как раз SCO судилась с IBM по поводу Linux. Даже если всё было блефом, но реально действовало на всех этих людей, которые понимали, что скоро придётся платить за свободные программы. Никто из них никогда не упоминает “Software Libre”, но все они знают о “Software Gratuit”. Излишне говорить, что проект напичкан библиотеками GNU, а эти ребята понятия не имеют, что так проект становится совместимым с GNU. Хотя ладно, учитывая ужасное качество этого кода, никто никогда не будет настаивать, чтобы они открыли исходники.
Технические знания ниже плинтуса. Мало кто знает об интернете. Те, кто знает, думает, что он создан для порно. Упомянете, что вы что-то видели в интернете — и вам начнут подмигивать и улыбаться.
Добро пожаловать в ад
Всё это было бы забавно, если бы высшее руководство не вело себя как нацисты в концлагере. Просто приведу несколько примеров.
- Запрещено приходить на работу после 9 утра. Однажды старший менеджер стоял перед главными воротами и тут же увольнял всех, кто пришел после 9:01. Под раздачу попали в том числе ряд менеджеров и продажников.
- Курильщики берут больше перерывов, поэтому меньше работают. Руководство попыталось заставить всех бросить курить по приказу. Не получилось.
- Кофе-машины регулярно выходят из строя на несколько дней. Те, кто пьёт кофе, меньше работают, чем те, кто неотрывно сидит за своим столом, набирая драгоценные строки кода.
- Те же кофе-машины выключают всякий раз, когда чиновники приходят в офис, чтобы создать впечатление, что все на работе.
- Туалеты самые отвратительные, какие я видел в жизни. Вероятно, идея заключалась в увеличении производительности: чем меньше времени вы тратите в туалете, тем больше (и лучше) работаете.
Наверное, вы задаётесь вопросом, зачем же люди продолжали приходить на работу в такое место. Первой и главной причиной стал глубокий экономический кризис, который переживала Франция в то время (и до сих пор, в определённой степени, переживает). Наличие работы и заработной платы считается привилегией, независимо от условий.
Другая причина заключалась в том, что для многих это была первая работа. Без какого-то сравнения невозможно оценить, насколько ваша работа отстой. Большинство новичков считали совершенно нормальным, что вынуждены приходить ровно в 9:00 или быть уволенными, когда абсолютно ничего не накладывало такого ограничения, кроме больного ума менеджера.
Что касается того, как правительство позволяет подобное: мы все знаем, как это работает. Ребята, отвечающие за бюджет в министерстве, дружат с топ-менеджерами в ряде компаний. В такой стране, как Франция, коррупция не редкость на этом уровне, она в основном не раскрывается и редко преследуется по закону. Видимо, это относится не только к Франции. Я слышал такие же истории из других мест Европы и из США.
В следующий раз при мысли, что твоя работа отстой — подумай еще раз.
Опубликовано 24 июня 2008 года
Комментарии (152)
Naves
02.04.2018 22:31+3CORBA — технология, про которую нужно рассказывать с огромным энтузиазмом на фуршете, чтобы потом конкуренты тоже отстали на полгода в развитии.
sshikov
02.04.2018 22:45+1Я пользовался CORBA, и довольно много. Ничего страшного в ней нет, даже по сегодняшним временам. А уж в 2008 не было и подавно. Более того, представьте, что у вас многоплатформенная распределенная система (отложим на время, нужно ли это на самом деле). И много ли у вас будет технологий, на базе которых вы сможете такую систему уверенно построить? И много ли было таких технологий в те времена?
При описанном подходе проблема как правило совсем не в одной отдельно взятой конкретной отдельной технологии. Загрузка с CD за семь суток — в этом что, тоже CORBA виновата? Да ладно…
evilruff
03.04.2018 13:18Я бы с удовольствием поставил бы Вам плюс, если бы мог =) на самом деле, совершенно не флейма ради, а что в современном мире предлагается как законченная альтернатива с вменяемой спецификацией хотябы уровня документов CORBA? я тоже на ней много писал включая всякие необычные реализации типа TAO RT, и знаю проекты, которые до сих пор ее используют именно в формате кроссплатформенных распределенных систем… что у нас в сухом остатке на сегодняшний день? велосипед от Qt под названием Remote Objects за авторством инженеров Ford Motor Company который сейчас продвигается как супер инновация… =( рукопашный доисторический RPC с кучей разных обвязок…
mayorovp
03.04.2018 13:29SOAP? Protobuf?
evilruff
03.04.2018 15:10да, SOAP возможно, но «затраты» на канал в десятки раз больше и скорость несравнимо ниже… protobuf вообще протокол сериализации… вроде как к обсуждаемому напрямую отношения не имеющий… protobuf наверное можно как то пытаться сравнивать с IIOP но это только малая часть спецификации CORBA…
sshikov
03.04.2018 19:40Думаю что SOAP (не одна спецификация, а целое семейство). И кстати, если их применить все вместе (а там есть например UDDI), то получится та еще зверушка.
На уровне протокола, сериализации и т.п. можно назвать скажем Avro, или AMQP, и на этом вполне можно делать работающие решения, но вот чего-то инфраструктурного полностью аналогичного корбе — такого я не знаю.
cheblin
03.04.2018 20:31И много ли у вас будет технологий, на базе которых вы сможете такую систему уверенно построить?
BlackBox — генератор исходного кода (JAVA, C#, C) обработки бинарного протокола Вашего распределенного приложения
QtRoS
02.04.2018 22:52+6То чувство, когда ты не очень-то и испугался…
vbif
02.04.2018 23:21+3Всё нормально. Если в проекте участвует государство — так и должно быть. Банальнейшая ошибка, которая не исправляется, потому, что сотрудник, писавший этот модуль уволился, а больше никто не знает, как он работает? Модуль, который нужно сделать по образцу существующего, потому что никто не знает, как он работает? ТЗ, которое пишут сами разработчики, и которое заворачивают из-за неправильного размера шрифта для нумерации страниц? Всё нормально.
igor_suhorukov
02.04.2018 23:24+2Кто работал в гос проектах, тот в цирке не смеется!
Если бы приходилось пользоваться на ежечасной основе тем, кто принимает систему мир был бы чуточку лучше.
F0iL
02.04.2018 23:12+6Только представьте, что сотрудникам нужно поддерживать 6 МИЛЛИОНОВ СТРОК кода
В Chromium более 9 миллионов строк кода, а со всякими third-party либами — и того больше. Тоже преимущественно C++.
При этом есть тесты, и код довольно приличный, а не лютое legacy, не смотря на историю уходящую почти на 20 лет назад в прошлое.
Так что в «миллионах строк» ужасного ничего нет, важна организация процесса разработки.kalininmr
03.04.2018 00:08если не увлекаться магией, С++ ничем не уступает яве.
VioletGiraffe
03.04.2018 08:25+18А если увлекаться, даже превосходит :)
kalininmr
03.04.2018 12:10в яве при желании тоже UB добится можно.
ненадо недооценивать
aleaksah
03.04.2018 14:47+3«Закоренелый настоящий программист может написать фортрановскую программу на любом языке.»
kalininmr
03.04.2018 16:38скорее наоборот. UB чаще появляется от излишней тяги к прекрасному.
0xd34df00d
04.04.2018 20:40Это смотря какой магией. Если битовыми сдвигами, голой арифметикой, юнионами и наркоманскими лейаутами объектов — возможно. Если всякими шаблонами и constexpr — нет.
nikitasius
02.04.2018 23:47Versioning 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.
Это гениально, это просто гениально!
baldr
03.04.2018 00:11+2Да, собственно, комментарии к оригинальной статье тоже недалеко ушли. Если бы на русском были, то вообще де жа вю:
Excellent, but you didnt get the whole picture: what we have here is a typical “detournement 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 лимард?
baldr
03.04.2018 00:29Статья, кстати, не фейк. По крайней мере, она точно была опубликована в 2008г, если верить Internet Archive.
Вот свежий (несколько дней) пост на реддите с ее обсуждением для тех, кто хочет еще перлов:
www.reddit.com/r/programming/comments/862f7j/article_project_from_hell
VMichael
03.04.2018 00:52-1Не может быть.
В стране со столь развитой демократией и такое возможно?
Хотя это 2008 год, сейчас то конечно все не так.valis
03.04.2018 06:34Работаю в очень крупной и успешной КОММЕРЧЕСКОЙ компании, настолько далекой от государства и политики как далеки герои данной статьи от здравого смысла.
Но я лично знаю пару крупных (более чем пол года) проектов, которые делались исключительно чтоб потратить бюджет подразделения (иначе потом бабок не дадут).
Знаю проекты которые длятся на столько долго, что все уже давно забыли про их цели, но они все равно двигаются по инерции.
Знаю с десяток людей, которые вообще ничего не делают (реально ничего) т.к их проекты заморозили и о них забыли.
К чему это я — в такой ад может вступить любой проект (не зависимо от происхождения), в коммерческих структурах этот риск минимизирует тот факт что люди зарабатывают деньги, а не питаются с кормушки. Вот и все, демократия тут не причем.VMichael
03.04.2018 09:37+3Да я про то, что когда пишут о подобном проекте в России, сразу идут тонны комментариев, что это власть довела конкретно Россию до этого, что в «демократических» странах такое невозможно.
Хотя вот, оказывается, возможно, хотя это и не укладывается в картину мира некоторых товарищей.
Estee
03.04.2018 14:24+4Знаю с десяток людей, которые вообще ничего не делают (реально ничего) т.к их проекты заморозили и о них забыли.
О, у нас тоже такая история была! Была команда в трех городах из десятка человек. Проект закрыли, из двух городов народ перевели на другие проекты/уволили и тп, а в третьем городе сидел один человек и про него просто забыли. Девять (!) месяцев чувак каждый день ходил на работу, получал зарплату и совсем абсолютно ничего не делал. Потом новый начальник отдела проверял своих новых подчиненных и вдруг его и нашел.
Marui
03.04.2018 08:52-5В стране со столь развитой демократией и такое возможно
Боже, еще один…
Демократия это не твоя свобода. Это свобода твоего соседа-тунеядца-алкашаю. А ты иди плати сверх налоги (во Франции самые большие налоги в ЕС) чтобы у твоего соседа было пособие. И ничего плохого про него не пиши и не говори. Это его оскорбляет и еще оскорбляет его подружку-лезбиянку (которая тоже сидит на пособии).mayorovp
03.04.2018 11:29+8У вас каша в голове.
Ситуация "А ты иди плати сверх налоги чтобы у твоего соседа было пособие" называется не "демократия", а "социально-рыночная экономика".
Ситуация "И ничего плохого про него не пиши и не говори. Это его оскорбляет и еще оскорбляет его подружку-лезбиянку" тоже не называется демократией, это гипертолерантность.
0xd34df00d
04.04.2018 20:42Если тунеядцев достаточно много, то (возможно, при некоторых дополнительных условиях) демократия приводит к социально-рыночной экономике.
mayorovp
04.04.2018 20:53Да, такое возможно и уже несколько раз происходило. Но это вовсе не единственная возможность разбития событий.
Ruins
03.04.2018 19:28Не понимаю ваших розовых грёз как и сарказма. Наличие коррупции ровно такой же факт как и разница в её уровне между развитыми странами и Россией, при том, что для России даже такой же процент коррупции на несколько порядков опасней. А тем более те, кого вы пытаетесь парадировать должны были вам рассказать о разнице в системах, где ни кто ни чего не может изменить, а где воруют, так что ни на что не влияет. Опять же огромная разница условий в странах.
p.s. ваше «откровение» в любом американском фильме очень ярко расписано, только вот придание этому факту сатирического окраса с попыткой оправдать тот ужас, что происходит в нашей стране — сам ужасен не меньше, так, что позвольте мне, списать это на разрушенные розовые грёзы.VMichael
03.04.2018 21:22Розовые грезы у тех, кто считает, что в других «развитых» странах, ситуация с коррупцией и прочей фигней лучше. Все то же самое, люди везде одинаковы.
Что лучше развито в этих странах это пиар. Это развито просто превосходно. Но мы к ним подтягиваемся успешно.zenkz
04.04.2018 17:21+2В развитых странах коррупция есть на уровне компаний и бюджета, обычные люди с ней не сталкиваются совсем. Т.е. если у тебя корпорация и ты очень хочешь освоить госбюджет, то тут взятка может помочь (а может и нет). А вот дать взятку полицейскому, доктору или пожарному инспектору — этого не бывает совсем. Разве что чаевые официантам )).
Тут дело в том, что в России и других странах б.СССР люди сами провоцируют коррупцию. Потому что не хотят делать всё по правилам, а хотят побыстрее и подешевле. Платя взятку полицейскому помните, что если вы заплатите штраф, то он пойдёт в бюджет (и хотя бы часть его может пойти вам во благо), платя взятку, вы спонсируете стоитесьство коттеджа для гаишника и его начальства, а также приучаете их брать взятки в ещё больших объёмах…awesomer
04.04.2018 18:40-1В развитых странах коррупция есть на уровне компаний и бюджета, обычные люди с ней не сталкиваются совсем.
Из чего вы исходите? Из того, что наши СМИ об этом не пишут?
Или вы читаете в оригинале их местные СМИ о местячковых новостях, они вам интересны?
Вы имеете ввиду — наши обычные люди ничего не знают об их коррупции.
Разумеется. Потому что это только их локальные местные новости.
По миру транслируют какого там ребенка по счету завела Анжелина Джоли, это да.
А то что там же в Калифорнии что то химичат с мед.страховками — по миру не повторяют, это не интересно, это только местным интересная новость.
immaculate
03.04.2018 09:22+5Я участвовал в таких проектах несколько раз в жизни. Правда масштабы несколько меньше, но остальное то же самое. В последний раз вляпался ровно год назад. На третий день, после знакомства с исходниками просто сказал руководству: «Извините, можете применять ко мне какие хотите штрафные санкции, но я ухожу. Ни за какие деньги работать над этим не готов».
Можно сказать, что я сдался, и не первый раз в жизни. Но жизнь большая, проектов много. Всегда можно найти интересный и продуктивный проект за те же деньги, а иногда и больше.
И потом я рассказываю упрощенную версию событий. Часто в этой ситуации понимаешь, что рыба гниет с головы, и что как ты не бейся, все будет упираться в главного человека, который не хочет никаких перемен. Или ты видишь, что по каким-то причинам главным разработчиком/архитектором сделали человека без опыта или вообще без способностей программиста. Который, например, заявляет: «В нашем проекте не должны использоваться исключения, потому что это опасно и неэффективно». И что делать — каждый день идти на конфликт? А переставлять стулья на титанике… Я не для этого родился на Земле, и второй жизни у меня не будет.
В первый раз в такой ситуации было очень тяжело сказать буквально сразу: я увольняюсь. Это была одна социальная сеть, которая влачит какое-то существование до сих пор.
Но я не жалею, хотя каждый раз корю себя за то, что не сумел распознать такую ситуацию сразу (например, исходники часто можно увидеть лишь после того, как официально принят на работу).
Кстати, знаю как минимум одну крупную организацию в РФ, которая до сих пор пользуется Rational ClearCase. Это хоть из не из Швеции, но это такая же убогая VCS со стоимостью в $5000+ на рабочее место (в компании не менее нескольких тысяч сотрудников, хотя не все пользуются VCS, но многие). По всем возможностям и «удобству» (это слова неприменимо к CC вообще) она проигрывает даже древнему забытому CVS. Тем не менее, каждый год лицензии продлеваются, компания работает.
Sklott
03.04.2018 09:57+1Rational ClearCase. Это хоть из не из Швеции, но это такая же убогая VCS
Вот не надо. «Вы просто не умеете их готовить (с)»
CC одна из крутейших VCS… была… в свое время… Другое дело, что с ней надо уметь обращаться, а то при неправильном использовании легко можно сделать хуже, а не лучше.
Это как те-же C/C++ возможностей больше, но в том числе возможностей выстрелить себе в ногу…immaculate
03.04.2018 10:04+3Когда я работал в той конторе, уже существовал и активно использовался по всему миру Git. Думаю, никто не станет спорить, что Git по всем параметрам, включая удобство использования, превосходит CC. Да мне кажется, что даже Subversion тоже, а ведь тогда уже был закат Subversion.
Может CC и крутая теоретически. А по факту, выбранные решения настолько странные, что во всей конторе за время работы я не увидел человека, понимающего на самом деле, как с ней работать. У нее настолько инопланетный и сложный интерфейс, что осиливают его в полной мере единицы.
И я еще раз напоминаю про цену… $5000+ за рабочее место (такая цена на сайте, она там то появляется, то исчезает, то колеблется в пределах ±500$ около этой отметки)
acmnu
03.04.2018 10:40что Git по всем параметрам, включая удобство использования, превосходит CC
Я не видел CC, но каждый день пользуюсь Git и крайне недоволен его "удобствами". Особенно git cli. Особенно, когда читаю лекции джуниорам. Как бы я уже давно привык к Git, но объяснить новичку, почему команда checkout напоминает швейцарский нож тяжко. Были и есть более вменяемые системы. Тот же hg, но его популярность падает каждый день и git сейчас реальный стандарт де факто.
immaculate
03.04.2018 10:46+1Идеального инструмента быть не может в принципе. Всегда во-первых, будут какие-то шероховатости, во-вторых, все люди разные и всем людям не может нравиться одно и то же по определению.
Например, я долго пользовался 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!
acmnu
03.04.2018 10:55То есть, в штате всегда должно быть минимум 1-2 человека только для обслуживания работы CC!
Ну если разработка закрытая и нужен внутренний репозиторий Git, то и там придется потеть. Хотя Gitlab нынче работает гораздо лучше, чем 5-6 лет назад.
mayorovp
03.04.2018 11:36Попотеть придется для того чтобы один раз его поднять. Кстати, Gitlab — далеко не единственный вариант.
Sklott
03.04.2018 13:36Ах да. И CC тоже требует нескольких специально выделенных админов для обслуживания! То есть, в штате всегда должно быть минимум 1-2 человека только для обслуживания работы CC!
Если у вас нет хотя-бы одного человека занимающегося Configuration Management, то одно из двух: или у вас маленький проект, или вы что-то делаете не так…
И это независимо от используемого инструментария.
Sklott
03.04.2018 13:26Не, ну вы сравнили!
Git появился в 2005, SVN в 2000, а CC в 1992.
Конечно в CC есть такие косяки, которые в новых системах поправили, например то что каждый файл имеет свое дерево версий. Но вместе с тем там было больше гибкости. И продумана система была неплохо. То что она довольно сложна для настройки и в обслуживании — согласен. То что она сложна для пользователей-разработчиков — нет, помоему (при правильной настройке) еще и попроще некоторых современных.
Насчет платности, так кто-же будет раздавать за бесплатно то, за что люди готовы платить? Старых проектов еще много…immaculate
03.04.2018 14:29Ну, дело было 10 лет назад, я уже не помню многие детали про CC. К счастью, с тех пор сталкиваться не приходилось. Но вот периодически спрашиваю тех, кто до сих пор там работает… Последний раз два года назад спрашивал, кажется. До сих пор так на ClearCase и сидят.
Да и вообще, статья не об этом, а об адских проектах. В той организации таких проектов вроде бы не было, во всяком случае, я с ними не столкнулся. А вот CC в память врезался.
sshmakov
03.04.2018 10:54ClearCase кое-кому в России достался практически бесплатно, причем легально, с ведома IBM. Просто в тот момент, когда IBM купили Rational, они захотели разрекламировать продукт и распространить его в крупняке.
А что за VCS из Швеции?immaculate
03.04.2018 11:23+1Про VCS из Швеции надо автор спрашивать.
А про ClearCase — вишенка на торте: пару месяцев назад прочитал, что IBM сама не использует ClearCase ни на одном проекте. Тут-то у меня в голове все и встало на свои места. Раньше не мог понять, как такой уродец в принципе мог возникнуть.
sshmakov
03.04.2018 11:38Это не их поделие, и даже не старой Rational, поэтому естественно, что IBM не использует.
danilec
03.04.2018 09:47-3Большинство новичков считали совершенно нормальным, что вынуждены приходить ровно в 9:00
Странно. Вроде и не новичок, а тоже прихожу на работу вовремя.
Ubuntaykin
03.04.2018 09:47Чего уж там. На одном предприятии при отправке электронной почты требуется в служебной записке указать размер отправляемого файла в байтах. Да, отправляемые файлы проверяются на предмет отсутствия секретов (что оправдано), и размер файла как раз играет роль контрольной суммы).
Whuthering
03.04.2018 11:06+4В следующий раз при мысли, что твоя работа отстой — подумай еще раз.
Ой, да ладно, я таком участвовал.
Заказчики — очень большие и богатые компании из нефтяной сферы. Проекту 10 лет, куча строк кода, про многие части которого никто не знает как они работают и почему именно так. Изначальная команда разработчиков свалила полностью в другое место из-за разногласий с руководством, на их место взяли разработчиков «с низов», в основном недавних студентов, большинство из которых даже не программисты, а инженеры разных специальностей, причем руководитель разработки тоже (и он как-то раз сам признался, что не знает, что такое «паттерн»). Кодовая база преимущественно на Delphi 7 (да-да), и перетащить на современные рельсы нельзя, т.к. никто не знает, как оно устроено и что делать если что-то отвалится.
Никаких тестов, только «херак и в продакшн», никаких VCS, только версионирование методом создания новой папки на расшаренном ресурсе.
Цикл разработки интенсивен, фичи добавляются резво и для разных заказчиков, четкого ТЗ нет, времени на рефакторинг и переписывание тоже. Только пиление новых фич, командировки для внедрения и поддержки, и поиски, почему оно стало внезапно и непредсказуемо падать после очередных изменений. Структура БД закладывалась те самые 10 лет назад, и тогда еще никто и не думал, что проект выстрелит и так разовьется — в итоге каждое изменение схемы БД это боль, костыли, и танцы с бубном на объекте заказчиков. Про «архитектуру» как БД, так и самого софта никто и не думает, живем одним днем.
И всё это дело управляет и контроллирует довольно ответственные процессы, стоящие довольно больших денег.
Рабочий день фиксировано с 8 утра, за опоздание хотя бы на 1 минуту утром или с обеда — унизительные объяснительные и теоретическое депримирование. Перекуры по расписанию каждые 2 часа не длительнее 10 минут. Регулярные командировки в раличиные еб… ня, отказаться нельзя.
Как школа жизни, место для старта и пример навсегда «как делать не надо» — прекрасное место :)
AlePil
03.04.2018 11:26+1Статья начиается с «несколько лет назад», то есть это даже не 2008 год, но, опять же судя по тексту, в 2008 году проекту было уже 12 лет, то нет ничего удивительного, что при разработке софта для госагенства в 1996 году был такой бардак…
Улыбнуло немного строчка про годы кризиса во Франции о 2008 года, причем такого, что для разрабов работка с зарплаткой просто за счастье, а в остальном…
Даже сегодня, когда говорится про разработку чего-то для госкомпаний и уж тем более каких-то агентств, и не только во Франции, но практически в любой стране, говорим всегда прежде всего об освоении бюджета, а выпуск реально чего-то работающего — это уже дело второе (если не десятое). Миллионы строк кода? Так в конце 90-х, начале 2000-х никто не отменял «индийскую» сиситему оплаты — больше кода, больше освоение средств выделенных на разработку.
ganqqwerty
03.04.2018 11:26Не исповедую никакого национал-шовинизма, но мне всегда тоже очень не везло с французами. Показалось, что у них крайне сильно распространено колониальное мышление, и отношение «я начальник ты дурак», даже в разработке ПО. И странное преклонение перед режимом работы — могли бы заставить в туалет строем ходить — заставили бы.
Throwable
03.04.2018 11:52+2Блин, как знакомо! Почти то же самое, только в одной крупной испанской транснациональной корпорации. Инструменты разработки — стек пропиетарных говнопродуктов нескольних крупных производителей со всеми вытекающими маразмами: BPM, ESB, MQ, Unix, Spark. Специалистов разработки нет. Организационная структура — перевернутая пирамида (продукт надо задвинуть в несколько стран, соответственно на каждую страну свой менеджер с командой дармоедов и т.д.). Постоянные трения, борьба за влияние и выяснение кто главный. Коммуникаций между командами никаких — каждый ревностно защищает свой огород, чтобы казаться незаменимым. Команда постоянно пухла, но вместо специалистов нанимались новые руководители, которые были даже не в курсе, кто и над чем работал в их команде. Проект переживал постоянные реорганизации, только за мое время сменилось 5 начальников. Специалисты вместо кодинга собирались в комнате и неделями обсуждали концептуальность того или иного решения, рисуя на доске бесконечные ящики и стрелочки.
В итоге проект зашевелился, когда наступил кризис, закончилось бабло и уволили 90% команды.
Из плюсов: платили хорошо, бабла было немеряно, кормили на убой, сортиры мыли несколько раз за день, кофе бесплатный, работа начиналась в 10:30.mayorovp
03.04.2018 12:01MQ и ESB — не маразмы. Хотя, конечно, от производителя и архитектора сильно зависит…
Throwable
03.04.2018 15:17Архитектор? Не, не слышали. В лучшем случае вся архитектура — это tutorials + best practices от производителя.
Насчет полезности ESB, лично моя практика показывает, что это не работает даже в компаниях с низким уровнем раздолбайства. По задумке команда ESB должна быть ответственна за все корпоративные интерфейсы: за дизайн, разработку, сопровождение, версионирование. Реально же получается, что системщики каждый раз умоляют их замепить уже задизайненные нужные им интерфейсы или изменить какой-то меппинг, а сами ESB-шники никогда ни о чем не вкурсе, тупо сидят на продукте и постоянно отнекиваются. В итоге ESB превращается в рудиментарную вещь, которая тупо мешает сразу всем.
И да, продукты дерьмо!
mayorovp
03.04.2018 15:43По задумке, ESB — это такая штука которая упрощает интеграцию с legacy. А потому ставить ESB нужно на границе системы, там где она с этим самым legacy должна интегрироваться.
Если же поставить ESB в центре системы — то в стадию legacy стремительно переходит все что пытается через нее взаимодействовать :-)
sshikov
03.04.2018 20:06М-м-м. Где-то это правда, но посмотрите на это с другой стороны. Вот живой пример, совсем свежий: через ESB бегают некие сообщения (сделки). Они внутри фильтруются, по своим атрибутам. И направляются туда или сюда — в разные системы. И вот в один прекрасный день аналитик одной из систем источников говорит разработчикам ESB — нужно поменять фильтр вот так — разрешить еще вот такие и такие типы, и такие-то, в том-то направлении. Аналитики системы приемника подтверждает.
Разработчик говорит: не вопрос, щас, работы на 15 минут. Ну ок, на 45.
Все это тестируется и выводится в релиз. А через два месяца прибегает сопровождение системы приемника (а точнее, еще одной системы, которая стоит где-то посередине), и шумят: «А-а-а, у нас в очереди ошибок ваши сделки!!!». Оказывается, что условия фильтрации сделали слишком слабыми, и под них попали некие производные сделки, типа, про которые никто не подумал. Так вот после этого аналитики с двух сторон еще пару месяцев обсуждали, как же эту ситуацию исправить — потому что в сообщениях не было такого атрибута, который позволил бы идентифицировать те из них, которые нужно отфильтровать. А добавить его — это не быстро.
ESB реально дает гибкость. Но это промежуточное звено, оно не должно решать, какие там «меппинги» должны быть. Даже если там дел на 15 минут )))Throwable
04.04.2018 18:25+1Ну это какой-то очень специфический пример. В реальных процессах взаимодействие между системами сводится к двум типам операций: когда одна система должна либо вызвать другую и получить от нее какие-то данные (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.
И вот на том и стоит весь корпоративный сектор: мажорные говнопродукты + куча скрепляющего самопального говна.sshikov
04.04.2018 19:20Я не знаю, кто такие «эти ребята», но у меня за последние четыре года было два крупных проекта, построенных на Apache Camel (и Karaf). И ничего, большей части описанных вами проблем в глаза не видели.
Throwable
05.04.2018 11:36Я не знаю ваш юзкейс, поэтому не могу судить о резонности применения ESB. В нашей среде практически все системы общаются через SOAP и Rest в рамках установленных бизнес-процессов. ESB здесь лишняя.
По поводу выбора инструментов: разобраться с Camel-ом не составит труда любому компетентнорму джависту. А вы попробуйте сделать то же самое на каком-нибудь пропиетарном продукте типа IBM Message Broker или Oracle Service Bus. Сначала встанет проблема найти соответствующих специалистов, затем вы ужаснетесь их ценам, и, наконец, разочаруетесь в их профессиональной компетентности. В итоге любое изменение в ESB выходит гораздо дороже и больнее, чем в системах.
Eldhenn
03.04.2018 12:38> Для первого извлечения кода (checkout) следовало назначить встречу с командой контроля версий. Встречу обычно назначали через неделю.
> Редактирование файлов не разрешалось без разрешения менеджеров среднего звена. Вы должны заранее сообщить своему менеджеру, какие файлы хотите отредактировать, а затем отправить официальный запрос на получение разрешения, который команда управления версиями может рассмотреть в течение нескольких дней.
Не верю. Либо что-то не так написано, либо преувеличено, либо вообще длинная цепочка испорченного телефона, но я не верю, что можно так работать — «посылать официальный запрос на разрешение редактирования файлов».F0iL
03.04.2018 13:00Возможно под «изменением файлов», для которого нужен специальный запрос, они имеют в виду изменение в master-ветке в процессе слияния с рабочим бранчем.
Crafter2012
03.04.2018 14:10+1Это если бранч не один)
только master, только хардкор. И да так бывает.
dim2r
03.04.2018 13:14В моем проекте порядка 20 млн строк кода. Правда языки полегче Delphi, plsql, vbs.
Если интересно, почитайте мой рецепт, как в таких проектах писать самодиагностирующиеся программы.
habrahabr.ru/post/342302
darkboatman
03.04.2018 14:44Редактирование файлов не разрешалось без разрешения менеджеров среднего звена. Вы должны заранее сообщить своему менеджеру, какие файлы хотите отредактировать, а затем отправить официальный запрос на получение разрешения, который команда управления версиями может рассмотреть в течение нескольких дней.
Здесь забыли (упомянуть?) внедрение системы документооборота.
madkite
03.04.2018 18:28+1Отсутствие динамического связывания библиотек: размеры исполняемых файлов начинаются с нескольких сотен мегабайт
Это спорный минус. Особенно на фоне всего остального кошмара.
У Google, например, на backend-е всё статически слинковано. Их стометровые бинарники пугают меньше, чем DLL Hell. А в Go — это вообще mainstream.dim2r
03.04.2018 18:34+1Особенно забавно, когда dll совмещается с ООП. Один модуль компилится с одной версией класса, другой модуль — с другой. Потом один модуль вызывает другой и все падает.
prospero78su
04.04.2018 11:04В Компонентном Паскале все эти проблемы были решены ещё в начале 2000х. Контроль типов на границе модулей. С учётом характера динамической загрузки модулей по требованию (и возможностью ручной выгрузки по окончании обработки) — даже сейчас весьма актуально.
dim2r
04.04.2018 11:47Когда есть под сотню модулей и они компилируются на разных машинах с немного разными версиями библиотек и опциями компилятора, то увы начинаются неотлавливаемые глюки.
prospero78su
04.04.2018 11:51Вы не понимаете суть компонентно-ориентированного программирования.
Оно создано специально, чтобы не было ошибок при компиляции на разных машинах с немного разными версиями библиотек и опциями компилятора. Никаких глюков не будет. Либо заработает сразу, либо никогда.dim2r
04.04.2018 12:26Я может не понимаю суть, но на практике часто сталкиваюсь с этим границами и падениями. У нас вперемешку дельфовский ооп с тучей компонентов, COM, RemObject, ActiveScript, ISAPI, WinAPI. Исходников примерно 2 GB. Скомпилированных модулей где-то 400 Мб.
prospero78su
04.04.2018 19:02При существующих в мейнстриме методов построения больших систем — это неизбежно. Вирт ещё в 90х предложил адекватный способ решения этих проблем. Дешёвый и исчерпывающий способ, систематический. Настоятельно рекомендую почитать по теме компонентно-ориентированного программирования, как основы расширяемых динамических систем. Ключевые слова: КОП, Component Pascal, WinAos (LinAos), Native Oberon, Oberon-2, Oberon-07. Думаю, также будет интересен материал о применении Оберон-технологий на сайте образовательного проекта «Информатика-21». Читается легко.
dim2r
05.04.2018 10:22Я когда учился в Новосибе в 90х, у нас Вирт в институте пару раз бывал. Привозил свой последний Оберон. Пареллельная группа на нём практиковала.
sshikov
03.04.2018 20:08Ну кстати, у нас (на хадупе) это тоже вполне mainstream. Проще собрать большой архив, чем думать, как на неизвестное число нод кластера динамически попадут все нужные тебе зависимости.
Singaporian
03.04.2018 19:47Я чет не понял… хэппи энда не будет?
BOOTLOADER
03.04.2018 20:29Судя, что дата публикации 2008 год и нет никакой новой информации… вместо хепи энд просто «The end !!»
alw
04.04.2018 14:01+1В связи с ростом популярности этого поста от 2008 года автор опубликовал сейчас некий follow-up, в котором написал, что по его неподтвержденной информации, главу проекта потом посадили за растрату бюджетных средств. Он не хочет уточнять эту информацию, но верит, что это правда.
projectfailures.wordpress.com/2018/03/24/follow-up-on-project-from-hell
Londoner
04.04.2018 12:03Кстати, кто знает примеры успешного оздоровления подобных проектов новым менеджментом?
Makc_K
04.04.2018 12:50Боюсь, что тут уже ничем не помочь.
Тут есть 3 варианта:
1) Как в староманекдотеДинастия юристов ведёт дело несколько поколений. Дед вёл, отец вёл. Вырос сын, тоже юрист и тоже ведёт это дело. Однажды радостный сын приходит домой и говорит: дед, отец, я закончил ваше начинание. Я выиграл это дело. Дед и отец погрустнели и отвечают: дурак ты, это дело кормило нашу семью несколько поколений…Londoner
04.04.2018 14:48Так то оно так, только вот сложно убедить заказчика, уже хорошо наученного горьким опытом, что у Вас получится что-то получше, чем уже имеющиеся три центнера ароматного говнокода.
Плюс обычно этот говнокод где-то нужен 24/7 вместе с пятью терабайтами криво хранящихся накопленных данных, так что даже одна мысль о миграции этого всего на новый проект приводит всех в неописуемый трепет.
И команду тоже разогнать не получится, ибо новая команда вообще не будет знать как к этому монстру подступиться.mayorovp
04.04.2018 15:24Мне кажется, конкретно в данном случае, когда заказчику даже релиз выдать не могут (сначала выдали пустой диск, потом выдали прошлый релиз) — заказчик был бы только рад подобным изменениям.
dim2r
05.04.2018 10:323) Выбросить все наработки, заново сформировать ТЗ, команду. И перезапустить весь проект с актуализированными требованиями и на современных технологиях.
Это возможно, если требования и люди стоят на месте. А в большой конторе, пока будешь собирать требования, уже успеется несколько новых законов выйти, смениться коллектив и перетусоваться бизнес структура. Очень трудно собрать требования для «бурлящего нечто».
alhimik45
04.04.2018 15:24+1три месяца. Это минимальный срок, чтобы иметь право уволиться во Франции.
Могли бы просто опоздать на минуту...
smer44
святые транзисторы, что они там такого делают? По описанию, то что проэкт на С++ это меньшее из зол по сравнению со всем описанным… такие экскременты мамонта как CORBA…
откуда столько классов…
Даже подумал что враньё если бы не видел своими глазами в мелкой немецкой (!!!) фирме:
kalininmr
ну почему, если С++, то сразу зло?
надо сказать, не так уж давно, особо не было альтернатив С++.
ява для десктопа стала пригодна довольно недавно, а GUI устаканилось вобще в 2010+ году(скорее в 2014, когда javafx8 вышел).
до 2000 года С++ был почти единственным вариантом для крупных проектов.
хотя были некоторые интересные экзотические штукенции, например Centura
smer44
не С++ зло а то что он позволяет делать.
удалить бы ему этак 80% синтаксиса)))
kalininmr
там не в синтаксисе дело, а в шаловливых ручках разработчиков :)
mclander
Ну да, сперва наплодим инструментов и сахара, а потом начнём бить программистов по рукам, за то что они этим пользуются…
True sorry… и это не только C++.
kalininmr
в котлине наплодили сахара, но стал безопаснее явы.
а так то и всякие shared_ptr — впринципе сахар :)
0xd34df00d
Проблемы как раз чаще обычно от непринятия новых практик, парадигм и прочего, которые упрощают написание выразительного, безопасного и эффективного кода (ну всякие там RAII, move semantics, constexpr if, лямбды, какие-нибудь boost/std::variant).
Arris
Удалить 80% шаловливых ручек? ;-)
kalininmr
оставить 2 пальца? :)
Arris
Можно и так, а можно вместе с носителем.
kalininmr
— Давайте отрубим голову!
— Но это жестоко.
— Ну… Тогда отрубим тело.
tangro
Вполне себе можно их просто не использовать. В куче проектов на С++ просто правилами проекта запрещены, например, исключения или goto. Разработчики знают, что такие вещи где-то там в языке есть, но сами от них не страдают.
guai
Если к языку надо доложить несколько сотен стайлгайдов, чтоб его можно стало продуктивно использовать — это признак хренового дизайна.
Нормальные языки отдельные секции safe/unsafe имеют, и это проверяется компилятором, а не манагером.
tangro
Стайлгайд тоже можно прикрутить на автоматическую проверку. Вот в студии последней даже Core Guidelines можно проверять.
guai
Что ж не прикрутили-то до сих пор?
На самом деле нельзя. Потому что для этого может не быть достаточно метаинформации в самом языке. Нормальный статический анализ к динамическому языку не приделаешь — инфы о типах нет. А к плюсам не прикрутишь, например, определение того, какие функции pure, какие нет, т.к. где-то в дереве вызовов обязательно наткнешься на библиотечную функцию, о которой ты не знаешь, pure она, или нет.
А также, это, по сути, выполнение одной работы 2 раза.
mayorovp
Там проблемы даже не c чистыми и нечистыми функциями, а с функциями и методами которые инвалидируют объект.
Я уже их перечислял: std::thread::detach, std::unique_ptr::release, std::move, std::future::share…
zenkz
Да ладно!
Delphi позволял делать отличный GUI вообще не напрягаясь ещё в конце 90х.
.Net появился в 2001 и к 2004 был вполне годен для создания GUI (WinForms), а с выходом в 2006 году WPF стало ещё красивее и удобнее.
C++ конечно не зло, но он требует наличия опытных программистов в команде, потому что по сравнению с другими языками выше порог входа и проще выстрелить себе в ногу. Поэтому-то в Enterprise стандартом стали C# и Java, а не C++.
kalininmr
Delphi малопригоден для крупных проектов, да и паскаль сразу ставит жирный крест. там были попытки ещё борланда, но не то чтоб выстрелило.
кстати С++ в дельфях тоже был.
.Net — ограничен платформой. а тут писали похоже под какую то экзотику
SergeyVin
Вы не правы. Я работал когда-то с ОЧЕНЬ большим проектом на Delphi. Думаю, не сильно ошибусь, если скажу, что там было порядка 20 млн. строк кода. И никаких особых проблем не было. Главное — разделить код на логические слои, которые, в свою очередь, раскидать по отдельным dll. Причем каждая dll — это отдельный COM-объект, то есть он загружается в память только если пользователь обратился к соответствующему куску функциональности. Проблема не в Delphi, а в очень низком пороге входа в него, что приводило к говно-софту с бизнес-логикой в OnClick. Вот в чем реально проблема Delphi, это отсутствие библиотеки коллекций. StringList и все. По крайней мере так было в те далёкие времена, когда я работал с Delphi.
geher
Это какая же версия Delphi была?
Сейчас глянул самую древнюю из доступных (5.5). Tlist и TCollection на месте, и очередь со стеком в наличии.
Да и сторонние библиотеки рпзнообразные коллекции предоставляли.
А позже и Tintegerlist добавили непосредственно в VCL (или RTL?).
А проекты на Delphi неслабые делались. Это да.
SergeyVin
TIntegerList тогда ещё точно не было. Про остальное не помню. Помню боль, связанную с этим, а детали выветрились. Ещё помню, очень активно использовали TClientDataSet, но за него отдельно платить надо было.
vbif
Боль скорее была связана не с отсутствием коллекций как таковых, а с необходимостью вручную создавать и удалять объекты, т.к. TList умел хранить только указатели.
za90
Зато я научился писать конструкторы и деструкторы. TList волшебен в этом смысле — дает базовую конструкцию и делай с ней что хочешь. Начинал с D3, дожил до D7. И это десктопное приложение до сих пор живо и перекрывает половину потребностей пользователей. Хотя уже давно вся функциональность перенесена в вэб. Ну вот не выходит так же удобно почему-то.
ElectroGuard
Рекомендую глянуть в сторону унигуя: www.unigui.com. D7, правда, увы, но на более свежих средах можно сделать вполне пристойное веб приложение, оставив почти весь легаси код.
SergeyVin
Версия, по-моему, Delphi 2007
Kealon
до Delphi 7 вкл., автор скорее всего имеет ввиду базовые коллекции которые есть в STL. С появлением генериков проблема в принципе хоть и не идеально, но решилась.
Помню ад на одном своём проекте на D7 из-за коллекций, 30+ модулей с {$I ...} реализаций базовых коллекций.
sshmakov
Delphi разумеется пригоден для крупных проектов, но здесь трехзвенка, для которой в Delphi в ту пору было не так много заготовок. Та же CORBA.
mclander
Pascal выигрывал свою часть рынка у С++ инструментов за счёт быстрой компиляции. Очень-очень быстрой, по сравнению с С.
Да, с сахаром в паскале плохо, а с бойлерплейтом хорошо. Но тем не менее, можно писать хороший, объектно или компонентно ориентированный код. Который к тому же близок к машинному. Т.е. выполняется тоже очень быстро (если программист не накосячил).
Ну и компоненты из коробки позволяли быстро накидывать прототипы. Главное было не увлекаться лишней юзабилити, по крайней мере на начальном этапе.
sanchezzzhak
Был есть еще Lazarus win/linux, Delphi не был таким ограниченным, сейчас продукт стал кросплатформеным.
Kobalt_x
Kylix ещё был — Delphi 7 compatible
ElectroGuard
Ой, как я вас всех люблю. Два проекта, в среднем по миллиону строк. Исходники около гигабайта. Всё отлично работает. Уймитесь.
MacIn
У нас примерно по 2 млн в двух проектах, опять же без проблем.
awesomer
Delphi
sshmakov
xBase же
Durimar123
>ну почему, если С++, то сразу зло?
Порог вхождения с С++ очень высок. А менеджмент, очень любит в место одного синьера брать на работу 3-4 джуниура. И можно только представить, что наделают их шаловливые, любознательные ручки, использую всю мощь С++.
RomanPokrovskij
Что плохого априори в собственном генераторе кода? Что значит «нормально вставить свой код»? Передать функцию/подцепить событие — это все что можно желать от любого объекта с поведением, если этого нет — плохо, но зачем же сокрушаться о каких-то «вставках», вас не поймут.
RomanPokrovskij
«обращение к БД когда выбираются все ряды, становятся java обьектами и потом в ПРОГРАММЕ цикл который ищет в списке один объект»
Это ни о чем не говорит, и за этим вполне может скрываться разумное распределение ресурсов — сервис поиска хорошо масштабируется (а ДБ индекс может не использоваться вовсе). Вторая причина: сплошь и рядом фильтрация в списках до 10 000 записей, перекладывается на клиента, чтобы время отклика между нажатием клавиши и обнавлением списка было максимально коротким (без сетевых задержек), те клиенту передается весь список, а потом «в ПРОГРАММЕ в ЦИКЛЕ» фильтруется.
smer44
подумай с точки зрения банальной эрудиции, если генератор кода хорош то его можно продавать за хорошее бабло, так как есть спрос на упростители разработок, если они юзают это просто так то это сродни быдлокода, что подтверждалось его фичами. Одна фича что в генерированый java исходник нельзя было вносить изменения, они стирались при повторной генерации, что по моему мнению — лютое быдло так как запомнить внесённое изменение в текст легче лёгкого. Генератор был тупой и не рассматривал декларированое как граф то есть возможные ссылки в разных местах на одни и те же обьекты из за чего возможны были глюки. Кроме того просто глюки GUI (он был в качестве плагина Netbeans) и надо было аккуратно соблюдать последовательность операций которые их обходили.
просто так прописали в утилиты которые обращались к БД. Было некритично так как таблицы сравнительно малы. Ещё в проэкте были также некритичные бессмысленные if несколько раз подряд, но был один глубокий глюк который никак не находился — причём при дебаггинге его не наблюдалось за счёт остановки на точке — хрен найдёшь.
Java проэкт без Spring. Это конечно маленькие звоночки по сравнению с громовым колокольным звоном описанного в статье. Предположу чрезмерную типизацию что обьясняет столько классов и ненужного кода, расширение CORBA своими утилитами но даже при таком оверхедле можно сделать сравнительно вменяемый (в производительности) проэкт… автор не написал откуда фантастический перформенс по компиляции и прочее…
Sklott
Может, наверное… Но врядли…
Однажды рефакторили одну программку которая выгружала данные из БД в специальном формате. Объем данных ~1-2 сотня Мб, время действия ~2000 года.
Программа работала ~1.5суток.
Первое что обнаружилось при внимательном рассмотрении, это что единственный SQL запрос выполняемый программой выглядел как «SELECT * FROM ».
Дальше шла функция выбора одной строчки из этой таблицы, поверх нее была написана функция поиска, которая вызывала функцию выбора одной строчки в цикле и т.д. и т.п.
Чисто замена этого «творчества», на нормальные SQL запросы сократило время работы программы до нескольких часов.
midday
Встречал людей, которые и не знали что такое SQL толком, юзали либу типа указанной выше обертки. Программа вытаскивала запросы суткаим, т.е. они даже и не могли ничего оптимизировать т.к. и не знали что там ковырять. Переход на нормальный SQL и немногих оптимизаций сократил запросы с почти пары суток до 20-30 минут =D
Arris
Однажды мне попал в руки код, который для отрисовки справочника ОКВЭД делал что-то в районе 1760 запросов к БД (в двух вложенных циклах — отрасли и подотрасли).
Оптимизация свелась к
SELECT *и обработке полученных 1760 строк в скрипте (ну и еще там были кое-какие мелкие фиксы)vlivyur
Пф. Мне попалось однажды чудо, когда для отрисовки небольшой таблицы (количество строк максимум штук 20, и фиксировано около 5 колонок) каждая ячейка запрашивалась отдельно одним и тем же запросом, который с первого же раза возвращал всю таблицу целиком, а потом в полученном результате искалась нужная строчка и бралась нужная колонка. Пользователи жаловались что очень медленно работает, но там БД отрабатывала около 20 секунд, а уж помноженное на 5, да на 20…
arheops
Недавний случай — asterisk, voicemail odbc. жалоба «не можем войти в управление voicemail». Результат анализа: при подозрении на неправильный порядок сообщений в базе выполняется заброс вида select * from voicemailmessages where DIR='XXX' and msgid='YYY'. Вроде ничего криминального, да? Но оно выполняется для ВСЕХ значений msgid от 1 до maxvoicemailmessages в цикле. для каждого обращения к войсмейл, ага.
Тоесть вроде как и индекс есть, и sql знал человек который писал. Но 1000 запросов по индексу база переварить не в состоянии за разумное время. После чего человек клиент ложит трубку и повторяет
KoToSveen
TC?