Добрый день всем!

Подскажите продвинутые курсы до уровня выше среднего .

которые вас научили хорошо программировать .

(118) SQL или запрос - всегда табличный доступ.
ДокументСсылка/ДокументОбъект - объектный доступ к конкретной строке главной таблицы, но так же и к строкам табличной части

(118) реализовать один из паттернов: Table Data Gateway, Raw Data Gateway, Active Record, DataMapper для произвольной таблицы или воспользоваться готовым DataMapper в 1С с табличными частями!

Любой курс по Java EE. Даже если нет цели связать с ней жизнь. Но как правило на таких курсах (EE, не SE!!!) выдают интерфейс JPA и какую-нибудь из его реализаций (hibernate, eclipselink.... etc). Дело нужное, так как придет понимание ORM, а с ним и понимание того, что делается под капотом 1С (без этого эффективно программировать на 1С без говнокода невозможно. навсегда отучит обращаться к реквизитам через точку, а так же бездумно использовать значения перечислений и предопределенные значения в коде. придет понимание объектной модели данных, маппинга полей, ленивой и жадной подгрузки, и т.д. можно дойти до всего самому с помощью профайлера БД, но дольше, и - ИМХО - нет гарантии, что в голове не образуется каша). Оч хороший курс по этому делу у ВТБ (курс довольно старый, но фундаментальные знание преподнесены качественно). В интернете выложен, но надо поискать (в ВК есть группа по джаве, у них в видеоресурсе эьль курс есть). Неплохо разжевана тема JPA, а также БД на примере postgresql, конкретно на пальцах показано, что такое транзакция, уровни изоляции и т.д.

выучить Java, чтобы потом работать на легаси в банках и страховых. тьфу, тьфу, не дай Боженька.
и вообще Java EE считалась устаревшей, когда я ее начинал свой нелегкий путь в это ваше тру IT в 2020м.
в Java большинство вакух на Spring'е. вот его и надо учить, если уж очень хочется вкусить тру ООП.
у меня эта болезнь прошла после того как я увидел, как это ваше тру ООП пишут некоторые люди, наоборот усложняя код, и делая ЭТО неотлаживаемым.

(124) что такое Spring? фреймворк, реализующий IoC и DI. Это и есть EE, те же яйца, только сбоку.

(124) + И да. помнится на курсах (назывались, к слову, ЕЕ) была в итоге спринга. Но до нее это должен был быть самописный проект, реализующий и ORM, и DI и IoC. Сам должен был всё это уметь написать "с нуля". Разумеется, в упрощенном виде, нежели в кошерной EE или спринге. финалка тоже была на спринге. И вот первый проект, на который я попал, (дико древнючим оказался) состоял из двух толстенных серверных аппликух (не считая фронта и мобилки), общающихся между собой по соапу. одна из них на кошерной ЕЕ, вторая на спринге. плюс куча микросервисов тоже на спринге. приходилось выполнять задачи и на ЕЕ, и на спринге. вообще не чувствовал каких-то неудобств. программист работает с кодом на джаве, описывет конкретные модели данных и сервисы для работы с ними, не задумываясь по большому счету о том, какой конкретно фреймворк этим всем барахлом рулит. какая разница? врубишься в ЕЕ (конкретно про кошерную оракловскую), будешь без проблем кодить и на спринге, и наоборот. ЕЕ - это принцип, а не реализация.

(125) Кстати в 1С Элементе Spring внутри....

(127) дело не в том (в нашем 1с-ном случае), какой фреймворк под капотом, а в понимании объектной модели работы с БД, что такое ленивая подгрузка, проксирование объектов моделей данных, что такое дескрипторы метаданных БД, как ORM-библиотека строит запросы в БД и т.д. Конечно, можно зазубрить, что "нельзя через точку, потому что говнокод", а можно понять, как это всё работает.

(127) почему ты так думаешь?

(129) даже путем логических рассуждений спринга напрашивается сама собой. во-первых, гугл даже при поверхностных попрыгушках по линкам намекает на то, что под капотом элемента java. во-вторых, спринга на сегодня основной промышленный фреймворк, да еще в придачу со всеми современными ништяками вроде работы с БД, облаками, очередями, секьюрностью и т.д., т.д., т.д..... "из коробки".

(125) это да, но реактивность пришла в Java EE позже чем в Spring.
в 2021м на тех же курсах по Java, мы делали на спринге все.
ORM - это красиво, пока в БД нет данных.
на больших объёмах - это костыль, который ломает колени при реальной нагрузке.
тот, кто писал высоконагруженные системы для банков (не CRUD-админки, а ядро с транзакциями, блокировками и SLA=99.99%), знает:
N+1 проблема - это цветочки. начинаются пакетные джобы, deadlock’и на уровне СУБД, а ORM тупо не умеет в FOR UPDATE SKIP LOCKED без костылей.
любой джойн на миллионах записей превращается в рулетку: сегодня Hibernate родил оптимальный SQL, завтра монстра с 10 вложенными подзапросами.
кэширование - отдельная боль.
ORM-кэш рвётся при репликации, а синхронизация кэша между нодами съедает всю "прелесть" горизонтального масштабирования.
паттерны должны служить, а не мы им.
1Сники, которые не отведали этого добра на реальных кейсах, продолжают молиться на ООП.
если ORM не справляется - её выкидывают и пишут ручные мапперы или хотя бы jOOQ.
в том же Spring Data JPA все адекватные разработчики отключают open-in-view, лезут в @Query(native=true) и допиливают SQL-оптимизатором.
Java EE или Spring - не важно. проблема в подходе "давайте сделаем Entity с 50 аннотациями, а потом будем хакать перфоманс".
реальный бизнес с большим объемом данных прежде всего про данные и перформанс, а не про красивые абстракции.

