Эту статью можно воспринимать как освещение нескольких часто встречающихся вопросов у фронтенд-разрабов по дизайну.
Например, раньше в своей практике постоянно сталкивался с вопросами, что не всегда понятно как строить темы в UI-китах или правильно применять те или иные компоненты. Поэтому надеюсь, что для других это хоть немного прольет свет на такие вопросы:)
Для начала стоит поставить мало-мальское произношение, а далее учить распространенные фразовые глаголы в комбинациях их в предложениях, а также шаблонные предложения.
Читать тоже стоит, но только с целью пополнения словарного запаса и с использованием новых выученных слов в ситуативных диалогах. Без постоянной практики эти слова попросту забудутся.
В общем, тут нужна каждодневная практика и полное погружение, чтобы поднять скилл. Как говорится: "Wer rastet der rostet".
Да, ставить юнит-тесты во главу угла действительно не стоит. Однако, через них можно выявить некоторые изъяны в приложении, например, проблемы с расширяемостью компонентов.
Так сказать, взглянуть со стороны на свой код через призму тестов:)
Соглашусь, починка тестов может занять некоторое время + все 100% тестами не покроешь.
Однако, львиная доля пользы от юнит-тестирования приходится на TDD, то есть написание тестов до реализации. Не зря говорят: "Хороший код – тестируемый код".
YAGNI и KISS это чисто рекомендации, и слепо следовать этим правилам не есть хорошо. Так же как и пихать паттерны куда не попадя. Важен все-таки баланс.
Например, весь код можно и в одном файле написать. А что, портянка кода как на ладони и лазить никуда не надо, все "чертовски просто", KISS "работает". Вот только со временем всю эту "простоту" будет все сложнее и сложнее поддерживать. Поэтому код и раскладывают по папочкам и файлам с красивыми именами.
То же самое и с функцией login. Писать в функции множество if/else условий для вызова разных функций ради "простоты" не является примером следования YAGNI и KISS, так как это будет сложнее поддерживать в дальнейшем. Поэтому тут и применяют паттерн стратегия.
А что если в один прекрасный момент понадобится, к примеру, добавить доп. параметры или вызовы сторонних функций? Получается, у нас login «потолстеет», и чтобы вернуть его в прежнюю форму придется приложить некоторые усилия...
function login(mode, param1, param2) {
if (mode === "account") {
// здесь предаем param1
loginWithPassword(param1);
} else if (mode === "email") {
// а здесь param2
loginWithEmail(param2);
} else if (mode === "mobile") {
// а здесь еще сделаем сайд-эффект
makeSideEffect();
loginWithMobile();
}
// А потом добавим еще 1001-проверку, которые также возможно потребуют
// доп. параметры или предварительные обработки.
// ...
}
Да, как раз https://medium.com/clean-code-channel/observer-vs-pub-sub-pattern-4fc1da35d11 описано, что для издателя нужен какой-либо промежуточный компонент, который будет перенаправлять события издателя нужным подписчикам, то есть этот компонент скрывает детали функциональности модулей-подписчиков и издатель тем самым не взаимодействует напрямую с этими модулями. Возможно, он будет посложнее в реализации чем Наблюдатель...
Суть статьи не заключается в том, чтобы побудить вас перейти с MVC на Redux, а в том, чтобы взглянуть на MVC-Flux-Redux спустя время и подвести итоги не только с теоретической стороны, но и с практической, так как в основном по этому вопросу предоставляют только теорию.
Про Human Interface Guidelines не слышал, но обязательно ознакомлюсь, спасибо!
Вы покрыли довольно много аспектов, которые трудно упаковать в одну статью.
Однако, вы раскрыли много интересных тем, в которые круто было бы погрузиться.
Кстати, статьи у вас интересные, обязательно добавлю к себе и буду изучать.
Эту статью можно воспринимать как освещение нескольких часто встречающихся вопросов у фронтенд-разрабов по дизайну.
Например, раньше в своей практике постоянно сталкивался с вопросами, что не всегда понятно как строить темы в UI-китах или правильно применять те или иные компоненты. Поэтому надеюсь, что для других это хоть немного прольет свет на такие вопросы:)
Под расширяемостью имеется в виду то, что часто на компонент накручивается больше чем надо, и через тесты можно выявить это.
В плане тестирования вью согласен с вами, такие тесты хрупкие и ломаются очень часто.
Для начала стоит поставить мало-мальское произношение, а далее учить распространенные фразовые глаголы в комбинациях их в предложениях, а также шаблонные предложения.
Читать тоже стоит, но только с целью пополнения словарного запаса и с использованием новых выученных слов в ситуативных диалогах. Без постоянной практики эти слова попросту забудутся.
В общем, тут нужна каждодневная практика и полное погружение, чтобы поднять скилл. Как говорится: "Wer rastet der rostet".
Да, ставить юнит-тесты во главу угла действительно не стоит. Однако, через них можно выявить некоторые изъяны в приложении, например, проблемы с расширяемостью компонентов.
Так сказать, взглянуть со стороны на свой код через призму тестов:)
Да, в целом юнит-тесты стоит писать на сложную разветвленную бизнес-логику, например, в библиотеках.
Соглашусь, починка тестов может занять некоторое время + все 100% тестами не покроешь.
Однако, львиная доля пользы от юнит-тестирования приходится на TDD, то есть написание тестов до реализации. Не зря говорят: "Хороший код – тестируемый код".
Если нам надо дождаться ререндера, то только через nextTick, а обновленное состояние, думаю, можно получить и без него, но надо проверять.
YAGNI и KISS это чисто рекомендации, и слепо следовать этим правилам не есть хорошо. Так же как и пихать паттерны куда не попадя. Важен все-таки баланс.
Например, весь код можно и в одном файле написать. А что, портянка кода как на ладони и лазить никуда не надо, все "чертовски просто", KISS "работает".
Вот только со временем всю эту "простоту" будет все сложнее и сложнее поддерживать. Поэтому код и раскладывают по папочкам и файлам с красивыми именами.
То же самое и с функцией login. Писать в функции множество if/else условий для вызова разных функций ради "простоты" не является примером следования YAGNI и KISS, так как это будет сложнее поддерживать в дальнейшем. Поэтому тут и применяют паттерн стратегия.
А что если в один прекрасный момент понадобится, к примеру, добавить доп. параметры или вызовы сторонних функций? Получается, у нас login «потолстеет», и чтобы вернуть его в прежнюю форму придется приложить некоторые усилия...
Да, как раз https://medium.com/clean-code-channel/observer-vs-pub-sub-pattern-4fc1da35d11 описано, что для издателя нужен какой-либо промежуточный компонент, который будет перенаправлять события издателя нужным подписчикам, то есть этот компонент скрывает детали функциональности модулей-подписчиков и издатель тем самым не взаимодействует напрямую с этими модулями. Возможно, он будет посложнее в реализации чем Наблюдатель...
Да, вы верно поняли.
Суть статьи не заключается в том, чтобы побудить вас перейти с MVC на Redux, а в том, чтобы взглянуть на MVC-Flux-Redux спустя время и подвести итоги не только с теоретической стороны, но и с практической, так как в основном по этому вопросу предоставляют только теорию.