самый крутой навык - врубаться в легаси
05.10.2022, 08:54
Потому что это единственное, что стабильно работает.
За очень большие деньги, за челлендж, за признание коллег, за чувство, что кроме тебя хуй кто сделает. Мотивации много разной может быть.
Ага ага, за звание главного программиста когда ты один программист или за звание директора отдела разработки в котором ты только один... Слышали знаем. Единственный важный пункт, это первый, за очень большие деньги, все остальное хуита, пройдет немного времени и ты поймёшь что тебя тупо наебали.
За очень большие деньги - за стандартную зарплату
за челлендж - сидеть по 12 часов?
за признание коллег - коллеги не понимают, что ты делаешь, и ржут над твоим свитером. Слушают громко музыку и пюът кофе. Ты работаешь, они ушли на обед и считают тебя "не общительным". Эти пидары ушли жрать и пиздеть, пока я вкалываю!
за чувство, что кроме тебя хуй кто сделает. - такого лоха поискать.
за челлендж - сидеть по 12 часов?
за признание коллег - коллеги не понимают, что ты делаешь, и ржут над твоим свитером. Слушают громко музыку и пюът кофе. Ты работаешь, они ушли на обед и считают тебя "не общительным". Эти пидары ушли жрать и пиздеть, пока я вкалываю!
за чувство, что кроме тебя хуй кто сделает. - такого лоха поискать.
Понял. Жалко конечно что в орекл код живёт только на тестах, странно другое, что орекл занимает одну из ведущих позиций СУБД. Открою вам секрет, в разработке самая главная ценность это тесты, а код можно написать и переписать 1000 раз. Это не является проблемой. Самая главная проблема "Легаси" это именно "боязнь" что-то менять, т.е. в натуральном плане люди психологически бояться прикасаться к коду, помогу что понимают что последствия никто не сможет спрогнозировать и взять за них ответственность, тесты и созданы для решения этой проблемы.
Ого, как вам там в стране единорогов?
Проблема же прямо в том, что код нельзя переписать и перерефакторить, потому что стоимость рефакторинга бьет все разумные пределы, а бизнес никогда не даст возможность заморозить поставку фич на полгода.
У легаси много проблем и проблема "сломать к хренам" только одна из них. Иногда в коде происходит полная дичь и 100% покрытие просто бьет тебя по рукам без объяснения чего либо, что не делает ситуацию лучше.
Ах да, еще один грязный секрет. Качество кода очень редко прямо влияет на то, насколько популярный проект.
Проблема же прямо в том, что код нельзя переписать и перерефакторить, потому что стоимость рефакторинга бьет все разумные пределы, а бизнес никогда не даст возможность заморозить поставку фич на полгода.
У легаси много проблем и проблема "сломать к хренам" только одна из них. Иногда в коде происходит полная дичь и 100% покрытие просто бьет тебя по рукам без объяснения чего либо, что не делает ситуацию лучше.
Ах да, еще один грязный секрет. Качество кода очень редко прямо влияет на то, насколько популярный проект.
Основная проблема легаси - не понимание, ЧТО делает код. Это видно по самому коду.
Основная проблема легаси в том, чтобы понимать, НАХУЯ он это делает. И КАКОГО ХУЯ он это делает именно таким образом.
Так вот, тесты проверяют то, ЧТО делает код, но не дают понимания того, НАХУЯ, и КАКОГО ХУЯ.
И вот человек, разгребающий легаси, постоянно задаётся именно этими двумя вопросами - НАХУЯ??? КАКОГО ХУЯ???
Изменить код, не ответив на эти вопросы, правильно - невозможно.
Основная проблема легаси в том, чтобы понимать, НАХУЯ он это делает. И КАКОГО ХУЯ он это делает именно таким образом.
Так вот, тесты проверяют то, ЧТО делает код, но не дают понимания того, НАХУЯ, и КАКОГО ХУЯ.
И вот человек, разгребающий легаси, постоянно задаётся именно этими двумя вопросами - НАХУЯ??? КАКОГО ХУЯ???
Изменить код, не ответив на эти вопросы, правильно - невозможно.
За это больше платят. При том, что при наличии навыка, работы по факту, меньше. Ибо подгонять того, кто отвечает за хуйню, в которую остальные боятся даже смотреть, никто не осмелится, и эстимейты ему ставить тоже. Можно спокойно срать на весь с(к)рам, и делать по своему графику, который сам себе нарисовал.
Легаси легаси рознь. Одно дело с четкой архитектурой и полной документацией, другое: мы 10 лет срали кодом как попало и размазывали
Должны быть, по логике. Ведь сначала делается всё красиво, по уму, best practices, красота, эффективность, Стив Макконнелл пускает слезу радости от такого совершенного проекта.
Правда, потом добавляется еще требований, которые не вписываются в архитектуру, и нужно ставить костыли. Потом эти костыли требуют еще костылей, больше костылей богу костылей! Потом сменяется команда, и половину функционала начинает дублировать, потому что не в курсе, что это уже реализовано. Потом дублированный функционал, костыли и прочее, как снежный ком требуют еще больше костылей и кривых решений. А сверху летят всё новые и новые бизнес-требования, как контрольный в голову, и всем уже просто насрать на красоту, лишь бы работало.
В конечном счете всё всё равно сводится к картине "мы 10 лет срали кодом". Даже если всё так хорошо начиналось. No escape
Правда, потом добавляется еще требований, которые не вписываются в архитектуру, и нужно ставить костыли. Потом эти костыли требуют еще костылей, больше костылей богу костылей! Потом сменяется команда, и половину функционала начинает дублировать, потому что не в курсе, что это уже реализовано. Потом дублированный функционал, костыли и прочее, как снежный ком требуют еще больше костылей и кривых решений. А сверху летят всё новые и новые бизнес-требования, как контрольный в голову, и всем уже просто насрать на красоту, лишь бы работало.
В конечном счете всё всё равно сводится к картине "мы 10 лет срали кодом". Даже если всё так хорошо начиналось. No escape
Именно поэтому я последние лет 10 использую принцип "сделай как можно проще".
Чем меньше кода и лишней архитектурной поебени, тем меньше потом говнокостылей, потому что переписывать под новые требования проще, ибо кода немного, и он занимается только тем, чем нужно, а не обслуживает навороченную архитектуру и "заделы на будущее", для которых это будущее никогда не наступает.
Чем меньше кода и лишней архитектурной поебени, тем меньше потом говнокостылей, потому что переписывать под новые требования проще, ибо кода немного, и он занимается только тем, чем нужно, а не обслуживает навороченную архитектуру и "заделы на будущее", для которых это будущее никогда не наступает.
Работающий в информационых ИТ технологиях. В любом случае простыня из sql-запросов -- кажись рядовая ситуация, и строго говоря когда пытаются тоже самое провернуть на orm, то лапша выходит гораздо эпичнее. А вынести все в BL мешает тот факт что все должно происходит под транзакцией и отрабатывать максимально быстро. В итоге имеем что код -- прослойка прокидывающая запросы между UI и Database. В идеале конечно нужно уходить от такого, но практика показывает что это не всегда достижимо.
Боже, чувак, ты не представляешь какой "feel" эффект ты у меня спровоцировал. Моя первая IT работа была с учетным софтом вся логика которого была построена на хранимках, функциях, вьюхах и триггерах к ним.
200 сотни процедур, сотня функций и пол сотни триггеров. Что из всего этого вообще участвует в процессе - никто не знает.
Нахуй такие рядовые ситуации.
200 сотни процедур, сотня функций и пол сотни триггеров. Что из всего этого вообще участвует в процессе - никто не знает.
Нахуй такие рядовые ситуации.
>>Что из всего этого вообще участвует в процессе - никто не знает.
Дык, это проблема отсутствия документации, а не того что "у нас очень много SP". Я так и не понял 200 или 20к, но строго говоря их может быть и миллион, при этом с БД работает N-команд, причем в разных странах на аутсорсе, и единого человека знающего что где к чему вообще не существовать, и нормально с этим работать. Ну, почти нормально.
Дык, это проблема отсутствия документации, а не того что "у нас очень много SP". Я так и не понял 200 или 20к, но строго говоря их может быть и миллион, при этом с БД работает N-команд, причем в разных странах на аутсорсе, и единого человека знающего что где к чему вообще не существовать, и нормально с этим работать. Ну, почти нормально.
200 процедур. Фронт на паскале у дедушки, который не хочет им делиться(и на хую вертел компанию в целом). Некоторые процедуры/функции до 2000 строк скрипта.
Ну и да, отсутствие документации и ежедневные требования по обновлению функционала, зачастую противоречащие друг другу, потому как разные отделы пытаются спихнуть ответственность друг на друга.
Ну и да, отсутствие документации и ежедневные требования по обновлению функционала, зачастую противоречащие друг другу, потому как разные отделы пытаются спихнуть ответственность друг на друга.
Я на прошлой работе поддерживал как раз такую прослойку, которая тупо гоняет запросы между фронтом и базой, а вся основная логика была в базе (которую поддерживали другие программисты). Когда-то, несколько лет назад, такой подход, может, и был оправдан, но когда я там работал, всё выродилось в "база упаковывает десятки тысяч записей в зип-архив на сотни мегабайт" и "база парсит архив на сотни мегабайт, создавая из под транзакции кучу временных таблиц, чтобы рассортировать эти данные".
чисто revolver ocelot
https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2010/zxsa8hkf(v=vs.100)?redirectedfrom=MSDN
Ну если хотеть скорости, то ORM проще выкинуть нахуй, ибо все что остается - преобразователь в классы и то, не всегда. И иногда генератор гибких запросов.
Я его понимаю, он прошел собес с вопросами как в НАСА или гугол, наобещали ему "все по красоте", он пришел в первый день - рабочее место не готово, притащили пыльный стол откуда-то, естественно "временно", в опенКЕЙЖД на 100500 жоп на квадратный сантиметр. Нам подрядчикам деваться особо не куда было, а он все правильно сделал) Встал, ушел, даже наушники забыл и не вернулся за ними.
Ну вот например пример: тысяча скриптов, которые вызывают сотню других скриптов, которые вызывают десяток других, и всё это перемешано плюс эта вложенность от одного до четырех.
Надо добавить новую переменную по фиче - добавил в вызов - сломалась часть скриптов, которая не относится к этой фиче. Добавил ее в эти скрипты - надо её добавить во флоу вне этой фичи, что-то где-то проглядел глазами - баги на проде, когда заказчик удачно попадет на кейс с той цепочкой вызова, которая сломана
Возможно появление внятных средств рефакторинга и проверок при редактировании помогло бы конечн
Надо добавить новую переменную по фиче - добавил в вызов - сломалась часть скриптов, которая не относится к этой фиче. Добавил ее в эти скрипты - надо её добавить во флоу вне этой фичи, что-то где-то проглядел глазами - баги на проде, когда заказчик удачно попадет на кейс с той цепочкой вызова, которая сломана
Возможно появление внятных средств рефакторинга и проверок при редактировании помогло бы конечн
У какого-то зарубежного банка крашилась мобильная приложенька, я помню, когда они поставили курс рубля ноль. С оракловской ошибкой
Проблема в плохой читабельности - любой С-подобный язык читается в разы легче, чем, например, простыня на оракловом синтаксисе
Плохие инструменты отладки - поди воткни брейкпойнт в середине процедуры, также легко как в каком-нибудь c# или java
Убогая тестируемость - лучше вскрыть вены себе, чем писать юнит-тесты под тот же оракл
Намертво привязываешь себя к вендору БД - у знакомого в компании большая часть логики была написана на хранимках внутри их БД от IBM, а теперь из-за санкций решили заменить бездуховный западный софт на скрепный постгрес. И теперь там все вешаются от осознания как теперь портировать эти киллометры простыней процедур.
Плохие инструменты отладки - поди воткни брейкпойнт в середине процедуры, также легко как в каком-нибудь c# или java
Убогая тестируемость - лучше вскрыть вены себе, чем писать юнит-тесты под тот же оракл
Намертво привязываешь себя к вендору БД - у знакомого в компании большая часть логики была написана на хранимках внутри их БД от IBM, а теперь из-за санкций решили заменить бездуховный западный софт на скрепный постгрес. И теперь там все вешаются от осознания как теперь портировать эти киллометры простыней процедур.
1) Какая разница портировать километры процедур или километры вшитых в код запросов?
2) При чем тут брекпоинты если процедура все равно выполняться будет на стороне сервера, точки останова в код запроса все равно не поставить
3) Плохая читабельность? По мне так наоборот одна строка наименования процедуры куда проще читается чем километр того же SQL запроса в коде
2) При чем тут брекпоинты если процедура все равно выполняться будет на стороне сервера, точки останова в код запроса все равно не поставить
3) Плохая читабельность? По мне так наоборот одна строка наименования процедуры куда проще читается чем километр того же SQL запроса в коде
1. Речь об ORM, которому без разницы, что под капотом ты ему подключил. Мы работая с Hibernate мигрировали с одного БД на другую без проблем.
2. Я хз как обстоят с этим дела в мире проф DB девелоперов. Но во-первых, я когда пишу код вначале разворачиваю микросервис у себя локально на дев машине и могу спокойно поставить бряки в любых местах и спокойно отладить любой кусок кода. Во-вторых, к пред-проду я могу подключиться remote дебагингом и все вызовы будут трассироваться мне в ide и если я поставлю бряку у себя в коде, то любой вызов на удаленном сервере, который наткнется на неё, автоматически остановит поток и отобразиться у меня, так как будто этот код был у меня запущен локально.
3. Опять же речь не о том, чтобы куски sql или процедур, тупо дергать из БД и вставлять их в код. А в том чтобы решать эти вещи программно. Естественно процедура исполняемая прям на БД выполнит какой-нибудь джоин с кучей сабселектов быстрее, чем если дернуть эти куски отдельно из БД и смапить их уже на уровне кода. Но компромисс находится почти всегда и почти всегда нет смысла тащить всю логику на уровень БД, а достаточно написать хранимки только для избранных критических мест, где производительность превыше всего.
2. Я хз как обстоят с этим дела в мире проф DB девелоперов. Но во-первых, я когда пишу код вначале разворачиваю микросервис у себя локально на дев машине и могу спокойно поставить бряки в любых местах и спокойно отладить любой кусок кода. Во-вторых, к пред-проду я могу подключиться remote дебагингом и все вызовы будут трассироваться мне в ide и если я поставлю бряку у себя в коде, то любой вызов на удаленном сервере, который наткнется на неё, автоматически остановит поток и отобразиться у меня, так как будто этот код был у меня запущен локально.
3. Опять же речь не о том, чтобы куски sql или процедур, тупо дергать из БД и вставлять их в код. А в том чтобы решать эти вещи программно. Естественно процедура исполняемая прям на БД выполнит какой-нибудь джоин с кучей сабселектов быстрее, чем если дернуть эти куски отдельно из БД и смапить их уже на уровне кода. Но компромисс находится почти всегда и почти всегда нет смысла тащить всю логику на уровень БД, а достаточно написать хранимки только для избранных критических мест, где производительность превыше всего.
У ОРМ в большинстве случаев проблемы с производительностью. По крайней мере в больших проектах это сильно заметно. тот же Entity Framework при больших объемах в принципе невозможно нормально использовать потому что он просто на просто виснет насмерть при апдейте структуры либо добавлении чего либо. Да и в скорости отработки у них проблемы.
К сожалению или к счастью я не вижу у прямых запросов в коде никаких особых преимуществ перед процедурами. В вашем случае может и возможно так отлаживать но когда бд раздувается до нескольких терабайт вы вряд ли станете ее разворачивать у себя либо дебажить на проде. Репликация такой бд тоже проблемная задача. Постоянно держать тестовую бд в соответствии с продом тоже проблематично. Производительность у хранимых процедур в большинстве случаев выше. Разделить разработку между SQL программистами и бэкендом куда проще, так как сикьюэлищикам не надо лезть туда куда им не следует. Бизнес логика в процедурах освобождает бэкенд от её обдумывания. Ты просто получаешь данные и возвращаешь их же обратно и опять же при ошибках в бизнес логике на стороне бд можно быстрее исправить ошибку в некоторых случаях это довольно критично.
В маленьких проектах может и проще использовать прямые запросы, так как весь код в одном месте, но я от этого отказался в пользу хранимых процедур, так как мне это удобнее и привычнее.
К сожалению или к счастью я не вижу у прямых запросов в коде никаких особых преимуществ перед процедурами. В вашем случае может и возможно так отлаживать но когда бд раздувается до нескольких терабайт вы вряд ли станете ее разворачивать у себя либо дебажить на проде. Репликация такой бд тоже проблемная задача. Постоянно держать тестовую бд в соответствии с продом тоже проблематично. Производительность у хранимых процедур в большинстве случаев выше. Разделить разработку между SQL программистами и бэкендом куда проще, так как сикьюэлищикам не надо лезть туда куда им не следует. Бизнес логика в процедурах освобождает бэкенд от её обдумывания. Ты просто получаешь данные и возвращаешь их же обратно и опять же при ошибках в бизнес логике на стороне бд можно быстрее исправить ошибку в некоторых случаях это довольно критично.
В маленьких проектах может и проще использовать прямые запросы, так как весь код в одном месте, но я от этого отказался в пользу хранимых процедур, так как мне это удобнее и привычнее.
Ещё добавлю: в систему контроля версий хранимки фиг запихнёшь.
Чтобы написать коммент, необходимо залогиниться