на текущей работе у меня MongoDB, так вот она умеет во всякие прикольные приседания с атомарностью записей.
но, эту атомарность не обеспечить через какой-то стандартный интерфейс для слоя хранения.
я забил на паттерны и прочую х**ню и использовал возможности движка для организации атомарности обновления списка прав на файл.
да, MongoDB торчит наружу из репозитория в слой бизнес-логики, но зато использует все возможности MongoDB, вместо того чтобы городить атомарность на уровне бизнес-логики.

PS: абстракции ORM не гарантируют атомарность так, как это делает $addToSet в MongoDB.
лучше нарушить "чистоту кода", чем получить race condition в продакшене.
если СУБД умеет что-то делать нативно - надо использовать это, а не абстракции.
Spring подход разбивается о реальные задачи, где важны:
атомарность,
контроль над запросами,
работа с distributed-системами.

если бы ORM и Spring решали всё, то MongoDB, Redis и Kafka не были бы так популярны. но почему-то их используют даже в Spring-проектах - когда абстракций уже не хватает.

а где адепты обучения по книжкам?
что дескать видео говно, надо непременно по книжкам учиться, желательно чтоб еще бумага была серой, шрифт мелким и код разнесен на разные страницы.

(133) Работаем, нам некогда херней страдать

(131) как раз сидел 2 года на банковской системе. вторая прилага на спринге как раз юзала ждбстемплейт, ибо она общалась с процессингом и шиной, там была важна скорость. первая больше для общения с юзверем на JPA (реализация эклипслинк) с кошерной, но неповоротливой, критериа. там тупо шел контроль сессии, бизнес-логика действий пользователя, прикапывались кое какие данные по истории операций для быстрой отправки на фронт.
не зря в спринге появилась Spring jdbc, да, народ давно наелся ORM. Удобно? безусловно. опять же, валидация на стадии компиляции и сборки. но нативность есть нативность. 1С никогда не позволит подобный разгул демократии, посему без приблуд с нарушением какого-то там страшного пункта лицензионки, которым всех пугают, но который мало кто видел, не обойтись...

(135) ну вот, я о том же.
там, где нужна скорость ORM выкидывают нах**й.
когда еще работал на 1С, в 2018м мы писали напрямую в MS SQL, потому что ORMка из 1С не справлялась с тем объемом данных, которые мы записывали.
и да, скорость была быстрее в 8 раз (!!!!!)

(130) java само-собой, под капотом элемента jvm, а синтаксис языка элемента жаваподобный. Но вот спринга под капотом - сомнительно. Тех фреймворков на каждый чих - хоть опой ешь. Это же не 1с, где кроме платформы и БСП ничерта нет

(131) в банках весь хайлоад пишут на чистом Oracle. Всякие там ORM используются лишь как прокладки между Oracle и бэкендом

(132) >>да, MongoDB торчит наружу из репозитория в слой бизнес-логики, но зато использует все возможности MongoDB

Ну такое себе. Угробил адаптивность архитектуры во имя монги. Завтра бизнес расширится, монга станет тесной, и пойдут свистопляски на 100500 программисто-часов по выкашиванию монги из кода. А сделай по-правильному, достаточно было бы заменить нижний слой хранилища данных на другой, не затронув и строчки кода бизнес-логики.
Перефразируя ту известную поговорку про девочку и деревню: 1сник может уйти на другой стек, но 1с из 1сника не уйдёт никогда) Сорри

(136) ORM-то выкидывают нах...й, но и БД в слой бизнес-логики не тянут. Хайлоад и бизнес-логика прекрасно отделяются друг от друга. Это у нас, у порочных 1сников, бизнес-логика сдружена с SQL. У нормальных людей за такое по рукам бьют

(0)Ничего не может быть лучше практики - нанимайтесь во франч и вперёд!)

А что вы такие умные в 1С делаете?!

(140) ахахах, как же трогательно наблюдать, как 1Сники, ненавидящие себя, пытаются учить других "чистоте архитектуры". причем я ничего не говорил. как вам живется в этой вечной ненависти к себе? я тоже был 1Сником, но не чувствовал себя ущербным - а вы сами себя лапками и приговариваете: "1сник может уйти на другой стек, но 1с из 1сника не уйдёт никогда". разве 1Сник это плохо?
1Сник - это фуллстек программист по сути.

