Будни программиста в Oracle: 25 млн строк кода, тысячи «падающих» тестов, 6-12 месяцев на разработку одной небольшой фичи

Почему не стоит работать в Oracle?

Когда очковтиратели вбрасывают заголовки в духе «Будущее за Big Data» или «Нужны Oracle-девелоперы», то они ставят ставку на то, что народ на волне хайпа купится на красивую обертку и мистическое «Оракл», да запишется на курсы или побежит искать работу. По факту же такая сложняцая система как Oracle не может быть простой по определению. Об этом и поведал бывший разработчик Oracle версии 12.2

Несколько фактов об Oracle:
— Эта СУБД состоит из 25 миллионов строк кода на С.

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

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

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

— Единственная причина, почему Oracle еще жив и до сих пор работает — это буквально миллионы написанных тестов!

Как выглядит жизнь рядового разработчика в Oracle:
— Начать работать над новым дефектом.

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

— Добавить еще один флаг, чтобы он покрывал этот новый особый сценарий. Добавить еще несколько строк кода, которые бы проверяли, что этот флаг работает, не создавая новых дефектов.

— Залить изменения на тестовый кластер, состоящий из 100-200 серверов, и в течение нескольких часов распределенно выполнять миллионы тестов.

— Пойти домой. На следующий день работать над чем-нибудь другим, ведь прогон тестов требует 20-30 часов для завершения.

— Снова пойти домой. На следующий день проверить наконец результаты тестов. В хороший день будет порядка 100 «упавших» тестов. В плохой день их может быть около тысячи. Тогда придется случайным образом выбрать несколько тестов и попытаться понять, какие же ваши предположения оказались ложными. Может, следовало взять во внимание ещё 10 флагов, дабы полностью понять природу того дефекта?

— Добавить еще несколько флагов в попытке пофиксить дефект. Залить изменения на тестовый кластер и снова ждать 20-30 часов.

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

— В один прекрасный день у вас будет 0 «падающих» тестов. Аллилуйя!

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

— Залить все изменения (в том числе новые тесты) для финального тестирования на кластере. Затем отдать изменения на ревью, который займет от двух недель до двух месяцев. Теперь можно взяться и за новый дефект!

— Через 2-8 недель, когда ревью закончится, ваш код наконец зальют в главную ветку.

Всё вышеописанное — это реальный жизненный опыт программера, который чинит дефект в Oracle. Теперь представьте какой его ждёт ужас, если ему дадут задание написать новую фичу! Ведь разработать небольшую фичу занимает 6-12 месяцев (а иногда и несколько лет!).

Сам факт того, что Oracle в принципе работает — нельзя назвать ничем иным, кроме как чудом!

Я больше не работаю в Оракле. И никогда больше не буду в нём работать!

 
Очевидно, что о таком кошмаре никто не скажет соискателю. Напротив, будут заливать в уши слащавые речи, мол «Компания с мировым именем, ко-ко-ко, работать у нас — большая часть». А по факту — это днище. То же самое можно сказать о многих других компаниях, где разработка софта длится не одно десятилетие. Взять те же банки: Raiffeisen или ПриватБанк — это может и популярные бренды. Но то, какой угар и мозгоплавильня там творятся — словами не описать. Чего стоят одни только SQL-запросы размером в A4! Базы данных — это, пожалуй, одна из самых тёмных сторон работы в IT. Если писать скриптики на JavaScript или фичи на Java — это ещё куда ни шло, то заниматься занудными базами данных — расписаться в том, что ты сноб и ботан, который способен впрягаться лишь на самую скучную и неблагодарную работу в мире. Об этом ли мы мечтали в детстве?

Источник: Hacker News

  • Yuriy Shakhnevich

    на хабрі писали тиждень тому

  • Danil Tsyban

    Что-то я не могу понять. Разработка больших систем всегда сопровождается большим кол-вом зависимостей и большим кол-вом костылей на проекте и бывает такое, что действительно «исправь там, сломается здесь». Это увы проблема архитектуры и проблема раширяемости. НО! Это хорошо, когда фирма знает и понимает об данной проблеме, и как бы не мешает гребцу скорыми дедлайнами и непонятными совещаниями. Автор описал этап разработкиотладки больших систем, но он не жаловался на зп, менеджеров и прочую лабуду. Вывод, автору хочется делать простенькие сайтики на php для интернет магазинов и клепать все по шаблону.

  • Oleg

    Когда фиксить уже становиться невозможно, то делаем новую версию Оракула!

    • Alex

      На Ангуляре и HTML5!

  • >Если писать скриптики на JavaScript или фичи на Java — это ещё куда ни
    шло, то заниматься занудными базами данных — расписаться в том, что ты
    сноб и ботан, который способен впрягаться лишь на самую скучную и
    неблагодарную работу в мире. Об этом ли мы мечтали в детстве?

    Ахаха, то есть мяу.

  • Jim Beam

    «Чего стоят одни только SQL-запросы размером в A4»

    меня как-то не впечатлило))))

    специально кинул в word одну из процедур отчёта, который я тестил,

    выставил шрифт Calibri 5, междустрочный интервал одинарный, без всяких отступов..

    получилось 87 страниц А4..

    • Alex

      87 страниц?! Спасибо, я в ваши банки (или где там у вас такой треш) ни ногой 🙂

    • Viktor Kovalev

      Плз имя конторы

      • Jim Beam

        SoftServe BS

    • Рукописная процедура или все-таки сгенерированная?

      • Jim Beam

        все процедуры рукописные, как правило 500-4000 строк на процедуру

  • HetmanNet

    Так і не зрозумів у чому автор побачив проблему.. хоч хтось зрозумів?

    • Vitaliy Dragun

      в тому, що копатися в г*мні мамонта насправді не так цікаво як комусь здається

      • HetmanNet

        Якщо пішов у археологи то нічого скаржитися що у бруді по саму шию.. 😉