Нет, не верно. С точки зрения бизнеса (при правильном понимании производственного процесса, конечно) выгодно освободить "звузду" от черновой низкоквалифицированной работы, дав ему только "звездные" задачи. Нанять и перетряхивать джунов и мидлов за копейки, пусть черновую, повторяюсь, работу выполняют, а "звезда" путь высокие задачи делает.
Задача тимлида, точнее, начальника группы - именно это и обеспечить. А задача СЕО, кстати - убедиться, что тимлид это понимает и выполняет. И не "душнилу" чморит, а следит, чтобы "звезда" "несла золотые яйца". И варежку недовольным джунам затыкает, если им не нравится со "звездой" работать.
Естественно, если наш душнила на самом деле "звезда", ценная для бизнеса.
Понимаю. Но я имел в виду - писать качественный код сразу. А не навалить как попало, а потом рефакторить и юнит-тесты дописывать. Бизнесу хочется, чтобы сразу было хорошо. А ваш человек ругался на что - что вы с начала наваливали некачественный код, или что вы не хотели некачественный код исправлять? Это разные вещи.
Нет, бывает так, что всю архитектуру проекта продумывает один человек. Все идеи, которые потом продает бизнес, придумывает и продвигает он. Он же материт всю остальную команду и требует высокого качества кода (при том, что никаких стандартов предприятия на этот счет нет).
Остальные реализуют классы, пишут юнит-тесты, скрипты, короче всю черную работу.
Древние люди изобрели лук, колесо, огниво. На том этапе это такие изобретения, которые изменили жизнь человека настолько кардинально, собственно, сделали его человеком, также как и изменили расклад сил в живой природе, что ваше "изобретение самолета" полнейшая чепуха.
Поддержу вас. Прочитал огромный тред, но не увидел простейших вещей, которые мне в университете говорил профессор по теории информации.
Никакая программа не способна при преобразовании информации получить больше информации, чем было в данных. Иначе говоря, при преобразовании данных, количество информации может только уменьшаться. Это закон природы, он доказан. Он применим что к сжатию данных, что к генеративным сетям, разница только в количестве. ИИ не может придумать ничего нового сверх того, что имеется в обучающем датасете. Новым он может показаться только нам с вами, не видящим и в принципе не могущим запомнить датасет из миллиардов изображений. Второй пример - клюква в фильмах, когда ФБРовцы увеличивают изображение и оно из пиксельного превращается в более четкое.
При преобразовании информации, как и при любом физическом процессе, энтропия только увеличивается. Это закон природы, он доказан.
Творческая деятельность, созидание новой информации ведет к уменьшению энтропии.
Уменьшать энтропию способны только живые существа. Причем только локально, за счет увеличения в более широком объеме. Соответственно, только живые существа способны к творческой деятельности. Это самый спорный тезис, признаю.
При обсуждении ИИ и способности его к мыслительной деятельности достаточно только п.1.
Забавно, но таки есть. Биметаллическая пластина состоит из двух слоев разнородных металлов с разным коэффициентом расширения. При нагревании длина слоев меняется по разному и пластина изгибается. Иначе говоря, сравнивается длина медного и железного слоя. При превышении определенной разницы, пластина изгибается на угол, больше заранее заданного и цепь размыкается. Причем не просто размыкается, а отщелкивается выключатель, чтобы при остывании снова не включился. Триггер, по-сути. Поэтому, комментатор выше в каком-то смысле прав.
Статья хорошая. Однако данный пример может ложно навести на мысль, что необходимо разбивать на классы с одним-единственным методом. А это не так, согласно Мартину.
Предлагаю или явно это указать, либо сделать классы, к примеру не Saver, а DataSource и определить в нем методы Save и Find.
Более того, я когда читал про solid, всегда вызывало отторжение. Всегда было чувство, что это модная чепуха. Много противоречий, разнотолков у авторов. Вплоть до того, что в классах оставляли только один метод invoke.
Потом я прочитал Мартина, дядю Боба. А у него все просто и понятно. SOLID - попытка бездумной формализации в нескольких предложениях философии Мартина. Имхо - довольно неудачная.
Кстати, и Spring необходимо изучать только после того, как прочитаешь "Желтую книгу". Иначе он все равно вызовет у тебя отторжение.
Работать что с Газпромом, что с Грефом - это надо быть смелым человеком. Все равно, что работать с бандой, которая берегов не знает. Никакого укорота на них нет. Все равно не переиграешь.
Проблема, имхо, не в реакторах, а в персонале, который их будет обслуживать. Это раз.
Второе. Тендеция на приближение реакторов к потребителю противоречит тенденции в ИТ на оутсорс. Предприятия выносят в облака свои серверы. С чего бы владельцы датацентров станут корячиться и овладевать компетенциями ядерной энергетики? Они или построят датацентр рядом с гидро, угольной, ветряной или той-же ядерной станцией, либо тупо проведут специальную высоковольтную линию к своему датацентру (и то не сами, а при помощи энергоснабжающей компании).
Все это уменьшение противоречит развитию техники, которая суть одно - укрупнение и централизация.
У нас в девяностые тоже бытовало заблуждение, что сейчас обанкротим крупные совхозы, коров раздадут фермерам и они всех накормят. А жизнь привела к тому, что фермеры либо разорились, либо поумирали от невыносимого труда, а рулить стали агрохолдинги.
Да в принципе нормально, прочитал код с интересом. Просто с базами данных - это такая заезженная тема, что там трудно что-то придумать.
Формирование объекта-алгоритма с заданием последовательности действий? Действия со счетом например. Сначала то, потом это, задать параметры, выполнить то и так далее. Да, спасибо за идею, надо подумать.
Другой разработчик, когда ему понадобится выбрать пользователей по имени, видя в базе кода вашу getById, скопипастит ваш код рядышком, немного подправит и сделает getByName.
Я правильно понимаю?
Точно такой-же копипастинг, как и просто использование TypedQuery. Только появляется прокладка-велосипед.
Если же вы предложите не имплементировать getById, а прямо писать этот кусок в классе бизнес-логики, то это грубейший залет. Проникновение деталей реализации в бизнес-код.
Правильно - реализация репозитория с методами UserRepository.getById, UserRepository.getByName, UserRepository.getByFamilyName и так далее. Хоть с сотней методов. И да, если они написаны копипастом с небольшими изменениями, ничего страшного.
А поле с версией может помочь при отсутствии транзакций? При редактировании документа, конечно а не при финансовых проводках.
Нет, не верно. С точки зрения бизнеса (при правильном понимании производственного процесса, конечно) выгодно освободить "звузду" от черновой низкоквалифицированной работы, дав ему только "звездные" задачи. Нанять и перетряхивать джунов и мидлов за копейки, пусть черновую, повторяюсь, работу выполняют, а "звезда" путь высокие задачи делает.
Задача тимлида, точнее, начальника группы - именно это и обеспечить. А задача СЕО, кстати - убедиться, что тимлид это понимает и выполняет. И не "душнилу" чморит, а следит, чтобы "звезда" "несла золотые яйца". И варежку недовольным джунам затыкает, если им не нравится со "звездой" работать.
Естественно, если наш душнила на самом деле "звезда", ценная для бизнеса.
Понимаю. Но я имел в виду - писать качественный код сразу. А не навалить как попало, а потом рефакторить и юнит-тесты дописывать. Бизнесу хочется, чтобы сразу было хорошо. А ваш человек ругался на что - что вы с начала наваливали некачественный код, или что вы не хотели некачественный код исправлять? Это разные вещи.
Нет, бывает так, что всю архитектуру проекта продумывает один человек. Все идеи, которые потом продает бизнес, придумывает и продвигает он. Он же материт всю остальную команду и требует высокого качества кода (при том, что никаких стандартов предприятия на этот счет нет).
Остальные реализуют классы, пишут юнит-тесты, скрипты, короче всю черную работу.
Положим, это оценка бизнеса.
А если в команде весь бизнес обеспечивает именно этот "душный человек", а остальные няшки балду пинают?
Тэкс, а гле ломбоковский lazy?
@Getter(lazy = true)
Древние люди изобрели лук, колесо, огниво. На том этапе это такие изобретения, которые изменили жизнь человека настолько кардинально, собственно, сделали его человеком, также как и изменили расклад сил в живой природе, что ваше "изобретение самолета" полнейшая чепуха.
Вы бы еще самокат "изобрели" и кичились бы этим.
Поддержу вас. Прочитал огромный тред, но не увидел простейших вещей, которые мне в университете говорил профессор по теории информации.
Никакая программа не способна при преобразовании информации получить больше информации, чем было в данных. Иначе говоря, при преобразовании данных, количество информации может только уменьшаться. Это закон природы, он доказан. Он применим что к сжатию данных, что к генеративным сетям, разница только в количестве. ИИ не может придумать ничего нового сверх того, что имеется в обучающем датасете. Новым он может показаться только нам с вами, не видящим и в принципе не могущим запомнить датасет из миллиардов изображений. Второй пример - клюква в фильмах, когда ФБРовцы увеличивают изображение и оно из пиксельного превращается в более четкое.
При преобразовании информации, как и при любом физическом процессе, энтропия только увеличивается. Это закон природы, он доказан.
Творческая деятельность, созидание новой информации ведет к уменьшению энтропии.
Уменьшать энтропию способны только живые существа. Причем только локально, за счет увеличения в более широком объеме. Соответственно, только живые существа способны к творческой деятельности. Это самый спорный тезис, признаю.
При обсуждении ИИ и способности его к мыслительной деятельности достаточно только п.1.
Забавно, но таки есть. Биметаллическая пластина состоит из двух слоев разнородных металлов с разным коэффициентом расширения. При нагревании длина слоев меняется по разному и пластина изгибается. Иначе говоря, сравнивается длина медного и железного слоя. При превышении определенной разницы, пластина изгибается на угол, больше заранее заданного и цепь размыкается. Причем не просто размыкается, а отщелкивается выключатель, чтобы при остывании снова не включился. Триггер, по-сути. Поэтому, комментатор выше в каком-то смысле прав.
Статья хорошая. Однако данный пример может ложно навести на мысль, что необходимо разбивать на классы с одним-единственным методом. А это не так, согласно Мартину.
Предлагаю или явно это указать, либо сделать классы, к примеру не Saver, а DataSource и определить в нем методы Save и Find.
Более того, я когда читал про solid, всегда вызывало отторжение. Всегда было чувство, что это модная чепуха. Много противоречий, разнотолков у авторов. Вплоть до того, что в классах оставляли только один метод invoke.
Потом я прочитал Мартина, дядю Боба. А у него все просто и понятно. SOLID - попытка бездумной формализации в нескольких предложениях философии Мартина. Имхо - довольно неудачная.
Кстати, и Spring необходимо изучать только после того, как прочитаешь "Желтую книгу". Иначе он все равно вызовет у тебя отторжение.
Выбрасывайте свою "неопределенность". Это еврословоблудие от ISO9000 сейчас будет неактуально.
Красивая продукция.
Не думал, что доживу до такого киберпанка. Но это из разряда саркастических фантастических рассказов про попаданца из прошлого:
-- А у вас турникеты в школах есть с проверкой по вживленному чипу?
-- ?? Зачем?
-- Ну а как-же, бандиты, насильники, воры, хулиганы, педофилы наводнят школу!
-- У нас бандиты и воры не ходят в школу. У нас их вообще почти нет, чтобы ради них всем школьникам ... что вы там вживляете? Тем более пе... кто?
Работать что с Газпромом, что с Грефом - это надо быть смелым человеком. Все равно, что работать с бандой, которая берегов не знает. Никакого укорота на них нет. Все равно не переиграешь.
Персонал нужен не для того, чтобы урановые ломы в топку кидать, а для того, чтобы реагировать при нештатных ситуациях.
Проблема, имхо, не в реакторах, а в персонале, который их будет обслуживать. Это раз.
Второе. Тендеция на приближение реакторов к потребителю противоречит тенденции в ИТ на оутсорс. Предприятия выносят в облака свои серверы. С чего бы владельцы датацентров станут корячиться и овладевать компетенциями ядерной энергетики? Они или построят датацентр рядом с гидро, угольной, ветряной или той-же ядерной станцией, либо тупо проведут специальную высоковольтную линию к своему датацентру (и то не сами, а при помощи энергоснабжающей компании).
Все это уменьшение противоречит развитию техники, которая суть одно - укрупнение и централизация.
У нас в девяностые тоже бытовало заблуждение, что сейчас обанкротим крупные совхозы, коров раздадут фермерам и они всех накормят. А жизнь привела к тому, что фермеры либо разорились, либо поумирали от невыносимого труда, а рулить стали агрохолдинги.
Да в принципе нормально, прочитал код с интересом. Просто с базами данных - это такая заезженная тема, что там трудно что-то придумать.
Формирование объекта-алгоритма с заданием последовательности действий? Действия со счетом например. Сначала то, потом это, задать параметры, выполнить то и так далее. Да, спасибо за идею, надо подумать.
Другой разработчик, когда ему понадобится выбрать пользователей по имени, видя в базе кода вашу
getById, скопипастит ваш код рядышком, немного подправит и сделает getByName.Я правильно понимаю?
Точно такой-же копипастинг, как и просто использование TypedQuery. Только появляется прокладка-велосипед.
Если же вы предложите не имплементировать getById, а прямо писать этот кусок в классе бизнес-логики, то это грубейший залет. Проникновение деталей реализации в бизнес-код.
Правильно - реализация репозитория с методами UserRepository.getById, UserRepository.getByName, UserRepository.getByFamilyName и так далее. Хоть с сотней методов. И да, если они написаны копипастом с небольшими изменениями, ничего страшного.
В чем проблема?