Не работайте в Oracle

например с OCI (oracle call interface) лет 10-15 назад подтверждаю было стремно смотреть на их изменения в api

Где-то здесь на ЛОРе эта ссылка уже мелькала https://habr.com/post/429946/

Приносили уже.

Хороший аргумент в пользу test-driven development :)

мне лет восемь назад приходилось работать с ораклом. и таки кроме кривого интерфейса у них в библиотеке ещё и память утекала и были разнообразные баги.

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

ну да я помню как пара dba бегали постоянно с криками shared pool по поводу известных багов в oracle которые те закрывали месяцами хоть и за бабло

видя этот мега api легко получить представление о внутреннем качестве этого продукта

Жесть. почему бы ЭТО не переписать с нуля?

Постгес наше фсё

А в чем говнокод-то? Коду 40 лет почти. Скорее проблема в инфраструктуре, которая не позволяет параллелить задачи сборки и тестирования. 200 серверов для сборки и тестирования как-то маловато для такой большой системы.

Обычный процесс в крупном проекте. Я бы добавил, что 0 упавших тестов - это недостижимая утопия, потому что эти 77 тестов падают всегда, те 36 - на этой версии, а вон те 13 - это плавающие падения, которые никто не может воспроизвести...

Не буду. Спасибо за предупреждение.

А с каким говнокодом приходилось работать вам?

В любой большой конторе код такого качества.

Линукс тоже таким был лет 15 назад, но его вытянули. Это потому что горящих дедлайнов и эффективных манагеров нет.

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

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

А в чем говнокод-то?

А ты правда не понял? Вот, цитирую:

20 different flags that interact in mysterious ways

Rinse and repeat for another two weeks until you get the mysterious incantation of the combination of flags right.

А вот это - закон размножения говнокода:

Add one more flag to handle the new special scenario

А что заставило тебя предположить это:

проблема в инфраструктуре, которая не позволяет параллелить задачи сборки и тестирования.

?

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

Поэтому придуманы умные слова вроде «рефакторинг» и «технический долг».

Поэтому придуманы умные слова вроде «рефакторинг»

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

и чем именно заняты сотня-тысяча лбов

В хедпосте написано, чем они заняты. Но ты не читатель, я понимаю.

Не работайте в тыртырпрайзе

На самом деле так.

Это не совсем правильная постановка вопроса, имхо.

Да, реальность такова.

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

Посмотрим, как У ВАС получится крутиться через сорок лет.

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

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

Участвовал я лет двадцать назад в одном проекте: отвечал на архитектуру и разработку нового набора фич в одной библиотеке. Багфиксами всей либы занималась команда индусов, вот там я насмотрелся всякого…

Типичный модус операнди:

• Убедиться, что код на определенном наборе данных выдает неверный результат.
• Добавить ветвление с проверкой на эти условия.
• Написать решение этого конкретного частного случая.
• Убедиться, что проблема «решена».
• Хвалить себя из каждого утюга.

Когда моей команде просто пришлось для добавления фич почистить авгиевы конюшни и отрефакторить часть кода, либа полегчала вдвое. Патч, выносящий из затронутой нами части либы 80% кода, был на ревью три месяца, проходя все тесты с первого дня. Нужно рассказывать, кого материли во всех филиалах по всему миру всё это время, и куда потом заткнули языки, когда код приняли в основное дерево, а поток багрепортов значительно сократился?

Ну только Solaris стремительно умирает, а Oracle Database - это дефолтная база данных в ынтерпрайзах. А дефолтной она стала благодаря агрессивному маркетингу и релизам, полным фичей (у Джоеля был когда-то блогпост про это, но потом этот сайт сломался). Релизы, полные фичей - это значит, кто-то там наяривает кнутом девелоперов, чтобы к часу Ч запилили X хайповых фичей, во что бы то ни стало. Есть ли пруфы, что с таким подходом за много лет проект может не стать свалкой мусора?

