Всё правильно сделал
Подробнее
I’m CTO, bitch ^ К нам сегодня вышел новый разработчик. Он два часа задумчиво смотрел в монитор. Потом просто встал и ушёл. Больше не берёт трубку и забанил меня в телеге. Вы реально ему в первый рабочий день показали наш модуль для прайсинга? Там же всё на хранимых процедурах написано, а ещё куски на перле. 2. Я говорил, что разработчики сейчас очень нежные, им нельзя такое в первый день показывать. Боюсь, мы не сработаемся, ю-да Почему? Что случилось? 10:43 УУ Интересный у вас код, благодаря ему я понял, как для меня важно работать в гетеросексуальном коллективе. Так что дальше наши пути расходятся ю-49 t.me/imctobitch/37
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,картинка с текстом,разработка,программист,телеграм,I'm CTO bitch,код,говнокод,начальство,увольнение
Еще на тему
за челлендж - сидеть по 12 часов?
за признание коллег - коллеги не понимают, что ты делаешь, и ржут над твоим свитером. Слушают громко музыку и пюът кофе. Ты работаешь, они ушли на обед и считают тебя "не общительным". Эти пидары ушли жрать и пиздеть, пока я вкалываю!
за чувство, что кроме тебя хуй кто сделает. - такого лоха поискать.
Про OrcaleDB, к примеру, ходит море слухов, что код там ужасный и живет только на тестах.
Проблема же прямо в том, что код нельзя переписать и перерефакторить, потому что стоимость рефакторинга бьет все разумные пределы, а бизнес никогда не даст возможность заморозить поставку фич на полгода.
У легаси много проблем и проблема "сломать к хренам" только одна из них. Иногда в коде происходит полная дичь и 100% покрытие просто бьет тебя по рукам без объяснения чего либо, что не делает ситуацию лучше.
Ах да, еще один грязный секрет. Качество кода очень редко прямо влияет на то, насколько популярный проект.
Тесты штука полезная, но реальная их польза только в одном - защита от тупых механических ошибок. Всё.
Я же не говорю, что тесты бесполезны. Они очень полезны. Но говорить, что они - главное в проекте - это уже религия.
Основная проблема легаси в том, чтобы понимать, НАХУЯ он это делает. И КАКОГО ХУЯ он это делает именно таким образом.
Так вот, тесты проверяют то, ЧТО делает код, но не дают понимания того, НАХУЯ, и КАКОГО ХУЯ.
И вот человек, разгребающий легаси, постоянно задаётся именно этими двумя вопросами - НАХУЯ??? КАКОГО ХУЯ???
Изменить код, не ответив на эти вопросы, правильно - невозможно.
Правда, потом добавляется еще требований, которые не вписываются в архитектуру, и нужно ставить костыли. Потом эти костыли требуют еще костылей, больше костылей богу костылей! Потом сменяется команда, и половину функционала начинает дублировать, потому что не в курсе, что это уже реализовано. Потом дублированный функционал, костыли и прочее, как снежный ком требуют еще больше костылей и кривых решений. А сверху летят всё новые и новые бизнес-требования, как контрольный в голову, и всем уже просто насрать на красоту, лишь бы работало.
В конечном счете всё всё равно сводится к картине "мы 10 лет срали кодом". Даже если всё так хорошо начиналось. No escape
Чем меньше кода и лишней архитектурной поебени, тем меньше потом говнокостылей, потому что переписывать под новые требования проще, ибо кода немного, и он занимается только тем, чем нужно, а не обслуживает навороченную архитектуру и "заделы на будущее", для которых это будущее никогда не наступает.
Потому я взял за правило девдоки писать до кода.
200 сотни процедур, сотня функций и пол сотни триггеров. Что из всего этого вообще участвует в процессе - никто не знает.
Нахуй такие рядовые ситуации.
Дык, это проблема отсутствия документации, а не того что "у нас очень много SP". Я так и не понял 200 или 20к, но строго говоря их может быть и миллион, при этом с БД работает N-команд, причем в разных странах на аутсорсе, и единого человека знающего что где к чему вообще не существовать, и нормально с этим работать. Ну, почти нормально.
Ну и да, отсутствие документации и ежедневные требования по обновлению функционала, зачастую противоречащие друг другу, потому как разные отделы пытаются спихнуть ответственность друг на друга.
Надо добавить новую переменную по фиче - добавил в вызов - сломалась часть скриптов, которая не относится к этой фиче. Добавил ее в эти скрипты - надо её добавить во флоу вне этой фичи, что-то где-то проглядел глазами - баги на проде, когда заказчик удачно попадет на кейс с той цепочкой вызова, которая сломана
Возможно появление внятных средств рефакторинга и проверок при редактировании помогло бы конечн
Плохие инструменты отладки - поди воткни брейкпойнт в середине процедуры, также легко как в каком-нибудь c# или java
Убогая тестируемость - лучше вскрыть вены себе, чем писать юнит-тесты под тот же оракл
Намертво привязываешь себя к вендору БД - у знакомого в компании большая часть логики была написана на хранимках внутри их БД от IBM, а теперь из-за санкций решили заменить бездуховный западный софт на скрепный постгрес. И теперь там все вешаются от осознания как теперь портировать эти киллометры простыней процедур.
2) При чем тут брекпоинты если процедура все равно выполняться будет на стороне сервера, точки останова в код запроса все равно не поставить
3) Плохая читабельность? По мне так наоборот одна строка наименования процедуры куда проще читается чем километр того же SQL запроса в коде
2. Я хз как обстоят с этим дела в мире проф DB девелоперов. Но во-первых, я когда пишу код вначале разворачиваю микросервис у себя локально на дев машине и могу спокойно поставить бряки в любых местах и спокойно отладить любой кусок кода. Во-вторых, к пред-проду я могу подключиться remote дебагингом и все вызовы будут трассироваться мне в ide и если я поставлю бряку у себя в коде, то любой вызов на удаленном сервере, который наткнется на неё, автоматически остановит поток и отобразиться у меня, так как будто этот код был у меня запущен локально.
3. Опять же речь не о том, чтобы куски sql или процедур, тупо дергать из БД и вставлять их в код. А в том чтобы решать эти вещи программно. Естественно процедура исполняемая прям на БД выполнит какой-нибудь джоин с кучей сабселектов быстрее, чем если дернуть эти куски отдельно из БД и смапить их уже на уровне кода. Но компромисс находится почти всегда и почти всегда нет смысла тащить всю логику на уровень БД, а достаточно написать хранимки только для избранных критических мест, где производительность превыше всего.
К сожалению или к счастью я не вижу у прямых запросов в коде никаких особых преимуществ перед процедурами. В вашем случае может и возможно так отлаживать но когда бд раздувается до нескольких терабайт вы вряд ли станете ее разворачивать у себя либо дебажить на проде. Репликация такой бд тоже проблемная задача. Постоянно держать тестовую бд в соответствии с продом тоже проблематично. Производительность у хранимых процедур в большинстве случаев выше. Разделить разработку между SQL программистами и бэкендом куда проще, так как сикьюэлищикам не надо лезть туда куда им не следует. Бизнес логика в процедурах освобождает бэкенд от её обдумывания. Ты просто получаешь данные и возвращаешь их же обратно и опять же при ошибках в бизнес логике на стороне бд можно быстрее исправить ошибку в некоторых случаях это довольно критично.
В маленьких проектах может и проще использовать прямые запросы, так как весь код в одном месте, но я от этого отказался в пользу хранимых процедур, так как мне это удобнее и привычнее.