но давайте по делу:
1) "ORM выкидывают, но БД в бизнес-логику не тянут" - а ну да, лучше data race в проде, зато "чистая архитектура". когда вы последний раз работали с MongoDB в продакшне? наверное, никогда. а я - работаю и знаю, что ее атомарные операции ($addToSet, $push, $concatArrays) решают реальные проблемы, а не выдуманные страхи про "а вдруг завтра сменим БД". как часто вы меняли БД в рабочем решении?
"монга станет тесной, и пойдут свистопляски" - ага, классический аргумент из серии "а вдруг на нас упадет золотой унитаз". только вот в постановке задачи стояло "выжать максимум из MongoDB", а не "сделать абстрактно-универсально". или вы всерьез думаете, что банки сначала пишут "чистый слой хранилища", а потом подключают Oracle? хахаха! они берут то, что дает максимальную производительность и надежность, а не то, что красиво выглядит на диаграмме классов. и как написал чувак в (135) приложуха, где нужен был рилтайм использовала Spring JDBC, а не ORM и там явно текли некоторые абстракции из слоя репозитория, что подтверждает мои слова.

2) "в банках хайлоад пишут на чистом Oracle" - ну да, а потом оказывается, что "чистый Oracle" - это тонны PL/SQL, который торчит в бизнес-логике, хранимки с тысячами строк и нулевая переносимость. но это же "нормально", да? а MongoDB - это "плохо", потому что... потому что вы так решили?

3) 1Сники любят говорить: "средства выбираются исходя из задачи бизнеса". вот здесь задача бизнеса решалась, и решалась эффективно. а ваши абстракции - это религия, а не инженерия.
когда я делаю обычные CRUD'ы на SQL, репозиторий у меня заправлен и никуда не торчит.

P.S. Если завтра MongoDB станет "тесной" - значит, бизнес вырос, и у нас будет бюджет на миграцию. а пока она работает быстрее, чем ваши "правильные" слои с костылями поверх ORM.

раунд!

(141) Практика может быть ниочем. Смотря какие задачи исполняешь. Если задачи никакие тогда единственный путь продвиаться через курсы.

(143) Так то по делу все да.
Меня тоже бесят те кто считают 1с ущербным)
1с прекрасно решает задачи на которые рассчитано.
переросли 1с - тоже согласен с тем что значит есть на что изменить ландшафт, а ходить и везде плевать ядом что 1с говно - отвратительная тактика

(143) прикин, у нас на предприятии (из списка топ-20 по стране) целая череда проектов по переходу с одной БД на другую. Импортозамещение? Не, не слышал. И тяжелее всего переход даётся в системах, где такие вот мамкины архитекторы плотно сдружили приложение с конкретной БД. Для некоторых систем выяснилось, что их проще целиком заново написать, чем пытаться отвязывать от БД

1) см.выше
2) не оказывается, это твои выдумки
3) топорно она решалась. Бизнес просто ни сном, ни духом, что им в будущем придётся сильно переплачивать


>>Если завтра MongoDB станет "тесной" - значит, бизнес вырос, и у нас будет бюджет на миграцию

Ну-ну. Только при нормальной архитектуре эта миграция стоила бы условные 10 килобаксов, а в твоем случае будет стоить 300 килобаксов. А так-то всё нормально

(145) 1с не говно. Низкая культура разработки среди 1сников - говно

(146) пфффф, 300 килобаксов за замену 2 методов, которые вызывают $addToSet? серьезно????
ты там по золотым клавишам стучишь? если твоя команда не может переписать пару методов без бюджета на яхту - это не про архитектуру, это про то, что у вас в отделе работают наркоманы на откате.

"нет хранимок в банках" - понял, пруфов не будет, как обычно.
в бигтехе, где я работал, логику в БД запрещали почему-то именно чувакам, которые делали банковские сервисы.
совпадение? не думаю.
а как это бывает на самом деле:
https://www.academia.edu/99808490/A_True_Story_of_Refactoring_a_Large_Oracle_PL_SQL_Banking_System

"бизнес в неведении" - ага, пусть лучше тормозит сейчас, но зато "чисто"!
понял логику "немамкиных архитекторов".

"импортозамещение" - омагад, только не это! давай сразу писать под PostgreSQL, Oracle, MongoDB и перфокарты - вдруг завтра США запретят нам NoSQL?
жду твой универсальный ORM для всего, даже для Excel'я.

если твои "немамкины архитекторы" не могут сменить БД без апокалипсиса - может, это они говно, а не мое решение?

P.S. ты так и не ответил:

1. когда ты последний раз видел реальный хайлоад на ORM? (подсказка была в (135): никто не пишет хайлоад на Hibernate)
2. почему чистый Oracle - это норм (со всеми его хранимками и проприетарщиной), а MongoDB - нет?
3. где твой production-опыт с MongoDB, чтобы так уверенно рассуждать? или как обычно - "за это бьют по рукам"?

накину еще:
4. когда ты в последний раз сам проектировал систему? какие требования к ней предъявлялись? то есть DAU, SLA и вот это вот все? ну или только в powerpoint'е и на форуме?

(147) это нормально. 1С работает на бизнес. если бизнесу будет нужна высокая культура программирования - она будет.
а если бизнес не знает что будет даже в краткосрочной перспективе - зачем ему вкладываться в ИТ? работает? - работает!  ну и ок.

