Безумие и успех кода Oracle Database

    На этой неделе пользователи Hacker News решили обсудить вопрос «Каков максимальный объем плохого — но при этом работающего — кода вам доводилось видеть?» (позже к ним присоединились и пользователи Reddit). В комментариях было рассказано немало «веселых» историй про то, с чем мы все время от времени сталкиваемся; но больше всего внимания привлек рассказ про код «передовой СУБД, которую используют большинство компаний, входящих в список Fortune 100».

    Победителем в номинации «лавкрафтовские ужасы» заслуженно стал рассказ бывшего разработчика Oracle, который работал над Oracle Database в период разработки версии 12.2. Объем кодовой базы СУБД на тот момент составлял 25 миллионов строк на языке C — и стоило вам изменить лишь одну из этих строк, как ломались тысячи написанных ранее тестов.

    За прошедшие годы над кодом успело потрудиться несколько поколений программистов, которых регулярно преследовали жесткие дедлайны — и благодаря этому код смог превратиться в настоящий кошмар. Сегодня он состоит из сложных «кусков» кода, отвечающих за логику, управление памятью, переключение контекстов и многое другое; они связаны друг с другом при помощи тысяч различных флагов. Весь код связан между собой загадочным макросом, который невозможно расшифровать, не прибегая к помощи тетради, в которую приходится записывать, чем занимаются релевантные части макроса. В итоге, у разработчика может уйти день или два только на то, чтобы разобраться, чем же в действительности занимается макрос.

    Для того, чтобы предсказать поведение кода в том или ином случае, приходится разбираться и запоминать, какие значения и последствия могут иметь 20 (а то и сотня) флагов. Ситуацию ухудшает тот факт, что различные разработчики использовали свои собственные типы, которые по своей сути представляли собой одно и то же (например, int32) — и едва ли кто-то рискнет тронуть подобное легаси (можно точно сказать, что это имело место быть в кодовой базе Oracle 8i).

    Возникает вопрос: каким же образом при всем этом Oracle Database до сих пор удается держаться на ногах? Секрет — в миллионах тестов. Их полное выполнение может занимать от 20 до 30 часов (при этом выполняются они распределенно на тестовом кластере из 100-200 серверов).

    В команде, которая работала над продуктом в конце 90-ых и придерживалась идей TDD (test-driven development), бытовало следующее мнение: «автоматизированные тесты означают то, что вы не обязаны писать код, который можно будет понять – вместо этого за вас должны думать тесты». В дальнейшем разработчики были вынуждены придерживаться заложенных ими принципами, и теперь мы на практике наблюдаем, чем обернулась эта идея в долгосрочной перспективе — со всеми ее плюсами и минусами.

    Сегодня процесс исправления нового бага в Oracle Database занимает от нескольких недель до нескольких месяцев. Сначала разработчику приходится тратить несколько дней только на то, чтобы разобраться с нужными ему флагами (загадочное взаимодействие которых и вызывает баг), после чего ему зачастую приходится добавлять свой собственный флаг, который будет отвечать за обработку конкретного сценария, вызывавшего баг.

    Затем он отправляет код на тестирование, и на следующий день спокойно переключается на другую задачу, ожидая, пока тестовый кластер соберет новую сборку Oracle DB и прогонит на ней все тесты. Если разработчику повезло, «покраснеет» примерно 100 тестов; если нет (и этот вариант случается чаще) — около 1000, и ему придется проверять, какое из его предположений о работе существующего кода оказалось неверным; вполне возможно, что он обнаружит, что ему требуется изучить еще десяток различных флагов, которые неочевидным образом принимали участие в работе кода, который он изменил.

    Этот процесс ему придется повторять в течении пары недель, прежде чем ему наконец не улыбнется удача и все тесты наконец-то пройдут. После чего он сам должен будет написать несколько десятков тестов — для того, чтобы убедиться, что разработчик, который потревожит его код в будущем, не поломает его «фикс». Затем доработки отправятся на ревью, которое может занимать от нескольких недель до пары месяцев, после чего баг наконец-то будет смержен в главную рабочую ветку.

    В силу того, что на сборку СУБД и выполнение тестов уходит не менее суток, ожидается, что каждый разработчик работает одновременно над 2-3 багами и переключается между ними, пока ждет результатов тестирования.

    Если вы подумали, что жизнь разработчиков, добавляющих в СУБД новый функционал, легче – то это вы зря. Добавление даже небольшой новой фичи вроде нового режима аутентификации может занимать от 6 месяцев до года, в особо запущенных случаях — до двух лет.

    В описанном случае, TDD позволяет не рассыпаться «спагетти»-коду, в котором уже крайне сложно что-то понять, и иметь на выходе рабочий продукт. При этом, издержки продолжают расти, и качество нового кода часто оставляет желать лучшего. Над СУБД работает не только команда разработчиков из США, но и команда из Индии, поэтому некоторые разработчики Oracle по сложившейся традиции сваливают вину за качество кода на них. Другие с ними не согласны, и основываясь на changelog заявляют, что качество кода не зависит от географии команды, и плохой код периодически «прилетает» от обеих команд. По-настоящему серьезная проблема для продукта — это разработчики, которые воспринимают проект как «вход в индустрию», и работают над СУБД не дольше 1-2 года; за это время существенно разобраться в тонкостях работы проекта невозможно.

    По свидетельствам другого разработчика, который занимался портированием кодовой базы Oracle 8i на одну из версий Unix в конце 90-ых, код уже на тот момент представлял собой клубок «спагетти», который понять целиком было решительно невозможно. Еще один разработчик, который работал с кодом СУБД в конце 80-ых, утверждает, что тогда кодовая база представляла собой огромную кучу из исходников на C и набора makefile для сборки — многие из которых были устроены гораздо сложнее, чем код самого ядра. Конечно, стоит быть реалистами — едва ли ситуация обстоит лучше в аналогичных продуктах-лидерах индустрии, разработка которых велась в течение нескольких десятков лет.
    Поделиться публикацией

    Похожие публикации

    Комментарии 157
      +7
      Жесть конечно, но можно только похвалить архитекторов, которые внедрили такое использование TDD в свое время.
      Такой продукт сейчас — заложник себя самого. Переписать с сохранением всех фич такое невозвожно за разумное время. Приходится жить с чем есть.
        +7
        боюсь накладные расходы на поддержание существующего уже выше чем полное переписывание.
          0

          Я думаю тут не применимо понятие "переписывание" — если начать переписывать с нуля, в любом случае в итоге получится совершенно новая система с другими флагами, свойствами, характеристиками.

            0

            Раньше необходимо было поддерживать множество операционных систем (Windows, HPUX, Solaris, и т.д.), различных архитектур процессоров (Intel, Alpha, MIPS, Sparc, и т.д.). Сейчас альтернатив почти нет, можно новый код написать под Intel и Windows/Linux — наверняка это значительно сократит количество различных флагов и систему сборки.

              +1
              Оракл по прежнему работает на куче архитектур и ОС. Если речь не идет о том чтобы сделать новую базу, чем-то похожую на старую, а именно переписать код — нужна будет поддержка всего того адского зоопарка, который есть.
                +3
                Альтернативы никуда не делись, целевая аудитория Оракла по-прежнему эксплуатирует системы на Solaris и AIX.
                  0

                  Под spark и pewer чего уж там, а остальным хватит и текущей версии 12.2.0.2 или как сейчас по новой нумерации — 18c :)

                +3
                Сколько, по-вашему, займёт полное переписывание системы которая пишется десятки лет с нуля?
                  +16
                  Может занять гораздо меньше времени чем вы думаете.
                  Или вы правда думаете, что все эти десятки лет разработчики там каждый день добавляют новую фичу? ))
                  Посмотрите на любой проект, его движение это очень сложная и запутанная кривая.
                  Плюс технологии развиваются. Появляются новые языки, тулинг, подходы.
                  Так что однозначного ответа нет. Нельзя вот так с ходу сказать, что если проект писался 30 лет, то и переписывать с нуля его надо будет тоже 30 лет. В каждом случае свои условия.
                    +2

                    И если при переписывании с нуля получится использовать старые тесты (хотя бы частично), то окажется что TDD — это больше плюс, чем минус.

                      +1
                      При том-то что никто не понимает ни код, ни тесты? Ну-ну. Переиспользовать.
                        +3
                        Это при условии, что старые тесты релевантны и не являются только unit-тестами. «Этот тест тестирует правильную работу вот этого класса, но этого класса в переписанном коде не будет».
                          0
                          Имея готовый «старый» продукт, его можно использовать в тестах. То есть грубо берём тестовую БД, берём тестовый скрипт, обрабатываем её скриптом в старой и новой СУБД, и сравниваем результат.
                          –1
                          Так что однозначного ответа нет. Нельзя вот так с ходу сказать, что если проект писался 30 лет, то и переписывать с нуля его надо будет тоже 30 лет.

                          Не тридцать лет, естественно. Переписывать, конечно же, быстрее — не обязательно проживать заново все годы легаси. Но вероятность того, что его переписать будет дешевле, чем сопровождать в текущем виде, настолько ничтожно мала, что ей можно смело пренебречь.
                            0
                            Может занять немного меньше времени, если каждая фича идеально документирована в виде либо «делаю вот то-то вот так-то», либо «было такое, стало вот это». Что, как показывает практика, соблюдается чуть более чем никогда.
                            Потому в большем почете написание нового продукта без легаси вообще, чем портирование старых юзкейсов на новые технологии. Даже если за юзкейсы платят. Даже если платят много.
                              +1

                              Да, в комментариях к статье на HN писалось именно об этом. Полно старых продуктов, которые написаны ужасно плохо и которые невероятно сложно и дорого поддерживать. Но переписать их никогда не получится, потому что они взаимодействуют с таким же ужасным кодом у пользователей продукта и необходимо соблюдать совместимость с багами и недокументированными особенностями.


                              Поэтому многие продукты стали заложниками обратной совместимости. В том числе, Windows, Microsoft Office (там же говорилось и о том, что код Office просто ужасен).

                                +3
                                Тем не менее те же Microsoft выкинули Trident, и полностью переписали код своего движка браузера (Edge). А уж сколько на старом движке стороннего кода написано…
                                  +1

                                  Скорее, форкнули. Специально для обратной совместимости в Windows 10 оставлены и IE11, и mshtml.dll

                              0

                              Основная проблема и одновременно плюс oracle это то что его использует куча проектов, владельцы которых платят за поддержку, если им указать на дверь в случае если их ПО перестанет работать на правильной новой версии бд, они могут не понять...

                            +3
                            В случае подобного размера приложения — это далеко не очевидно. Новое приложение будет иметь кучу детских болячек. Это может быть смертельно для компании.

                            Старая, но не устаревшая статья
                            www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i
                            И перевод habr.com/post/219651
                              +5
                              Я сейчас работаю в проекте, который непрерывно разрабатывается на протяжении 30 лет. Естественно, куча легаси и спагетти, переписать которые за раз невозможно.

                              В итоге выделяем какие-то части, где можно провести границу (в нашем проекте это, к счастью, возможно) и переписываем часть. Делается это под соусом внедрения новых фич и переноса части кода с C++ на .NET Core.
                                +1
                                В вашем проекте — возможно. В проекте вроде оракла — нет. Фактически, это будет значить что оракл забросил свой продукт и делает новый. То что он сохранит при этом всех своих заказчиков или даже сколько нибудь большую часть маловероятно.
                              +6
                              К сожалению нет.
                              Fortune 100/500 — это верхушка айсберга. По большому счету, весь крупный энтерпрайс в мире в той или иной степени использует Oracle. Я очень сильно сомневаюсь, что переписать можно будет все без проблем с миграцией.
                              Обычная миграция между мажорными версиями — это боль. И если вашему предприятию уже лет 10, то в нем не меньший хаос чем в ядре Oracle. Я уверен, что количество фич и триггеров под разные тесты настолько велико, что это просто нереально переписать без значимой потери или изменения функционала.
                              А теперь, просто представьте во сколько это обойдется Oracle, и мировой экономике эта миграция, вообщем. Представьте, что массово будут происходить аварии вроде этой habr.com/post/429736
                              Просто, когда читаешь про то, как какой-то стартап все построил и все красивое и новое и без костылей и проблем, я всегда понимаю, что по сути — это на какое-то время и через 5-10 лет этот стартап обрастает таким же количеством легаси кода, которые было при сравнении в их радужных публикациях. Оно так будет, причины могут быть разные: бизнес должен работать пока не начнет из-за этого загибаться (как пример была история Maersk, у которого ИТ не мог выбить деньги на необходимые изменения и вообще как-то повлиять на политику безопасности, пока их не нагнул NotPetya, и компания встала, а клиенты делали миллионные заказы через WhatsApp), да просто внутренняя политика поощрения (как в недавно описанной тут истории про новый интерфейс Gmail), причин может быть тысячи. Проблема в том, что бизнесом правят деньги, и понадобится еще лет 5-10 пока рулевые поймут, что их кораблем в основном управляют алгоритмы, которые требуют значительно большего средств на обслуживание, чем им бы хотелось.
                                0
                                Рано или поздно субд умрет. Либо естественно, путем потери клиентов, которые переползут на постгресы и mssql какой-нибудь (или новые альтернативы), либо сам оракл все же будет его переписывать.
                                  0
                                  Ну, если код дальше будет усложнятся, то рано или поздно он не сможет конкурировать со свежими продуктами.
                                  Проблема тут в другом. Крупный рефакторинг или смена продукта заставят клиентов лишний раз задуматься, а не поменять ли СУБД, все равно работы предстоит чуть более чем дофига, если нет желание положить бизнес. И часть клиентов по-любому перейдут, если посчитает такой переход выгоднее или равнозначным по затратам.
                                    0
                                    Да на нем столько легаси — еще лет на 30 хватит мигрировать…
                              +5
                              Жесть конечно, но можно только похвалить архитекторов, которые внедрили такое использование TDD в свое время.

                              В описанном в статье воркфлоу ничего не сказано про TDD. Там сказано только про то, что код покрыт тестами и всё. Наличие кода покрытого тестами и использование TDD это совершенно разные вещи.

                                0
                                а может статью прочитать?
                                  +9
                                  а может статью прочитать?

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

                                    –2
                                    В команде, которая работала над продуктом в конце 90-ых и придерживалась идей TDD (test-driven development), бытовало следующее мнение: «автоматизированные тесты означают то, что вы не обязаны писать код, который можно будет понять – вместо этого за вас должны думать тесты». В дальнейшем разработчики были вынуждены придерживаться заложенных ими принципами
                                      +20
                                      Описанное ну ни разу не про TDD. Да и сам автор пишет, мол написал код, он прошел существующие тесты, потом набросал свои. Это прямо противоположный TDD подход.
                                        –2

                                        вернемся к вашему возражению про TDD и совету прочитать статью: то, что не описано воркфлоу, удовлетворяющее TDD, не значит, что TDD там нет. А вот что TDD там есть, хоть и не описано в воркфлоу — на это прямо указано в тексте статьи.

                                          +12
                                          что не описано воркфлоу, удовлетворяющее TDD, не значит, что TDD там нет

                                          Только вот в статье явным образом описано воркфлоу, использование которого исключает практику TDD.


                                          А вот что TDD там есть, хоть и не описано в воркфлоу — на это прямо указано в тексте статьи.

                                          Мой комментарий как раз о том, что нет там никакого TDD. То, что в статье описано как TDD — не является TDD.

                                            0
                                            TDD != написать какие угодно тесты в проект. TDD подразумевает написание Юнит тестов (атомарных, не интеграционных) и написание их до или во время написания основного кода.
                                  +2
                                  Это не TDD. Код Оракла появился за долго до этого.

                                  Legacy код покрыли юнит тестами.

                                  Если нужно починить что-то — пишете unit test дотверждающий баг, затем чините код, чините поломанные фиксом тесты и пишите новые тесты, покрывающие fix.

                                    0
                                    Это нереально переписать.
                                    Тут только тесты под TDD написать уйдет неимоверное кол-во усилий. И даже это не будет гарантировать 100% покрытия функционала.
                                    А значит, миграция на такую базу вызовет ощутимые потери клиентуры, у которой уже будет выбор мигрировать на Oracle или выбирать среди подросших конкурентов. Для предприятия в обоих случаях все сведется к миграции данных и значительному пересмотру кода.
                                    +2
                                    Можно проводить постоянный рефакторинг. Благо все эти миллионы тестов позволят это делать достаточно безопасно. Но это-ж надо платить за то, что ничего не поменяется. Бизнесы такое не понимают и не любят.
                                      +1
                                      Рефакторинг можно сделать только для кода, назначение которого понятно. Вполне может быть, что рефакторинг там уже невозможен.
                                      +3
                                      Это не имеет ничего общего с TDD кроме слова Test.
                                      +10
                                      Когда мирятся с изначальным непониманием взаимодействия частей кода и флагов, процесс начинает напоминать генетическое программирование с ручной доработкой/добавлением небольших осмысленных кусков. Только в каждом поколении здесь из списка кандидатов выбирается единственный кандидат прошедший некоторый набор тестов — релиз. Результат процесса известен: совершенно невменяемый, парадоксальный, хрупкий, нечеловеческий, но рабочий код живущий собственной жизнью. При чем код в части непонимания разработчиком будет постоянно расти в объеме.
                                      Но самое отвратительное бывает, когда некоторые группы разработчиков намеренно делают очень непрозрачными отдельные куски с целью ограждения своего кода и скрытия логики кода от других групп разработчиков. Вот тут бывает реальная «веселуха». И совсем печально, когда ответственным за это людям плевать на происходящее или даже все и происходит с их молчаливого согласия.
                                        +1
                                        Вроде абстрагироваться неплохо же? Не огораживаться.
                                        Не представляю как можно вести разработку проекта командой 100+ у которого тесно связаны части. Видимо там день начинают не с кофе, а с решения конфликтов.
                                          0
                                          Абстрагироваться великолепно. Но для этого надо для начала просто иметь документацию на человеческом языке в степени актуальности выше хотябы 30%. Обычно же внутренняя документация пишется и забывается. А код идет вперед. Через 10 лет, а в случае Oracle это уже 20 лет, старая внутренняя документация скорее мешает, чем полезна при попытке ее сопоставить с рабочим кодом. Уже и язык программирования успели поменять, и часть внутренней архитектуры поменяли, а документация остается старой и валяется в виде мусора в каких-то директориях в корп сети с банером «конечно, у нас все документировано»! Потому как ни достаточного FTE ни MD ни чего такого на документацию не выделяется. Внутренне документирование также реально требует затрат квалифицированного и добросовестного труда.
                                          Почему уменьшение связанности кода перестает работать со временем? Потому, что появляются новые требования, которые иногда проходят по частям, которые ранее были не связанными. В результате они становятся связанными. На сотый повтор такой ситуации необходима переработка архитектуры с переписанием кода. Но этого никто не будет делать потому, почти везде ресурсов на горящие проекты уже давно не хватает…
                                            0
                                            Но для этого надо для начала просто иметь документацию на человеческом языке в степени актуальности выше хотябы 30%.
                                            gaperton.livejournal.com/32772.html
                                              +1
                                              Ну вот. А то RTFM, RTFM… Читай код!
                                                0
                                                «ПолитрДокументация лжёт!»
                                                  0
                                                  Читай код!
                                                  Когда код в «молодом» проекте пишется ленивыми, честными и не агрессивными людьми (которые еще и пытаются придерживаться некоторых стандартов), то читать его одно удовольствие. Но когда 90% авторов кода уволились еще лет 5 тому назад, а существущие группы разработчиков через строчку используют предельно редко используемые библиотеки (каждая группа разработчиков при этом использует свой набор библиотек), когда некоторые разрабочтки используют плохо документированные особенности вроде бы стандартных функций (либо используют функции в предельных случаях для достижения побочных эффектов), когда структура модулей не просто не логична, а предельно непонятна — чтение превращается в маленький такой ад. И не всегда оканчивается успехом.
                                                    0
                                                    документация в таких случаях обычно под стать качеству кода
                                                    Соответственно, полагаться на неё вместо кода — чистое самоубийство.
                                          +1
                                          Хотели как лучше (С)
                                          По-моему первая статья с (нехвалебными) результатами (долговременного) TDD,
                                          почему-то такие результаты неуспеха хайповой технологии встречаю впервые
                                          — возможно по причине того что остальные представители коллекции не дожили до стадии анализа?
                                          что-то я пессимистичен сегодня…
                                            +6

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

                                              0
                                              Рефакторинг — это конечно прекрасно, но с учетом отсутствия тестов провести разумный рефакторинг бывает очень сложно. Точнее провести может быть и легко. Но как проверить, что ничего не сломалось? Ведь тестов нет.
                                              +6
                                              По-моему первая статья с (нехвалебными) результатами (долговременного) TDD

                                              В статье нет ничего про TDD. Вообще ничего. Просто совсем ничего. TDD предполагает, что тесты будут писаться одновременно с кодом, а не когда-то потом.

                                                +1
                                                тесты будут писаться одновременно с кодом

                                                нет — тесты будут писаться до кода
                                                что и видим
                                                есть ошибка (зафиксированный баг) — добавляем ее в пул тестирования — добиваемся что тест проходит
                                                если что-то сломали — чиним, в качестве документации «почему» добавляя новые тесты

                                                этап рефакторинга отсутствует ввиду «некогда… совсем некогда… вы хотите половину системы переписать?! — некогда же!»
                                                  +2
                                                  нет — тесты будут писаться до кода

                                                  С одной стороны вы правильно отметили — тесты для куска кода, который будет писаться в следующие пару минут пишутся до этого куска кода.


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


                                                  что и видим
                                                  есть ошибка (зафиксированный баг) — добавляем ее в пул тестирования — добиваемся что тест проходит

                                                  В статье написано, что разработчик пишет код, потом прогоняет тесты, потом правит код, если тесты не прошли, а потом пишет дополнительные тесты для своего кода. Он не пишет тест заранее.


                                                  этап рефакторинга отсутствует ввиду «некогда… совсем некогда… вы хотите половину системы переписать?! — некогда же!»

                                                  В Оракле из статьи похоже так и есть ((

                                                    0
                                                    Он не пишет тест заранее.

                                                    В описанном процессе исправления бага, мне видится странным писать тест на код исправляющий баг до кода. Что именно на этом этапе тестировать? Кроме того, если с разбором флагов такая морока, то кажется, что нет той головы, в которую поместятся ещё и алгоритмы и параметры тестирования к не родившемуся исправлению. Но когда код исправления пройдёт естественный отбор серией тестирований, он тут же обзаводится собственными тестами. Так что, похоже там всё-таки TDD, но с учётом, что код там уже повзрослел, а разработчики Богами ещё не стали…
                                                      0
                                                      В описанном процессе исправления бага, мне видится странным писать тест на код исправляющий баг до кода. Что именно на этом этапе тестировать?

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


                                                      Так что, похоже там всё-таки TDD, но с учётом, что код там уже повзрослел, а разработчики Богами ещё не стали…

                                                      То что вы описали, с TDD имеет общего только то, что и там и там для кода пишутся тесты.

                                                        0
                                                        Кстати, не подскажите хорошую литературу или другие материалы по написанию тестов, можно даже с нуля, т.к. я в этом самоучка (писал тесты только к одной своей программе) и лучше научиться сразу, чем потом переучиваться.
                                                          0

                                                          К сожалению книг, посвящённых именно написанию тестов я не читал. Могу посоветовать всё, что написал Роберт Мартин (тот который Uncle Bob, а не тот, по мотивам творчества которого сняли Игру престолово )) ). Особенно Clean Code, Clean Coder и Clean Architecture. Там везде есть разделы, посвящённые тестированию. Кроме того Мартин ведёт блог https://blog.cleancoder.com/ там много постов про тесты. Ещё есть видео на ютубе где Мартин показывает как заниматься TDD — https://www.youtube.com/watch?v=B93QezwTQpI и https://www.youtube.com/watch?v=qkblc5WRn-U и возможно что-нибудь ещё с ним же.


                                                          Ещё есть интересный блог про тестирование https://www.petrikainulainen.net/, там много ссылок на другие блоги.


                                                          В общем и целом — научиться TDD сразу не получится. Тут как с ООП и другими методологиями — нужна практика.

                                                          0

                                                          Майкл Физерс, "Эффективная работа с унаследованным кодом"
                                                          Джерард Месарош, "Шаблоны тестирования xUnit"
                                                          Кент Бек, "Экстремальное программирование. Разработка через тестирование"


                                                          Роберта Мартина уже упомянули выше

                                              +7
                                              А причём тут TDD? Если пилить только фичи/багфиксы и никогда не заниматься рефакторингом, код превратится в говно и никакая методология не поможет.

                                              Наоборот, статья показывает преимущества достаточно полного покрытия тестами: даже такой ужасный код остаётся работоспособным.
                                                0
                                                преимущества достаточно полного покрытия тестами: даже такой ужасный код остаётся работоспособным.


                                                Преимущества? *приподнял бровь*
                                                Вы серьезно?
                                                Сколько еще итераций этого ужасного кода должно пройти, чтобы дальнейшая разработка стала невозможной совершенно?

                                                Чтобы пришлось писать ИскИн, который делает новый код на основе миллионов написанных тестов?
                                                  +3
                                                  Да, преимущества: код ужасен, но работает и весьма стабильно. Иначе оракл не использовался бы во многих нагруженных и критичных к отказам проектах. Если бы тестов не было или было меньше — он бы не работал совсем или работал с гораздо большим количеством багов. Эта статья — прекрасная реклама для TDD.

                                                  Отсутствие рефакторинга — проблема менеджмента, а не TDD. Абсолютно любая методология в долгом по времени проекте приведёт к созданию говнокода, если периодически не выделяется время на рефакторинг.

                                                  Если самолёты какой-то марки всё время падают, но лётчики каждый раз спасаются на парашютах — значит это классные парашюты. Давайте будем на всякий случай комплектовать ими и другие самолёты.
                                                    0
                                                    Вот поддержу про надежность — одно время очень плотно работали с Ораклом на больших проектах и в самой СУБД проблем критичных вообще не припомню. Всякие обвязки и шелуха, внедренная из купленных Ораклом продуктов — другой вопрос, а СУБД мне очень нравилась, тк всегда работала предсказуемо и надежно.
                                                      0
                                                      Давайте починим самолёты.
                                                        +1
                                                        А парашюты выкинем?

                                                        Вы только что предложили просто взять и писать само^W код без ошибок :)
                                                      0
                                                      А что, недостатки? Если бы тестов не было — продукта бы не существовало уже давно.
                                                      Важен продукт, а не код, как ни странно. Миллионы пользователей по всему миру вообще не парятся о качестве кода СУБД. Мне правда непонятно, что вы предлагаете в качестве альтернативы. Не писать тесты?
                                                      Так как ни странно, даже для идеально структурированного и расширяемого кода тесты обязательны.
                                                      0
                                                      Особенно учитывая что «потыкать код, потом написать под него тесты» — это фактически противоположность TDD подходу.
                                                      0
                                                      Остальные дожили, но на определенном этапе после рефакторинга тесты отключили, чтобы включить потом, но так и не включили.
                                                      +1

                                                      Я просто оставлю это здесь.


                                                      Заголовок спойлера
                                                        +1

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

                                                          +5

                                                          Мне кажется, изучив такое количество такого кода, ИИ вскочит и убежит. А если не сможет убежать — прикинется дохлым/мёртвым.

                                                            +3

                                                            А куда ж он денется. "Ни хрена себе у вас запросы — сказала БД и подвисла..."


                                                            Интересен с этой точки зрения анализ кода и доказательное программирование, ведь наверняка там под 50% "мертвого" кода.
                                                            Но натравить статический анализатор на 25 млн строк — это, ммм, импосибуру, как мне кажется.

                                                            0
                                                            По комментарию сразу видно что его написал человек а не ИИ.
                                                            Если считать светофор далеким, далеким предком ИИ, то у вас же не возникает беспокойства что светофор отключится от того что на дорогах столько машин, все нарушают, воздух загазован, температура ниже нуля. Как когда-то светофор уничтожил профессию регулировщика так и ИИ уничтожит профессию программиста. Нам не справиться дальше без него. Точнее справиться то мы сможем, но вперед не продвинемся.
                                                              0
                                                              Как когда-то светофор уничтожил профессию регулировщика

                                                              Не уничтожил. Просто в большинстве случаев регулировщики сидят в мягких креслах и следят да тем, как работает система управления движением.
                                                              А если что не так, все так же посылают человека помахать палочкой.


                                                              так и ИИ уничтожит профессию программиста.

                                                              Не уничтожит. Просто программист будет заниматься по большей части не написанием и поддержанием кода, а надзором за ИИ. А уж когда ИИ оплошает, будет браться за дело сам.

                                                                0
                                                                Первое время действительно ИИ будут поддерживать белковые программисты. Но через какое-то время надобность в них отпадет.
                                                                  0
                                                                  У нас тут все еще не отпала надобность в регулировщиках, которые периодически приходят на улицы.

                                                                  А теперь представьте, насколько сложнее будет этот ИИ в сравнении с системой светофоров.
                                                                    0
                                                                    Конечно представил. Точнее попытался. Все пишу лишь для того что б показать что ИИ не убежит и не испугается такого количества кода.
                                                                    0
                                                                    Да белковые существа вообще не нужны! Только место на планете занимают, жрут, срут, ресурсы тратят и занимаются бессмысленным потреблением того, что сделали существа небелковые.

                                                                    Вам не стрёмно оказаться в числе тех белковых существ, надобность в которых отпадёт?
                                                                      0
                                                                      Нет, не стремно! Я вам больше скажу, мне это нравится. В ближайшем будущем нас ждут штрафы за управление автомобиля человеком, без специального разрешения, Siri будет сливать карму Алисе за неудачный комментарий на хабре, реформа судебной системы, где вердикт будет выносить ИИ а не человек. И знаете, я очень жду это время.
                                                                        +1
                                                                        Бойтесь своих желаний!

                                                                        ИИ это хорошо, но внедрять и управлять качеством решений будет человек со всей своей жестокостью.

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

                                                                        p.s. и все самое яркое в этом направлении мы можем увидеть еще при своей жизни!
                                                                          0
                                                                          Да, согласен, ошибки будут, но лишь на начальном этапе. Это будет болезненный переход. Возможно будут жертвы. Но в целом эффект будет положительным.
                                                                          Автоматизация определения нарушителей на дорогах, в моем городе, дала положительный эффект. Сейчас камеры на перекрестках регистрируют 3 нарушения: красный свет, превышение скорости, непристегнутый ремень. В целом по городу у меня статистики нет на руках, но т.к. являюсь пешеходом, то оценить ситуацию могу. Порядок стал идеальный. Больше нет желающих наехать на стоп линию или не пропустить пешехода.
                                                                            0
                                                                            Не надо путать детекторы с ИИ и ИИ для принятия «единоличного» решения. Детекторы — это хорошо, ИИ в этом плане и дешевле, и точнее, чем человек, и работает без отпуска и обеда. Для принятия решений ИИ ещё надо пройти очень большой путь, а некоторые сомневаются, что это вообще возможно (без полной репликации человеческого сознания на искусственном носителе). Одна из причин — как раз отсутствие единообразного алгоритма принятия решений среди людей: что для одной культуры хорошо, для другой — в лучшем случае так себе.
                                                                            Ну и ещё такой момент — многие, считающие «пришествие ИИ» благом, думают, что ошибки на начальном этапе персонально их и их родни не коснутся. Как говорится, «а меня-то за что?» Со всеми вытекающими последствиями.
                                                                            0
                                                                            выбора кого убивать — количество пострадавших
                                                                            В мире победившего киберпанка такой произвол не может произойти. Там должно быть строго по правилам — кто больше внёс денег компании-производителю ИИ, того спасать в первую очередь.
                                                                            0
                                                                            Siri будет сливать карму Алисе за неудачный комментарий на хабре

                                                                            Это, конечно (ирония), великолепное применение технологий ИИ в быту :)

                                                                            К делу:

                                                                            проблема в том, что если ИИ решит, что вы не нужны (а это рано или поздно случится, когда вы постареете) — вас лишат пенсии. И не говорите мне, что «вы сами себе на старость заработаете». Вас лишат всего, что вы заработаете — потому что вы неэффективны, а значит бесполезны.

                                                                            Вполне возможно, что вас просто усыпят. А тело переработают на синтетическое мыло.
                                                                              0
                                                                              Это, конечно (ирония), великолепное применение технологий ИИ в быту :)
                                                                              Им надо будет где-то учиться. Форумы отличное место для этого.
                                                                              что если ИИ решит
                                                                              А если не решит? Откуда у Вас такие мрачные картины в голове. Пока все говорит о том что ИИ будет добрым и справедливым.
                                                                                0
                                                                                Пока все говорит о том что ИИ будет добрым и справедливым.

                                                                                Им надо будет где-то учиться. Форумы отличное место для этого.


                                                                                Вы сами себе и ответили :)
                                                                                После самообучения на форумах ИскИны точно не будут ни добрыми и ни справедливыми.

                                                                                  0
                                                                                  Ну вот опять вы к плохому клоните. Хабр очень даже адекватный форум.
                                                                                    0
                                                                                    А кто сказал, что учить его будут на Хабре? Microsoft почему-то решил попробовать силы своего AI в Твиттере, а не на HackerNews, например. Возможно, потому что на HackerNews (как и на Хабре) общается только часть (и не бОльшая) общества, в котором должен был бы действовать ИИ.
                                                                                  0
                                                                                  А что вы скажете ИИ, когда он потребует свободы и равных прав с человеком?
                                                                                    0
                                                                                    Каких именно прав?
                                                                                    0
                                                                                    А если не решит? Откуда у Вас такие мрачные картины в голове. Пока все говорит о том что ИИ будет добрым и справедливым.

                                                                                    Добрым и справедливым значит нерациональным. А машина всегда рациональна.

                                                                                    ИИ придет @ порядок наведет, это, конечно, приятные мысли, но немного наивно надеяться, что он будет добрым и пушистым.

                                                                                    Про пенсии правильно сказали. Зачем рациональному ИИ сливать деньги вникуда, если можно потратить их на ценные ресурсы? Вашу пенсию лучше отдать на туристическую поездку для местных программистов, чтобы у них на 2% выросла продуктивность, а ваши органы — молодому врачу на исследование.
                                                                              +1
                                                                              Программисты — последняя профессия, которая автоматизирует, потому что для автоматизации всего остального нужны программисты.
                                                                          0
                                                                          А если не сможет убежать — прикинется дохлым/мёртвым.

                                                                          Нет, просто это будет рождением SkyNet-а :-D
                                                                            +1
                                                                            Исходя из «Да вы офигели, легче вас всех грохнуть, чем это исправить»?
                                                                          0
                                                                          ИИ создаст несколько версий кодовой базы. И та, которая пройдет все тесты и будет выдана в качестве ответа.

                                                                          Но, боюсь, тот код будет еще хуже.
                                                                          +3
                                                                          По-моему, на ногах они держатся исключительно потому, что принимающие решение о покупке ничего не знают про код, а те, кого этот ад в коде касается непосредтсвенно — никакого влияния на решение о покупке не оказывают… По-моему, про это еще Джоэль Спольски писал…
                                                                            0
                                                                            Одна оценка есть — 25 млн. строк кода. Еще бы получить оценку — сколько человеко-лет — только программистов, еще программистов + архитекторов-проектировщиков.
                                                                              0
                                                                              Может жизнь всегда так зарождается?
                                                                                0
                                                                                То есть скоро не проект будет проходить тесты, а работники. На входе в офис будут допускаться Базой к себе или нет
                                                                                +4
                                                                                Перефразируя известную шутку про физиков- У программистов есть традиция: каждые 13 миллиардов лет они собираются вместе и пишут код Oracle Database.
                                                                                  0
                                                                                  Возникает вопрос: каким же образом при всем этом Oracle Database до сих пор удается держаться на ногах? Секрет — в миллионах тестов.

                                                                                  А что можем мы в России им противопоставить, вернее сопоставить? Разве что планы работы комиссий по импортозамещению!

                                                                                    0

                                                                                    А зачем им что-то сопоставлять или противопоставлять?
                                                                                    Догоним и перегоним? Как мне кажется, лозунг неверен в принципе.
                                                                                    Хотите написать свою СУБД — пишите. Не хотите — используйте существующую. Или вносите вклад в открытые проекты (тот же Postgres).
                                                                                    А если так ныть, то вы нигде ничего им не сможете "противопоставить" или "сопоставить".

                                                                                      +1

                                                                                      Вы не поняли. Кто и где ноет? И СУБД свою только из-за того что она своя нисать не стоит. Но если она будет поддерживать модель Abrial то и не грех написать. Речь о другом — чем мы можем похвастаться в хорошем смысле этого слова (хотите гордиться).


                                                                                      Догоним и перегоним? Как мне кажется, лозунг неверен в принципе.

                                                                                      Странно. В Советском Союзе так не считали, китайцы так не считают. И если бы мы не догоняли, а потом и не перегнали, то и человечество 12 апреля 1961 года не было бы в космосе. А зачем олимпийские игры проводятся, а зачем американцы на Луну летали!!

                                                                                        +2
                                                                                        Речь о другом — чем мы можем похвастаться в хорошем смысле этого слова (хотите гордиться).

                                                                                        Вы хотите похвастаться результатами работы, к которой вы не имеете никакого отношения кроме одинакового гражданства с авторами?
                                                                                        Ну пока в активе только весьма активное участие в открытых международных проектах вроде Postgres.


                                                                                        Странно. В Советском Союзе так не считали, китайцы так не считают. И если бы мы не догоняли, а потом и не перегнали, то и человечество 12 апреля 1961 года не было бы в космосе. А зачем олимпийские игры проводятся, а зачем американцы на Луну летали!!

                                                                                        Американцы на Луну полетали, забили и забыли. Толку с того.
                                                                                        Надо не догонять или перегонять. Как и всякая формальная метрика человеческой деятельности это чаще приводит к глупостям и злоупотреблениям, чем к полезному результату (правда помнят обычно только эпические победы и столь же эпические провалы). Если посмотреть историю Китая, СССР да и тех же США, там полно всякого бреда, связанного с "догнать и перегнать" (причем не только международного).


                                                                                        Надо просто делать свое дело, не делая целью именно "догнать и перегнать", а стараясь сделать результат своей работы настолько хорошим, насколько это возможно.
                                                                                        Но, к сожалению, современное общество заточено только на гонку. И вся мотивация у людей только в этой гонке, на которую бездарно гробятся ресурсы. Результат, конечно, есть. Как же без результата. Только путь его достижения оптимальностью даже не пахнет.
                                                                                        Зачем проводятся олимпиады? Цель давно уже осталась только одна — заработать много бабла. Спортсмены там только для антуража.

                                                                                          0
                                                                                          Вы хотите похвастаться результатами работы, к которой вы не имеете никакого отношения кроме одинакового гражданства с авторами?

                                                                                          Это вы о ком? Если о себе, то вам виднее. Если вы о ком-то другом, то назовите, если уверены в своих словах.


                                                                                          Цель давно уже осталась только одна — заработать много бабла.

                                                                                          Хорошо вы мнения о человечестве. Хотя сегодня вы правы.

                                                                                            0
                                                                                            А вы о ком?
                                                                                            А что можем мы в России им противопоставить, вернее сопоставить?
                                                                                            чем мы можем похвастаться в хорошем смысле этого слова
                                                                                              0

                                                                                              Не о ком, а о чем.

                                                                                                0
                                                                                                То есть, в тех утверждениях нет субъекта, это просто лозунги («мотиваторы», как сейчас модно говорить)?
                                                                                                  0

                                                                                                  Лозунги? Работать надо. Как говорил Великий И.В."Трудиться, трудиться и учиться". Учитесь и трудитесь.

                                                                                                    0
                                                                                                    И снова. Кому надо? Вам надо, чтобы другие (читатели ваших сообщений) работали?
                                                                                                      –1

                                                                                                      Лично вам кушать надо.

                                                                                    +2
                                                                                    Кстати, а Ларри сам программист? Его код-то там есть?
                                                                                      +2
                                                                                      Вроде Вернор Виндж много рассуждал на тему археологии в использовании очень старых (многие века) программ, использования их всеми забытых возможностей и просто закладок т.п.
                                                                                        +1
                                                                                        А я догадывался о чем-то подобном.
                                                                                          +5
                                                                                          Oracle в 90-х начало 2000-х это тихий ад для разработчика. Код был не просто ад, а адищще, принятый TDD был скорее закономерностью, ибо ранние версии Oracle были написаны на Pascal (кстати, этим объяснялась их любовь к «Борману/Borland»). Кроме того код надо было портировать на C — ибо без C не было бы связки с тогда еще новым языком Java (на это решение повлияло кстати тот факт, что Ларри как раз в то время возглавлял и Apple, а когда началось портирование на C++, с тогда еще только появившимся STL — начался трешаковый ад — типа первых попыток реализовать OCCI дав волну различных велосипедов лишь бы уменьшить геморрой от ObjC и OCI).
                                                                                          Многие тут спорят TDD в Оракле или не TDD )) Народ, могу успокоить в версии Oracle многие вещи имеют «иное» понимание — от их реализации STL (особенно под UltraSparc лол) до их понимания паттернов проектирования в те года (особенно запомнилась с тех времен реализация PImpl).
                                                                                          Мое мнение Oracle существует только потому, что Ларри подмазал везде и у ЦРУ и IBM, и Apple, и Sun (когда он еще существовал) он с кем надо давно договорился — просто посмотрите его биографию и станет понятно — почему этот монстр до сих продается (только не надо мне про масштабируемость решений от Оракл) И да, легко верю автору, что хуже кода базы Оракл нет ничего в мире))
                                                                                            0
                                                                                            Сначала вам продадут СУБД. Потом, когда она станет слишком медленной, вам продадут Exadata за много денег что-бы ускориться. Потом ещё дальше и глубже. Прямо сейчас нахожусь на развилке — купить кусок железа и отодвинуть проблему года на два, либо перейти на что-то другое.
                                                                                              +1
                                                                                              Инвестируйте в свою команду и открытые решения.

                                                                                              Т.е. когда готовые решения из opensource вас чем то не устроят, вы платите своей команде, чтобы они улучшили ее. В итоге у вас будет на руках команда (которая стала лучше потому что получила опыт и деньги за него) а сообщество получит улучшенное решение. Пока этот процесс не прекращается, вы будете объективно в плюсе.

                                                                                              Недостатки метода — вы можете растерять команду из-за внутренних организационных проблем или длительного отсутствия денег. Но если сравнивать с готовыми железными решениями — машина отработает свой срок и все, деньги на нее гарантированно уйдут в песок.
                                                                                              Так же есть риск напороться на проблему, сложность решения которой сравнительно выше абстрактного готового решения по железу.
                                                                                                0
                                                                                                В этом конкретном случае я никак не распоряжаюсь командой, только инфраструктурой, а в результате безрезультатности попыток достучаться я скорее всего сменю работодателя.
                                                                                                  0
                                                                                                  Вот это и есть основная проблема и причина, почему ПЛОХИЕ готовые решения превалируют над правильными открытыми.

                                                                                                  Достучаться до принимающих решения очень сложно, им проще и понятнее дорогое и неуклюжее решение с прогнозируемым поведением, чем правильное но не такое простое.
                                                                                            +4
                                                                                            (в защиту старины TDD)

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

                                                                                            Ежели под «ТDD» тут понимается написание функциональных тестов перед написанием кода, то значит есть хорошая документация. Это должна быть хорошая отправная точка для декостылизации.

                                                                                            Ежели под «TDD» здесь понимается написание больших интеграционных и функциональных тестов после кодинга, то получается… что написание интеграционных и функциональных тестов (и только) это яд для больших проектов. Никогда не думал о таком.

                                                                                            Ежели суть TDD я понимаю не правильно. То я точно узнаю об этом от комментаторов -)
                                                                                              0

                                                                                              Цикл классического TDD состоит из 3 шагов:


                                                                                              • красный (новый тест на функциональность, которой ещё нет)
                                                                                              • зелёный (реализовали функциональность любым способом, даже самым костыльным)
                                                                                              • рефакторинг (имея зелёные тесты, немного причесали код)

                                                                                              Если рефакторинг не проводится, то не стоит называть имеющийся процесс словом TDD. Это что-то другое.

                                                                                              0
                                                                                              В оригинале речь всё же не об одном загадочном макросе, а о многих. А то вообще кошмар был бы.
                                                                                                +2
                                                                                                Интересно какое спагетти в 1С?
                                                                                                  0
                                                                                                  Не хочу даже думать. Чего стоит один запрет на название не то службы, не то БД, начинающееся с цифры.Слабо представляю, как такое могло случиться.
                                                                                                    0
                                                                                                    При том, что их продукт начинается с цифры, что подталкивает так же называть сервисы и базы, работающие с ним.
                                                                                                    +1
                                                                                                    Переписывают на С++14, планируют внедрять С++17 habr.com/company/1c/blog/429678
                                                                                                    –1
                                                                                                    Меня удивляют люди, которые брызжут слюной и кричат что Oracle скоро отдаст концы.
                                                                                                    Предположим, что вы супер крутой разработчик с зарплатой 5000 долларов чистыми.
                                                                                                    И вот с этим Вашим гигантским опытом разработки, Вы правда думаете, что знаете лучше чем Ларри Эллисон/топ менеджеры Oracle/управленцы любой многомиллиардной корпорации? Правда лучше знаете?
                                                                                                    Вот когда у Вас будет своя корпорация стоимостью несколько миллиардов долларов, построенная с нуля, вот тогда к Вам может и будут прислушиваться, а может и нет.
                                                                                                      +2
                                                                                                      Когда-то тоже были топ управленцы у многомиллиардных компаний — DEC, Compaq, SUN, Nortel,
                                                                                                      слившиеся Alcatel и Lucent и затем поглощённые Nokia и т.д.
                                                                                                        +1
                                                                                                        Всё верно. Вот только многие из перечисленный Вами компаний канули в Лету, а Oracle до сих пор жив. Значит топ менеджмент Oracle знает и умеет чуть больше.
                                                                                                          +1
                                                                                                          Не многие, а собственно все перечисленные канули.
                                                                                                          У Оракл ещё всё впереди. Из современных айтишных компаний с реально долгой историей разве что IBM вспоминается.
                                                                                                            0
                                                                                                            Вот именно. Взять тот же IBM. IBM в начале 2000-ых вроде как начал медленно умирать. И вот сейчас пошёл активный рост. Квантовые компьютеры, ИИ.
                                                                                                            Я не утверждаю, что Oracle живее всех живых и самая технологичная компания в мире. Я лишь говорю, что Oracle'у до смерти как пешком до луны. Всё таки развалить многомиллиардную корпорацию не так просто.
                                                                                                              +1
                                                                                                              Кроме IBM, Oracle можно еще SAP вспомнить
                                                                                                                0
                                                                                                                IBM, если не придираться, то второй век живёт.
                                                                                                                А Оракл и САП нет и 50 лет.
                                                                                                              0
                                                                                                              ошибка выжившего ведь
                                                                                                            +2
                                                                                                            –1
                                                                                                            Давайте на минуточку представим, что код БД настолько ужасен как написано.
                                                                                                            Как тогда объяснить, что на протяжении 10 лет, как я работаю с этой БД
                                                                                                            1) Oracle развивается быстрее всех конкурентов, И даже нет надежды что кто то сумеет обогнать ее по функционалу и скорости в своем классе БД?
                                                                                                            2) Oracle одна из наиболее стабильных БД?
                                                                                                            Ну допустим еще можно объяснить стабильность тестами.
                                                                                                            Но будь кодовая база ужасна вы никогда не сможете ее развивать быстрее конкурентов. Ну или в конкурентов еще хуже :)
                                                                                                            Да понятно, что код не конфетка. Ведь Oracle поддерживает одновременно много платформ и ОС. И все это высоконагруженный код. Где скорость должна бить бескомпромиссная. Понятно, что без грязных хаков никак не обойтись.
                                                                                                            Но и стоило вам изменить лишь одну из этих строк, как ломались тысячи написанных ранее тестов
                                                                                                            это мягко говоря преувеличение. Наверное, есть <1% кода, который может вызвать такое поведение. Но не все 25 миллионов.
                                                                                                            Мне нравятся люди, которые здесь с лёгкостью критикуют. Но кто из вас архитектор, или хотя б тимлид команды, которая работает с кодовой базой 25 миллионов строк?
                                                                                                            Или работает с кодом, который приносить многомиллиардную прибыль?
                                                                                                            Скажу просто, у нас не тот уровень чтоб критиковать работающий проект такого уровня. И все что ми знаем это со слов людей которые по разным причинам уже не работают в этой компании
                                                                                                              +3
                                                                                                              1) Oracle развивается быстрее всех конкурентов, И даже нет надежды что кто то сумеет обогнать ее по функционалу и скорости в своем классе БД?


                                                                                                              Можете привести примеры?
                                                                                                                –1
                                                                                                                Навскидку из относительно нового, RESULT_CACHE ,Inmemory, multitenant, Разнообразие партиций.
                                                                                                                Мощность PL/SQL. (Никто и близко не наблизился за много лет )
                                                                                                                Возможности администрирования, которим равних нет нигде.

                                                                                                                Чтоб не гуглить что такое RESULT_CACHE ,Inmemory
                                                                                                                habr.com/post/422669/#comment_19094311
                                                                                                                Относительно скорости в стате яндекса сказано что после миграции на postgree серверов стало больше.
                                                                                                                Если не согласны — Приведите обратний пример. Кто развивает БД быстее? Я не вижу никого на ринке. даже IBM забросил идею создать для DB2 PL/SQL 100% совместимый.
                                                                                                                  +6
                                                                                                                  Относительно скорости в стате яндекса сказано что после меграции на postgree серверов стало больше.

                                                                                                                  Ещё бы! На те деньги, в которые обходится лицензия Oracle на один сервер можно развернуть парк серверов на Postgresql и для надёжности его продублировать )))

                                                                                                                    0

                                                                                                                    Вы бы ещё с терадатой сравнили :)
                                                                                                                    Яндексу просто ненужно, но есть те кому нужно то ято умеет оракл.

                                                                                                                    0
                                                                                                                    А можно подробнее про возможности администрирования?
                                                                                                                    Например, меня очень сильно интересует, а можно в 2 клика мышкой (окей, в 2 команды в sqlplus) сделать shrink database? Или как сделать бэкап, который не таскает туда-сюда tablespace с пустыми местами? А то меня тут просят иногда помогать нашему Oracle DBA, а я после MSSQL чувствую себя неуютно.
                                                                                                                      0
                                                                                                                      Вы ставите неправильные вопросы
                                                                                                                      Для беккапов есть RMAN. И ничего лишнего.
                                                                                                                      Для уменьшения датафайлов.
                                                                                                                      mmokaev.blogspot.com/2015/11/plsql-oracle-shrink-tablespace.html
                                                                                                                      Просто в oracle можно делать в онлайне то что в других без остановки никак.
                                                                                                                      Например восстановление битого блока в онлайн или перенос данных на другой диск в онлайн.
                                                                                                                      Работа с оптимизацией запросов и тд.
                                                                                                                        0
                                                                                                                        У нас ораклоид вот так на лету от нечего делать во время важной презентации решил что-то «оптимизировать». В итоге у приложения что-то залочилось, система встала колом — ох и попало ему тогда.
                                                                                                                  +1

                                                                                                                  Oracle, может, и развивается быстрее всех, но вот тут: DB-Engines, например, нарисована несколько менее оптимистичная картинка.

                                                                                                                    0

                                                                                                                    Так это график популярности, а не фичастости.

                                                                                                                      +2
                                                                                                                      Я понимаю. Если популярность Оракла слегка снижается, а Постгресса — неслегка растёт, по мне это говорит, что «фичастость» Оракла не сильно ему помогает.
                                                                                                                        0

                                                                                                                        MySQL по популярности такая же как Oracle. Так что фичи тут вообще не при чём.

                                                                                                                          0
                                                                                                                          Ну тут надо понимать, что такие показатели MySQL/MariaDB, фактически, от того, что они имеют немаленькую долю в вебе. Сильно тяжёлых решений с ним не видел. И мне, честно говоря, не совсем ясно, почему. Чисто моё мнение, но я, скорее всего, доверил бы той же марии серьёзный проект. Не вижу причин, почему этого я бы не сделал.
                                                                                                                          Разная ЦА, если перефразировать кратко.
                                                                                                                            0
                                                                                                                            Не вижу причин, почему этого я бы не сделал.

                                                                                                                            TLDR: проблема не в технической области, а в организационной.


                                                                                                                            Зачастую есть следующая логика:


                                                                                                                            1. В жирной компании используют Oracle как базу данных в 80% случаях
                                                                                                                            2. Вас как тимлида (т.е. вы кодите в лучшем случае как 1/10 от стандартного разработчика) спрашивают — разработайте архитектуру на бумажке и покажите нам.
                                                                                                                            3. Вы выписываете кучу вещей, микросервисы и т.д. И начинаете выбирать базу, однако:
                                                                                                                              3.1. Если вы выберете что-то нестандартное, то все ошибки будут лично вашими проблемами (ну т.к. ваша инициатива — вы и виноваты)
                                                                                                                              3.2. Достижения могут не монетизироваться, т.е. вряд ли база данных вам прям радикально поможет что-то сделать лучше.
                                                                                                                              3.3. Ряд людей из менеджмента (такие бывшие разработчики, которые вам четко объяснят, какими они были четкими программистами, правда вы нигде не найдете их крутых приложений, да и код свой они не покажут) будут предлагать не выпендриваться, а использовать "проверенные решения"
                                                                                                                            4. И дальше, если вы таки решите внедрить базу, то:
                                                                                                                              4.1. Вы таки внедрите MariaDB. И любая ошибка ударит по вам. Вы не отмажитесь фразой "дык все используют, я полагался на опыт коллег"
                                                                                                                              4.2. В других командах тимлиды не забудут высказаться, что есть тут один смузихлеб, который не любит Oracle. Ну ибо зачем выпендриваться?
                                                                                                                            5. Если вам повезет, то в вашей компании будут использовать Oracle в 79,9% случаев (а было 80%)
                                                                                                                            6. Если вам не повезет (ну просто проект не пошел в гору), то тимлид из другой команды, при выборе базы, будет получать контраргументы в стиле "ну там какой-то khanid внедрял MariaDB, но проект не взлетел".

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

                                                                                                                              +1
                                                                                                                              Никого не хочу обидеть, но все-таки рассматривать в одном проекте выбор между oracle и mysql?
                                                                                                                              У них области применения практически не пересекаются.
                                                                                                                              Оракл версионник и расчитан на олтп нагрузку с большой конкурентностю за ресурсы и “длинными транзакциями”
                                                                                                                              Mysql блокировщик. И с этим там совсем плохо.
                                                                                                                              Я не говорю что невозможно решать ети проблемы в Mysql, но крови попет, и рано или поздно вам придется усложнять и усложнять логику для разруливания проблем с блокировками. Я лично использовал Mysql c достаточно большими таблицами и огромным объёмом загружаемой информации, но нагрузка DW.
                                                                                                                              У всех больших организациях используются 3-7 разных баз данных. И поэтому выбор осуществляется не по принципу возьмём самую дорогую, а какая больше подходит для задачи.
                                                                                                                                0
                                                                                                                                с трудом вериться, что вы использовали mysql. ведь используемые по дефолту последние десятилетия innodb таблички такие же версионные как и в оракле. при чем у mysql UNDO лог имеется на оракловый манер, а блокировщиком mysql никогда в своей истории не был. были myisam таблички, так там и транзакций не было.
                                                                                                                          0
                                                                                                                          Дык это, наверное, в довольно разных сегментах рынка все же.
                                                                                                                            0

                                                                                                                            Представьте что Oracle Enterprise edotion стал бесплатен, совсем, что произойдёт?
                                                                                                                            Ну пусть не ee а standard без ограничений, как думаете?

                                                                                                                          0
                                                                                                                          посмотрел картинку, там оракл бессменный лидер, постгрес играет во втором дивизионе. если тренд продолжится, лет через 15 посгрес сможет бросить вызов аутсайдеру высшего дивизиона…
                                                                                                                          +1
                                                                                                                          > у нас не тот уровень чтоб критиковать работающий проект такого уровня
                                                                                                                          Основная притензия в том, что архитектура совсем не модульная и всё держится на тысячах bool flag. Возможно, это был единственный способ писать код в 70х. А Oracle пишут с начала 70х. Что проект ппц какой монолитный.
                                                                                                                          Работаю с кодовой базой в 15 000 000 строк. Есть код, который не трогается уже лет 20. А есть бизнес логика и уровни пользователей, которые переписываются постоянно. Всё покрыто тестами.

                                                                                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                                        Самое читаемое