The tests can take 20 hours to 30 hours to complete.

По нашим меркам, это очень быстро.

У нас тестирование зачастую растягивается на недели и месяцы.

А с каким говнокодом приходилось работать вам?

С самым разнообразным. Он повсюду. Такова жизнь.

Open Source - это просто образец качества.

Ну только Solaris стремительно умирает

Ну только никаких технических причин для этого нет.

агрессивному маркетингу

Я думал, мы не об этом. Хотя... наверное, ты уже всегда. будешь об этом

это ты типа объяснил, почему покупают оракель? а откатов не существует, это только в грязной рашке так?

У нас тестирование зачастую растягивается на недели и месяцы.

Автоматически прогоняемые тесты идут месяцами? Имитаторы VHDL-моделей процессоров?

А вот это - закон размножения говнокода:

Я написал знакомым, которые работают в Orcale. Говорят, что чувак сильно приукрашивает.

А что заставило тебя предположить это:

Флаги - не флаги. Тесты должно работать 30-60 минут максимум. А дальше сколько бы ни было флагов их всегда будет легко поправить.

Я написал знакомым, которые работают в Orcale. Говорят, что чувак сильно приукрашивает.

Приукрашивает? Ничего себе. Т.е. на самом деле всё обстоит еще хуже?

Флаги - не флаги. Тесты должно работать 30-60 минут максимум.

Я, конечно, не настоящий QA, но даже я понимаю некоторые простые вещи: что тесты должны отлавливать ошибки (а не работать быстро), что объем тестов зависит от объема и сложности тестируемого продукта, что тесты имеют тенденцию накапливаться со временем (представь, сколько регрессионных тестов накопилось за 35 лет). Так что нет, тесты никому не должны «работать за 60 минут максимум».

сколько бы ни было флагов их всегда будет легко поправить.

Ага, ага. Грубо говоря, по тесту на каждую комбинацию флагов (на каждой платформе) - какая ерунда. Ну и, если всё-таки прочитать хедпост, никто не «правит флаги» - просто их количество увеличивают.

Автоматические могут идти неделями, потому что вовлечен не только софт, но и железо. В прошлом проекте стандартный QA cycle занимал две недели.

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

Автоматические могут идти неделями, потому что вовлечен не только софт, но и железо.

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

не все автоматизируемо в принципе. Иногда ждешь инфу с полей месяцами.

Понятно. Но в хедпосте речь об автоматизированных тестах, если я правильно понял.

Чтобы автоматизированные тесты шли аж неделями - это железо должно быть феноменально медленным (или требовать ручной раобты)

Железо не такое уж и медленное, но переконфигурация всего и вся требует времени. Нормальный пользователь это делает редко, при тестах же все время меняется конфигурация.

Кроме этого, требуется убедиться в надежной работе длительное время в каждом режиме.

Но в хедпосте речь об автоматизированных тестах, если я правильно понял.

Думаю, не только о них. Потому что разработчику вообще не так важно, как они там тестируют. Главное, чтобы быстро и корректно. А в нашем деле (встраиваемые и сетевые технологии) быстро и корректно почти не бывает :)

Железо не такое уж и медленное, но переконфигурация всего и вся требует времени.

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

Но в хедпосте речь об автоматизированных тестах, если я правильно понял.

Думаю, не только о них.

Ну, судя по «test farm» и миллионам тестов, это именно автоматические тесты.

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

Простой отвлеченный пример: сколько времени занимает загрузка компа? Нормального человека это мало волнует. А если тебе надо его перезагрузить 1000 раз, то это ощутимо. Кроме того, надо убедиться, что комп не зависнет хотя бы час после загрузки.

Ну, судя по «test farm» и миллионам тестов, это именно автоматические тесты.

Да. Но упор делается на то, что тесты идут очень долго по ощущениям автора. Я же о том, что всё относительно, и что долго для него, то совсем не долго для нас :)

