Всё начиналось с Dojo, потом Ext.js. Мы писали на Polymer 0.5, и, когда он стал deprecated (с выходом версии 1.0), перед нами встал вопрос — что же выбрать?
Проект скачет не по трансляторам, а по библиотекам UI и фреймворкам. Очень интересно как на это смотрит владелец проекта или тот, за чьи деньги проект переписывали 3 раза. Проект явно существует без "архитектора".
Такой большой и старый проект уже должен понять, что не стоит завязываться на фреймворки. Нужно писать модульный код, в котором ни какая библиотека (а тем более фреймворк) не пронизывает все слои приложения. Как кто то сказал Не учите фреймворки, учите архитектуру
MCTS не хватает, потому что дерево ходов слишком широкое. Для каждой позиции в среднем есть 250 вариантов хода. А AlfaGo сразу отсекает по дерево перебора ширине, плюс по ходу перебора отсекает по глубине.
Как происходит выбор ответа в ходе диалога? Как я понял, нужно прогнать через нейросеть k раз контекст вопроса + вариант ответа №i (i от 0 до k), и затем выбрать ответ, которому сеть поставила максимальный балл?
Аргументируйте свою позицию ссылками на авторитетные книги, статьи классиков проектирования. Если же в компании даже не знают про таких «авторитетов», то значит пытайтесь просветить людей докладами, примерами. Если же ничего не помогает, это значит, что люди не хотят профессионально развиваться — в такой компании я бы не стал задерживаться.
Convert выглядит так будто он не связан с классом Manager, поэтому это должен быть некий отдельный MessageConverter. Так как Message «не содержит» поведения, то ничего плохого в создании его через new.
Вообще лично мне пример решения с House не очень нравится, поскольку мы перенесли инстанцирование в фабрику, но не избавились от зависимости от конкретной реализации, просто перенесли её.
Для того, чтобы добиться тестируемости (а именно это было целью) не обязательно избавляться от конкретной реализации. Если бездумно скрывать все классы за интерфейсами, то ни к чему, кроме разбухания кодовой базы и усложнению поддержки, это не приведет.
Тестируемый код не обязан иметь тесты. Можно лишь гипотетически представить как будет написан тест на класс. Если представить получилось — значит код тестируемый.
Да вы правы, не совсем верно, что нет способа подменить, LoginService.setForTest(...) даст возможность. Но такой подход к написанию тестов не является «правильным», о чем говорится в начале статьи:
Далее под понятием тест подразумевается красивый и чистый unit тест, который написан без различных хаков, без дополнительных «магических» библиотек для подмены зависимостей на лету, и прочего удовольствия, затрудняющего чтение и поддержку тестов.
Проект скачет не по трансляторам, а по библиотекам UI и фреймворкам. Очень интересно как на это смотрит владелец проекта или тот, за чьи деньги проект переписывали 3 раза. Проект явно существует без "архитектора".
Такой большой и старый проект уже должен понять, что не стоит завязываться на фреймворки. Нужно писать модульный код, в котором ни какая библиотека (а тем более фреймворк) не пронизывает все слои приложения. Как кто то сказал Не учите фреймворки, учите архитектуру
еще есть асинхронные генераторы. Пример синтаксиса:
вот тут подробнее https://www.youtube.com/watch?v=DqMFX91ToLw
не туда написалЧто? В идее Flux ни чего не сказано о глобальных переменных.
Для того, чтобы добиться тестируемости (а именно это было целью) не обязательно избавляться от конкретной реализации. Если бездумно скрывать все классы за интерфейсами, то ни к чему, кроме разбухания кодовой базы и усложнению поддержки, это не приведет.
Правильно умножать на 0.8, а не делить на 1.2