Тем не менее, рассмотренные примеры говорили, что GOTO дает выигрыш. Программа без GOTO становится более простой, однако цена — это скорость исполнения.
Рассмотрим примеры из статьи
Оба примера кода (2a и 2b) иллюстрируют алгоритм БЕЗ GOTO :)
2b — не про GOTO, а про ручную оптимизацию цикла. Увеличиваем индекс через 2, и читаем по 2 элемента на каждой итерации. То, что в 2b фигурирует GOTO — это автор так пытался сделать свою мысль более понятной для определенной аудитории. В оригинальной статье это звучит как:
And if Example 2 were really critical, I would improve on it still more by "doubling it up" so that the machine code would be essentially as follows
что можно примерно перевести как
Я бы мог еще больше улучшить программу путем "удвоения" цикла, так что ее ее машинный код [после компиляции — прим. переводчика] будет выглядеть как-то так
По существу: поймал себя на мысли, что внутренее киваю, преодолевая раздел за разделом в статье. Да, согласен, так и есть, я тоже так думаю, звучит разумно. В целом, скорее увидел подтвержение своим соображениям на эту тему, нежели нашел что-то новое. Что тоже полезно времня от времени :).
Отдельное спасибо за ссылки на другие отличные статьи, многие из которых я в свое время пропустил.
Автор этой странички считает это хаком и настаивает на том, что поддержка должна быть встроена во фреймворк. Получается, что результаты этого теста основаны на субъективном мнении, а не технической возможности/невозможности решить задачу.
Все известные мне фреймворки так или иначе дают разработчику взможность работать напрямую с ДОМ-нодами. Следуя вашей логике — все они 100% дают техническую возможность решить задачу, если собственно ДОМ ее поддерживает. Такой подход лишает эту оценку совместимости всякого смысла.
Таким образом, необходимость создания оберток, из-за которой React влепили его 71% рейтинга, не помешала дать Angular 100%. Вот такой вот непредвзятый рейтинг.
Да нет же. Просто на событие с двоеточием автор не написал теста. Почему не написал — это уже другой вопрос: предвзятость или упущение или еще что. Но 100% у Ангуляра не потому, что "необходимость создания оберток" проигнорировали, а потому что все написанные тесты выполняются — вот и все.
Про разницу сервера и клиента.
Несколько лет назад в России перестали переводить время зимой/летом. Мой коллега сидел на Windows XP, патча для которой не было. Чтобы видеть правильное время на экране при использовании неправильного (непропатченного) часового пояса, он просто перевел системные часы на час.
И все работало хорошо. До тех пор, пока ему не понадобилось сделать аплоад файла из браузера на AWS S3. Клиентский модуль в браузере добавляет заголовок "x-amz-date" со временем браузера. Это время не соответствует подписи, сделанной на бэкенде. В итоге S3 отвечает ошибкой.
Второй вариант —отвязать свой разум от бутстраповских брейкпоинтов и рассматреть каждый блок как независимый.
…
как показывает практика, этих состояний вряд ли будет больше шести, и все они будут инкапсулированы внутри своих блоков и ни на что не повлияют
В моей личной практике ничего хорошего из этого не вышло (может, просто не умели говить). Основная проблема — при таком подходе концептуально верным было бы адаптировать лэйаут блока в зависимости от размеров самого блока. К сожалению, соответствующее предложение в стандарт находится на стадии черновика и непонятно, будет ли когда-то реализовано (поправьте меня, если ошибаюсь).
В итоге, блок адаптируется под размеры экрана (вью порт) — но сам-то блок тоже не один на странице. Какой-то блок вообще может быть скрыт на меньше разрешении — оставляя больше места для другого блока. И вот различные сочетания брейкпойнтов у разных блоков привдят к тому, что, скажем, в одном конкретном диапазоне ширины экрана раскладка ломается.
Дописав все это, понял, что мало конкретики. Сорри. Конкретные баги, которые вылезали из-за этого, уже не помню. Было не так чтоб все плохо, но с глобальными брейкпойнтами стало надежней как-то.
Нужная, но все еще ограниченная. Очень часто при обрезании контента после 2-3-n строчек пользователю надо бы дать возможность полностью посмотреть этот контент. Всякие там кнопки "показать все", "больше" и т.д. Само собой, эта кнопка должна быть видна только когда контект реально был обрезан. Но чисто на CSS так не сделать — приходится кнопку показывать/прятать скриптом. И вся эта изящная конструкция с грохотом рушится, когда мы добавляем серверный рендеринг — ведь на сервере скрипт не знает размера окна браузера и то, обрежет ли этот браузер текст или нет.
В комментариях к оригинальной статье автор ответил, что Интегратор бэк-портировал багфикс андроида (вышедший для Marshmallow) под Lollipop (под которым работал телевизор). Я так понял, что приложение нефликса вообще менять не пришлось.
The integrator back-ported the patch (linked above) to L. It is literally only a few lines so this was straightforward. Some of the hardest problems take 1 or 2 lines to fix :)
По привычке прокликал несколько ссылок хабре. Даже не особо планируя читать — так, механический ритуал. А потом — хоп — влип и вот уже таращусь на заголовок "Комментарии" и смакую послевкусие от рассказа. Восхитительно!
Если твои тесты — интеграционные, то все хорошо. Но они, как правило, дорогие, их пишут меньше и позже. А если юнит-тесты, то на них оказывает влияние то, как ты декомпозировал свою задачу. И в ходе работы над задачей эта декомпозиция частенько меняется. С точки зрения конечного потребителя это неважно. А с точки зрения юнит тестов меняется довольно много — раньше это был тест на класс А, теперь на класс Б, а в тесте класса А надо зависимость от Б замокать.
Опять же, если ты такой весь в белом и с первого раза все идеально декомпозировал — то проблем нет. Тогда и тесты передывать не придется, и ТДД ложится идеально. Но конкретный я — ни разу не дАртаньян, у меня так не получается.
А, ну это все же совсем другой сценарий. Я отвечал в контексте задачи, где можно рассуждать о применении или не применении TDD.
Конечно, ты не получишь модульный код, если перед тобой в принципе не стоит задача написания кода.
TDD отлично работает для задачи, для которой уже заранее примерно ясно, как будет выглядеть решение. Желательно чтобы еще и зависимостей у решения не было. Хороший пример — всякие алгоритмические задачки типа leetcode и того, что на интервью спросят.
Зачастую это не так. Пишешь-пишешь, оппа, оказывается есть такой подводный камень и пол решения надо переделывать, включая интерфейс взаимодействия с внешним миром. Половина тестов к коту под хвост.
Или вот про зависимости. Начали по ТДД, раз тест, два тест, три. А потом добавили зависимость — и все предыдущие тесты надо поправить. Потом снова. А затем переосмыслил подход и избавился от зависимости — снова меняем ранее написанные тесты.
В завершение — отдельный тип задач, где ТДД (а точнее, написания теста до реального кода) помогает. Это багфикс или минорные изменения в имеющемся коде. Так код уже имеет фиксированный интерфейс, который в рамках фикса, скорее, изменяться не должен бы. Тогда локализуем баг, пишем точный тест, падающий из-за этого бага, чиним баг и радуемся зеленеющему тесту.
Про процессы не уверен. Что мне запомнилось — это то, что фреймворк пытается защитить программиста от задания некорректной системы реакций. Что-то ловится на этапе компиляции, что-то исключениями в рантайме.
Это первая статья подобного масштаба на хабре, которую я "осилилил" за последние годы (в несколько заходов). Автор молодец!
Некоторое время назад я наткнулся на такой вот фреймврок для реакций на Scala — https://github.com/Chymyst/chymyst-core. Тогда это для меня выглядело очень абстрактно, но после объяснений в этой статье мне кажется, то он ту же самую задачу решает.
Привычки бывают разные. У одних они одни, у других другие. Так что кого-то заставят, а кого-то и нет — неважно в каком стиле код писать.
Это практически из той же оперы, что и type assertion.
И в том, и в том случае программист говорит компилятору, что программисту лучше знать, какой там будет тип.
Чисто позанудствовать
Оба примера кода (2a и 2b) иллюстрируют алгоритм БЕЗ GOTO :)
2b — не про GOTO, а про ручную оптимизацию цикла. Увеличиваем индекс через 2, и читаем по 2 элемента на каждой итерации. То, что в 2b фигурирует GOTO — это автор так пытался сделать свою мысль более понятной для определенной аудитории. В оригинальной статье это звучит как:
что можно примерно перевести как
Отличный слог. Автор, пиши еще!
По существу: поймал себя на мысли, что внутренее киваю, преодолевая раздел за разделом в статье. Да, согласен, так и есть, я тоже так думаю, звучит разумно. В целом, скорее увидел подтвержение своим соображениям на эту тему, нежели нашел что-то новое. Что тоже полезно времня от времени :).
Отдельное спасибо за ссылки на другие отличные статьи, многие из которых я в свое время пропустил.
Все известные мне фреймворки так или иначе дают разработчику взможность работать напрямую с ДОМ-нодами. Следуя вашей логике — все они 100% дают техническую возможность решить задачу, если собственно ДОМ ее поддерживает. Такой подход лишает эту оценку совместимости всякого смысла.
Да нет же. Просто на событие с двоеточием автор не написал теста. Почему не написал — это уже другой вопрос: предвзятость или упущение или еще что. Но 100% у Ангуляра не потому, что "необходимость создания оберток" проигнорировали, а потому что все написанные тесты выполняются — вот и все.
Про разницу сервера и клиента.
Несколько лет назад в России перестали переводить время зимой/летом. Мой коллега сидел на Windows XP, патча для которой не было. Чтобы видеть правильное время на экране при использовании неправильного (непропатченного) часового пояса, он просто перевел системные часы на час.
И все работало хорошо. До тех пор, пока ему не понадобилось сделать аплоад файла из браузера на AWS S3. Клиентский модуль в браузере добавляет заголовок "x-amz-date" со временем браузера. Это время не соответствует подписи, сделанной на бэкенде. В итоге S3 отвечает ошибкой.
Было очень непросто найти источник проблемы :)
Так це ж византийское время. Как на Афоне
https://radiovera.ru/afon-zhit-po-vizantiyskomu-vremeni.html
В моей личной практике ничего хорошего из этого не вышло (может, просто не умели говить). Основная проблема — при таком подходе концептуально верным было бы адаптировать лэйаут блока в зависимости от размеров самого блока. К сожалению, соответствующее предложение в стандарт находится на стадии черновика и непонятно, будет ли когда-то реализовано (поправьте меня, если ошибаюсь).
В итоге, блок адаптируется под размеры экрана (вью порт) — но сам-то блок тоже не один на странице. Какой-то блок вообще может быть скрыт на меньше разрешении — оставляя больше места для другого блока. И вот различные сочетания брейкпойнтов у разных блоков привдят к тому, что, скажем, в одном конкретном диапазоне ширины экрана раскладка ломается.
Дописав все это, понял, что мало конкретики. Сорри. Конкретные баги, которые вылезали из-за этого, уже не помню. Было не так чтоб все плохо, но с глобальными брейкпойнтами стало надежней как-то.
Нужная, но все еще ограниченная. Очень часто при обрезании контента после 2-3-n строчек пользователю надо бы дать возможность полностью посмотреть этот контент. Всякие там кнопки "показать все", "больше" и т.д. Само собой, эта кнопка должна быть видна только когда контект реально был обрезан. Но чисто на CSS так не сделать — приходится кнопку показывать/прятать скриптом. И вся эта изящная конструкция с грохотом рушится, когда мы добавляем серверный рендеринг — ведь на сервере скрипт не знает размера окна браузера и то, обрежет ли этот браузер текст или нет.
В комментариях к оригинальной статье автор ответил, что Интегратор бэк-портировал багфикс андроида (вышедший для Marshmallow) под Lollipop (под которым работал телевизор). Я так понял, что приложение нефликса вообще менять не пришлось.
По привычке прокликал несколько ссылок хабре. Даже не особо планируя читать — так, механический ритуал. А потом — хоп — влип и вот уже таращусь на заголовок "Комментарии" и смакую послевкусие от рассказа. Восхитительно!
А, спасибо, я хотел раскрыть этот момент.
Если твои тесты — интеграционные, то все хорошо. Но они, как правило, дорогие, их пишут меньше и позже. А если юнит-тесты, то на них оказывает влияние то, как ты декомпозировал свою задачу. И в ходе работы над задачей эта декомпозиция частенько меняется. С точки зрения конечного потребителя это неважно. А с точки зрения юнит тестов меняется довольно много — раньше это был тест на класс А, теперь на класс Б, а в тесте класса А надо зависимость от Б замокать.
Опять же, если ты такой весь в белом и с первого раза все идеально декомпозировал — то проблем нет. Тогда и тесты передывать не придется, и ТДД ложится идеально. Но конкретный я — ни разу не дАртаньян, у меня так не получается.
К слову, в TDD три шага (помним мантру "красный-зеленый-рефакторинг") — все три важны. Если поленились отрефакторить, то это уже не вина ТДД
А, ну это все же совсем другой сценарий. Я отвечал в контексте задачи, где можно рассуждать о применении или не применении TDD.
Конечно, ты не получишь модульный код, если перед тобой в принципе не стоит задача написания кода.
Эм. Ну… да, пожалуй.
Я такого сам не видел и звучит дико — но допускаю, что и так бывает.
Написание юнит тестов в принципе подталкивает к модульному и изолированному коду. Безотносительно к TDD
TDD отлично работает для задачи, для которой уже заранее примерно ясно, как будет выглядеть решение. Желательно чтобы еще и зависимостей у решения не было. Хороший пример — всякие алгоритмические задачки типа leetcode и того, что на интервью спросят.
Зачастую это не так. Пишешь-пишешь, оппа, оказывается есть такой подводный камень и пол решения надо переделывать, включая интерфейс взаимодействия с внешним миром. Половина тестов к коту под хвост.
Или вот про зависимости. Начали по ТДД, раз тест, два тест, три. А потом добавили зависимость — и все предыдущие тесты надо поправить. Потом снова. А затем переосмыслил подход и избавился от зависимости — снова меняем ранее написанные тесты.
В завершение — отдельный тип задач, где ТДД (а точнее, написания теста до реального кода) помогает. Это багфикс или минорные изменения в имеющемся коде. Так код уже имеет фиксированный интерфейс, который в рамках фикса, скорее, изменяться не должен бы. Тогда локализуем баг, пишем точный тест, падающий из-за этого бага, чиним баг и радуемся зеленеющему тесту.
Спрашивать определения каких-то терминов на собеседовании — так себе идея, по-моему. Чай не экзамен.
Например, куб масштабирование. Красивый термин. И что? Гораздо полезнее напрямую спросить, знает ли кандидат про репликацию и шардинг.
Или вот стабы vs моки. Это вообще зависит от библиотеки — я видел кучу вариантов взаимозаменяемого использования spy/stub/mock в разных инструментах.
Про процессы не уверен. Что мне запомнилось — это то, что фреймворк пытается защитить программиста от задания некорректной системы реакций. Что-то ловится на этапе компиляции, что-то исключениями в рантайме.
Это первая статья подобного масштаба на хабре, которую я "осилилил" за последние годы (в несколько заходов). Автор молодец!
Некоторое время назад я наткнулся на такой вот фреймврок для реакций на Scala — https://github.com/Chymyst/chymyst-core. Тогда это для меня выглядело очень абстрактно, но после объяснений в этой статье мне кажется, то он ту же самую задачу решает.