Приукрашивает? Ничего себе. Т.е. на самом деле всё обстоит еще хуже?

Я тебе передаю слова человека изнутри. Склонен ему верить.

Так что нет, тесты никому не должны «работать за 60 минут максимум».

И будешь потом двое суток ждать коммита. С «зеленым транком» задолбаешься ждать прохождения тестов.

Ну и, если всё-таки прочитать хедпост, никто не «правит флаги» - просто их количество увеличивают.

Опять же, люди говорят что далеко все не так.

Ты так говоришь, будто у соляриса мало фич. Если про другие коммерческие юниксы ничего не слышно, то в солярис завозили smf, dtrace, containers/zones, zfs и т.п. Причем зачастую до хайпа, который возникал когда подобное появлялось в других системах. Даже всякая хрень типа https://www.serverwatch.com/img/then.jpg

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

Простой отвлеченный пример: сколько времени занимает загрузка компа?

30 сек.

А если тебе надо его перезагрузить 1000 раз, то это ощутимо.

30000сек - примерно 8 часов.

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

Вот теперь более-менее понятно.

Приукрашивает? Ничего себе. Т.е. на самом деле всё обстоит еще хуже?

Я тебе передаю слова человека изнутри. Склонен ему верить

Тогда интересно, какой там ад на самом деле.

Так что нет, тесты никому не должны «работать за 60 минут максимум».

И будешь потом двое суток ждать коммита.

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

С «зеленым транком» задолбаешься ждать прохождения тестов.

А при наличии монолитного продукта и политики «зеленого транка» другого выхода просто нет.

Ну и, если всё-таки прочитать хедпост, никто не «правит флаги» - просто их количество увеличивают.

Опять же, люди говорят что далеко все не так.

Люди (по твоим же словам) говорят, что в посте всё приукрашено (не преувеличено, а приукрашено). Или ты таки хотел сказать «преувеличено»?

никаких технических причин для этого нет.

ну они же не опенсорс пилят ради искусства, а выполняют желания бизнеса

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

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

Грубо говоря, по тесту на каждую комбинацию флагов (на каждой платформе) - какая ерунда.

В JDK если честно запустить всю основную матрицу конфигураций, тесты будут проходить наверное, больше месяца. А если честно протестировать вообще всё-всё, то это будет делаться до конца жизни Вселенной, кто-то считал (найду ссылку - скину) =)

В том же HotSpot тесты организованы по tiers. Начиная с обычных smoke-тестов и заканчивая достаточно серьезными тестами. А ведь кроме юнит-тестов есть и перфоманс-тестирование, и стресс-тестирование - это трата времени по определению.

Поэтому есть некое искусство внести ченж так, чтобы понять, какие участки системы оно затронет, и по-нормальному тестировать только их, а на остальные забить «авось обойдётся»

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

никаких технических причин для этого нет.

ну они же не опенсорс пилят ради искусства, а выполняют желания бизнеса

Они пилят опенсорс для бизнеса. Как Linux.

надо понимать, что Оракл - это компания про продажу коробочных решений

Не вижу, как коробка с Оракелом отличается от коробки с Солярисом, и, даже если она отличается, почему это имеет значение.

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

Как в Оракел Ынтерпрайз ДБ.

Выпью за твоё здоровье!

А с каким говнокодом приходилось работать вам?

С говнокодом сходного уровня. Так будет в любом более-менее крупном проекте по следующим причинам:

1. Два джуниора по цене одного сеньора будут намного быстрее клепать фичи (и плодить баги).
2. На качество кода наплевать всем, кто с кодом не работает (да и большинству разрабочиков, скажем чество, тоже плевать). К черту качество, задавим поток багов потоком фичей!
3. Немного смягчаем пункт 2 тестами: unit или integrational — не важно. Заодно это немного смягчит эффект от повышенной волатильности текучки кадров: снижается шанс фатального бага от джуниора-который-пилит-core-фичу-в-первые-недели-работы.

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

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