(4) "4. когда ты в последний раз сам проектировал систему? какие требования к ней предъявлялись? то есть DAU, SLA и вот это вот все? ну или только в powerpoint'е и на форуме?"
- а кому это надо? я сейчас если надо - костылю и угрызений не испытываю. особенно когда в тоннах говнокода разбираться приходится.

(143) < "в банках хайлоад пишут на чистом Oracle" - ну да, а потом оказывается, что "чистый Oracle" - это тонны PL/SQL, который торчит в бизнес-логике, хранимки с тысячами строк и нулевая переносимость. но это же "нормально", да?>

Зачем банковской системе переносимость? она пишется под конкретную БД с использованием системных ф-ций самой СУБД для максимальной оптимизации
Я касался в свое время Way4 которая как раз помесь явы и тонн PL/SQL кода и подавляющая часть бизнес логики там в хранимках
куда вы хотите его переносить? этот продукт написан под Оракл, у него GUI на Oracle Forms реализован..под него сервера оракловые покупают ради этого, никто не будет никуда переезжат

(148) да-да, к моменту Х нужно будет поменять всего пару методов) Не самообманывайся.

>>если твоя команда не может переписать пару методов без бюджета на яхту - это не про архитектуру, это про то, что у вас в отделе работают наркоманы на откате

А это вопрос именно архитектуры. Если работа с БД гвоздиками приколочена к чему только можно, то даже самые сеньёрные сеньоры из майкрософта не отвяжут приложение от конкретной БД малыми усилиями. Требуется много времени и усилий, соответственно $$$

Разница между нашими мамкиными архитекторами и тобой в том, что для них момент истины и час расплаты настал, для тебя пока что нет

>>"импортозамещение" - омагад, только не это! давай сразу писать под PostgreSQL, Oracle, MongoDB и перфокарты - вдруг завтра США запретят нам NoSQL?

Не надо доводить до абсурда. Если технология перестала быть лицензионной и соответственно больше не обновляется, то рано или поздно может появиться такая уязвимость, которая поставит под угрозу существование всей системы, работающей на оной технологии. Поэтому разумные люди стараются отказываться от таких технологий, чтобы не ставить весь бизнес под удар

Разница между тобой и нашими мамкиными архитекторами (из отдельных команд) лишь в том, что для них момент истины и час расплаты за беспечность уже наступил, у тебя он настанет позже. А может и не настанет, свалишь из организации, и разгребать за тобой будет кто-то другой

(151) и здоровенная система на Oracle в нашей компании есть, с ораклоформочками и ораклосерверами. Сейчас идет большой проект по откалыванию от неё всего что можно в отдельные сервисы. Впоследствии на Oracle должно остаться только чувствительное к хайлоаду

(149) ну пока бизнес маленький, можно плевать на культуру разработки. А когда (если) бизнес вырастет, с ним вырастет и разрабатываемая система: экспоненциально увеличится число хотелок на доработки, соответственно разрастется и команда разработки. И вот тут-то весь поднакопленный техдолг ударит под дых

> Подскажите продвинутые курсы до уровня выше среднего .

бумажная копия мана по  1С77 распечатанная на матричном принтере тайком в офисе. 2 ночи печатал. а между страницами бежал играть в билиард.
1997 г.

эмммм.... ващета человек писал про курсы... я указал курсы по джаве с упором в орм не потому, что орм - это хорошо или зло, а потому, что 1С я и есть ваш сенат и есть орм. один большой и толстый орм. разумеется, понять его самые стрёмные места - дело очень нужное. безусловно, можно всё зазубрить из всяких видео "только не вздумайте обращаться к реквизитам через точку" или попытаться дойти до всего через профайлер скуля (интересно, какой процент 1С-ников хотя бы раз запускали скулевый профайлер? можно было бы опрос запилить, кто из мистян им пользуется), но можно посмотреть объяснения того, что такое орм, из любого курса по джаве.

(150) т. е. ты хочешь сказать, что твой максимум - латание дыр? ну это тоже имеет право на жизнь.

(151) если система заточена под Oracle и работает - лезть туда с кривыми абстракциями 'на всякий случай' - это инженерный мазохизм.
но речь не про Way4, а про страшилки того чувака, который:
орет 300к за миграцию! - но не может объяснить, почему замена $addToSet должна стоить как квартира.
пугает MongoDB - говно, потому что завтра надо будет переносить - но сам ни разу не сталкивался с реальной миграцией.
требует чистых слоев! - но при этом забывает, что даже в 1С при смене БД (MS SQL → PostgreSQL) все равно приходится переписывать запросы.
так что да - если бабки есть и бизнес требует - переносим. но пока все работает - зачем трогать?
ты хотя бы реальные кейсы привёл (Way4), видно что у тебя опыт есть, а тот чувак строит теории на основе пустых пугалок.

(158) что монга говно, это ты выдумал, я такого не говорил. Ну и не рассказывай, что у тебя единственная деталь конкретной СУБД просочилась в приложение. Уверен, приложение сдружено с БД по самое не балуй. Вот разлучить приложение с монгой и будет стоить дорого. Я же выше уже написал, в нашей компании нашлись твои собратья по-разуму, которые сделали конкретную СУБД центральным нервом приложения. И теперь проще то приложение заново написать, чем отвязать от БД. То же самое ждёт и твое приложение

