Попадал в похожую ситуацию с удалёнкой, когда не понятно как вообще наладить контакт с коллегами. Созваниваетесь в основном по работе, в офис никто не едет, потому что никто не едет :) Большинство из разных городов. И даже попытки компании всех подружить безуспешны. В общем тема актуальная. Согласен, что "непонятно, где можно завести новые знакомства в такой ситуации."
Что касается спорт зала, хожу в зал, где вся регистрация и вход через приложение и в нём же список присутствующих с фоточками, коммуникация, какие-то челенжы и т.п.
Но пообщавшись с тренером, понял, что вроде как, этим мало кто пользуется.
Кажется корень проблемы в том, что потребителям ПО (и не только ПО), стало плевать на качество, кто-то просто не понимает разницы, кто-то привык что всё лагает и забагано. Решать все эти проблемы можно было бы хорошим отделом QA, который проводил бы качественное функциональное и нагрузочное тестирование (косвенно это увеличивало бы и внутреннее качество кода), но кажется таких отделов QA не существует или очень мало.
Частенько в работе с современным ПО наталкиваюсь на баги, которые можно было воспроизвести просто запустив это ПО и потыкать пару кнопок, как специалисты QA эти баги пропускают мне не понятно.
Любит дядюшка Боб кинуть пыль в глаза, обожаю его, весёлый мужик.
Количество аргументов функции - тут главное не загнать себя в ловушку, именованные параметры есть не только в kotlin, но и c# или php. Аргумент про то, что связанные параметры должны быть классом, справедлив, если эти совместно изменяются и потом, как только мы их сделали классом, теперь они летят большой кучей в конструктор. Как по мне много параметров ни есть проблема, как минимум в конструкторе.
Передача булевых аргументов - есть кейсы когда мы просто хотим засетить флаг, но передавать bool как режим работы - страшное дело.
Не используйте возвращаемые аргументы - вообще вроде бы такой код являет процедурой. Менять аргументы функции не умеют, за то умеют принимать ссылки на ресурс (указатели, хосты, имена файлов и т.д.) и дальше по ним изменять этот ресурс. Не подходит для ООП, но полностью от процедур не уйти, надо знать где применять.
Не используйте nullable-аргументы - наверно справедливо только для языков где nullable не указать в типе.
Stepdown rule - лучше просто не использовать приватные функции :) и перетащить всё в отдельный класс. На крайний случай в самый низ.
Switch case - в целом да. Но есть ряд исключений и как по мне дело даже е в ООП. От пользователя приходит 10 видов запросов, надо их как-то роутить, например. Не все классы можно подогнать под общий интерфейс, можно иметь два абсолютно разных класса, и абсолютно по разному их нужно обработать.
Side-эффекты - практически всё ООП на них строиться :) CQS проблему не решить, а только перенести на уровень выше. Решается проблема тестами. К слову, query не имеющие сайдов, отличаются от чистых функций, отвечающих всегда одинаково на один и тот же запрос.
Я бы сказал, что если меняется значение метода без изменения сигнатуры, то скорее всего надо переименовывать класс.
Т.е. в данном примере, если посмотреть сигнатуру метода он ничего не принимает и возвращает строку. Как назвать интерфейс класса этого метода? Чё он делает абстрагируясь от реализации? Ты его дёргаешь - он тебе какую-то строку возвращает, причём, причем не непонятно какую, ты её в него не клал. Я бы назвал этот интерфейс каким-то строко-генератором. А реализацию генератором имени строки или типо того.
Тогда при изменении реализации, я бы изменил бы название класса, или вообще ничего не менял, а просто новый класс создал бы.
Бывают случае когда нужно переименовывать метод, обычно это полное изменение сигнатуры и контракта. Фактические это создание нового метода и изменение всего клиентского кода. Можно новый метод создать, можно через IDE переименовать, он в любом случае придёт пробежаться по всему клиентскому коду.
Как вывод, IDE отличная штука, но не нужно завязывать архитектуру на возможности IDE.
я имею ввиду, что разве module-1 не является абсолютно стабильным исходя из того, что все стрелки смотрят в него, и ни одной из него (т.е. он же ни от чего не зависит, почему он не стабильный)?
Речь идёт о какой-то приблуде (так понимаю полностью самописной), которая считает метрики про которые Боб Мартин писал книжке "чистая архитектура"? Упомянутая Zipkin Dependency тоже так может?
не совсем понял: "Например, у нас падает приложение currencies, от него падает приложение api-gateway, и по цепочке от него может упасть приложение sbp. То есть, казалось бы, sbp не использует никакой функциональности currencies, но онo (приложение) транзитивно падает от того, что падает не связанное с ним приложение. " разве такая проблема не может возникнуть при отсутствии циклических зависимостей, типо того:
1) как раз с юридической точки зрения невозможно доказать что это придумал не человек
2) даже, если как доказать что это создал компутер, то тогда реально придумавшему эту мелодию невозможно будет доказать, что он сам придумал это, а не взял из этой базы.
3) как раз небольшие совпадения в различных песнях за частую достаточны, что бы считать песню плагиатом. Иначе любые каверы не попадали бы под авторское право и оно уже давно не имело бы смысла.
Нам бы бота который сам эти каналы искал, летел в тур и писал отзыв с фотками и т.д. :)
Какая-то коммуникация там есть
Попадал в похожую ситуацию с удалёнкой, когда не понятно как вообще наладить контакт с коллегами. Созваниваетесь в основном по работе, в офис никто не едет, потому что никто не едет :) Большинство из разных городов. И даже попытки компании всех подружить безуспешны. В общем тема актуальная. Согласен, что "непонятно, где можно завести новые знакомства в такой ситуации."
Что касается спорт зала, хожу в зал, где вся регистрация и вход через приложение и в нём же список присутствующих с фоточками, коммуникация, какие-то челенжы и т.п.
Но пообщавшись с тренером, понял, что вроде как, этим мало кто пользуется.
Кажется корень проблемы в том, что потребителям ПО (и не только ПО), стало плевать на качество, кто-то просто не понимает разницы, кто-то привык что всё лагает и забагано. Решать все эти проблемы можно было бы хорошим отделом QA, который проводил бы качественное функциональное и нагрузочное тестирование (косвенно это увеличивало бы и внутреннее качество кода), но кажется таких отделов QA не существует или очень мало.
Частенько в работе с современным ПО наталкиваюсь на баги, которые можно было воспроизвести просто запустив это ПО и потыкать пару кнопок, как специалисты QA эти баги пропускают мне не понятно.
Любит дядюшка Боб кинуть пыль в глаза, обожаю его, весёлый мужик.
Количество аргументов функции - тут главное не загнать себя в ловушку, именованные параметры есть не только в kotlin, но и c# или php. Аргумент про то, что связанные параметры должны быть классом, справедлив, если эти совместно изменяются и потом, как только мы их сделали классом, теперь они летят большой кучей в конструктор. Как по мне много параметров ни есть проблема, как минимум в конструкторе.
Передача булевых аргументов - есть кейсы когда мы просто хотим засетить флаг, но передавать bool как режим работы - страшное дело.
Не используйте возвращаемые аргументы - вообще вроде бы такой код являет процедурой. Менять аргументы функции не умеют, за то умеют принимать ссылки на ресурс (указатели, хосты, имена файлов и т.д.) и дальше по ним изменять этот ресурс. Не подходит для ООП, но полностью от процедур не уйти, надо знать где применять.
Не используйте nullable-аргументы - наверно справедливо только для языков где nullable не указать в типе.
Stepdown rule - лучше просто не использовать приватные функции :) и перетащить всё в отдельный класс. На крайний случай в самый низ.
Switch case - в целом да. Но есть ряд исключений и как по мне дело даже е в ООП.
От пользователя приходит 10 видов запросов, надо их как-то роутить, например.
Не все классы можно подогнать под общий интерфейс, можно иметь два абсолютно разных класса, и абсолютно по разному их нужно обработать.
Side-эффекты - практически всё ООП на них строиться :)
CQS проблему не решить, а только перенести на уровень выше.
Решается проблема тестами.
К слову, query не имеющие сайдов, отличаются от чистых функций, отвечающих всегда одинаково на один и тот же запрос.
Я бы сказал, что если меняется значение метода без изменения сигнатуры, то скорее всего надо переименовывать класс.
Т.е. в данном примере, если посмотреть сигнатуру метода он ничего не принимает и возвращает строку. Как назвать интерфейс класса этого метода? Чё он делает абстрагируясь от реализации? Ты его дёргаешь - он тебе какую-то строку возвращает, причём, причем не непонятно какую, ты её в него не клал. Я бы назвал этот интерфейс каким-то строко-генератором. А реализацию генератором имени строки или типо того.
Тогда при изменении реализации, я бы изменил бы название класса, или вообще ничего не менял, а просто новый класс создал бы.
Бывают случае когда нужно переименовывать метод, обычно это полное изменение сигнатуры и контракта. Фактические это создание нового метода и изменение всего клиентского кода. Можно новый метод создать, можно через IDE переименовать, он в любом случае придёт пробежаться по всему клиентскому коду.
Как вывод, IDE отличная штука, но не нужно завязывать архитектуру на возможности IDE.
я имею ввиду, что разве module-1 не является абсолютно стабильным исходя из того, что все стрелки смотрят в него, и ни одной из него (т.е. он же ни от чего не зависит, почему он не стабильный)?
Речь идёт о какой-то приблуде (так понимаю полностью самописной), которая считает метрики про которые Боб Мартин писал книжке "чистая архитектура"? Упомянутая Zipkin Dependency тоже так может?
В правой части разве стрелки не должны смотреть от module-1, или я не так понял?
не совсем понял: "Например, у нас падает приложение currencies, от него падает приложение api-gateway, и по цепочке от него может упасть приложение sbp. То есть, казалось бы, sbp не использует никакой функциональности currencies, но онo (приложение) транзитивно падает от того, что падает не связанное с ним приложение. " разве такая проблема не может возникнуть при отсутствии циклических зависимостей, типо того:
чё то не совсем понял с этими картинками, почему они все 3 одинаковые?
2) даже, если как доказать что это создал компутер, то тогда реально придумавшему эту мелодию невозможно будет доказать, что он сам придумал это, а не взял из этой базы.
3) как раз небольшие совпадения в различных песнях за частую достаточны, что бы считать песню плагиатом. Иначе любые каверы не попадали бы под авторское право и оно уже давно не имело бы смысла.