|
Stream API
|
|||
---|---|---|---|
#18+
mayton, немного не так он топит за то чтобы литералов вообще не было в джава коде все должнго выноситься в проперти файлы, и твой код не должен перекомпилироваться при изменении констант я думаю что это очень грамотное решение (в первый раз я с блиновым согласен)))) хочу нашим разрабам такое предложить ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2020, 22:44 |
|
Stream API
|
|||
---|---|---|---|
#18+
mayton И чего мы добились? Код стал толще. И форматирование - неочевидно. ты не понял его мысли ) он хочет все константы выносить в application.properties чтобы при старте приложения при изменннии констант приложение не перекомпилировалось я с ним полностью согласен если сегодня у нас образно заемщик в справочнике написан как borrower а завтра будет как coborrower то придется приложение передеплоить и рефакторить код а в случае с пропертями просто перезапустить с испрвленым скриптом ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2020, 22:49 |
|
Stream API
|
|||
---|---|---|---|
#18+
2) Java-компиллятору вообще плевать на блиновские рефакторинги и он сводит 2 одинаковых литерала в 1 после компилляции .class файла. Ты можешь это проверить если дизассемблировать. Тоесть внедрение стринговых констант это эстетическое и организационное действие. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2020, 22:52 |
|
Stream API
|
|||
---|---|---|---|
#18+
asv79 mayton И чего мы добились? Код стал толще. И форматирование - неочевидно. ты не понял его мысли ) он хочет все константы выносить в application.properties чтобы при старте приложения при изменннии констант приложение не перекомпилировалось я с ним полностью согласен если сегодня у нас образно заемщик в справочнике написан как borrower а завтра будет как coborrower то придется приложение передеплоить и рефакторить код а в случае с пропертями просто перезапустить с испрвленым скриптом Это очень странная крайность - которая побочных эффектом имеет кучу эффорта при разработке. Чтоб константа была полезной как настройка приложения - надо еще доказать что она должна изменяться при рестарте. А доказывать это надо обсуждая с коллегами и с бизнесом эту возможность. Беря во внимание дефицит времени на обсуждение - ябы сказал что коллеги пошлют Блинова нах вместе со всеми кто впадает в такие крайности. Код должен читаться как книга на английском. А чтение .properties и кода это как чтение конституции с поправками. Вроде и читаешь но раздражает постоянние переключения зрения с одного на другое. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2020, 22:56 |
|
Stream API
|
|||
---|---|---|---|
#18+
mayton asv79 пропущено... ты не понял его мысли ) он хочет все константы выносить в application.properties чтобы при старте приложения при изменннии констант приложение не перекомпилировалось я с ним полностью согласен если сегодня у нас образно заемщик в справочнике написан как borrower а завтра будет как coborrower то придется приложение передеплоить и рефакторить код а в случае с пропертями просто перезапустить с испрвленым скриптом Это очень странная крайность - которая побочных эффектом имеет кучу эффорта при разработке. Чтоб константа была полезной как настройка приложения - надо еще доказать что она должна изменяться при рестарте. А доказывать это надо обсуждая с коллегами и с бизнесом эту возможность. Беря во внимание дефицит времени на обсуждение - ябы сказал что коллеги пошлют Блинова нах вместе со всеми кто впадает в такие крайности. Код должен читаться как книга на английском. А чтение .properties и кода это как чтение конституции с поправками. Вроде и читаешь но раздражает постоянние переключения зрения с одного на другое. я и с тобой тоже согласен ,но и он тоже прав- код не должен пекомилироваться если код валюты поменяется с 643 на 810 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2020, 23:04 |
|
Stream API
|
|||
---|---|---|---|
#18+
asv79 код не должен пекомилироваться если код валюты поменяется с 643 на 810 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2020, 23:10 |
|
Stream API
|
|||
---|---|---|---|
#18+
PetroNotC Sharp asv79 код не должен пекомилироваться если код валюты поменяется с 643 на 810 помоему 196 страница его последней книги,завтра могу точно сказать ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2020, 23:16 |
|
Stream API
|
|||
---|---|---|---|
#18+
PetroNotC Sharp asv79 код не должен пекомилироваться если код валюты поменяется с 643 на 810 ну и вообще как бы да - что тебе мешает вместо константны прописать value1 и тд в и пропертях указать значение почему кто то должен пересобирать твое приложение если какая то цифа поменяется? обоснуй это ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2020, 23:18 |
|
Stream API
|
|||
---|---|---|---|
#18+
А когда к примеру приходит json {"lastname": "Иванов"}, а станет приходить {"surname": "Иванов"}. Название lastname тоже надо в конфиги? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2020, 23:21 |
|
Stream API
|
|||
---|---|---|---|
#18+
asv79 спроси у блинова,он вроде еще жив) Лучше завтра не надо. ПТ. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2020, 23:22 |
|
Stream API
|
|||
---|---|---|---|
#18+
asv79 почему кто то должен пересобирать твое приложение если какая то цифа поменяется? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.03.2020, 23:23 |
|
Stream API
|
|||
---|---|---|---|
#18+
asv79 тоесть вот я сдаю проект небольшой заказчику у меня там в пропертях прописаны кастомные настройки при старте приложухи достаточно прописать -Dspring.datasource.username=postgres Ну и жестоко заставлять админа расписывать длинные и бессмысленые для него имена: Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2020, 06:47 |
|
Stream API
|
|||
---|---|---|---|
#18+
asv79 я и с тобой тоже согласен ,но и он тоже прав- код не должен пекомилироваться если код валюты поменяется с 643 на 810 ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2020, 06:50 |
|
Stream API
|
|||
---|---|---|---|
#18+
SpringMan А когда к примеру приходит json {"lastname": "Иванов"}, а станет приходить {"surname": "Иванов"}. Название lastname тоже надо в конфиги? а ты не видишь разницы между key-value surname/lastname это поля DTO а 643- это значение из справочника- которое неизменно если у нас сейчас предполагается ,что кредитьы будут рублевые -валидируем по 643 - и например я соглсен с блиновым что эти значения нужно выносить в проперти,чтобы если бизнес скажет - теперь выдаем в долларах я просто рестартнул приложение с новым скриптом,без передеплоев и перекомпиляций- согласись в этом есть здавый смысл ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2020, 09:24 |
|
Stream API
|
|||
---|---|---|---|
#18+
А зачем рестарт? Давайте вспомним что есть zookeeper. Есть БД. Есть бины у которых lifecycle короче чем цикл приложения. Блинов устарел на 20 лет со своими вредными советами. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2020, 09:38 |
|
Stream API
|
|||
---|---|---|---|
#18+
asv79 SpringMan А когда к примеру приходит json {"lastname": "Иванов"}, а станет приходить {"surname": "Иванов"}. Название lastname тоже надо в конфиги? а ты не видишь разницы между key-value surname/lastname это поля DTO а 643- это значение из справочника- которое неизменно если у нас сейчас предполагается ,что кредитьы будут рублевые -валидируем по 643 - и например я соглсен с блиновым что эти значения нужно выносить в проперти,чтобы если бизнес скажет - теперь выдаем в долларах я просто рестартнул приложение с новым скриптом,без передеплоев и перекомпиляций- согласись в этом есть здавый смысл Ты серьезно о такой мелочи решил поговорить? Если... То берем локальную переменную. Если...то берем поле класса. Если... То берем константу. Про это говорить в теме Stream? Тут уже обижаются что уровень упал. Вот из за таких вопросов он и упал. Либо ты делаешь вброс. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2020, 10:02 |
|
Stream API
|
|||
---|---|---|---|
#18+
mayton А зачем рестарт? Давайте вспомним что есть zookeeper. Есть БД. Есть бины у которых lifecycle короче чем цикл приложения. Блинов устарел на 20 лет со своими вредными советами. Книга в довольно свежей редакции -2015 помоему) не ну мы же выносим например конекты в проперти и ок- не буду же я каждый раз перекомпилировать приложение если база адрес поменяет ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2020, 10:27 |
|
Stream API
|
|||
---|---|---|---|
#18+
На деле все это, как говорит коллега skyANA, влажные фантазии Блиновых и прочих Ivory Tower Architechts, оторванных от реальности. Бизнес логика редко меняется без изменения кода, поэтому вынесение бизнес констант в конфиги, как правило, неоправданно. А если быстрый цикл CI/CD, то вообще ненужно. Мы, например, деплоим в прод хоть по десять раз на день, если нужно. Что имеет смысл выносить в конфиги, так это фича свитчи, трешхолды, таймауты и прочие "подстроечники", но тогда из нужно делать изменяемыми без перезапуска приложения. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2020, 10:37 |
|
Stream API
|
|||
---|---|---|---|
#18+
asv79 не ну мы же выносим например конекты в проперти и ок- не буду же я каждый раз перекомпилировать приложение если база адрес поменяет Ты не удивился что солнце круглое? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2020, 10:44 |
|
Stream API
|
|||
---|---|---|---|
#18+
fixxer поэтому вынесение бизнес констант в конфиги, ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2020, 10:45 |
|
Stream API
|
|||
---|---|---|---|
#18+
asv79 а ты не видишь разницы между key-value surname/lastname это поля DTO а 643- это значение из справочника- которое неизменно если у нас сейчас предполагается ,что кредитьы будут рублевые -валидируем по 643 - и например я соглсен с блиновым что эти значения нужно выносить в проперти,чтобы если бизнес скажет - теперь выдаем в долларах я просто рестартнул приложение с новым скриптом,без передеплоев и перекомпиляций- согласись в этом есть здавый смысл Ты во внешний сервис посылаешь json c lastname. Если бизнес скажет - теперь переходим на новую версию сервиса с surname, то ты просто рестартанул приложение, без передеплоев и перекомпиляции ) На бумаге переходы 643->доллары и lastname->surname могут выглядеть логично. Как правило бизнес параметры нет смысла выносить. Если они как-то меняются, то меняется бизнес логика, а не только константа. Если у вас сбер решит перейти с рубля на доллар, то бизнес процессы поменяются так, что твой сервис вообще исчезнет и появиться что-то новое. PS опять же про передеплой и перекомпиляцию всем как правило не важно. Это может быть только важно девопсам, который конфиги к базе меняют и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2020, 11:07 |
|
Stream API
|
|||
---|---|---|---|
#18+
SpringMan Если у вас сбер решит перейти с рубля на доллар, то бизнес процессы поменяются так, что твой сервис вообще исчезнет и появиться что-то новое. Поэтому обсуждаемый вопрос настолько мелкий в обсуждении. Как экономия на спичках. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2020, 11:13 |
|
Stream API
|
|||
---|---|---|---|
#18+
asv79 mayton А зачем рестарт? Давайте вспомним что есть zookeeper. Есть БД. Есть бины у которых lifecycle короче чем цикл приложения. Блинов устарел на 20 лет со своими вредными советами. Книга в довольно свежей редакции -2015 помоему) не ну мы же выносим например конекты в проперти и ок- не буду же я каждый раз перекомпилировать приложение если база адрес поменяет Смотри дальше. Если ты разрабатываешь кластерное приложение. Которое будте развернуто на 100 узлов. То сопрвождение пропертей на всех 100 узлах станет технической проблемой. Надо будет держать штат dev-ops. Короче трата денег. У Spring Cloud есть коробочные решения которые опираются либо на Zookeeper либо на другие распределенные и очень отказоустойчивые решения. Вобщем к чему я это. Ты у Блинова услышал рекомендацию - выносить в проперти те настройки которые должны конфигурироваться отделом сопровождения. Рекомендация - верная. Но способ имплементации - старый. И непригодный для облачных систем. И если у тебя в приложении 100500 констант то это не значит что тебе надо создавать properties с простыней настроек. Ведь их надо будет группировать. Документировать и прояснять внутренние зависимости одних пропертей от других. Вобщем там появляется другой технический долг который в совокупности может быть еще хуже чем было раньше. Короче - грумить каждое свойство с командой разработки. И голосовать. Доречі є така українська поговорка - Шо занадто - то не здраво . Очень отражает смысл. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2020, 11:37 |
|
Stream API
|
|||
---|---|---|---|
#18+
mayton asv79 пропущено... Книга в довольно свежей редакции -2015 помоему) не ну мы же выносим например конекты в проперти и ок- не буду же я каждый раз перекомпилировать приложение если база адрес поменяет Смотри дальше. Если ты разрабатываешь кластерное приложение. Которое будте развернуто на 100 узлов. То сопрвождение пропертей на всех 100 узлах станет технической проблемой. Надо будет держать штат dev-ops. Короче трата денег. У Spring Cloud есть коробочные решения которые опираются либо на Zookeeper либо на другие распределенные и очень отказоустойчивые решения. Вобщем к чему я это. Ты у Блинова услышал рекомендацию - выносить в проперти те настройки которые должны конфигурироваться отделом сопровождения. Рекомендация - верная. Но способ имплементации - старый. И непригодный для облачных систем. И если у тебя в приложении 100500 констант то это не значит что тебе надо создавать properties с простыней настроек. Ведь их надо будет группировать. Документировать и прояснять внутренние зависимости одних пропертей от других. Вобщем там появляется другой технический долг который в совокупности может быть еще хуже чем было раньше. Короче - грумить каждое свойство с командой разработки. И голосовать. Доречі є така українська поговорка - Шо занадто - то не здраво . Очень отражает смысл. кое что выносится в проперти ,тут блинов прав. То что он говорит,что приложение с литералами в коде говно - я тоже не согласен ... |
|||
:
Нравится:
Не нравится:
|
|||
11.03.2020, 13:35 |
|
|
start [/forum/topic.php?fid=59&msg=39936187&tid=2120851]: |
0ms |
get settings: |
26ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
171ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
475ms |
get tp. blocked users: |
2ms |
others: | 325ms |
total: | 1034ms |
0 / 0 |