Миграция на другую СУБД - не так уж и больно, если архитектура изначально грамотная, и слой дао четко отделен от бизнес-логики.
(143) Эммм.... банку она незачем, безусловно, но бывают ситуации, когда резко банк перестают спрашивать. например, санкции, уход оракл из РФ.... бросаем всё и переходим с веблоджика и оракла на томкат и постгрес... как вам такие приколы? я такое проходил. в 22-м. и "тысячи строк pl/sql" видел и фиксил собственными глазами и пальцами. тому, кто пихает бизнес в СУБД, надо гвоздь в голову вбить. это моё твердое убеждение. Такой подход подразумевает кучу вопросов начиная с порога вхождения на проект и заканчивая миграцией.

(160) >>Миграция на другую СУБД - не так уж и больно, если архитектура изначально грамотная, и слой дао четко отделен от бизнес-логики.

Повторите, пожалуйста, погромче. Для товарищей на задних рядах

(152) ахахаха, и это все что ты можешь ответить на:
1. откуда 300к за пару методов?
ты либо гений распила, либо твоя команда пишет код на золотой клавиатуре. в любом случае - позовите следователя.

2. почему "гвоздями прибито", если речь о двух изолированных запросах?
где тут "архитектурный апокалипсис"? это опять же говорит о качестве твоей команды.

3. где твой production-опыт с MongoDB?
его тупо нет или максимум это мучения с atlas на localhost.

не понимаешь сути задачи - мне нужно было выжать максимум из MongoDB через k6 и я это сделал.
ты наверное даже не запускал k6 ни разу.
существующая система на графовой базе тормозила при получении списка доступных пользователю файлов.

ты предлагаешь "готовиться к миграции", которая может никогда не понадобиться.
опираешься на фантазии, а не факты:
"час расплаты" - ага, как в плохом фильме ужасов.
"импортозамещение" - да да, мы все умрем!
чувак из (151) привел факты. а ты - страшилки для junior'ов.
MongoDB работает 5 лет уже и никто ее не меняет.
ты демонстрируешь некомпетентность, видно, что дальше 1С ты не работал. не можешь отличить over-engineering от нормальной оптимизации.
ты - классический пример "архитектора", который:
- не имеет практического опыта, но любит учить других.
- путает теорию из книжек с реальными требованиями бизнеса.
- сливается с дискуссии, как только потребовались реальные кейсы.

когда научишься отличать MongoDB от MySQL - возвращайся, поговорим, а пока твои комменты - это как анекдоты, только грустные.

(159) Семен Семеныч, опять 25.
"монга говно - это ты выдумал" - ага, просто ты 3+ поста грозишь мне расплатой, импортозамещением и 300к за миграцию.
"уверен, приложение сдружено с БД по самое не балуй" - Ванга вошла в чат?!! ты даже не видел код, но уже "уверен". вот твой уровень компетентности, прям как у цыганки на вокзале.
"в нашей компании..." - опять страшилки без деталей:
какое приложение? какая БД? какие "собратья по разуму"? или опять "один чувак в чате сказал"?
"то же самое ждет и твое приложение" - чувак, у тебя дар предвидения. может, еще курс биткоина подскажешь? я закупиться хотел.

(162) чувак, ты мыслишь категориями ларёчной разработки. Где один разработчик, он же архитектор, он же верховный повелитель приложения. А я тебе уже написал, что работаю в одной из самых крупных компаний страны. У нас штат ИТ измеряется тысячами человек. И я тебе говорю не про какую-то там книжную теорию, а про случившиеся перед моими глазами ФАКТЫ!
Твоё "спасение" в том, что период загнивания приложения при вялотекущей разработке силами одного Васи, может составлять десятилетия. А в большом ИТ жизнь течет быстрее. Тут одно приложение разрабатывают десятки человек. Интенсивность разработки такая, что архитектурные просчёты бьют под дых не через года (как в твоём случае), а уже через месяцы

(164) ахахахахах!!!! ааа, почему мне так смешно.
ты работаешь в "одной из самых крупных компаний страны", где:
штат - тысячи человек (но почему-то ты один тут споришь с рандомом на форуме).
"ФАКТЫ перед глазами" - окей, тогда ответь:
какое конкретно приложение у вас "загнило"?
какие архитектурные просчеты?
сколько реально стоила миграция?
"а в большом ИТ жизнь течет быстрее"
окей, тогда почему ты не можешь ответить на простые вопросы?
ИМЯ, СЕСТРА, ИМЯ!!!
если у тебя есть реальные кейсы - давай, мы все ждем.

(165) что за поток вопросов? Какие конкретно приложения загнили я тебе не скажу, подписывал бумаги о неразглашении. В чём конкретно архитектурные просчёты я тебе уж десятый раз пишу, и ты десятый раз эти архитектурные просчёты защищаешь.

==>> Наплевали на слои, плотно сдружили приложение с конкретной СУБД <<==

Вот он главный архитектурный просчёт. Сколько ещё раз повторить нужно?

(166) "не могу назвать приложение", но громко заявляешь, что оно "загнило".
"подписывал бумаги", но почему-то можешь обсуждать это на форуме.
если бы у тебя был реальный кейс, ты бы хоть намекнул, а не прятался за NDA.
ты не понимаешь разницы между "плотно сдружили" (когда все завязано на хранимки) и двумя методами, которые используют $addToSet.

