Это просто очевидно. Ни за что не поверю, что вы когда-то были по другую сторону баррикад на месте тех людей, которым нравится пользоваться вимом, а потом вдруг взяли в руки мышку и переметнулись.
покажите, пожалуйста, пальцем, где я приводил диаграмму классов в качестве преимущества?
Да вот, показываю:
… Вот например, моя ИДЕ умеет строить диаграмму классов. Очень полезная фича. Пару раз в день я ее использую. ...
Но я понимаю, вы, наверное, что-то другое имели ввиду.
Наверное, что «это не преимущество IDE, а недостаток вима». Или что «это не преимущество, а достоинство».
И причем здесь
пребывать в иллюзиях обладания тайными знаниями, «навыками» и мнить себя крутым хакером
? Вы себе это сами придумали. Знания настолько тайные, что вас
… конкретно заколебали раз в неделю появляющиеся мамкины хакеры, рассказывающие про какие-то чудеса...
Это, я извиняюсь, уже совсем абсурд.
И я в целом то и не хотел вас убеждать в том, что с вимом вы станете продуктивнее. Если нравится нажимать на кнопки в менюшках, то и не надо отказывать себе в удовольствии это делать.
Я просто отметил, что в своих комментариях вы приводите такие доводы и задаете такие вопросы, которые пользователи вима уже сами себе задавали и сами через эти сомнения проходили.
Вот вы сравниваете интерфейс вима и Идеи. По-вашему, пользователь вима живет в вакууме и не знает про Идею? Конечно знает, скорее всего, он уже использует ее хоткеи и просто хочет сделать свою работу еще более удобной.
Сейчас с вима не начинают как когда-то, когда не было IDE, сейчас наоборот вим тянут в IDE.
Большинство тех, кто пользуется вимом, так же как и вы сейчас, когда-то испытывали к нему отвращение и помнят себя на вашем месте. Но вы на их месте ещё не были, поэтому очень сложно обьяснить «в чем прикол».
Но я постараюсь поставить вас на место этих людей)
Знаете, есть такие игры для детей, которые учат программировать. И в них условные конструкции, циклы, переменные - это такие графические блоки и их надо мышкой или пальцем перетаскивать по экрану, вставлять друг в друга и тд.
Вот, как человек, который пишет код с клавиатуры, постарайтесь объяснить плюсы своего способа человеку, который не понимает зачем надо печатать что-то с клавиатуры. Зачем ему помнить форматирование, как пишутся операторы, модификаторы и тд., если ему удобнее все в менюшке найти? И то, что для вас будет какой-то базовой вещью, он будет искать в интерфейсе.
Я обожаю Идею, без многих ее плюшек было бы совсем грустно, но без вим плагина я обожал бы ее меньше.
Но когда диаграмму классов приводят как ее конкурентное преимущество, которым удобно пользоваться пару раз в день, я все же начинаю представлять те самые игры, где вместо кода - графические кубики.
Зачем?
Get заботливо припаркует поток (в зависимости от реализации future, конечно) вместо того, чтобы жечь ресурсы в цикле (в зависимости от реализации ос, конечно).
И я полагаю, что все таки результат вычисления нужен чаще всего тогда, когда без него уже не обойтись.
Так что, как мне кажется, наоборот не надо городить логику на isDone просто так, если можно просто вызвать get.
В каком смысле спорное заявление? Перефразирую немного: без вынесения интерфейсов, в классах с бизнес-логикой пришлось бы импортировать классы из модуля с доступом к данным, что означало бы, что бизнес логика зависела бы от логики доступа к данным.
И тут совершенно не важно, используется Repository или нет.
В общем случае это применимо ко всему тому, что вы перечислили. Но так как в случае с сервисами/кластерами абстракции будут являться не интерфейсами, очевидно, что я имею ввиду пекеджи.
>>Я предположу, вы хотели сказать, что зависимости должны быть в отношении слоёв приложения. Где внутренний слой доменная модель, которая ни от чего не зависит.
Да, это именно из той самой книжки Мартина. Но нет, я имел ввиду именно то, что написал. Два модуля: с бизнес-логикой и с логикой доступа к данным. Для этого примера все равно как организована сама бизнес логика, скажу даже еще более страшную вещь: не обязательно должна быть модель домена.
Я думаю, что, по меньшей мере, название этой книги говорит о чем она.
И не совсем понял при чем там монолиты из 2005-тых? Описанные там принципы можно применять хоть в монолитах из 2005, хоть в микросервисах 2021.
SOLID — это скорее про архитектуру, а не про код. И интерфейс на все не нужен, он нужен, в частности, там, где надо, собственно, инвертировать зависимость.
Долго расписывать, советую почитать про это в первоисточнике — у Роберта Мартина в книге «Чистая архитектура», там в конце есть даже несколько страниц относительно архитектуры в типичных спринговых приложениях. Вообще интересная книжка, сам не так уж прям давно читал, получил удовольствие.
Не совсем понял. «Выделение интерфейсов» и «формировании абстракций» — это же одно и то же.
Зависимость должна быть в направлении модулей более верхних уровней. И оба типа модулей должны зависеть от абстракций: нижние — по иерархии наследования, верхние — по композиции.
Тоесть в простейшем варианте, модуль с сервисами (который содержит бизнес логику и выше модуля доступа к данным) должен включать в себя интерфейсы доступа к данным и «зависеть» от них в классах сервисов. А модуль доступа к данным должен реализовывать интерфейсы из модуля сервисов. Таким образом получается инвертировать зависимость в сторону бизнес логики. Тоесть модуль доступа к данным знает про модуль сервисов, а модуль сервисов про модуль доступа к данным — уже нет. В ином случае, без вынесения интерфейсов, бизнес логика зависела бы от логики доступа к данным.
Очень интересно, жду финальный релиз.
Есть несколько вопросов по теме:
1. Где можно искать библиотеки, созданные сообществом? В смысле есть какой-то аналог js.coach для Реакта и mvnrepository.com для Java?
2. Существует ли какой-то способ отправки пуш-уведомлений во Флаттер-приложение без использования Firebase? Имею ввиду из коробки, без написания своей нативной библиотеки.
3. Я, например, хочу сделать приложение, которое будет выглядеть нативно и на андроиде и на айфоне. Возможно ли на Флаттере это сделать в одной кодовой базе и без проверок типа «if(isOnAndroid){...}else{...}»?
Спасибо большой за статью!
Только вчера интересовался, может ли флаттер выглядеть нативно без проверки платформы. Оказывается, что не может.
Вообще, очень интересный инструмент, но пока что смущают подобные мелочи.
Есть еще пара вопросов по флаттеру:
1. Где можно искать библиотеки, созданные сообществом? В смысле есть какой-то аналог js.coach для Реакта и mvnrepository.com для Java?
2. Существует ли какой-то способ отправки пуш-уведомлений во Флаттер-приложение без использования Firebase? Имею ввиду из коробки, без написания своей нативной библиотеки.
Очень интересное мнение на самом деле, что рефакторинг приводит к увеличению багов.
И что разработчику нужно любой рефакторинг согласовывать с бизнесом. То есть, безусловно, если бизнес — это компания из 5 человек и владелец бизнеса — сам принимает участие в разработке, то это разумно. Иначе — это как если бы повара в ресторане согласовывали уборку своего рабочего места каждый вечер с владельцем.
Поэтому ни от одного рефакторинга пользователю лучше не станет.
Ну раз такое дело, то заодно можно распустить и весь обслуживающий персонал в IT-компаниях, а так же большую часть менеджмента, hr-ов и вот это вот все. Не просто так, а потому, что они не занимаются непосредственно разработкой фич, которые должны сделать лучше пользователям.
За быстродействие!
Что значит рефакторинг за быстродействие?
Для быстродействия занимаются оптимизацией, а никак не рефакторингом. Часто бывает наоборот, что рефакторинг замедляет программу, а оптимизация усложняет исходный код.
В дереве не может быть циклов. Оно по определению ациклично.
Да вот, показываю:
Но я понимаю, вы, наверное, что-то другое имели ввиду.
Наверное, что «это не преимущество IDE, а недостаток вима». Или что «это не преимущество, а достоинство».
И причем здесь ? Вы себе это сами придумали. Знания настолько тайные, что вас
Это, я извиняюсь, уже совсем абсурд.
И я в целом то и не хотел вас убеждать в том, что с вимом вы станете продуктивнее. Если нравится нажимать на кнопки в менюшках, то и не надо отказывать себе в удовольствии это делать.
Я просто отметил, что в своих комментариях вы приводите такие доводы и задаете такие вопросы, которые пользователи вима уже сами себе задавали и сами через эти сомнения проходили.
Вот вы сравниваете интерфейс вима и Идеи. По-вашему, пользователь вима живет в вакууме и не знает про Идею? Конечно знает, скорее всего, он уже использует ее хоткеи и просто хочет сделать свою работу еще более удобной.
Сейчас с вима не начинают как когда-то, когда не было IDE, сейчас наоборот вим тянут в IDE.
Это не то, чтобы спор на самом деле.
Большинство тех, кто пользуется вимом, так же как и вы сейчас, когда-то испытывали к нему отвращение и помнят себя на вашем месте. Но вы на их месте ещё не были, поэтому очень сложно обьяснить «в чем прикол».
Но я постараюсь поставить вас на место этих людей)
Знаете, есть такие игры для детей, которые учат программировать. И в них условные конструкции, циклы, переменные - это такие графические блоки и их надо мышкой или пальцем перетаскивать по экрану, вставлять друг в друга и тд.
Вот, как человек, который пишет код с клавиатуры, постарайтесь объяснить плюсы своего способа человеку, который не понимает зачем надо печатать что-то с клавиатуры. Зачем ему помнить форматирование, как пишутся операторы, модификаторы и тд., если ему удобнее все в менюшке найти? И то, что для вас будет какой-то базовой вещью, он будет искать в интерфейсе.
Я обожаю Идею, без многих ее плюшек было бы совсем грустно, но без вим плагина я обожал бы ее меньше.
Но когда диаграмму классов приводят как ее конкурентное преимущество, которым удобно пользоваться пару раз в день, я все же начинаю представлять те самые игры, где вместо кода - графические кубики.
Всмысле где?) Вот же: yyp
Вбивать туда же, куда и Ctrl+..., Shift+...
Зачем?
Get заботливо припаркует поток (в зависимости от реализации future, конечно) вместо того, чтобы жечь ресурсы в цикле (в зависимости от реализации ос, конечно).
И я полагаю, что все таки результат вычисления нужен чаще всего тогда, когда без него уже не обойтись.
Так что, как мне кажется, наоборот не надо городить логику на isDone просто так, если можно просто вызвать get.
И тут совершенно не важно, используется Repository или нет.
>>Я предположу, вы хотели сказать, что зависимости должны быть в отношении слоёв приложения. Где внутренний слой доменная модель, которая ни от чего не зависит.
Да, это именно из той самой книжки Мартина. Но нет, я имел ввиду именно то, что написал. Два модуля: с бизнес-логикой и с логикой доступа к данным. Для этого примера все равно как организована сама бизнес логика, скажу даже еще более страшную вещь: не обязательно должна быть модель домена.
И не совсем понял при чем там монолиты из 2005-тых? Описанные там принципы можно применять хоть в монолитах из 2005, хоть в микросервисах 2021.
SOLID — это скорее про архитектуру, а не про код. И интерфейс на все не нужен, он нужен, в частности, там, где надо, собственно, инвертировать зависимость.
Долго расписывать, советую почитать про это в первоисточнике — у Роберта Мартина в книге «Чистая архитектура», там в конце есть даже несколько страниц относительно архитектуры в типичных спринговых приложениях. Вообще интересная книжка, сам не так уж прям давно читал, получил удовольствие.
Не совсем понял. «Выделение интерфейсов» и «формировании абстракций» — это же одно и то же.
Зависимость должна быть в направлении модулей более верхних уровней. И оба типа модулей должны зависеть от абстракций: нижние — по иерархии наследования, верхние — по композиции.
Тоесть в простейшем варианте, модуль с сервисами (который содержит бизнес логику и выше модуля доступа к данным) должен включать в себя интерфейсы доступа к данным и «зависеть» от них в классах сервисов. А модуль доступа к данным должен реализовывать интерфейсы из модуля сервисов. Таким образом получается инвертировать зависимость в сторону бизнес логики. Тоесть модуль доступа к данным знает про модуль сервисов, а модуль сервисов про модуль доступа к данным — уже нет. В ином случае, без вынесения интерфейсов, бизнес логика зависела бы от логики доступа к данным.
Разумеется, я имел ввиду D, а не I.
Хм, а про что, по-твоему, I в SOLID? Как инвертировать зависимость без выноса интерфейса?
Есть несколько вопросов по теме:
1. Где можно искать библиотеки, созданные сообществом? В смысле есть какой-то аналог js.coach для Реакта и mvnrepository.com для Java?
2. Существует ли какой-то способ отправки пуш-уведомлений во Флаттер-приложение без использования Firebase? Имею ввиду из коробки, без написания своей нативной библиотеки.
3. Я, например, хочу сделать приложение, которое будет выглядеть нативно и на андроиде и на айфоне. Возможно ли на Флаттере это сделать в одной кодовой базе и без проверок типа «if(isOnAndroid){...}else{...}»?
Только вчера интересовался, может ли флаттер выглядеть нативно без проверки платформы. Оказывается, что не может.
Вообще, очень интересный инструмент, но пока что смущают подобные мелочи.
Есть еще пара вопросов по флаттеру:
1. Где можно искать библиотеки, созданные сообществом? В смысле есть какой-то аналог js.coach для Реакта и mvnrepository.com для Java?
2. Существует ли какой-то способ отправки пуш-уведомлений во Флаттер-приложение без использования Firebase? Имею ввиду из коробки, без написания своей нативной библиотеки.
Так, и что? Что с ней не так?
А с этим какие проблемы вообще?
На том же реакт нейтиве пишут делают приложения не только большие компании. И это прекрасно, что он подходит и для тех и для других.
И что разработчику нужно любой рефакторинг согласовывать с бизнесом. То есть, безусловно, если бизнес — это компания из 5 человек и владелец бизнеса — сам принимает участие в разработке, то это разумно. Иначе — это как если бы повара в ресторане согласовывали уборку своего рабочего места каждый вечер с владельцем.
Ну раз такое дело, то заодно можно распустить и весь обслуживающий персонал в IT-компаниях, а так же большую часть менеджмента, hr-ов и вот это вот все. Не просто так, а потому, что они не занимаются непосредственно разработкой фич, которые должны сделать лучше пользователям.
Что значит рефакторинг за быстродействие?
Для быстродействия занимаются оптимизацией, а никак не рефакторингом. Часто бывает наоборот, что рефакторинг замедляет программу, а оптимизация усложняет исходный код.