Тогда интересно, какой там ад на самом деле.

Ты хочешь интерпретировать мои слова, переданные от другого человека для того, чтобы подтвердить полуанонимный пост с HN? Если тебе так выгодней, то да. У них все плохо, скоро все развалится от 1000 флага :)

Они пилят опенсорс для бизнеса. Как Linux.

важно: сейчас скажу собственное мнение, а не мнение работодателя и не позицию Oracle

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

RedHat - это про оказание поддержки для разработанного ими опенсорса. У Оракла бизнес прямо противоположный - вначале они продавали проприетарные продукты, коробки с ними. Потом они перешли на продажу software-as-a-service. Если у этих сервисов/коробок не будет публичного исходника, и их не нужно будет поддерживать - это для них отлично.

почему так решил? Ну, множество всяких интервью с Ларри, который последовательно тонко намекал, что бизнес-модель RedHat - нежизнеспособная. Отзывы друзей, которые там работали и уволились - увоилились в момент покупки Сана Ораклом, уволились в ближайшие годы, уволились совсем недавно...

Попробовал погуглить по словам «larry ellison red hat business model», но там тонна всяких статей, это нужно потратить кучу времени, чтобы притащить тебе пруфы. Вот есть цитата из верха поиска (это 2006 год - год, когда Oracle скопипастили себе Oracle Linux):

I don’t think Oracle and IBM want to create a second Microsoft in Red Hat. But you can’t – because Red Hat doesn’t own anything, they own nothing. They couldn’t [become the next Microsoft], they own nothing. [...]

We make more money selling software-as-a-service than we make just selling software. I’d much rather be in the monthly service charge business, I’ve said this repeatedly. [At present] a huge percentage of our sales are done in the last week of the quarter: all of that goes away, it’s a much better business model.[...]

On the one hand, people say open source and software-as-a-service are really hot – on the other hand, all they look at is our new licence sales. It’s the kind of absurdity that you find in the world at times.

All I care about is that we keep growing our profits every year. We have a five-year plan to grow our profits at 20 per cent a year. Last year we overshot, we grew at 28 per cent. This year we will grow at 20. We’re growing our profits very, very rapidly.

вся эта их риторика выглядит как-то... мерзко

например, Java не укладывается в этот подход, но слить по-быстрому они её не могут, слишком много на неё завязано. Когда можно что-то слить, они это делают - например, в этом году на мороз отправилась Java EE, уволили команду Java Mission Control и отдали поддержку двум индусам, и т.п. Всё остальное, пришедшее от Sun, они тоже посливали. IBM-RedHat им поставила пару палок в колёса в этих чудных начинаниях, и возможно, падающее знамя перехватят они

тот же GraalVM, для начала, делается не в Oracle, а в Oracle Labs - отдельной структуре с историей ещё из Sun. И даже GraalVM - это коробка с проприетарными закрытыми исходниками. Есть Community Edition, но план в том, чтобы продавать Enterprise Edition, на которую даже цен на сайте нет - нужно звонить продажникам и узнавать стоимость.

как это ложится на Solaris? Это ты мне расскажи, я совершенно не в теме. Есть предположение, что закрытая проприетарная коробочная солярка продавалась не так чтобы очень хорошо, а делать вокруг неё второй RedHat не входит в их планы никаким образом.

отдельный вопрос, что делать во всём этом мне. Я сделал ставку не на тех людей и не на то направления развития, и очень раскаиваюсь. Похоже, придётся изучать C# и устраиваться менеджером влажной уборки помещений в MS :(

Ты хочешь интерпретировать мои слова, переданные от другого человека

Естественно, я хочу их интерпретировать. Я думал, ты именно для этого их и написал.

скоро все развалится от 1000 флага :)

Скорее остановится в развитии.

И что теперь делать? Как там дела к качеством кода у pgsql?