Победителем в номинации «лавкрафтовские ужасы» заслуженно стал рассказ бывшего разработчика 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 для сборки — многие из которых были устроены гораздо сложнее, чем код самого ядра. Конечно, стоит быть реалистами — едва ли ситуация обстоит лучше в аналогичных продуктах-лидерах индустрии, разработка которых велась в течение нескольких десятков лет.
Комментарии (149)
fivehouse
15.11.2018 15:51+6Когда мирятся с изначальным непониманием взаимодействия частей кода и флагов, процесс начинает напоминать генетическое программирование с ручной доработкой/добавлением небольших осмысленных кусков. Только в каждом поколении здесь из списка кандидатов выбирается единственный кандидат прошедший некоторый набор тестов — релиз. Результат процесса известен: совершенно невменяемый, парадоксальный, хрупкий, нечеловеческий, но рабочий код живущий собственной жизнью. При чем код в части непонимания разработчиком будет постоянно расти в объеме.
Но самое отвратительное бывает, когда некоторые группы разработчиков намеренно делают очень непрозрачными отдельные куски с целью ограждения своего кода и скрытия логики кода от других групп разработчиков. Вот тут бывает реальная «веселуха». И совсем печально, когда ответственным за это людям плевать на происходящее или даже все и происходит с их молчаливого согласия.springimport
15.11.2018 18:32+1Вроде абстрагироваться неплохо же? Не огораживаться.
Не представляю как можно вести разработку проекта командой 100+ у которого тесно связаны части. Видимо там день начинают не с кофе, а с решения конфликтов.fivehouse
16.11.2018 18:44Абстрагироваться великолепно. Но для этого надо для начала просто иметь документацию на человеческом языке в степени актуальности выше хотябы 30%. Обычно же внутренняя документация пишется и забывается. А код идет вперед. Через 10 лет, а в случае Oracle это уже 20 лет, старая внутренняя документация скорее мешает, чем полезна при попытке ее сопоставить с рабочим кодом. Уже и язык программирования успели поменять, и часть внутренней архитектуры поменяли, а документация остается старой и валяется в виде мусора в каких-то директориях в корп сети с банером «конечно, у нас все документировано»! Потому как ни достаточного FTE ни MD ни чего такого на документацию не выделяется. Внутренне документирование также реально требует затрат квалифицированного и добросовестного труда.
Почему уменьшение связанности кода перестает работать со временем? Потому, что появляются новые требования, которые иногда проходят по частям, которые ранее были не связанными. В результате они становятся связанными. На сотый повтор такой ситуации необходима переработка архитектуры с переписанием кода. Но этого никто не будет делать потому, почти везде ресурсов на горящие проекты уже давно не хватает…develop7
16.11.2018 22:46Но для этого надо для начала просто иметь документацию на человеческом языке в степени актуальности выше хотябы 30%.
gaperton.livejournal.com/32772.html
SUA
15.11.2018 16:45+2Хотели как лучше (С)
По-моему первая статья с (нехвалебными) результатами (долговременного) TDD,
почему-то такие результаты неуспеха хайповой технологии встречаю впервые
— возможно по причине того что остальные представители коллекции не дожили до стадии анализа?
что-то я пессимистичен сегодня…format1981
15.11.2018 17:05+1По моему, нельзя в этом винить только TDD.
Мне довелось поработать на крупном проекте, где не было тестов вообще, а ситуация с легаси очень похожая. Но так как сам проект на много моложе оракла, и это не база данных, а веб-приложение, то удаление и добавление багов происходило на много быстрее.
Главной проблемой считаю — отказ от рефакторинга. Если делать его своевременно, то он обходится дешевле.ianzag
15.11.2018 21:52Рефакторинг — это конечно прекрасно, но с учетом отсутствия тестов провести разумный рефакторинг бывает очень сложно. Точнее провести может быть и легко. Но как проверить, что ничего не сломалось? Ведь тестов нет.
poxvuibr
15.11.2018 17:34+2По-моему первая статья с (нехвалебными) результатами (долговременного) TDD
В статье нет ничего про TDD. Вообще ничего. Просто совсем ничего. TDD предполагает, что тесты будут писаться одновременно с кодом, а не когда-то потом.
SUA
15.11.2018 17:41+1тесты будут писаться одновременно с кодом
нет — тесты будут писаться до кода
что и видим
есть ошибка (зафиксированный баг) — добавляем ее в пул тестирования — добиваемся что тест проходит
если что-то сломали — чиним, в качестве документации «почему» добавляя новые тесты
этап рефакторинга отсутствует ввиду «некогда… совсем некогда… вы хотите половину системы переписать?! — некогда же!»poxvuibr
15.11.2018 17:49+1нет — тесты будут писаться до кода
С одной стороны вы правильно отметили — тесты для куска кода, который будет писаться в следующие пару минут пишутся до этого куска кода.
С другой стороны за время решения задачи разработчик переключается между кодом и тестами много раз и получается что он написал чуть чуть тестов, потом написал чуть чуть кода. Так что в масшабе задачи тесты и код пишутся одновременно.
что и видим
есть ошибка (зафиксированный баг) — добавляем ее в пул тестирования — добиваемся что тест проходитВ статье написано, что разработчик пишет код, потом прогоняет тесты, потом правит код, если тесты не прошли, а потом пишет дополнительные тесты для своего кода. Он не пишет тест заранее.
этап рефакторинга отсутствует ввиду «некогда… совсем некогда… вы хотите половину системы переписать?! — некогда же!»
В Оракле из статьи похоже так и есть ((
a0fs
15.11.2018 22:03Он не пишет тест заранее.
В описанном процессе исправления бага, мне видится странным писать тест на код исправляющий баг до кода. Что именно на этом этапе тестировать? Кроме того, если с разбором флагов такая морока, то кажется, что нет той головы, в которую поместятся ещё и алгоритмы и параметры тестирования к не родившемуся исправлению. Но когда код исправления пройдёт естественный отбор серией тестирований, он тут же обзаводится собственными тестами. Так что, похоже там всё-таки TDD, но с учётом, что код там уже повзрослел, а разработчики Богами ещё не стали…poxvuibr
16.11.2018 00:37В описанном процессе исправления бага, мне видится странным писать тест на код исправляющий баг до кода. Что именно на этом этапе тестировать?
По уму надо написать тест, который предполагает, что код работает нормально. То есть такой тест, который будет воспроизводить баг. Тест проходить, естественно не будет. После этого надо поправить код так, чтобы тест проходил.
Так что, похоже там всё-таки TDD, но с учётом, что код там уже повзрослел, а разработчики Богами ещё не стали…
То что вы описали, с TDD имеет общего только то, что и там и там для кода пишутся тесты.
Kocmohabt314
16.11.2018 11:29Кстати, не подскажите хорошую литературу или другие материалы по написанию тестов, можно даже с нуля, т.к. я в этом самоучка (писал тесты только к одной своей программе) и лучше научиться сразу, чем потом переучиваться.
poxvuibr
16.11.2018 11:59К сожалению книг, посвящённых именно написанию тестов я не читал. Могу посоветовать всё, что написал Роберт Мартин (тот который 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 сразу не получится. Тут как с ООП и другими методологиями — нужна практика.
zloddey
16.11.2018 14:03Майкл Физерс, "Эффективная работа с унаследованным кодом"
Джерард Месарош, "Шаблоны тестирования xUnit"
Кент Бек, "Экстремальное программирование. Разработка через тестирование"
Роберта Мартина уже упомянули выше
selivanov_pavel
15.11.2018 19:44А причём тут TDD? Если пилить только фичи/багфиксы и никогда не заниматься рефакторингом, код превратится в говно и никакая методология не поможет.
Наоборот, статья показывает преимущества достаточно полного покрытия тестами: даже такой ужасный код остаётся работоспособным.Arris
15.11.2018 23:05преимущества достаточно полного покрытия тестами: даже такой ужасный код остаётся работоспособным.
Преимущества? *приподнял бровь*
Вы серьезно?
Сколько еще итераций этого ужасного кода должно пройти, чтобы дальнейшая разработка стала невозможной совершенно?
Чтобы пришлось писать ИскИн, который делает новый код на основе миллионов написанных тестов?selivanov_pavel
15.11.2018 23:20Да, преимущества: код ужасен, но работает и весьма стабильно. Иначе оракл не использовался бы во многих нагруженных и критичных к отказам проектах. Если бы тестов не было или было меньше — он бы не работал совсем или работал с гораздо большим количеством багов. Эта статья — прекрасная реклама для TDD.
Отсутствие рефакторинга — проблема менеджмента, а не TDD. Абсолютно любая методология в долгом по времени проекте приведёт к созданию говнокода, если периодически не выделяется время на рефакторинг.
Если самолёты какой-то марки всё время падают, но лётчики каждый раз спасаются на парашютах — значит это классные парашюты. Давайте будем на всякий случай комплектовать ими и другие самолёты.Stas911
15.11.2018 23:50Вот поддержу про надежность — одно время очень плотно работали с Ораклом на больших проектах и в самой СУБД проблем критичных вообще не припомню. Всякие обвязки и шелуха, внедренная из купленных Ораклом продуктов — другой вопрос, а СУБД мне очень нравилась, тк всегда работала предсказуемо и надежно.
Arris
16.11.2018 09:21Давайте починим самолёты.
selivanov_pavel
16.11.2018 11:39А парашюты выкинем?
Вы только что предложили просто взять и писать само^W код без ошибок :)
balexa
16.11.2018 12:58А что, недостатки? Если бы тестов не было — продукта бы не существовало уже давно.
Важен продукт, а не код, как ни странно. Миллионы пользователей по всему миру вообще не парятся о качестве кода СУБД. Мне правда непонятно, что вы предлагаете в качестве альтернативы. Не писать тесты?
Так как ни странно, даже для идеально структурированного и расширяемого кода тесты обязательны.
YemSalat
17.11.2018 08:28Особенно учитывая что «потыкать код, потом написать под него тесты» — это фактически противоположность TDD подходу.
Alcpp
16.11.2018 23:07Остальные дожили, но на определенном этапе после рефакторинга тесты отключили, чтобы включить потом, но так и не включили.
wild_one
15.11.2018 17:27Я просто оставлю это здесь.
Заголовок спойлера
aquarium
15.11.2018 17:36Думаю будущее в данной области за ИИ. Людям уже просто не под силу контролировать и проверять такое большое количество строк кода. Ситуации, когда исправление одной ошибки, приводит к появлению новых ошибок, заставляют задуматься.
Yaris
15.11.2018 17:55+1Мне кажется, изучив такое количество такого кода, ИИ вскочит и убежит. А если не сможет убежать — прикинется дохлым/мёртвым.
wild_one
15.11.2018 17:58А куда ж он денется. "Ни хрена себе у вас запросы — сказала БД и подвисла..."
Интересен с этой точки зрения анализ кода и доказательное программирование, ведь наверняка там под 50% "мертвого" кода.
Но натравить статический анализатор на 25 млн строк — это, ммм, импосибуру, как мне кажется.
aquarium
15.11.2018 18:02По комментарию сразу видно что его написал человек а не ИИ.
Если считать светофор далеким, далеким предком ИИ, то у вас же не возникает беспокойства что светофор отключится от того что на дорогах столько машин, все нарушают, воздух загазован, температура ниже нуля. Как когда-то светофор уничтожил профессию регулировщика так и ИИ уничтожит профессию программиста. Нам не справиться дальше без него. Точнее справиться то мы сможем, но вперед не продвинемся.geher
15.11.2018 21:34Как когда-то светофор уничтожил профессию регулировщика
Не уничтожил. Просто в большинстве случаев регулировщики сидят в мягких креслах и следят да тем, как работает система управления движением.
А если что не так, все так же посылают человека помахать палочкой.
так и ИИ уничтожит профессию программиста.
Не уничтожит. Просто программист будет заниматься по большей части не написанием и поддержанием кода, а надзором за ИИ. А уж когда ИИ оплошает, будет браться за дело сам.
aquarium
15.11.2018 21:37Первое время действительно ИИ будут поддерживать белковые программисты. Но через какое-то время надобность в них отпадет.
SirEdvin
15.11.2018 22:20У нас тут все еще не отпала надобность в регулировщиках, которые периодически приходят на улицы.
А теперь представьте, насколько сложнее будет этот ИИ в сравнении с системой светофоров.aquarium
15.11.2018 22:22Конечно представил. Точнее попытался. Все пишу лишь для того что б показать что ИИ не убежит и не испугается такого количества кода.
Arris
15.11.2018 23:12Да белковые существа вообще не нужны! Только место на планете занимают, жрут, срут, ресурсы тратят и занимаются бессмысленным потреблением того, что сделали существа небелковые.
Вам не стрёмно оказаться в числе тех белковых существ, надобность в которых отпадёт?aquarium
15.11.2018 23:25Нет, не стремно! Я вам больше скажу, мне это нравится. В ближайшем будущем нас ждут штрафы за управление автомобиля человеком, без специального разрешения, Siri будет сливать карму Алисе за неудачный комментарий на хабре, реформа судебной системы, где вердикт будет выносить ИИ а не человек. И знаете, я очень жду это время.
rPman
16.11.2018 00:56Бойтесь своих желаний!
ИИ это хорошо, но внедрять и управлять качеством решений будет человек со всей своей жестокостью.
Судебная система на базе ИИ будет как страшный сон и смесь фантазий из черного зеркала и текущих экспериментов китайцев с их рейтинговой системой. Вы будете получать штрафы от ИИ за то что он не смог вас распознать как человека в костюме зайчика, а граничные условия в системе управления автомобилями будут убивать людей, может быть реже чем люди, но это будет значительно страшнее для участников, например потому что какой то разработчик выбрал в качестве допустимой меры выбора кого убивать — количество пострадавших.
p.s. и все самое яркое в этом направлении мы можем увидеть еще при своей жизни!aquarium
16.11.2018 09:16Да, согласен, ошибки будут, но лишь на начальном этапе. Это будет болезненный переход. Возможно будут жертвы. Но в целом эффект будет положительным.
Автоматизация определения нарушителей на дорогах, в моем городе, дала положительный эффект. Сейчас камеры на перекрестках регистрируют 3 нарушения: красный свет, превышение скорости, непристегнутый ремень. В целом по городу у меня статистики нет на руках, но т.к. являюсь пешеходом, то оценить ситуацию могу. Порядок стал идеальный. Больше нет желающих наехать на стоп линию или не пропустить пешехода.Yaris
16.11.2018 11:26Не надо путать детекторы с ИИ и ИИ для принятия «единоличного» решения. Детекторы — это хорошо, ИИ в этом плане и дешевле, и точнее, чем человек, и работает без отпуска и обеда. Для принятия решений ИИ ещё надо пройти очень большой путь, а некоторые сомневаются, что это вообще возможно (без полной репликации человеческого сознания на искусственном носителе). Одна из причин — как раз отсутствие единообразного алгоритма принятия решений среди людей: что для одной культуры хорошо, для другой — в лучшем случае так себе.
Ну и ещё такой момент — многие, считающие «пришествие ИИ» благом, думают, что ошибки на начальном этапе персонально их и их родни не коснутся. Как говорится, «а меня-то за что?» Со всеми вытекающими последствиями.
qw1
17.11.2018 11:18выбора кого убивать — количество пострадавших
В мире победившего киберпанка такой произвол не может произойти. Там должно быть строго по правилам — кто больше внёс денег компании-производителю ИИ, того спасать в первую очередь.
Arris
16.11.2018 09:03Siri будет сливать карму Алисе за неудачный комментарий на хабре
Это, конечно (ирония), великолепное применение технологий ИИ в быту :)
К делу:
проблема в том, что если ИИ решит, что вы не нужны (а это рано или поздно случится, когда вы постареете) — вас лишат пенсии. И не говорите мне, что «вы сами себе на старость заработаете». Вас лишат всего, что вы заработаете — потому что вы неэффективны, а значит бесполезны.
Вполне возможно, что вас просто усыпят. А тело переработают на синтетическое мыло.aquarium
16.11.2018 09:23Это, конечно (ирония), великолепное применение технологий ИИ в быту :)
Им надо будет где-то учиться. Форумы отличное место для этого.
что если ИИ решит
А если не решит? Откуда у Вас такие мрачные картины в голове. Пока все говорит о том что ИИ будет добрым и справедливым.Arris
16.11.2018 09:26Пока все говорит о том что ИИ будет добрым и справедливым.
Им надо будет где-то учиться. Форумы отличное место для этого.
Вы сами себе и ответили :)
После самообучения на форумах ИскИны точно не будут ни добрыми и ни справедливыми.
aquarium
16.11.2018 09:37Ну вот опять вы к плохому клоните. Хабр очень даже адекватный форум.
Yaris
16.11.2018 11:20А кто сказал, что учить его будут на Хабре? Microsoft почему-то решил попробовать силы своего AI в Твиттере, а не на HackerNews, например. Возможно, потому что на HackerNews (как и на Хабре) общается только часть (и не бОльшая) общества, в котором должен был бы действовать ИИ.
Alcpp
16.11.2018 23:13ИИ создаст несколько версий кодовой базы. И та, которая пройдет все тесты и будет выдана в качестве ответа.
Но, боюсь, тот код будет еще хуже.
olekl
15.11.2018 19:00+1По-моему, на ногах они держатся исключительно потому, что принимающие решение о покупке ничего не знают про код, а те, кого этот ад в коде касается непосредтсвенно — никакого влияния на решение о покупке не оказывают… По-моему, про это еще Джоэль Спольски писал…
dag_tech
15.11.2018 19:35Одна оценка есть — 25 млн. строк кода. Еще бы получить оценку — сколько человеко-лет — только программистов, еще программистов + архитекторов-проектировщиков.
googlodrocher
15.11.2018 19:43Может жизнь всегда так зарождается?
appletesta
15.11.2018 22:51То есть скоро не проект будет проходить тесты, а работники. На входе в офис будут допускаться Базой к себе или нет
googlodrocher
15.11.2018 19:50Перефразируя известную шутку про физиков- У программистов есть традиция: каждые 13 миллиардов лет они собираются вместе и пишут код Oracle Database.
saipr
15.11.2018 20:07+1Возникает вопрос: каким же образом при всем этом Oracle Database до сих пор удается держаться на ногах? Секрет — в миллионах тестов.
А что можем мы в России им противопоставить, вернее сопоставить? Разве что планы работы комиссий по импортозамещению!
geher
15.11.2018 21:55А зачем им что-то сопоставлять или противопоставлять?
Догоним и перегоним? Как мне кажется, лозунг неверен в принципе.
Хотите написать свою СУБД — пишите. Не хотите — используйте существующую. Или вносите вклад в открытые проекты (тот же Postgres).
А если так ныть, то вы нигде ничего им не сможете "противопоставить" или "сопоставить".saipr
16.11.2018 21:02+1Вы не поняли. Кто и где ноет? И СУБД свою только из-за того что она своя нисать не стоит. Но если она будет поддерживать модель Abrial то и не грех написать. Речь о другом — чем мы можем похвастаться в хорошем смысле этого слова (хотите гордиться).
Догоним и перегоним? Как мне кажется, лозунг неверен в принципе.
Странно. В Советском Союзе так не считали, китайцы так не считают. И если бы мы не догоняли, а потом и не перегнали, то и человечество 12 апреля 1961 года не было бы в космосе. А зачем олимпийские игры проводятся, а зачем американцы на Луну летали!!
geher
16.11.2018 22:44+2Речь о другом — чем мы можем похвастаться в хорошем смысле этого слова (хотите гордиться).
Вы хотите похвастаться результатами работы, к которой вы не имеете никакого отношения кроме одинакового гражданства с авторами?
Ну пока в активе только весьма активное участие в открытых международных проектах вроде Postgres.
Странно. В Советском Союзе так не считали, китайцы так не считают. И если бы мы не догоняли, а потом и не перегнали, то и человечество 12 апреля 1961 года не было бы в космосе. А зачем олимпийские игры проводятся, а зачем американцы на Луну летали!!
Американцы на Луну полетали, забили и забыли. Толку с того.
Надо не догонять или перегонять. Как и всякая формальная метрика человеческой деятельности это чаще приводит к глупостям и злоупотреблениям, чем к полезному результату (правда помнят обычно только эпические победы и столь же эпические провалы). Если посмотреть историю Китая, СССР да и тех же США, там полно всякого бреда, связанного с "догнать и перегнать" (причем не только международного).
Надо просто делать свое дело, не делая целью именно "догнать и перегнать", а стараясь сделать результат своей работы настолько хорошим, насколько это возможно.
Но, к сожалению, современное общество заточено только на гонку. И вся мотивация у людей только в этой гонке, на которую бездарно гробятся ресурсы. Результат, конечно, есть. Как же без результата. Только путь его достижения оптимальностью даже не пахнет.
Зачем проводятся олимпиады? Цель давно уже осталась только одна — заработать много бабла. Спортсмены там только для антуража.saipr
16.11.2018 22:49Вы хотите похвастаться результатами работы, к которой вы не имеете никакого отношения кроме одинакового гражданства с авторами?
Это вы о ком? Если о себе, то вам виднее. Если вы о ком-то другом, то назовите, если уверены в своих словах.
Цель давно уже осталась только одна — заработать много бабла.
Хорошо вы мнения о человечестве. Хотя сегодня вы правы.
qw1
17.11.2018 11:24А вы о ком?
А что можем мы в России им противопоставить, вернее сопоставить?
чем мы можем похвастаться в хорошем смысле этого слова
plm
15.11.2018 21:30Вроде Вернор Виндж много рассуждал на тему археологии в использовании очень старых (многие века) программ, использования их всеми забытых возможностей и просто закладок т.п.
Maur
15.11.2018 23:18+1Oracle в 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 (когда он еще существовал) он с кем надо давно договорился — просто посмотрите его биографию и станет понятно — почему этот монстр до сих продается (только не надо мне про масштабируемость решений от Оракл) И да, легко верю автору, что хуже кода базы Оракл нет ничего в мире))Roto
16.11.2018 00:53Сначала вам продадут СУБД. Потом, когда она станет слишком медленной, вам продадут Exadata за много денег что-бы ускориться. Потом ещё дальше и глубже. Прямо сейчас нахожусь на развилке — купить кусок железа и отодвинуть проблему года на два, либо перейти на что-то другое.
rPman
16.11.2018 01:00+1Инвестируйте в свою команду и открытые решения.
Т.е. когда готовые решения из opensource вас чем то не устроят, вы платите своей команде, чтобы они улучшили ее. В итоге у вас будет на руках команда (которая стала лучше потому что получила опыт и деньги за него) а сообщество получит улучшенное решение. Пока этот процесс не прекращается, вы будете объективно в плюсе.
Недостатки метода — вы можете растерять команду из-за внутренних организационных проблем или длительного отсутствия денег. Но если сравнивать с готовыми железными решениями — машина отработает свой срок и все, деньги на нее гарантированно уйдут в песок.
Так же есть риск напороться на проблему, сложность решения которой сравнительно выше абстрактного готового решения по железу.Roto
16.11.2018 01:05В этом конкретном случае я никак не распоряжаюсь командой, только инфраструктурой, а в результате безрезультатности попыток достучаться я скорее всего сменю работодателя.
rPman
16.11.2018 21:04Вот это и есть основная проблема и причина, почему ПЛОХИЕ готовые решения превалируют над правильными открытыми.
Достучаться до принимающих решения очень сложно, им проще и понятнее дорогое и неуклюжее решение с прогнозируемым поведением, чем правильное но не такое простое.
tmteam
16.11.2018 03:34+1(в защиту старины TDD)
Если я правильно понимаю суть TDD и юнит тестирования в целом- то код должен был тестироваться атомарно и без зависимостей, что в общем то исключает возможность спагетти.
Ежели под «ТDD» тут понимается написание функциональных тестов перед написанием кода, то значит есть хорошая документация. Это должна быть хорошая отправная точка для декостылизации.
Ежели под «TDD» здесь понимается написание больших интеграционных и функциональных тестов после кодинга, то получается… что написание интеграционных и функциональных тестов (и только) это яд для больших проектов. Никогда не думал о таком.
Ежели суть TDD я понимаю не правильно. То я точно узнаю об этом от комментаторов -)zloddey
16.11.2018 14:07Цикл классического TDD состоит из 3 шагов:
- красный (новый тест на функциональность, которой ещё нет)
- зелёный (реализовали функциональность любым способом, даже самым костыльным)
- рефакторинг (имея зелёные тесты, немного причесали код)
Если рефакторинг не проводится, то не стоит называть имеющийся процесс словом TDD. Это что-то другое.
katzurki
16.11.2018 04:40В оригинале речь всё же не об одном загадочном макросе, а о многих. А то вообще кошмар был бы.
Ranckont
16.11.2018 08:20Интересно какое спагетти в 1С?
asd111
16.11.2018 20:14+1Переписывают на С++14, планируют внедрять С++17 habr.com/company/1c/blog/429678
na9ort
16.11.2018 09:05-1Меня удивляют люди, которые брызжут слюной и кричат что Oracle скоро отдаст концы.
Предположим, что вы супер крутой разработчик с зарплатой 5000 долларов чистыми.
И вот с этим Вашим гигантским опытом разработки, Вы правда думаете, что знаете лучше чем Ларри Эллисон/топ менеджеры Oracle/управленцы любой многомиллиардной корпорации? Правда лучше знаете?
Вот когда у Вас будет своя корпорация стоимостью несколько миллиардов долларов, построенная с нуля, вот тогда к Вам может и будут прислушиваться, а может и нет.wlr398
16.11.2018 09:30Когда-то тоже были топ управленцы у многомиллиардных компаний — DEC, Compaq, SUN, Nortel,
слившиеся Alcatel и Lucent и затем поглощённые Nokia и т.д.na9ort
16.11.2018 09:36Всё верно. Вот только многие из перечисленный Вами компаний канули в Лету, а Oracle до сих пор жив. Значит топ менеджмент Oracle знает и умеет чуть больше.
wlr398
16.11.2018 09:45Не многие, а собственно все перечисленные канули.
У Оракл ещё всё впереди. Из современных айтишных компаний с реально долгой историей разве что IBM вспоминается.na9ort
16.11.2018 10:10Вот именно. Взять тот же IBM. IBM в начале 2000-ых вроде как начал медленно умирать. И вот сейчас пошёл активный рост. Квантовые компьютеры, ИИ.
Я не утверждаю, что Oracle живее всех живых и самая технологичная компания в мире. Я лишь говорю, что Oracle'у до смерти как пешком до луны. Всё таки развалить многомиллиардную корпорацию не так просто.
OlehR
16.11.2018 09:51+1Давайте на минуточку представим, что код БД настолько ужасен как написано.
Как тогда объяснить, что на протяжении 10 лет, как я работаю с этой БД
1) Oracle развивается быстрее всех конкурентов, И даже нет надежды что кто то сумеет обогнать ее по функционалу и скорости в своем классе БД?
2) Oracle одна из наиболее стабильных БД?
Ну допустим еще можно объяснить стабильность тестами.
Но будь кодовая база ужасна вы никогда не сможете ее развивать быстрее конкурентов. Ну или в конкурентов еще хуже :)
Да понятно, что код не конфетка. Ведь Oracle поддерживает одновременно много платформ и ОС. И все это высоконагруженный код. Где скорость должна бить бескомпромиссная. Понятно, что без грязных хаков никак не обойтись.
Но и стоило вам изменить лишь одну из этих строк, как ломались тысячи написанных ранее тестов
это мягко говоря преувеличение. Наверное, есть <1% кода, который может вызвать такое поведение. Но не все 25 миллионов.
Мне нравятся люди, которые здесь с лёгкостью критикуют. Но кто из вас архитектор, или хотя б тимлид команды, которая работает с кодовой базой 25 миллионов строк?
Или работает с кодом, который приносить многомиллиардную прибыль?
Скажу просто, у нас не тот уровень чтоб критиковать работающий проект такого уровня. И все что ми знаем это со слов людей которые по разным причинам уже не работают в этой компанииDieSlogan
16.11.2018 11:00+11) Oracle развивается быстрее всех конкурентов, И даже нет надежды что кто то сумеет обогнать ее по функционалу и скорости в своем классе БД?
Можете привести примеры?OlehR
16.11.2018 16:44-2Навскидку из относительно нового, RESULT_CACHE ,Inmemory, multitenant, Разнообразие партиций.
Мощность PL/SQL. (Никто и близко не наблизился за много лет )
Возможности администрирования, которим равних нет нигде.
Чтоб не гуглить что такое RESULT_CACHE ,Inmemory
habr.com/post/422669/#comment_19094311
Относительно скорости в стате яндекса сказано что после миграции на postgree серверов стало больше.
Если не согласны — Приведите обратний пример. Кто развивает БД быстее? Я не вижу никого на ринке. даже IBM забросил идею создать для DB2 PL/SQL 100% совместимый.poxvuibr
16.11.2018 16:48+6Относительно скорости в стате яндекса сказано что после меграции на postgree серверов стало больше.
Ещё бы! На те деньги, в которые обходится лицензия Oracle на один сервер можно развернуть парк серверов на Postgresql и для надёжности его продублировать )))
nikolayv81
18.11.2018 16:55Вы бы ещё с терадатой сравнили :)
Яндексу просто ненужно, но есть те кому нужно то ято умеет оракл.
Areso
17.11.2018 12:50А можно подробнее про возможности администрирования?
Например, меня очень сильно интересует, а можно в 2 клика мышкой (окей, в 2 команды в sqlplus) сделать shrink database? Или как сделать бэкап, который не таскает туда-сюда tablespace с пустыми местами? А то меня тут просят иногда помогать нашему Oracle DBA, а я после MSSQL чувствую себя неуютно.OlehR
17.11.2018 18:38Вы ставите неправильные вопросы
Для беккапов есть RMAN. И ничего лишнего.
Для уменьшения датафайлов.
mmokaev.blogspot.com/2015/11/plsql-oracle-shrink-tablespace.html
Просто в oracle можно делать в онлайне то что в других без остановки никак.
Например восстановление битого блока в онлайн или перенос данных на другой диск в онлайн.
Работа с оптимизацией запросов и тд.Stas911
18.11.2018 04:45У нас ораклоид вот так на лету от нечего делать во время важной презентации решил что-то «оптимизировать». В итоге у приложения что-то залочилось, система встала колом — ох и попало ему тогда.
Yaris
16.11.2018 11:40Oracle, может, и развивается быстрее всех, но вот тут: DB-Engines, например, нарисована несколько менее оптимистичная картинка.
staticlab
16.11.2018 11:46Так это график популярности, а не фичастости.
Yaris
16.11.2018 11:52Я понимаю. Если популярность Оракла слегка снижается, а Постгресса — неслегка растёт, по мне это говорит, что «фичастость» Оракла не сильно ему помогает.
poxvuibr
16.11.2018 12:01MySQL по популярности такая же как Oracle. Так что фичи тут вообще не при чём.
khanid
16.11.2018 14:49Ну тут надо понимать, что такие показатели MySQL/MariaDB, фактически, от того, что они имеют немаленькую долю в вебе. Сильно тяжёлых решений с ним не видел. И мне, честно говоря, не совсем ясно, почему. Чисто моё мнение, но я, скорее всего, доверил бы той же марии серьёзный проект. Не вижу причин, почему этого я бы не сделал.
Разная ЦА, если перефразировать кратко.imanushin
16.11.2018 19:28Не вижу причин, почему этого я бы не сделал.
TLDR: проблема не в технической области, а в организационной.
Зачастую есть следующая логика:
- В жирной компании используют Oracle как базу данных в 80% случаях
- Вас как тимлида (т.е. вы кодите в лучшем случае как 1/10 от стандартного разработчика) спрашивают — разработайте архитектуру на бумажке и покажите нам.
- Вы выписываете кучу вещей, микросервисы и т.д. И начинаете выбирать базу, однако:
3.1. Если вы выберете что-то нестандартное, то все ошибки будут лично вашими проблемами (ну т.к. ваша инициатива — вы и виноваты)
3.2. Достижения могут не монетизироваться, т.е. вряд ли база данных вам прям радикально поможет что-то сделать лучше.
3.3. Ряд людей из менеджмента (такие бывшие разработчики, которые вам четко объяснят, какими они были четкими программистами, правда вы нигде не найдете их крутых приложений, да и код свой они не покажут) будут предлагать не выпендриваться, а использовать "проверенные решения" - И дальше, если вы таки решите внедрить базу, то:
4.1. Вы таки внедрите MariaDB. И любая ошибка ударит по вам. Вы не отмажитесь фразой "дык все используют, я полагался на опыт коллег"
4.2. В других командах тимлиды не забудут высказаться, что есть тут один смузихлеб, который не любит Oracle. Ну ибо зачем выпендриваться? - Если вам повезет, то в вашей компании будут использовать Oracle в 79,9% случаев (а было 80%)
- Если вам не повезет (ну просто проект не пошел в гору), то тимлид из другой команды, при выборе базы, будет получать контраргументы в стиле "ну там какой-то khanid внедрял MariaDB, но проект не взлетел".
По сути успех Oracle во многом связан с тем, что они были первыми когда-то, а потом научились договариваться с бизнесом.
OlehR
18.11.2018 18:00Никого не хочу обидеть, но все-таки рассматривать в одном проекте выбор между oracle и mysql?
У них области применения практически не пересекаются.
Оракл версионник и расчитан на олтп нагрузку с большой конкурентностю за ресурсы и “длинными транзакциями”
Mysql блокировщик. И с этим там совсем плохо.
Я не говорю что невозможно решать ети проблемы в Mysql, но крови попет, и рано или поздно вам придется усложнять и усложнять логику для разруливания проблем с блокировками. Я лично использовал Mysql c достаточно большими таблицами и огромным объёмом загружаемой информации, но нагрузка DW.
У всех больших организациях используются 3-7 разных баз данных. И поэтому выбор осуществляется не по принципу возьмём самую дорогую, а какая больше подходит для задачи.
nikolayv81
18.11.2018 16:58Представьте что Oracle Enterprise edotion стал бесплатен, совсем, что произойдёт?
Ну пусть не ee а standard без ограничений, как думаете?
Yo1
16.11.2018 23:33посмотрел картинку, там оракл бессменный лидер, постгрес играет во втором дивизионе. если тренд продолжится, лет через 15 посгрес сможет бросить вызов аутсайдеру высшего дивизиона…
finlandcoder
16.11.2018 12:01> у нас не тот уровень чтоб критиковать работающий проект такого уровня
Основная притензия в том, что архитектура совсем не модульная и всё держится на тысячах bool flag. Возможно, это был единственный способ писать код в 70х. А Oracle пишут с начала 70х. Что проект ппц какой монолитный.
Работаю с кодовой базой в 15 000 000 строк. Есть код, который не трогается уже лет 20. А есть бизнес логика и уровни пользователей, которые переписываются постоянно. Всё покрыто тестами.
baldr
Жесть конечно, но можно только похвалить архитекторов, которые внедрили такое использование TDD в свое время.
Такой продукт сейчас — заложник себя самого. Переписать с сохранением всех фич такое невозвожно за разумное время. Приходится жить с чем есть.
rPman
боюсь накладные расходы на поддержание существующего уже выше чем полное переписывание.
leventov
Я думаю тут не применимо понятие "переписывание" — если начать переписывать с нуля, в любом случае в итоге получится совершенно новая система с другими флагами, свойствами, характеристиками.
immaculate
Раньше необходимо было поддерживать множество операционных систем (Windows, HPUX, Solaris, и т.д.), различных архитектур процессоров (Intel, Alpha, MIPS, Sparc, и т.д.). Сейчас альтернатив почти нет, можно новый код написать под Intel и Windows/Linux — наверняка это значительно сократит количество различных флагов и систему сборки.
molnij
Оракл по прежнему работает на куче архитектур и ОС. Если речь не идет о том чтобы сделать новую базу, чем-то похожую на старую, а именно переписать код — нужна будет поддержка всего того адского зоопарка, который есть.
Fuzzyjammer
Альтернативы никуда не делись, целевая аудитория Оракла по-прежнему эксплуатирует системы на Solaris и AIX.
nikolayv81
Под spark и pewer чего уж там, а остальным хватит и текущей версии 12.2.0.2 или как сейчас по новой нумерации — 18c :)
mIK_LH
Сколько, по-вашему, займёт полное переписывание системы которая пишется десятки лет с нуля?
solver
Может занять гораздо меньше времени чем вы думаете.
Или вы правда думаете, что все эти десятки лет разработчики там каждый день добавляют новую фичу? ))
Посмотрите на любой проект, его движение это очень сложная и запутанная кривая.
Плюс технологии развиваются. Появляются новые языки, тулинг, подходы.
Так что однозначного ответа нет. Нельзя вот так с ходу сказать, что если проект писался 30 лет, то и переписывать с нуля его надо будет тоже 30 лет. В каждом случае свои условия.
format1981
И если при переписывании с нуля получится использовать старые тесты (хотя бы частично), то окажется что TDD — это больше плюс, чем минус.
TerraV
При том-то что никто не понимает ни код, ни тесты? Ну-ну. Переиспользовать.
AEP
Это при условии, что старые тесты релевантны и не являются только unit-тестами. «Этот тест тестирует правильную работу вот этого класса, но этого класса в переписанном коде не будет».
kryvichh
Имея готовый «старый» продукт, его можно использовать в тестах. То есть грубо берём тестовую БД, берём тестовый скрипт, обрабатываем её скриптом в старой и новой СУБД, и сравниваем результат.
DrPass
Не тридцать лет, естественно. Переписывать, конечно же, быстрее — не обязательно проживать заново все годы легаси. Но вероятность того, что его переписать будет дешевле, чем сопровождать в текущем виде, настолько ничтожно мала, что ей можно смело пренебречь.
snuk182
Может занять немного меньше времени, если каждая фича идеально документирована в виде либо «делаю вот то-то вот так-то», либо «было такое, стало вот это». Что, как показывает практика, соблюдается чуть более чем никогда.
Потому в большем почете написание нового продукта без легаси вообще, чем портирование старых юзкейсов на новые технологии. Даже если за юзкейсы платят. Даже если платят много.
immaculate
Да, в комментариях к статье на HN писалось именно об этом. Полно старых продуктов, которые написаны ужасно плохо и которые невероятно сложно и дорого поддерживать. Но переписать их никогда не получится, потому что они взаимодействуют с таким же ужасным кодом у пользователей продукта и необходимо соблюдать совместимость с багами и недокументированными особенностями.
Поэтому многие продукты стали заложниками обратной совместимости. В том числе, Windows, Microsoft Office (там же говорилось и о том, что код Office просто ужасен).
kryvichh
Тем не менее те же Microsoft выкинули Trident, и полностью переписали код своего движка браузера (Edge). А уж сколько на старом движке стороннего кода написано…
staticlab
Скорее, форкнули. Специально для обратной совместимости в Windows 10 оставлены и IE11, и mshtml.dll
nikolayv81
Основная проблема и одновременно плюс oracle это то что его использует куча проектов, владельцы которых платят за поддержку, если им указать на дверь в случае если их ПО перестанет работать на правильной новой версии бд, они могут не понять...
balexa
В случае подобного размера приложения — это далеко не очевидно. Новое приложение будет иметь кучу детских болячек. Это может быть смертельно для компании.
Старая, но не устаревшая статья
www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i
И перевод habr.com/post/219651
slonpts
Я сейчас работаю в проекте, который непрерывно разрабатывается на протяжении 30 лет. Естественно, куча легаси и спагетти, переписать которые за раз невозможно.
В итоге выделяем какие-то части, где можно провести границу (в нашем проекте это, к счастью, возможно) и переписываем часть. Делается это под соусом внедрения новых фич и переноса части кода с C++ на .NET Core.
balexa
В вашем проекте — возможно. В проекте вроде оракла — нет. Фактически, это будет значить что оракл забросил свой продукт и делает новый. То что он сохранит при этом всех своих заказчиков или даже сколько нибудь большую часть маловероятно.
willyd
К сожалению нет.
Fortune 100/500 — это верхушка айсберга. По большому счету, весь крупный энтерпрайс в мире в той или иной степени использует Oracle. Я очень сильно сомневаюсь, что переписать можно будет все без проблем с миграцией.
Обычная миграция между мажорными версиями — это боль. И если вашему предприятию уже лет 10, то в нем не меньший хаос чем в ядре Oracle. Я уверен, что количество фич и триггеров под разные тесты настолько велико, что это просто нереально переписать без значимой потери или изменения функционала.
А теперь, просто представьте во сколько это обойдется Oracle, и мировой экономике эта миграция, вообщем. Представьте, что массово будут происходить аварии вроде этой habr.com/post/429736
Просто, когда читаешь про то, как какой-то стартап все построил и все красивое и новое и без костылей и проблем, я всегда понимаю, что по сути — это на какое-то время и через 5-10 лет этот стартап обрастает таким же количеством легаси кода, которые было при сравнении в их радужных публикациях. Оно так будет, причины могут быть разные: бизнес должен работать пока не начнет из-за этого загибаться (как пример была история Maersk, у которого ИТ не мог выбить деньги на необходимые изменения и вообще как-то повлиять на политику безопасности, пока их не нагнул NotPetya, и компания встала, а клиенты делали миллионные заказы через WhatsApp), да просто внутренняя политика поощрения (как в недавно описанной тут истории про новый интерфейс Gmail), причин может быть тысячи. Проблема в том, что бизнесом правят деньги, и понадобится еще лет 5-10 пока рулевые поймут, что их кораблем в основном управляют алгоритмы, которые требуют значительно большего средств на обслуживание, чем им бы хотелось.
poxvuibr
В описанном в статье воркфлоу ничего не сказано про TDD. Там сказано только про то, что код покрыт тестами и всё. Наличие кода покрытого тестами и использование TDD это совершенно разные вещи.
Tortortor
а может статью прочитать?
poxvuibr
Я внимательно прочитал статью и после этого написал комментарий. Такие дела. Я не совсем понимаю, что вы хотели сказать своим комментарием, напишите, пожалуйста прямо. Если вы просто хотели сказать, что я не читал статью — уверяю вас, вы ошиблись.
zelenin
mkshma
Описанное ну ни разу не про TDD. Да и сам автор пишет, мол написал код, он прошел существующие тесты, потом набросал свои. Это прямо противоположный TDD подход.
zelenin
вернемся к вашему возражению про TDD и совету прочитать статью: то, что не описано воркфлоу, удовлетворяющее TDD, не значит, что TDD там нет. А вот что TDD там есть, хоть и не описано в воркфлоу — на это прямо указано в тексте статьи.
poxvuibr
Только вот в статье явным образом описано воркфлоу, использование которого исключает практику TDD.
Мой комментарий как раз о том, что нет там никакого TDD. То, что в статье описано как TDD — не является TDD.
tmteam
TDD != написать какие угодно тесты в проект. TDD подразумевает написание Юнит тестов (атомарных, не интеграционных) и написание их до или во время написания основного кода.
BalinTomsk
Это не TDD. Код Оракла появился за долго до этого.
Legacy код покрыли юнит тестами.
Если нужно починить что-то — пишете unit test дотверждающий баг, затем чините код, чините поломанные фиксом тесты и пишите новые тесты, покрывающие fix.
willyd
Это нереально переписать.
Тут только тесты под TDD написать уйдет неимоверное кол-во усилий. И даже это не будет гарантировать 100% покрытия функционала.
А значит, миграция на такую базу вызовет ощутимые потери клиентуры, у которой уже будет выбор мигрировать на Oracle или выбирать среди подросших конкурентов. Для предприятия в обоих случаях все сведется к миграции данных и значительному пересмотру кода.
vsb
Можно проводить постоянный рефакторинг. Благо все эти миллионы тестов позволят это делать достаточно безопасно. Но это-ж надо платить за то, что ничего не поменяется. Бизнесы такое не понимают и не любят.
akuzmin
Рефакторинг можно сделать только для кода, назначение которого понятно. Вполне может быть, что рефакторинг там уже невозможен.
tmteam
Это не имеет ничего общего с TDD кроме слова Test.