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

Для того, чтобы предсказать поведение кода в том или ином случае, приходится разбираться и запоминать, какие значения и последствия могут иметь 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 года; за это время существенно разобраться в тонкостях работы проекта невозможно.
...