Фактически для нас ИИ может оказать сложным компилятором, который умеет компилировать программы на языке, который знает любой обыватель, но на котором не практично создавать программы.
У любого проекта (продукта) изначально есть бизнес описание (ТЗ по нашему). Когда программист пишет код, то он "скармливает" свой код написанный по определённому алгоритму, стандарту, синтаксису и т.д. компилятору. Код необходимо написать с учетом бизнес требований от заказчика.
Если ИИ научится "писать код сам", то по большому счету возникает задача написать бизнес требование для компилятора ИИ так, чтобы это превратилось в рабочий проект. И это тоже будет своего рода "программирование", да, для этого будут нудны другие знания, умения.
Мне кажется, что если так произойдет, то большая часть программистов превратится в разработчиков-аналитиков, которые будут писать требования для ИИ, а уже он будет генерировать продукт.
Тут наверное все гораздо проще: есть определенная цена на товар (плюс минус скидка) для всех клиентов (по тексту статьи это постоянные клиенты), для новых клиентов на эту цену дают скидку так сказать привлечь новых клиентов, вот все. Т.е. цену занижают только для небольшой категории (численности) новых клиентов.
А что потом делать с этой "АЭС на Марсе" спустя много лет, когда выйдет срок эксплуатации? И это мы не говорим о том, что делать если произойдет какая-нибудь авария.
Когда весь мир разрабатывает альтернативные источники энергии куда проще паразитировать на "ядерной" технологии. Загадили эту планету, давайте следующую ....
То что вы описали даже сильнее подходит для «возрастных» работников. Каждый переход из одной компании в другую это стресс. У каждого «возрастного» работника со стажем (с годами работы) появляется своё понимание и видение работы. Свои привычки, свои взгляды и на всё это у них есть успешные примеры из прошлых работы, так сказать есть с чем сравнить. Они практически всегда могут привести пример «удачной» реализации задачи из своего опыта работы в прошлых компаниях, при этом они не всегда понимают, что этот «удачный» опыт нельзя применить в текущей компании по тем или иным причинам. Примерно с этого момента начинается разочарование (выгорание) и т.д… И вот тут наверное не все готовы подстроиться под требования и правила в новой компании и продолжать работу.
Яркий пример, который наблюдаю прямо сейчас, это когда компания переходит из формата работы «по Техническому заданию» с примерным сроком реализации 2-4 месяца на формат «Agile», «Kanban» и т.д. когда вся задача оценивается не больше спринта (1-2 недели). Разработчики, которые всю жизнь работали по ТЗ воспринимают все эти нововведения «в штыки» и чаще всего, компании проще обучить молодого сотрудника новым требованиям чем переучивать «возрастного».
Спасибо за комментарий. Да, сам в последнее время использую «select count(*)», чтоб не городить последовательность блоков «begin… end».
Если будет время дописать третью статью о мониторинге событий на основе описанных предыдущих статьях и тогда, я надеюсь, может вам станет понятнее вся суть «новаторства».
поэтому не надо настраиваться негативно и отвергать советы
Я стараюсь отвечать на каждое сообщение и излагать свою точку зрения, да она может не совпадать с вашей (или другой). Суть всех статей не в том, чтобы выдать на всеобщее обозрение готовый продукт, который «скачал — установил — и в путь». Так не бывает, каждый проект, команда разработчиков, тимлиды, компания и т.д. все в совокупности дает индивидуальную реализацию. Иногда это качественный лог ошибок с многоуровневым логированием, а иногда его вовсе нет т.к. тимлид «не понимает зачем ему хранить тексты ошибок».
По мере развития своего видения модели логирования событий и пришел к выводу, чтоб «рабочая» модель логирования это максимально простой в использовании функционал как для разработчиков, так и для пользователей (тестировщиков). Именно его я и описал в статьях. В текущей модели есть проблемы и я их стараюсь учитывать «от проекта к проекту» и если однажды появится возможность написать новое логирование «с нуля» на каком-нибудь проекте, то он будет более совершенный чем предыдущие версии. Помимо простого функционала необходимо устанавливать определенные правила логирования ошибок (их я тоже постарался раскрыть). Говоря по простому, не важно каким логированием вы пользуетесь важно то, как его будут использовать в работе ваши коллеги.
Приведенные вами примеры логирования хорошо и удобны при точечном устранении ошибки. Использовать это в повседневной работе трудно. Лично я сомневаюсь, что кто-нибудь из читающих эту статью сможет реализовать описанное вами логирование в своем проекте.
А так в целом спасибо за советы.
Не ожидал, что кто-нибудь напишет целую статью по мотивам моих, спасибо. Когда увидел ссылки аж сердце прихватило. Если можно то оставлю свои комментарии.
В показанной системе не хватает гибкости настройки логгирования: как уровня детализации, так и места, куда их выводить. Можно было позаимствовать функциональность из широко известных систем логгирования а-ля java.util.logging (SLF4j, log4j и его вариации для других языков/систем, и тд), гибкую настройку для какого кода с какого уровня сообщений и куда их сохранять. Например, в том же log4plsql можно настроить вывод и в alert.log, и в trace file (с помощью `dbms_system.ksdwrt()`)
Могу лишь вас заверить, что представленная модель логирования это результат написания более 5 БД с активным логированием ошибок. Изначально, в нашем логировании были уровни детализации, было логирование как в таблицу так и в лог-файл. За основы брались упомянутые вами системы. И все они так или иначе видоизменились до того состояния, что вы видели в описанных статьях. Описанная модель логирования совсем простая (примитивная, и я с этим согласен) и это тоже не просто так. Чем проще система логирования, тем более читаемый и предсказуемый результат вы получите на выходе (к этому мы пришли не сразу). Мной представлен способ логирования с помощью одной таблицы + 3 процедуры для создания записей в ней, куда же проще. Всё что вы описали оно все работает хорошо на демонстрационных примерах, а в реально действующей БД это не нужно. Опять же это мое личное мнение, но убежден, что в действующей БД при возникновении ошибки нам необходимо уметь:
1) Выявить факт возникновения ошибки максимально быстро для это необходимо знать: место возникновения ошибки; код + текст ошибки; параметры при которых возникла ошибка.
2) Максимально быстро воспроизвести эту ошибку для того, чтобы исправить её. Для того чтобы воспроизвести ошибку у нас есть все данные.
Представленная модель логирования это делает, а нужно ли больше? Это риторический вопрос.
К сожалению, это только мой опыт и моё суждение, но большинство разработчиков БД не станут писать логирование ошибок в своих БД если им об этом не сказать, к сожалению большинство из них не понимает зачем это делать. Комментарии к моим статьям это доказывают.
Если же вам удалось убедить своих коллег вести логирование ошибок в БД с помощью представленных вами SLF4j, log4j и его вариации для других языков/систем, и тд или Logger, то результат логирования с течением времени превращается в «свалку» различных записей. В таких системах лога наверное стоит работать DBA и разработчикам, а как быть тестировщикам и пользователям? В представленном вами «трейсфайле» много «воды», нужна конкретика: что сломалось, где и с какими параметрами. И когда представленными вами системами логирования будут активно пользоваться разработчики + тестировщики + пользователи, то убежден, что рано или поздно эти системы логирования видоизменятся до самой простой формы.
Вы не обязаны понимать, «что тут вообще происходит» [речь идет о плане запроса], но вам нужно уметь получать этот план. Пригодится.
Никогда не понимал зачем в подобных статьях «для начинающих» закидывать абсолютно всё и сразу. Сначала «что такое БД», «как извлечь данные (select)» и в конце «хинты и план запроса»! Зачем? Тема хинтов и плана запроса очень сложные, по хорошему это отдельная добротная статья. Пример джоина таблиц clients и phone в демонстрации «плана запроса» тоже вызывает много вопросов, но повторюсь это можно обсуждать очень долго и наверное о таких вещах (хинты и план запроса) лучше вообще не писать в статьях «для начинающих».
В целом, до абзаца с «хинтами» статья вполне полезна начинающим.
Есть такая поговорка: «Если правило не обязательно к исполнению, то оно не будет работает!». Примерно также можно сказать и к логированию. Если вы логируете не все, а только «в нужных местах», «в важных процедурах» или «в процедурах верхнего уровня», то в момент возникновения очень и очень критичной ошибки вы можете обнаружить, что у вас есть логирование ошибок но нет информации о конкретной ошибке (которая вам так необходима) в таблице лога. И как правило после таких инцидентов весь функционал логирования умирает.
Моя позиция такая, что проще вставить кусок кода в блок exception в момент написания процедуры один раз и навсегда, нежели его не писать или рассуждать о том нужен он или нет. И суть данного метода логирования ошибок состоит в том, чтобы отловить максимально те параметры на которых возникла ошибка, чтобы в дальнейшем использовать их для воспроизведения ошибки на тестовом стенде и быстрого исправления. Но тут уже выбор каждой команды как им вести или вообще не вести логирование ошибок.
На самом деле шаблон такой процедуры есть (часть 2), но что-то мне подсказывает, что он вам не понравится.
Также, прошу обратить внимание на выходные параметры процедуры-шаблона
p_errcode out number
p_errtext out varchar2
обычно на них идет условие дальнейшего выполнения алгоритма, либо его завершения, но в примерах текущей статьи я их не использовал.
Почему? Например, компиляцию нельзя выполнить, если в коде есть синтаксическая ошибка. Это же не расстраивает программиста, а наоборот, помогает.
Мой опыт работы в команде разработчиков говорит мне только о том, что большинство разработчиков (к сожалению) только пишет код, не думая о том как с этим кодом будут работать другие в будущем. Заставлять людей делать что-то «принудительно» не работает, либо работает до тех пор пока есть кому требовать и контролировать выполнение требований. Да, наверное так можно сделать, но я такой метод использовать не стал бы.
Я часто делаю код ревью. При этом предлагаете пересчитывать на глаз количество параметров в заголовке процедуры и в ее хвосте, которые могут быть за сотни строк друг от друга? А параметров может быть штук 10. Или так ПО КАЖДОЙ процедуре?
Да, в каждой процедуре вручную вставлять параметр и это удобно делать когда у вас есть контроль версий (Tortoise, git и прочее). Со временем уже на автомате видишь новый параметр и ниже смотришь его в блоке исключений.
Если вы никогда не использовали данный метод это не значит, что он не работоспособный.
Не надо судить о всей статье, о всей предложенной концепции, об архитектуре БД и архитекторе только по нескольким примерам данной статьи. Это только пример, делайте как хотите. Еще раз говорю, это примеры написанные «на коленке». То, как будет вести себя алгоритм до и после ошибки это уже отдельная история.
Спасибо, видел раньше похожую реализацию (может это и она была). Всегда можно взять готовую реализацию, а можно сделать свою (изобрести очередной велосипед, но зато свой). Мне кажется у такого логера есть плюсы помимо тех, что вы описали это простота. Но есть и минусы и главный минус как мне кажется это то, что такой лог быстро превращается в «славку».
Опять же, все зависит от команды и отношения к логированию. Просто в данной статье я показал один из способов логирования.
Также, наверное необходимо эту статью рассматривать совместно со второй (третьей и четвертой которые в разработке) частью.
Мне понятна ваша позиция, но я с ней не согласен от слова совсем.
Мое мнение такое, что when others then… raise и rollback to savepoint в обработчике ошибок общего назначения — это как раз должно использоваться всегда, а вот отказ от них возможен в редких частных случаях.
За свою практику работы с Oracle я наблюдаю диаметрально противоположную картину — во многих компаниях используется концепция: «если транзакция падает с ошибкой (типа «when others then»), то данную транзакцию завершают полным откатом изменений т.е. либо алгоритм отрабатывает без ошибок и сохраняем результат, либо завершаем алгоритм и не сохраняем вообще ничего».
Такая практика поможет избежать множества сложновылавливаемых ошибок.
Я бы сказал, что все наоборот. Такая практика только усложняет понимание корректности полученных данных. Поясню на примере, у вас есть функция которая рассчитывает процент по кредиту для клиента. Внутри этой функции вызовы множества процедур, которые рассчитывают различные атрибуты, параметры которые необходимы при расчете итогового процента по кредиту. Но вот в одной из процедур возникла неизвестная «when others then» ошибка и что делать тогда? В нашем случае мы уроним весь расчет и залогируем ошибку с параметрами запуска процедуры в которой произошла ошибка. После того, как исправят данную ошибку, то можно будет перезапустить расчет процента для указанного клиента. В вашем же случае, произойдет откат до сохраненной точки, а дальше что? Вы продолжите рассчитывать остальные атрибуты и на основании их посчитаете процент по кредиту? Т.е. у вас есть некий итог работы функции, но вот как понять что он корректный?
Это я все к тому, что способы написания кода бывают разные, у вас свои взгляды и нас свои. Вопросы rollback, raise и savepoint я в статьях не затрагиваю т.к. смысл статей не в этом. Еще раз раз повторюсь, я лишь показываю как можно отловить ошибку с её параметрами в момент её возникновения. Что вы (либо другой читатель) будете делать после возникновения ошибки это дело непосредственно ваше.
Список параметров каждой процедуры есть в системных view. Можно написать функцию проверки наличия всех параметров в тексте пакета/процедуры и запускать эту функцию по триггеру в момент компиляции пакета/процедуры на тестовом или разработческом стенде.
Если я так сделаю на каком-либо проекте, то меня будут вспоминать проклиная и ненавидя… На самом деле это не такая частая проблема, да иногда забывают и ничего не мешает добавить позже, все решается обычным кодревью.
Приведенные примеры показывают как использовать логирование ошибок в момент возникновения самой ошибки (exception), то как будет вести алгоритм далее после передачи управления во внешний блок это уже совсем другая история. Описанные вами примеры использования raise и savepoint необходимо использовать в конкретных ситуациях, описание которых это отдельная тема для разговора.
Вероятность 50/50, что программист при добавлении параметра в процедуру забудет добавить его в строку p_paramvalue и в самый неподходящий момент выяснится, что его значение не залогировано, а оно-то как раз и необходимо.
Да, есть такая вероятность и даже сам с этим сталкивался. А какая может быть альтернатива? Пока что остается одно — вручную вносить список параметров в p_paramvalue.
Два года я работал в одной конторе на позиции джуна, но роста там особо не было. Надеялся, что скоро закончу магистратуру, и меня повысят до милда. Но этого не произошло.
Наверное, открою вам маленькую тайну, но не бывает такой «медальки» под названием «junior developer», «middle developer» и т.д., которую получают за выслугу лет. Более того, рост зарплаты и карьерный рост никак не зависит от отработанных лет в конкретной компании. К сожалению, я в своей практике встречал 40 летних сотрудников тех.поддержки и знаю лично разработчиков в 25 лет работающих в FB. Всё зависит от амбиций и желания развиваться. Могу лишь посоветовать не зацикливаться на этих эфемерных статусах «junior», «middle» и просто развиваться как разработчик повышая свои коммуникативные, технические навыки.
На мой взгляд в статье можно добавить ещё один шаг:
Пятый шаг. Введение стандартов разработки. После того, как вам удалось привести код в порядок необходимо «закрепить» наработки в виде каких-либо внутренних правил, стандартов для разработчиков. Если у вас уже имеется успешный опыт улучшения легаси конкретно в вашей команде, а в других командах продолжают работать «по старинке», то рано или поздно в коде появятся всё те же проблемы с которыми вы успешно поборолись. Другими словами, если конкретно вам удалось вытянуть проект и далее поддерживать его, то все это развалится после вашего ухода (повышение или переход в другую компанию).
Автору и его команде пожелаю только удачи и успехов в этом нелегком деле. Если честно, то я даже не знал что у нас частная компания (помимо государственных компаний) занимается подобными разработками.
Вопрос автору:
В частности, под техзадание S7 прекрасно подходит ещё «королёвский» РД-108, который сейчас летает на второй ступени ракеты «Союз-2».
А вы не боитесь, что использование двигателя РД-108 наложит на проект некие ограничения связанные с гос.тайной? И привлечение иностранных специалистов по этой причине может стать проблемой. Спасибо.
Ну видимо уже отработана стратегия «закрытия занавеса» — создать кучу абсурдных, невыполнимых условий. По началу штрафовать, а в случае отказа иностранной компании выполнять локальные нормативные акты (только для одной нашей страны) блокировать их. А потом спокойно сказать, что это всё законы для защиты прав граждан. А если кому-то что-то не нравится, то можете обратиться в «наши» суды.
Как говорил кто-то (не будем показывать пальцем): «Курочка по зёрнышку клюёт...»
Грустно.
У любого проекта (продукта) изначально есть бизнес описание (ТЗ по нашему). Когда программист пишет код, то он "скармливает" свой код написанный по определённому алгоритму, стандарту, синтаксису и т.д. компилятору. Код необходимо написать с учетом бизнес требований от заказчика.
Если ИИ научится "писать код сам", то по большому счету возникает задача написать бизнес требование для компилятора ИИ так, чтобы это превратилось в рабочий проект. И это тоже будет своего рода "программирование", да, для этого будут нудны другие знания, умения.
Мне кажется, что если так произойдет, то большая часть программистов превратится в разработчиков-аналитиков, которые будут писать требования для ИИ, а уже он будет генерировать продукт.
Тут наверное все гораздо проще: есть определенная цена на товар (плюс минус скидка) для всех клиентов (по тексту статьи это постоянные клиенты), для новых клиентов на эту цену дают скидку так сказать привлечь новых клиентов, вот все. Т.е. цену занижают только для небольшой категории (численности) новых клиентов.
А что потом делать с этой "АЭС на Марсе" спустя много лет, когда выйдет срок эксплуатации? И это мы не говорим о том, что делать если произойдет какая-нибудь авария.
Когда весь мир разрабатывает альтернативные источники энергии куда проще паразитировать на "ядерной" технологии. Загадили эту планету, давайте следующую ....
Яркий пример, который наблюдаю прямо сейчас, это когда компания переходит из формата работы «по Техническому заданию» с примерным сроком реализации 2-4 месяца на формат «Agile», «Kanban» и т.д. когда вся задача оценивается не больше спринта (1-2 недели). Разработчики, которые всю жизнь работали по ТЗ воспринимают все эти нововведения «в штыки» и чаще всего, компании проще обучить молодого сотрудника новым требованиям чем переучивать «возрастного».
Если будет время дописать третью статью о мониторинге событий на основе описанных предыдущих статьях и тогда, я надеюсь, может вам станет понятнее вся суть «новаторства».
Я стараюсь отвечать на каждое сообщение и излагать свою точку зрения, да она может не совпадать с вашей (или другой). Суть всех статей не в том, чтобы выдать на всеобщее обозрение готовый продукт, который «скачал — установил — и в путь». Так не бывает, каждый проект, команда разработчиков, тимлиды, компания и т.д. все в совокупности дает индивидуальную реализацию. Иногда это качественный лог ошибок с многоуровневым логированием, а иногда его вовсе нет т.к. тимлид «не понимает зачем ему хранить тексты ошибок».
По мере развития своего видения модели логирования событий и пришел к выводу, чтоб «рабочая» модель логирования это максимально простой в использовании функционал как для разработчиков, так и для пользователей (тестировщиков). Именно его я и описал в статьях. В текущей модели есть проблемы и я их стараюсь учитывать «от проекта к проекту» и если однажды появится возможность написать новое логирование «с нуля» на каком-нибудь проекте, то он будет более совершенный чем предыдущие версии. Помимо простого функционала необходимо устанавливать определенные правила логирования ошибок (их я тоже постарался раскрыть). Говоря по простому, не важно каким логированием вы пользуетесь важно то, как его будут использовать в работе ваши коллеги.
Приведенные вами примеры логирования хорошо и удобны при точечном устранении ошибки. Использовать это в повседневной работе трудно. Лично я сомневаюсь, что кто-нибудь из читающих эту статью сможет реализовать описанное вами логирование в своем проекте.
А так в целом спасибо за советы.
Могу лишь вас заверить, что представленная модель логирования это результат написания более 5 БД с активным логированием ошибок. Изначально, в нашем логировании были уровни детализации, было логирование как в таблицу так и в лог-файл. За основы брались упомянутые вами системы. И все они так или иначе видоизменились до того состояния, что вы видели в описанных статьях. Описанная модель логирования совсем простая (примитивная, и я с этим согласен) и это тоже не просто так. Чем проще система логирования, тем более читаемый и предсказуемый результат вы получите на выходе (к этому мы пришли не сразу). Мной представлен способ логирования с помощью одной таблицы + 3 процедуры для создания записей в ней, куда же проще. Всё что вы описали оно все работает хорошо на демонстрационных примерах, а в реально действующей БД это не нужно. Опять же это мое личное мнение, но убежден, что в действующей БД при возникновении ошибки нам необходимо уметь:
1) Выявить факт возникновения ошибки максимально быстро для это необходимо знать: место возникновения ошибки; код + текст ошибки; параметры при которых возникла ошибка.
2) Максимально быстро воспроизвести эту ошибку для того, чтобы исправить её. Для того чтобы воспроизвести ошибку у нас есть все данные.
Представленная модель логирования это делает, а нужно ли больше? Это риторический вопрос.
К сожалению, это только мой опыт и моё суждение, но большинство разработчиков БД не станут писать логирование ошибок в своих БД если им об этом не сказать, к сожалению большинство из них не понимает зачем это делать. Комментарии к моим статьям это доказывают.
Если же вам удалось убедить своих коллег вести логирование ошибок в БД с помощью представленных вами SLF4j, log4j и его вариации для других языков/систем, и тд или Logger, то результат логирования с течением времени превращается в «свалку» различных записей. В таких системах лога наверное стоит работать DBA и разработчикам, а как быть тестировщикам и пользователям? В представленном вами «трейсфайле» много «воды», нужна конкретика: что сломалось, где и с какими параметрами. И когда представленными вами системами логирования будут активно пользоваться разработчики + тестировщики + пользователи, то убежден, что рано или поздно эти системы логирования видоизменятся до самой простой формы.
Никогда не понимал зачем в подобных статьях «для начинающих» закидывать абсолютно всё и сразу. Сначала «что такое БД», «как извлечь данные (select)» и в конце «хинты и план запроса»! Зачем? Тема хинтов и плана запроса очень сложные, по хорошему это отдельная добротная статья. Пример джоина таблиц clients и phone в демонстрации «плана запроса» тоже вызывает много вопросов, но повторюсь это можно обсуждать очень долго и наверное о таких вещах (хинты и план запроса) лучше вообще не писать в статьях «для начинающих».
В целом, до абзаца с «хинтами» статья вполне полезна начинающим.
p_errcode и p_errtext.
Моя позиция такая, что проще вставить кусок кода в блок exception в момент написания процедуры один раз и навсегда, нежели его не писать или рассуждать о том нужен он или нет. И суть данного метода логирования ошибок состоит в том, чтобы отловить максимально те параметры на которых возникла ошибка, чтобы в дальнейшем использовать их для воспроизведения ошибки на тестовом стенде и быстрого исправления. Но тут уже выбор каждой команды как им вести или вообще не вести логирование ошибок.
Также, прошу обратить внимание на выходные параметры процедуры-шаблона
p_errcode out number
p_errtext out varchar2
обычно на них идет условие дальнейшего выполнения алгоритма, либо его завершения, но в примерах текущей статьи я их не использовал.
Мой опыт работы в команде разработчиков говорит мне только о том, что большинство разработчиков (к сожалению) только пишет код, не думая о том как с этим кодом будут работать другие в будущем. Заставлять людей делать что-то «принудительно» не работает, либо работает до тех пор пока есть кому требовать и контролировать выполнение требований. Да, наверное так можно сделать, но я такой метод использовать не стал бы.
Да, в каждой процедуре вручную вставлять параметр и это удобно делать когда у вас есть контроль версий (Tortoise, git и прочее). Со временем уже на автомате видишь новый параметр и ниже смотришь его в блоке исключений.
Если вы никогда не использовали данный метод это не значит, что он не работоспособный.
изобрести очередной велосипед, но зато свой). Мне кажется у такого логера есть плюсы помимо тех, что вы описали это простота. Но есть и минусы и главный минус как мне кажется это то, что такой лог быстро превращается в «славку».Опять же, все зависит от команды и отношения к логированию. Просто в данной статье я показал один из способов логирования.
Также, наверное необходимо эту статью рассматривать совместно со второй (третьей и четвертой которые в разработке) частью.
За свою практику работы с Oracle я наблюдаю диаметрально противоположную картину — во многих компаниях используется концепция: «если транзакция падает с ошибкой (типа «when others then»), то данную транзакцию завершают полным откатом изменений т.е. либо алгоритм отрабатывает без ошибок и сохраняем результат, либо завершаем алгоритм и не сохраняем вообще ничего».
Я бы сказал, что все наоборот. Такая практика только усложняет понимание корректности полученных данных. Поясню на примере, у вас есть функция которая рассчитывает процент по кредиту для клиента. Внутри этой функции вызовы множества процедур, которые рассчитывают различные атрибуты, параметры которые необходимы при расчете итогового процента по кредиту. Но вот в одной из процедур возникла неизвестная «when others then» ошибка и что делать тогда? В нашем случае мы уроним весь расчет и залогируем ошибку с параметрами запуска процедуры в которой произошла ошибка. После того, как исправят данную ошибку, то можно будет перезапустить расчет процента для указанного клиента. В вашем же случае, произойдет откат до сохраненной точки, а дальше что? Вы продолжите рассчитывать остальные атрибуты и на основании их посчитаете процент по кредиту? Т.е. у вас есть некий итог работы функции, но вот как понять что он корректный?
Это я все к тому, что способы написания кода бывают разные, у вас свои взгляды и нас свои. Вопросы rollback, raise и savepoint я в статьях не затрагиваю т.к. смысл статей не в этом. Еще раз раз повторюсь, я лишь показываю как можно отловить ошибку с её параметрами в момент её возникновения. Что вы (либо другой читатель) будете делать после возникновения ошибки это дело непосредственно ваше.
Если я так сделаю на каком-либо проекте, то меня будут вспоминать проклиная и ненавидя… На самом деле это не такая частая проблема, да иногда забывают и ничего не мешает добавить позже, все решается обычным кодревью.
Да, есть такая вероятность и даже сам с этим сталкивался. А какая может быть альтернатива? Пока что остается одно — вручную вносить список параметров в p_paramvalue.
Наверное, открою вам маленькую тайну, но не бывает такой «медальки» под названием «junior developer», «middle developer» и т.д., которую получают за выслугу лет. Более того, рост зарплаты и карьерный рост никак не зависит от отработанных лет в конкретной компании. К сожалению, я в своей практике встречал 40 летних сотрудников тех.поддержки и знаю лично разработчиков в 25 лет работающих в FB. Всё зависит от амбиций и желания развиваться. Могу лишь посоветовать не зацикливаться на этих эфемерных статусах «junior», «middle» и просто развиваться как разработчик повышая свои коммуникативные, технические навыки.
Пятый шаг. Введение стандартов разработки. После того, как вам удалось привести код в порядок необходимо «закрепить» наработки в виде каких-либо внутренних правил, стандартов для разработчиков. Если у вас уже имеется успешный опыт улучшения легаси конкретно в вашей команде, а в других командах продолжают работать «по старинке», то рано или поздно в коде появятся всё те же проблемы с которыми вы успешно поборолись. Другими словами, если конкретно вам удалось вытянуть проект и далее поддерживать его, то все это развалится после вашего ухода (повышение или переход в другую компанию).
Вопрос автору:
А вы не боитесь, что использование двигателя РД-108 наложит на проект некие ограничения связанные с гос.тайной? И привлечение иностранных специалистов по этой причине может стать проблемой. Спасибо.
Как говорил кто-то (не будем показывать пальцем): «Курочка по зёрнышку клюёт...»
Грустно.