- все умрут!
- кто, где, когда?
- это секрет!

закругляйся уже. ты проиграл, потому что твои аргументы смешнее, чем твоя же риторика.
без пруфов ты - просто шум.

(167) так я же дателей не разглашаю, поэтому нарушений нет. И не собираюсь разглашать. Хочешь верь, хочешь нет, но у нас прямо сейчас идут проекты под названием "Рефакторинг [какой-то там загнившей приложухи]" с бюджетами в семизначные суммы. Есть и более запущенные случаи, когда проект называется вроде "Повышение жизнестойкости [важная, но запущенная система]", и цифры бюджета уже восьмизначные. Тот случай, когда компания не то что цену квартир, а цену яхт платит, не получив ни грамма новой функциональности. Вот такая она расплата за "забил на паттерны и прочую х**ню и использовал возможности движка" (с)

(162) "ты предлагаешь "готовиться к миграции", которая может никогда не понадобиться."

вот пжалста реалии из моей практики. никакой миграции СУБД. как была оракл, так и осталась.
но! заказчик потихоньку начал переходить на внешнюю систему. т.е. часть данных из БД переехала куда-то в космос. имеем только инфу о торчащих наружу апихах вроде гет, пост, апдейт, делит и т.д. с описанием джейсонов.
благо слои были четко отделены. по сути, переписали только реализацию слоя дао, интерфейсы такие же и остались: ходим не в базу, а плюемся запросами к внешней системе. вот и всё. это была не миграция, а песня какая-то. и это при условии, что сама система была заточена под оракл и местами слой дао состоял из нативного spring template и специфичного для оракла диалекта вроде использования оракловских хинтов, оракловского трехэтажного монстра для паджинации и т.д.

песня песней, но дао-то частично пришлось переписать....
и никто и никогда не предполагал миграцию....
в сегодняшних реалиях ИТ !!!ВСЕГДА!!! нужно оставлять в уме вариант миграции: сегодня СУБД, завтра внешняя система, послезавтра очередь/шина, через неделю... кто знает, что там через неделю...

(168) чувак, да ты ходячий кринж-мем:
"хочешь верь, хочешь нет!" - но ни одного конкретного примера.
"цифры бюджета уже восьмизначные!" - ок, бабки у конторы есть.
"архитектура важна!" - но ни одного вменяемого аргумента. ты так и не ответил ни на один прикладной вопрос про MongoDB.

P.S. если твои "кейсы" - это "рефакторинг какой-то загнившей приложухи", то давай на этом закончим.
еще раз, без пруфов - ты шум. не позорься дальше.

(170) у меня для тебя новости) Позоришься ты, не я. Зайди на какой-нибудь большой форум джавистов, и там попиши свои нарративы про забивание на паттерны и архитектуру. Много нового про себя узнаешь)

(169)
1. Ваш "идеальный" кейс:
- Никакой миграции СУБД не было (Oracle так и остался)
- Но DAO всё равно переписали (кек)
- С оракловыми хинтами и адской пагинацией (очень "чистая архитектура", да)

2. Ваш же пример доказывает:
- Даже с "чистыми слоями" код все равно меняли
- Oracle-специфичный код - это норм (тут можно, а мне нельзя)
- Но MongoDB - плохо, потому что "вдруг миграция" (понял, принял)

3. Главный перл:
"ВСЕГДА готовьтесь к миграции!"
(при этом ваш кейс - это переход НЕ на другую СУБД, а на API)

Вы либо:
а) Не понимаете разницы между миграцией СУБД и интеграцией с API
б) Демонстрируете двойные стандарты
в) Все вышеперечисленное

P.S. YAGNI и KISS - это не про вас, да?

(170) >>без пруфов - ты шум. не позорься дальше.

Вот в этом твоя проблема. Ты никогда не работал в большом ИТ. Был 1сником-ларёчником, стал жавистом-ларёчником. Как я уже говорил, деревня из девочки...) Когда-нибудь может и ты поработаешь в большом ИТ, узнаешь, как тут и что. В частности, большие компании тратят миллиарды на информационную безопасность. У нас люди ездят на конференции, и слайды с картиночками согласовывают с безопасниками. Чтобы ни дай бох лишняя циферка куда не ушла. А ты насел на меня со своим ларёчным мировоззрением "назови системы, назови детали".
Открой авторитетные книги по программированию. Там признанные авторы пишут о проблемах... и ни одного названия конкретного приложения конкретной компании. Ну так вот оно устроено, что разглашение пруфов чревато проблемами на работе, вплоть до схлопотать судимость. Доступно объяснил?

(171) о, новый уровень! сначала "у нас миллионы!", потом "спросите на другом форуме".
чувак, ты не дискуссию ведешь, а квест "как слиться красиво".

(172) >>Даже с "чистыми слоями" код все равно меняли

Кто-то обещал волшебство?) Повторю то, что я уже писал:
при нормальной архитектуре миграция будет стоить условные 10 килобаксов, а при запущенной архитектура уже 300 килобаксов

(174) как же тебя несёт...

