Это надо месяцами учить разные темы. Это надо тренироваться - решать задачи почти каждый день. Это концентрация на одной теме месяцами а то и годами.
На какой "одной теме"? Разработке? Так любой разработчик на этой теме всю жизнь сконцентрирован.
Еще раз. Олимпиадник концентрируется на короткое время на небольшой изолированной задаче. Бизнес-разработчик концентрируется длительное время на большой задаче и должен держать в голове десятки тысяч строк кода. Плюс смотреть шире чем написано в ТЗ, думать об интеграции. Плюс еще в бизнес-логику общую вникать (которая, опять же, в ТЗ не прописана полностью).
В данном случае это что-то в таком стиле: разбиваем каждый адрес на слова(уже после нормализации), и строим для каждого слова сортированный список клиентов, у которых данное слово входит в адрес.
Ну оно сразу так и делалось. Это и есть "витрина". Три таблицы
ID клиента ID адреса в витрине
ID элемента (слова) Элемент (слово)
ID адреса в витрине ID элемента (слова) Номер слова в адресе
Это для адресов клиентов (там чуть сложнее на самом деле т.к. есть разделение на типы клиентов - ФЛ/ЮЛ и типы адресов - 5 типов для ФЛ и 3 типа для ЮЛ)
Для адресов субъектов чуть проще, там нет нужды в витрине, там есть только "ключевое слово" - элемент адреса субъекта который реже всего встречается в витрине адресов клиентов (в таблице связей адрес-элемент). Это нужно для повышения селективности первичной выборки - она идет как раз по ключевому слову.
Дальше можно все сделать одним скулевым запросом, но работает очень долго. Сложнее, но быстрее писать это используя прямой доступ к БД по индексам.
Берем ключевое слово адреса субъекта и находим его ID в витрине (таблица элементов адреса) адресов клиентов. Если его там нет - все, совпадений точно не будет.
Если ID есть - составляем массив уникальных ID остальных элементов адреса субъекта.
По ID ключевого слова делаем первичную выборку - составляем массив ID адресов клиентов в которые входит ключевое слово (по таблице связей адрес-элемент). В реальности там может быть до 500-600 тысяч элементов.
Дальше идем по массиву ID элементов адреса субъекта и для каждого проходим по массиву ID адресов клиентов проверяя наличие записи ID адреса клиента - ID элемента адреса субъекта. Вот это делается без чтения самой записи, просто проверкой ее наличия в индексе - это намного быстрее. Если записи в индексе нет - удаляем элемент из массива (т.е. на каждом "обороте" внешнего цикла внутренний становится короче).
На выходе в массиве остаются только те ID адресов клиентов куда входят все элементы адреса субъекта.
Но дело в том, что этот алгоритм в реализации сложнее чем один скулевый запрос. И в том, что для режима работа по дельте (когда совпадения ищутся не для всех, а только для тех, кто менялся за прошедшие сутки) время работы скулевого запроса удовлетворяет заказчика (укладывается в заданное временное окно). Поэтому вот так... Дельты обрабатываются одним алгоритмом, полная выборка - другим (это две разные задачи).
А во-вторых, не вижу причин, почему олимпиадники должны в среднем (или обязательно) плохо справляться с задачами разработки. Ну кроме истории с ресёрчем, про которую говорили в другой ветке — но она мешает не только олимпиадникам.
Моя мысль в другом. Олимпиада и бизнес суть разные вещи. Разные подходы. И то, что человек блестящий олимпиадник, практически никаких преимуществ в бизнесе ему не дает. Как и наоборот. Отличный бизнесовый разработчик не будет иметь никаких преимуществ в олимпиаде.
Разница прежде всего в том, что олимпиадник всегда сконцентрирован на одной конкретной задаче. А бизнесовый разработчик всегда рассматривает задачу как часть большой системы (вот у нас только на центральном сервере несколько десятков тысяч программных объектов так или иначе между собой взаимодействующих, пара десятков тысяч таблиц с которыми мы работаем, и это не считая интеграций с внешними системами через веб-сервисы и очереди). Поэтому получая ТЗ на новый модуль всегда надо понимать с какими объемами данных он будет работать, какая будет плотность вызовов, какие типичные сценарии использования предполагаются - все это влияет на выбор деталей реализации. И все это, как правило, выходит за скобки постановки задачи - это то, о чем хороший разработчик должен думать сам прежде чем хвататься за клавиатуру.
Как вы себе представляеете "индекс" который будет определять вхождение набора слов в фразу без учета дублированя этих слов и порядка их следования во фразе. Т.е. условно говоря фразы
"один два три три четыре" и "четыре два один два"
являются совпадением.
А
"один два три три четыре" и "четыре два один два пять"
не являются.
На самом деле, это решается через "витрины". Где все адреса хранятся в разбитом на слова виде. Это отдельная задача, которую надо решить до того как начнете решать основную. Т.е. надо сделать таблицы витрины (три штуки) + написать модуль ведения - раскладка по таблицам (добавление/удаление/изменение).
Дальше надо написать модуль поддержки этой витрины - если произошли какие-то изменения в таблице адресов, то витрина должна автоматически сразу актуализироваться. Это еще одна задача.
В этом и отличие - на олимпиаде вы решаете отдельную задачу, которая ни к чему не привязана, в бизнесе вы интегрируете новый функционал в большую работающую систему. И должны заботится о том, чтобы он не нарушил работу системы в целом.
Именно так - навыки спринта в марафоне бесполезны. Там не нужна быстрая мышечная реакция и взрывная сила. Зато там нужна выносливость и умение распределять усилия, нужна стратегия.
Я в детстве немного конькобежным занимался. И знаете что больше всего устает на длинных дистанциях (10км - 25 кругов)? Не ноги. Спина.
Вообще, на длинных дистанциях голова устает быстрее (от монотонности) чем тело. В этом плане спортивное ориентирование бегать (а там 10-15км набегать запросто) проще чем ту же дистанцию кругами по стадиону намотать - там голова постоянно занята.
В бизнес-разработке это выгорание. Если приходится долго заниматься однотипными рутинными задачами. Приходится и с этим бороться. И, повторюсь опять, попадаются хорошие олимпиадники, которые на это органически не способны.
Общее тут только физическая форма. Применительно к разработке - "алгоритмы и структуры данных". Но это должен знать любой приличный разработчик, не только олимпиадник.
Я всего лишь говорил о том, что в бизнесовой разработке много такого, чего нет в олимпиадной. И, повторюсь, я встречал одного блестящего олимпиадника, который не мог работать в бизнесе. Ну не получалось у него месяцами держать концентрацию на одной большой задаче - ему просто было это скучно, много рутины.
Даже когда вы ее декомпозируете на много мелких (а это происходит всегда - все программирование есть декомпозиция большого невозможного на много мелких реализуемых), это будет много тесно взаимосвязанных между собой задач - решая первую вам уже надо в голове держать все что будет решаться потом.
Плюс когда ваша задаче есть развитие и дополнение большой и давно работающей системы, вам приходится заботиться о корректной интеграции - чтобы не дай бог не порушить то, что уже работает.
И коль было угодно сравнивать спринтера-олимпиадника с курьером-бизнес-разработчиком, то извольте. У олимпиадника есть старт и финиш и задача быстрее от старта до финиша добежать. А у курьера есть список заказов. Ему еще надо маршрут построить, решить "задачу коммивояжера" прежде чем приступить к выполнению собственно основной задачи.
С этим навыком и длинные задачи отлично разбиваются на маленькие и уже без разницы, проект на 3 года или на месяц.
Вообще-то разница есть. И в бизнесе логика бывает достаточно сложной. А на нее еще накладываются требования по эффективности... Причем, в заранее не можете сказать хватит вам простого решения или нет. Может быть хватит (время выполнения задачи укладывается в отведенное временное окно и нагрузка на процессор не превышает предельных для одного задания величин). А может и нет и надо начинать все сначала и придумывать что-то иное.
Или вот такое. Чтобы разработать API надо сначала провести некий набор тестов чтобы понять насколько оно будет лучше уже существующего. Потом перерыть огромное количество документации. Потом спроектировать API исходя из типичных предполагаемых сценариев его использования. И только потом уже садиться писать.
Почему вы думаете, что человек, который может удержать в голове десятки структур данных, математических моделей и алгоритмов нужных для решения задач, не сможет удержать в голове "сущности и взаимосвязи между ними". Это один и тот же отлично развиваемый олимпиадами навык.
Ну хотя бы потому что все вами перечисленное тоже нужно держать в голове. Плюс понимание (хотя бы базовое) сути бизнес-процессов. Плюс набор нефункциональных требований. Плюс набор типичных сценариев использования того что вы пишете (без этого удобный контракт вам не создать). Это очень большое количество разнородной информации.
И работа в индустрии - не марафон
Увы, но марафон. У меня была задача, которая (в целом) длилась пять лет. Там было и проектирование БД (десяток таблиц, несколько десятков индексов) и огромное количество кода только на первом этапе и потом еще огромное количество доработок уже существующего кода для интеграции всего этого в систему. И это все на фоне того что попутно приходилось и другие задачи тоже делать. Ссылка выше (про адреса) - это лишь один маленький кусочек всего этого добра (там, кстати, решение пришло чуть не во сне - утром проснулся и вдруг понял как надо, т.е. задача все равно крутится где-то в фоне, так что это именно марафон).
Я не говорю о перекладывании джйсонов - те задачи можно вообще не думая решать, но у меня таких не бывает.
И, кстати, марафонец в среднем всегда бежит медленнее спринтера. Но там нужна выносливость а не взрывная сила.
В контекст свой вы не "загружаете" весь большой проект, а лишь маленькую релевантную часть
Увы, но нет. Приходится держать в голове именно весть проект, иначе потом столкнетесь с тем, что чтобы очередной кусочек пазла лег на свое место, надо возвращаться на пару-тройку месяцев назад и править что-то там. Что тянет за собой правки на всем протяжении того, что уже сделано.
Если я не продумал при проектировании БД ее структуру до конца (что зачем и с чем связано и что мне понадобится еще), то на определенном этапе обязательно начнется лютый костылинг.
Уж поверьте человеку, который в разработке (профессионально) с 91-го года.
Спортивное и промышленное программирование родственны ровно так же, как родственны спринт и марафон.
10 задач на 5 часов - это короткие задачи. А в бизнесе часто приходится решать задачи длинные, от недели и до месяца. Совершенно иной объем кода, сущностей и взаимосвязей между ними, которые нужно удержать в голове. Да и объем бизнес-логики и разных условий там может быть несравнимо больше.
Плюс, если речь идет о какой-то действительно большой системе из огромного количества модулей, будет еще длинный список нефункциональных требований. Плюс надо постоянно думать про интеграцию в систему, соблюдение общей архитектуры и т.д. и т.п.
Ну и не забывать что потом кому-то (может вам а может и нет) через год-два-три (а то и более) придется это все дорабатывать потому что что-то где-то поменяется в бизнес-процессах (например). И этот кто-то (а может и вы через три года) должен ваш код легко понять и быстро понять где и что надо поменять в соответствии с новыми требованиями.
Я далек от того, чтобы считать "олимпиадников" непригодными к бизнес-разработке (хотя был случай именно такого - блестящий олимпиадник, но бизнес не тянул - ему просто становилось скучно и наступало "временное выгорание"), но это, все-таки, "две большие разницы...
В спортивном программировании: ограничения по памяти, производительности, времени на решение задачи.
В "бизнес" программировании: трех ограничений выше в 99% случаев нет. Но твой код должен быть поддерживаемым и расширяемым.
Не соглашусь. В бизнесе очень часто эффективность не менее важна чем поддерживаемость. И тут приходится искать баланс и решения где одно не вступает в противоречие с другим.
Скорее всего это функция деперсонализвации клиентов. Точнее, очень мала ее часть (т.к. кроме ФОИ у клиентов хранится еще огромная куча всяких данных и все они должны быть деперсонализированы.
Нужно все это при пересоздании тестовых юнитов с боевого. Суть в том, что берется какая-то часть реальных клиентов с боя, деперсоналилируется и этом всем заполняются тестовые юниты.
Это специфический для платформы IBM i (AS/400) язык RPG. Он не то чтобы "встроен в БД" - на этой платформе БД (DB2) является частью ОС ну и языки освновные (С/С++, RPG, COBOL, CL) тоже "встроены" (компилаторы являются частью ОС) в систему.
Язык типа COBOL по назначению - основное в нем работа с БД и коммерческие вычисления.
И да, в синтаксисе есть "привкус" PL-I который IBM одно время активно пыталась развивать. В виде всех этих dcl-... в объявлениях.
Кстати, там нет ожидания ответа. Там именно отправлен ответ отмены операции автоматом. "A cancel reply to an inquiry message was received."
Кабы оно ждало ответа, то задание висело бы в ожидании, а не вывалило бы ошибку.
Вот, не поленился джоблог поднять:
alter table y2ku.tstidxpf drop column tidxclc;
DIAGNOSTIC Изменение в поле TIDXCLC может привести к потере данных.
DIAGNOSTIC Change of file TSTIDXPF in Y2KU canceled.
ESCAPE Файл TSTIDXPF в библиотеке Y2KU не изменен.
DIAGNOSTIC Обработка оператора SQL завершена. Код причины: 10.
И удаление поля из середины записи небезопасная операция. В больших БД с большим количеством интеграций я бы даже сказал недопустимая. Потому что обвал прода в mission-critical системе это уже практически катастрофа.
И мне не кажется что нетипичной такого поведения для БД это хорошо.
Момент номер раз. Удаление поля из БД. Не знаю что там за БД, но, работаю с "дибитухой" (DB2) уже 9 лет и вот там поле из существующей таблицы удалить невозможно. Оно просто не даст это сделать. Выдаст ошибку. Да что там удалить, там не то что тип поля, описание его уже не поменять... Единственное допустимое изменение в таблице - добавление нового поля в конец записи. Все. Остальное только полным пересозданием таблицы с потерей данных (хочется сохранить данные? делай скрипт для миграции, требуется отдельное согласование т.к. мигрировать несколько десятков а то и сотен миллионов записей такое себе...)
Момент номер два. Разделение зон ответственности. БД достаточно большая - несколько десятков тысяч таблиц. И она разделена на "зоны ответственности" разных команд. Так вот, доступ в "чужие" таблицы только через ретриверы и модули внешнего ввода. Никак иначе.
Момент номер три. Тестирование. Первый этап - песочница. Еженедельно пересоздаваемая копия компонентного юнита. Поставка туда разворачивается руками (системой сборки) из гита. Дальше - компонентный юнит. Тут уже установка через devops сервисы - доставка должна быть собрана и размещена в artifactory. Потом бизнес-юнит (бизнес-тест). Далее нагрузочное тестирование на копии промсреды и техтест на прелайве (тоже копия прома). И только после этого внедрение в пром. При внедрении в пром обязательно должен быть прописан план отката. На случай если что. Установками в бизнес-юнит и выше занимается дежурная смена по заявке. Т.е. в пром поставка попадает только после прохождения всех этапов тестирования - компонентного, бизнес, нагрузка, интеграция.
Поскольку всегда с поставкой идет план отката, то внедрение в пятницу нормальное дело. Если, не дай бог, что - поставка просто откатывается силами дежурной смены и все. Единственный мораторий на внедрения (за исключением хотфиксов) - период пиковых нагрузок с середины декабря и до конца новогодних праздников.
Абсолютно согласен.
Я не считаю что олимпиадный опыт влияет собственно на качество кода - это как раз быстро дрессируется в бизнесе.
Но вот что именно олимпиадные навыки мало что дают для бизнеса - это да.
На какой "одной теме"? Разработке? Так любой разработчик на этой теме всю жизнь сконцентрирован.
Еще раз. Олимпиадник концентрируется на короткое время на небольшой изолированной задаче. Бизнес-разработчик концентрируется длительное время на большой задаче и должен держать в голове десятки тысяч строк кода. Плюс смотреть шире чем написано в ТЗ, думать об интеграции. Плюс еще в бизнес-логику общую вникать (которая, опять же, в ТЗ не прописана полностью).
Совершенно нет.
Вот именно это я и имел ввиду. Успехи на олимпиадах для бизнеса не дают ничего.
Ага. Только для бизнеса бесполезный. Равно как, например, призовые места в соревнованиях по тяжелой атлетике. Или умение разгадывать кроссворды.
Вот именно.
Ну оно сразу так и делалось. Это и есть "витрина". Три таблицы
ID клиента
ID адреса в витрине
ID элемента (слова)
Элемент (слово)
ID адреса в витрине
ID элемента (слова)
Номер слова в адресе
Это для адресов клиентов (там чуть сложнее на самом деле т.к. есть разделение на типы клиентов - ФЛ/ЮЛ и типы адресов - 5 типов для ФЛ и 3 типа для ЮЛ)
Для адресов субъектов чуть проще, там нет нужды в витрине, там есть только "ключевое слово" - элемент адреса субъекта который реже всего встречается в витрине адресов клиентов (в таблице связей адрес-элемент). Это нужно для повышения селективности первичной выборки - она идет как раз по ключевому слову.
Дальше можно все сделать одним скулевым запросом, но работает очень долго. Сложнее, но быстрее писать это используя прямой доступ к БД по индексам.
Берем ключевое слово адреса субъекта и находим его ID в витрине (таблица элементов адреса) адресов клиентов. Если его там нет - все, совпадений точно не будет.
Если ID есть - составляем массив уникальных ID остальных элементов адреса субъекта.
По ID ключевого слова делаем первичную выборку - составляем массив ID адресов клиентов в которые входит ключевое слово (по таблице связей адрес-элемент). В реальности там может быть до 500-600 тысяч элементов.
Дальше идем по массиву ID элементов адреса субъекта и для каждого проходим по массиву ID адресов клиентов проверяя наличие записи ID адреса клиента - ID элемента адреса субъекта. Вот это делается без чтения самой записи, просто проверкой ее наличия в индексе - это намного быстрее. Если записи в индексе нет - удаляем элемент из массива (т.е. на каждом "обороте" внешнего цикла внутренний становится короче).
На выходе в массиве остаются только те ID адресов клиентов куда входят все элементы адреса субъекта.
Но дело в том, что этот алгоритм в реализации сложнее чем один скулевый запрос. И в том, что для режима работа по дельте (когда совпадения ищутся не для всех, а только для тех, кто менялся за прошедшие сутки) время работы скулевого запроса удовлетворяет заказчика (укладывается в заданное временное окно). Поэтому вот так... Дельты обрабатываются одним алгоритмом, полная выборка - другим (это две разные задачи).
Моя мысль в другом. Олимпиада и бизнес суть разные вещи. Разные подходы. И то, что человек блестящий олимпиадник, практически никаких преимуществ в бизнесе ему не дает. Как и наоборот. Отличный бизнесовый разработчик не будет иметь никаких преимуществ в олимпиаде.
Разница прежде всего в том, что олимпиадник всегда сконцентрирован на одной конкретной задаче. А бизнесовый разработчик всегда рассматривает задачу как часть большой системы (вот у нас только на центральном сервере несколько десятков тысяч программных объектов так или иначе между собой взаимодействующих, пара десятков тысяч таблиц с которыми мы работаем, и это не считая интеграций с внешними системами через веб-сервисы и очереди). Поэтому получая ТЗ на новый модуль всегда надо понимать с какими объемами данных он будет работать, какая будет плотность вызовов, какие типичные сценарии использования предполагаются - все это влияет на выбор деталей реализации. И все это, как правило, выходит за скобки постановки задачи - это то, о чем хороший разработчик должен думать сам прежде чем хвататься за клавиатуру.
Я про то, что неприятие рутины для олимпиады не проблема. Там ее нет. В отличии от бизнесовой разработки.
Все к тому, что самый блестящий олимпиадник в бизнесе может хорошо себя показать, а может и наоборот. Потому что это очень разные вещи.
Как вы себе представляеете "индекс" который будет определять вхождение набора слов в фразу без учета дублированя этих слов и порядка их следования во фразе. Т.е. условно говоря фразы
"один два три три четыре" и "четыре два один два"
являются совпадением.
А
"один два три три четыре" и "четыре два один два пять"
не являются.
На самом деле, это решается через "витрины". Где все адреса хранятся в разбитом на слова виде. Это отдельная задача, которую надо решить до того как начнете решать основную. Т.е. надо сделать таблицы витрины (три штуки) + написать модуль ведения - раскладка по таблицам (добавление/удаление/изменение).
Дальше надо написать модуль поддержки этой витрины - если произошли какие-то изменения в таблице адресов, то витрина должна автоматически сразу актуализироваться. Это еще одна задача.
В этом и отличие - на олимпиаде вы решаете отдельную задачу, которая ни к чему не привязана, в бизнесе вы интегрируете новый функционал в большую работающую систему. И должны заботится о том, чтобы он не нарушил работу системы в целом.
Напрямую с олимпиадами не связано, конечно. Но. Олимпиаднику это не мешает, а продуктовому разработчику очень.
Именно так - навыки спринта в марафоне бесполезны. Там не нужна быстрая мышечная реакция и взрывная сила. Зато там нужна выносливость и умение распределять усилия, нужна стратегия.
Я в детстве немного конькобежным занимался. И знаете что больше всего устает на длинных дистанциях (10км - 25 кругов)? Не ноги. Спина.
Вообще, на длинных дистанциях голова устает быстрее (от монотонности) чем тело. В этом плане спортивное ориентирование бегать (а там 10-15км набегать запросто) проще чем ту же дистанцию кругами по стадиону намотать - там голова постоянно занята.
В бизнес-разработке это выгорание. Если приходится долго заниматься однотипными рутинными задачами. Приходится и с этим бороться. И, повторюсь опять, попадаются хорошие олимпиадники, которые на это органически не способны.
Общее тут только физическая форма. Применительно к разработке - "алгоритмы и структуры данных". Но это должен знать любой приличный разработчик, не только олимпиадник.
Все верно.
Я всего лишь говорил о том, что в бизнесовой разработке много такого, чего нет в олимпиадной. И, повторюсь, я встречал одного блестящего олимпиадника, который не мог работать в бизнесе. Ну не получалось у него месяцами держать концентрацию на одной большой задаче - ему просто было это скучно, много рутины.
Даже когда вы ее декомпозируете на много мелких (а это происходит всегда - все программирование есть декомпозиция большого невозможного на много мелких реализуемых), это будет много тесно взаимосвязанных между собой задач - решая первую вам уже надо в голове держать все что будет решаться потом.
Плюс когда ваша задаче есть развитие и дополнение большой и давно работающей системы, вам приходится заботиться о корректной интеграции - чтобы не дай бог не порушить то, что уже работает.
И коль было угодно сравнивать спринтера-олимпиадника с курьером-бизнес-разработчиком, то извольте. У олимпиадника есть старт и финиш и задача быстрее от старта до финиша добежать. А у курьера есть список заказов. Ему еще надо маршрут построить, решить "задачу коммивояжера" прежде чем приступить к выполнению собственно основной задачи.
Вообще-то разница есть. И в бизнесе логика бывает достаточно сложной. А на нее еще накладываются требования по эффективности... Причем, в заранее не можете сказать хватит вам простого решения или нет. Может быть хватит (время выполнения задачи укладывается в отведенное временное окно и нагрузка на процессор не превышает предельных для одного задания величин). А может и нет и надо начинать все сначала и придумывать что-то иное.
Или вот такое. Чтобы разработать API надо сначала провести некий набор тестов чтобы понять насколько оно будет лучше уже существующего. Потом перерыть огромное количество документации. Потом спроектировать API исходя из типичных предполагаемых сценариев его использования. И только потом уже садиться писать.
Ну хотя бы потому что все вами перечисленное тоже нужно держать в голове. Плюс понимание (хотя бы базовое) сути бизнес-процессов. Плюс набор нефункциональных требований. Плюс набор типичных сценариев использования того что вы пишете (без этого удобный контракт вам не создать). Это очень большое количество разнородной информации.
Увы, но марафон. У меня была задача, которая (в целом) длилась пять лет. Там было и проектирование БД (десяток таблиц, несколько десятков индексов) и огромное количество кода только на первом этапе и потом еще огромное количество доработок уже существующего кода для интеграции всего этого в систему. И это все на фоне того что попутно приходилось и другие задачи тоже делать. Ссылка выше (про адреса) - это лишь один маленький кусочек всего этого добра (там, кстати, решение пришло чуть не во сне - утром проснулся и вдруг понял как надо, т.е. задача все равно крутится где-то в фоне, так что это именно марафон).
Я не говорю о перекладывании джйсонов - те задачи можно вообще не думая решать, но у меня таких не бывает.
И, кстати, марафонец в среднем всегда бежит медленнее спринтера. Но там нужна выносливость а не взрывная сила.
Увы, но нет. Приходится держать в голове именно весть проект, иначе потом столкнетесь с тем, что чтобы очередной кусочек пазла лег на свое место, надо возвращаться на пару-тройку месяцев назад и править что-то там. Что тянет за собой правки на всем протяжении того, что уже сделано.
Если я не продумал при проектировании БД ее структуру до конца (что зачем и с чем связано и что мне понадобится еще), то на определенном этапе обязательно начнется лютый костылинг.
Уж поверьте человеку, который в разработке (профессионально) с 91-го года.
Спортивное и промышленное программирование родственны ровно так же, как родственны спринт и марафон.
10 задач на 5 часов - это короткие задачи. А в бизнесе часто приходится решать задачи длинные, от недели и до месяца. Совершенно иной объем кода, сущностей и взаимосвязей между ними, которые нужно удержать в голове. Да и объем бизнес-логики и разных условий там может быть несравнимо больше.
Плюс, если речь идет о какой-то действительно большой системе из огромного количества модулей, будет еще длинный список нефункциональных требований. Плюс надо постоянно думать про интеграцию в систему, соблюдение общей архитектуры и т.д. и т.п.
Ну и не забывать что потом кому-то (может вам а может и нет) через год-два-три (а то и более) придется это все дорабатывать потому что что-то где-то поменяется в бизнес-процессах (например). И этот кто-то (а может и вы через три года) должен ваш код легко понять и быстро понять где и что надо поменять в соответствии с новыми требованиями.
Я далек от того, чтобы считать "олимпиадников" непригодными к бизнес-разработке (хотя был случай именно такого - блестящий олимпиадник, но бизнес не тянул - ему просто становилось скучно и наступало "временное выгорание"), но это, все-таки, "две большие разницы...
Не соглашусь. В бизнесе очень часто эффективность не менее важна чем поддерживаемость. И тут приходится искать баланс и решения где одно не вступает в противоречие с другим.
Выглядит все это как борьба с SQL движком. Бессмысленная и беспощадная.
Пример того, как отказ от SQL в пользу прямой работы с БД ускорил выполнение реальной задачи в ~40раз.
Скорее всего это функция деперсонализвации клиентов. Точнее, очень мала ее часть (т.к. кроме ФОИ у клиентов хранится еще огромная куча всяких данных и все они должны быть деперсонализированы.
Нужно все это при пересоздании тестовых юнитов с боевого. Суть в том, что берется какая-то часть реальных клиентов с боя, деперсоналилируется и этом всем заполняются тестовые юниты.
Это вполне реальная задача.
Это специфический для платформы IBM i (AS/400) язык RPG. Он не то чтобы "встроен в БД" - на этой платформе БД (DB2) является частью ОС ну и языки освновные (С/С++, RPG, COBOL, CL) тоже "встроены" (компилаторы являются частью ОС) в систему.
Язык типа COBOL по назначению - основное в нем работа с БД и коммерческие вычисления.
И да, в синтаксисе есть "привкус" PL-I который IBM одно время активно пыталась развивать. В виде всех этих dcl-... в объявлениях.
Кстати, там нет ожидания ответа. Там именно отправлен ответ отмены операции автоматом. "A cancel reply to an inquiry message was received."
Кабы оно ждало ответа, то задание висело бы в ожидании, а не вывалило бы ошибку.
Вот, не поленился джоблог поднять:
За изменение контракта без обеспечения обратной совместимости должен быть пожизненный эцих с гвоздями...
Да, IBM i.
И удаление поля из середины записи небезопасная операция. В больших БД с большим количеством интеграций я бы даже сказал недопустимая. Потому что обвал прода в mission-critical системе это уже практически катастрофа.
И мне не кажется что нетипичной такого поведения для БД это хорошо.
И получите
Reason code 10 означает "A cancel reply to an inquiry message was received."
Аналогичный результат есть попробовать сделать это через DDS командой CHGPF.
Момент номер раз. Удаление поля из БД. Не знаю что там за БД, но, работаю с "дибитухой" (DB2) уже 9 лет и вот там поле из существующей таблицы удалить невозможно. Оно просто не даст это сделать. Выдаст ошибку. Да что там удалить, там не то что тип поля, описание его уже не поменять... Единственное допустимое изменение в таблице - добавление нового поля в конец записи. Все. Остальное только полным пересозданием таблицы с потерей данных (хочется сохранить данные? делай скрипт для миграции, требуется отдельное согласование т.к. мигрировать несколько десятков а то и сотен миллионов записей такое себе...)
Момент номер два. Разделение зон ответственности. БД достаточно большая - несколько десятков тысяч таблиц. И она разделена на "зоны ответственности" разных команд. Так вот, доступ в "чужие" таблицы только через ретриверы и модули внешнего ввода. Никак иначе.
Момент номер три. Тестирование. Первый этап - песочница. Еженедельно пересоздаваемая копия компонентного юнита. Поставка туда разворачивается руками (системой сборки) из гита. Дальше - компонентный юнит. Тут уже установка через devops сервисы - доставка должна быть собрана и размещена в artifactory. Потом бизнес-юнит (бизнес-тест). Далее нагрузочное тестирование на копии промсреды и техтест на прелайве (тоже копия прома). И только после этого внедрение в пром. При внедрении в пром обязательно должен быть прописан план отката. На случай если что. Установками в бизнес-юнит и выше занимается дежурная смена по заявке. Т.е. в пром поставка попадает только после прохождения всех этапов тестирования - компонентного, бизнес, нагрузка, интеграция.
Поскольку всегда с поставкой идет план отката, то внедрение в пятницу нормальное дело. Если, не дай бог, что - поставка просто откатывается силами дежурной смены и все. Единственный мораторий на внедрения (за исключением хотфиксов) - период пиковых нагрузок с середины декабря и до конца новогодних праздников.