+
Но полезность ведь уже и не такая сферическая в вакууме становится. Попробую обе мысли более точно описать — хороший код более предсказуем (*и для бизнеса тоже)
Ну а легаси это легаси, оно не может быть плохим или хорошим
Полезность для бизнеса очень простая. Если говнокод — мы выпустим эту фичу за 14 дней, если код норм — за 7. Другой пример. Если говнокод — новый очень дорогой разработчик будет разбираться в проекте многие месяцы. При наличии же тестов, документации и хорошему отношению к качеству кода в компании — быстрее. Понятно, что идеального кода не существует, и у каждого разработчика понятие идеального кода своё. Но есть общие принципы, которыми плохой код отличается от Не плохого
А есть разница на реальных проектах? Все равно львиная доля ресурса уйдет на сериализацию/десериализацию json и бизнес логику. Да и на проектах с нагрузкой больше 1к уже инфраструктура состоит не из 1 ядра, и масштабировать придется все равно бизнес логику а не реализацию ws
Торин — гном ростом примерно 1.50-1.60, Азог — шпала под 2 метра, крупный урк-хай т. е. по умолчанию больше даже обычного орка, не говоря уже про остальных. Гном в таком случае получается одноразовый.
Ну почему же одноразовый…
А как же известный фильм?
Нечитаемость кода… соминтельно, учитывая тот факт что сейчас почти все пользуются сборщиками и читать нужно исходник а не сгенеренный код. Давайте еще скажем что минифицированный js плохо читается.
На мой взгляд все проблемы описанные в статье — скорее преимущества методологии, а не недостатки.
И если строго следовать методологии — то как минимум БЭМ не позволяет говнокодить — а только дисциплинирует и закаляет.
Речь шла про пол года назад. Дальше про орфографию и пунктуацию напишите, или по факту аргументируете почему считаете использование try/catch целесообразным ВЕЗДЕ и await в цикле «ни в какие ворота»?
8.3 еще небыло, и неизвестно как оно будет работать в дальнейшем
Точно так же я не видел чтобы использование try/catch являлось хорошим тоном в продакшне. Если можно обойтись без него — буду обходиться без него. Зачем полагаться на исключение и ждать его, если простой проверкой можно предотвратить?
Нет, это не узкое горлышко, но одна из оптимизаций, как в плане производительности так и в плане качества.
Промис вернет ошибку на уровне метода, а не на уровне логики (обработки результата запроса)
Я не говорю что лучше а что хуже. Я говорю что в каждой конкретной ситуации/проекте/компании могут применяться свои методы. И любой из вариантов имеет право на жизнь.
4) Await в цикле чтобы не дожидаться остальных запросов (как это делает promise.all), если на каком то этапе нужно все отменить.
3) вот тут достаточно убедительно https://m.habrahabr.ru/company/ruvds/blog/334806/
4) внутри транзакции могут быть не только запросы к базе, но и запросы в микросервисы или сторонние апи. В ситуации, когда всё работает — ваш вариант правильнее. Если что-то отваливается внутри — то мой вариант практичнее
Не то что бы принципиально… некоторый код полностью дублируется на клиенте, а там натив без всякий babel и прочего. А поддержка пока не сильно. Полифилы без сборщиков подключать слишком много гемороя.
2) promisify отдаст нам then и catch, что лично для меня выглядит как колбэк
3) try/catch слишком накладно для realtime под нагрузкой
4) ну извините) есть некоторые цели, например когда несколько разных запросов мы хотим выполнить параллельно, а результат отрабатывать постепенно. Например в случае с базой там могут использоваться транзакции, которым по какой то причине иногда нужно делать rollback. Так что по ситуации, для моего способа есть определенные "ворота"
Я вот не думаю что это хорошо. Когда человек привыкает к чему то хорошему, ему от этого очень тяжело отказаться, мозг перестает думать. В один прекрасный момент сотрудник скажет ок гласс, а wifi отвалился у всего цеха. Работа встала, потому что мозг не быстро сам вспомнит какие там нужны инструменты. Такой же эффект с навигаторами.
Тут еще большая разница, срендерить один раз или манипулировать этим на 60fps.Во многих случаях canvas будет лучше и по удобству и по производительности. Пруфа, к сожалению, нет
+
Но полезность ведь уже и не такая сферическая в вакууме становится. Попробую обе мысли более точно описать — хороший код более предсказуем (*и для бизнеса тоже)
Ну а легаси это легаси, оно не может быть плохим или хорошим
Полезность для бизнеса очень простая. Если говнокод — мы выпустим эту фичу за 14 дней, если код норм — за 7. Другой пример. Если говнокод — новый очень дорогой разработчик будет разбираться в проекте многие месяцы. При наличии же тестов, документации и хорошему отношению к качеству кода в компании — быстрее. Понятно, что идеального кода не существует, и у каждого разработчика понятие идеального кода своё. Но есть общие принципы, которыми плохой код отличается от Не плохого
А есть разница на реальных проектах? Все равно львиная доля ресурса уйдет на сериализацию/десериализацию json и бизнес логику. Да и на проектах с нагрузкой больше 1к уже инфраструктура состоит не из 1 ядра, и масштабировать придется все равно бизнес логику а не реализацию ws
Ну почему же одноразовый…
А как же известный фильм?
#FFFFFF
Быть может в порноиндустрии так показывают потому что до них эта тема добралась раньше всех и они вынуждены?
Я прямо уже вижу как засудят компании где в дизайне устройства черного цвета меньше чем белого
На мой взгляд все проблемы описанные в статье — скорее преимущества методологии, а не недостатки.
И если строго следовать методологии — то как минимум БЭМ не позволяет говнокодить — а только дисциплинирует и закаляет.
Точно так же я не видел чтобы использование try/catch являлось хорошим тоном в продакшне. Если можно обойтись без него — буду обходиться без него. Зачем полагаться на исключение и ждать его, если простой проверкой можно предотвратить?
Нет, это не узкое горлышко, но одна из оптимизаций, как в плане производительности так и в плане качества.
Промис вернет ошибку на уровне метода, а не на уровне логики (обработки результата запроса)
Я не говорю что лучше а что хуже. Я говорю что в каждой конкретной ситуации/проекте/компании могут применяться свои методы. И любой из вариантов имеет право на жизнь.
4) Await в цикле чтобы не дожидаться остальных запросов (как это делает promise.all), если на каком то этапе нужно все отменить.
3) вот тут достаточно убедительно https://m.habrahabr.ru/company/ruvds/blog/334806/
4) внутри транзакции могут быть не только запросы к базе, но и запросы в микросервисы или сторонние апи. В ситуации, когда всё работает — ваш вариант правильнее. Если что-то отваливается внутри — то мой вариант практичнее
В андроид браузере нету. А многие приложения с webview открывают ссылки именно там. А с новыми фичами типа foreach/filter/reduce еще печальнее
Не то что бы принципиально… некоторый код полностью дублируется на клиенте, а там натив без всякий babel и прочего. А поддержка пока не сильно. Полифилы без сборщиков подключать слишком много гемороя.
2) promisify отдаст нам then и catch, что лично для меня выглядит как колбэк
3) try/catch слишком накладно для realtime под нагрузкой
4) ну извините) есть некоторые цели, например когда несколько разных запросов мы хотим выполнить параллельно, а результат отрабатывать постепенно. Например в случае с базой там могут использоваться транзакции, которым по какой то причине иногда нужно делать rollback. Так что по ситуации, для моего способа есть определенные "ворота"
Я вот не думаю что это хорошо. Когда человек привыкает к чему то хорошему, ему от этого очень тяжело отказаться, мозг перестает думать. В один прекрасный момент сотрудник скажет ок гласс, а wifi отвалился у всего цеха. Работа встала, потому что мозг не быстро сам вспомнит какие там нужны инструменты. Такой же эффект с навигаторами.
Простите, я один заметил что слово прокрастинация слишком часто употребляется и решил заменить его на слово с буквы М?
Я написал почему так сделано