(173)
"вот в этом твоя проблема."
о, диванный психиатр подъехал.
"был 1сником-ларёчником, стал жавистом-ларёчником"
я не джавист
"ты никогда не работал в большом IT" - ахахаахахах! уже 2 раза не работал, ага.
"миллиарды на безопасность!" - но при этом ты треплешься на форуме про "загнившие системы".
"открой авторитетные книги по программированию" - ну да, Мартин Фаулер пишет "один крупный банк" - а ты "одна загнившая система".
разница в том, что он - эксперт, а ты - просто мем с NDA-фетишем.
если твоя "большая компания" платит миллиарды, но не может научить тебя аргументировать без "верьте мне!" - мне ее не жалко.
когда научишься спорить без детского сада - возвращайся.

(172) "Даже с "чистыми слоями" код все равно меняли"
разумеется. у вас есть какой-то другой способ?
даже с вашей (нашей) любимой спрингой иначе не получится. правка свойств в пропертях подразумевает смену реализации. это то, что спринга делает за вас.

"Не понимаете разницы между миграцией СУБД и интеграцией с API"

хм.... а архитектурно какая, собственно, разница? в упор не вижу, в чем существенная разница с точки зрения архитектуры между отправкой запросов в базу и во внешние апихи? напомню, архитектура - это про интерфейсы и слои, а не про реализацию.

ЗЫ и да. в той задаче таки вариант хождения в базу остался. я бы сказал, что код был не переписан, а дописан. т.е. добавилась реализация с вариантом внешней апихи и переключением через пропертю. архитектура прилаги не поменялась от слова совсем.

(177) ты вообще в адеквате? Просишь меня нарушать закон, чтобы предоставить тебе пруфы🤦‍♂️ Чувак, да ты сам хер с горы, никем не признанный и не эксперт. И твои слова ну ничуть не авторитетнее моих. Что же тебя так несёт-то, а?

(179) ахахах, ну если твой уровень экспертности - "хотите верьте, хотите нет", то я не эксперт, в натуре.
сначала "верьте мне!", потом "это NDA!", теперь "ты хер с горы!" - это не дискуссия, а квест "как не отвечать на вопросы". поздравляю, ты прошел его на 100%

(180) ну я тебе предложил вариант, как получить оценку своих компетенций. Конечно на форуме 1сников легко разглагольствовать, тут большинство слово "паттерны" даже не знает

(178) наш пациент пока не дорос до понимания архитектуры

(152) /* Разница между тобой и нашими мамкиными архитекторами (из отдельных команд) лишь в том, что для них момент истины и час расплаты за беспечность уже наступил, у тебя он настанет позже. А может и не настанет, свалишь из организации, и разгребать за тобой будет кто-то другой */

Ну вот пишет человек "с костылями" в УПП. Он же точно знает что когда всё это перестанет бизнес устраивать то никто во всём этом разбираться не будет - будет переход на ERP и период написания там новых костылей. До следующей итерации - переход с ERP на то, что будет потом. А без "переходов" в мире 1С не бывает :-)

p.s. А если он откажется делать костыли то его выгонят прямо сейчас, ибо бизнесу всё всегда надо "уже вчера". Вот это и будет "расплатой"...

(178) приятно говорить с человеком, который понимает разницу между "мы подготовились к изменениям" и "мы написали кучу ненужного кода на случай апокалипсиса".
видно что опыт есть, респект и уважуха. так и надо работать.

1. "чистые слои не равно отсутствие правок"
абсолютно верно! даже с Spring:
меняем application.properties -> меняется реализация.
добавляем новый @Repository -> код растет, но архитектура не ломается.
это и есть норма, а не "переписывать все с нуля".

2. "разница между СУБД и API"
архитектурно да, разницы нет:
и там, и там - интерфейс + реализация.
но! миграция СУБД (Oracle -> PostgreSQL) - это боль из-за: хранимок, специфичного SQL, разных оптимизаций.
переход на API - это проще, если:
есть четкие контракты (Swagger/OpenAPI), нет жесткой привязки к БД-специфике.

3. "код дописан, а не переписан"
идеальный кейс!
если архитектура не треснула - значит, сделано правильно.
в моем случае с MongoDB:
методы с $concatArrays - это такие же "дописанные" методы

вы подтвердили мою точку зрения:
гибкость - это про слои и интерфейсы, а не про "абстракции ради абстракций".
любые изменения требуют правок, но хорошая архитектура минимизирует боль.
MongoDB-специфичные методы - это не "грех", а инструмент - как оракловые хинты.

(182) о, "эксперт" из "большого IT":
- не ответил на вопросы -> слился с темы
- не привел реальных примеров (как коллега из (178)) -> фейк
- перешел на личности -> рукалицо
- зачем-то оскорбляет компетенции 1Сников, которым сам и является. что там с самооценочкой то?

единственная твоя компетенция - быть мемасом, это у тебя хорошо получается.

(184) чувак, с тебя так и прёт непонимание сути архитектуры. Ты всю дорогу тычешь конкретными реализациями и конкретными фреймворками. Архитектура это когда есть нижнеуровневый слой данных, а всё остальное приложение ни сном, ни духом, как и чем этот слой управляется с данными. Будь там хоть работа с конкнертной БД через JDBC, хоть ORM, хоть HTTP-запросы к облаку... Остальной части приложения на это вообще насрать!

(185) реальные примеры я тебе привёл. Проблема в том, что твоя религия не пропускает эти примеры

(186) а ну ок, кем наш "мемный IT экперт" работает? неужели 1С-программистом? тем самым, "которые и слова паттерны не знают"?

(187) чел, соррян, но паттерн-религия - это у тебя.
еще парочка твоих тейков:

- "архитектура - это абстракция!" - кек, но сам ты не смог отличить слои данных от API
- "всему приложению насрать" - тогда почему ты орешь про "гвозди" и "300к за миграцию"?

мем, и есть мем.

А где мамкины архитекторы прокачивают архитектуру ПО или кода?

хлопцы, я тут перечитал сначала. вам не кажется, что вы спорите об одном и том же? смотрите с разных сторон на одну и ту же дверь? только для одного эта дверь открывается изнутри наружу, а у другого внутрь? всем работу работать! понедельник на дворе.

(191) я прост угараю с типа. согласен, уже 10-00 пора к станку.

(188) также как и ты, сползший (но не окончательно) с 1с. Слово "паттерны" я знаю, и получше твоего

(192) да? А у меня наоборот, сижу и хихикаю с тебя)

(193) ахахаха.
зачем ты продолжаешь сидеть на 1С, которую так ненавидишь?
я вот конфигуратор уже 4 года не открывал вообще.
5 раз в день долбишься лбом в книжку Фаулера наверное, да?

(194) да да, слив засчитан.

(195) а с чего ты взял, что я ненавижу 1с? Ну вот с чего?

(197) ахахахха, у эксперта память как у рыбки, понял.
сам же написал, "1Сника из 1Сника не убрать", "1Сники, которые не знают слова паттерн".

(198) в чем тут ненависть? Это же факты. Ты сам как ходячий пример того, что 1сные взгляды "БД-центричности" остаются навсегда. Что 1сники не знают паттерны... ну это вообще очевидный факт

(199) аххаха, ну да, главное, что у тебя все хорошо в идеальном мире.

(200) чудной ты) Пишу, что у нас дорогие проекты по переписыванию за любителями наплевать на архитектурку, а ты про какой-то идеальным мир. Это ты в идеально мире живёшь, где наплевательство на архитектуру не стреляет в ногу (конечно стреляет, но не сразу), а не я)

(201) да, да. только паттерны, и не дай боженька иначе.
нету иного пророка кроме Фаулера.

(202) вот видишь, сам в своей голове какую-то х..ню накручиваешь, и зачем-то приписываешь её мне

(203) как скажешь

Сертификация по "1С:Специалист по платформе". За 4 часа на экзамене нужно настрочить оперативный учет, бухучет и расчет, да ещё бизнес-процессы по случайно выбранному билету. Попробуй не продвинься).

(154) ударит под дых
Ну и что? Это что, мои проблемы как разработчика? Нет, это проблемы бизнеса. Надо раньше было думать, ссзб.
А так жили как-то на том что крутилось, еще полгода-год проживут, пока перестройка будет идти.

(157) ну, дырылатать и костыли ставить тоже кому-то надо.  А То развелось онолитегов, архитекторов, девопсов и прочих. А работать некому.

(207) "...Вы телефончик-то запишите. ..."©анекдот

(207) аналитики тоже нужны.

Аналитик (сущ.) - тот, кто на корпоративах (тимбилдингах) проверят: а налито ли у всех

(209) но, как правило, делает это в соответствии через первые 4 буквы...

(210) согласен. нередко аналитики лажают. поэтому и существует тесная связь аналитик-разраб-тестер, и спека по ходу разработки правится. но тем не менее, без аналитиков не представляю как разрабатывать более-менее серьезный проект. что-то там на коленке можно, но не уровня энтерпрайз

ну тут в ветках у Фабриканта как-то долго терли, но так по-моему и не пришли к единому мнению что/кто такое "аналитик". Я за свою 1сную жизнь аналитика видел один раз. Причем повезло - грамотный парень был, в Астане проект был. Одинэсником он не был. Но отлично преставлял как и прчему работает компания и как процессы увязаны. Все проблемы/неточности/пояснения = решались влет. Знал кого дернуть, у каого по частностям глубоким проконсультироваться, комфортно было работать. Вот такой был бизнес-аналитик.

(212) Так ты наверное. ))

(212) Как не пришли? Аналитик это симпатичная девочка, которая носит кофе разработчику, разве нет?))

(213) не, такой я у себя на фирме был.
а это проект на стороне.

(214) "кофейный аналитик"?

главная задача аналитика - уметь приготовить хороший кофе.
Аналитик так себе - готовит хорошее кофе.

(12) Лиспом балуешься, в свое время мне там не хватало глобальных переменных

(0) Я учился на курсах 8-ки после 7-ки (1 или 2 недели) и на курсах по управляемым формам (недельные вроде). Это хорошие курсы были, помогли преодолеть барьер перехода.

(218) глобальные переменные - зло. А лисп это другой уровень, не для костылёвщиков, для функциональщины требуется математическое мышление