К слову о переборе всех частных случаев. Одним из важных требований TDD, предотвращающих «застревание» разработчика является требование о том, что в стадии Green (написании кода реализации) по возможности нужно повышать уровень абстракции решения (ну или в худшем случае, не уменьшать его), что противоречит такому подходу к разработке как «перебрать всевозможные решения».
Роберт Си. Мартин в своей серии видеоуроков «Clean Code» (В эпизоде «Advanced TDD») говорил об этих принципах и рассказывал о том, о чем умалчивают три постулата TDD.
Вряд ли вы можете утверждать, что реализация вида
if (a == 0 && b == 0) return 0;
if (a == 1 && b == 0) return 2;
//Повторить для всех a, b принаждежащих R
будет проще return a + b;
В этом смысле, a + b — и есть минимальная реализация, и это станет понятно после того, как вы напишете три теста, складывающих разные числа. И если строго следовать принципам, вы должны будете «зарефакторить» кучу if-else в сложение только после пары тестов. на практике получается, что большая часть программистов — не идиоты и сразу видят тенденцию, заменяя операцию на сложение уже после первой реализации.
Быть может, строчек в методе? Речь скорее не о языке, а о коде, который на нем пишется. К тому же, как автор статьи про Кошелек Миллера дал знать, дело вовсе не в 7±2, а скорей N±ε, где эти значения сильно зависят от контекста.
Желание ввести подобного рода сахар скорей всего возникло именно для того, чтобы подчеркнуть функциональную натуру javascript'а, потому что подобного рода let-блоки встречаются повсеместно в разного рода функциональных языках. Марк прав в отношении данной фичи: Это не тот сахар, который бы значительно облегчил жизнь разработчикам, и не тот, который значительно улучшил бы читаемость кода, как и сказал переводчик, скорей всего, этому блоку будет лучше житься в отдельной функции.
Да и к тому же, будем честны: JS использует огромное количество людей и вряд ли хотя бы треть из них когда нибудь писала на языках типа Lisp или Haskell. Подобного рода сахар оценила бы лишь маленькая ниша разработчиков, который тащятся от разных функциональных плюшек, да и те, скорей всего, в свободное время пишут на ClojrueScript.
Жаль что примеры кода есть только по самым простым и «плохим» реализациям мультипоточности. Неплохо было бы добавить примеров использования модулей subprocess и multiprocessing в соответствующих параграфах статьи.
Все это потому что Unity/Unreal позволяют сделать играбельный прототип быстро и в одиночку без нужды разработки кастомного движка с нуля. Обычно, если нет какого-то готового решения, чтобы написать что-то приходится тратить сотни часов на программирование самого движка, что достаточно далеко от гейм дизайна, а Unity/Unreal обладают достаточным количеством инструментов для того, чтобы на коленке собрать какой-то концепт и проверить его на «наличие Фана».
Пункт «В начале методов проверяйте входные данные» в целом порадовал тем, как категорично рекомендует проверять все входные данные в большинстве методов. По-моему слишком сильное требование, подразумевающее, что все пользователи класса намерены сломать его в 10 местах.
Во всех вещах нужно соблюдать баланс. По-моему, проверка входных данных — обязательное условие только для торчащего наружу кода, либо кода, работающего с User-Input'ом. В случае, если в написанном вами потрясающем компоненте упадет null-reference exception по вине вашего тиммейта, вы сможете высказать ему лично вместо того, чтобы проверять на null все и вся.
Интересно. Но что-то мне подсказывает, что результирующие разрешения для карт высот были больше. (То есть количество чанков было больше), потому что маленькие деформации типа трещин юнитов Exodus, выглядели очень точными.
Роберт Си. Мартин в своей серии видеоуроков «Clean Code» (В эпизоде «Advanced TDD») говорил об этих принципах и рассказывал о том, о чем умалчивают три постулата TDD.
if (a == 0 && b == 0) return 0;
if (a == 1 && b == 0) return 2;
//Повторить для всех a, b принаждежащих R
будет проще return a + b;
В этом смысле, a + b — и есть минимальная реализация, и это станет понятно после того, как вы напишете три теста, складывающих разные числа. И если строго следовать принципам, вы должны будете «зарефакторить» кучу if-else в сложение только после пары тестов. на практике получается, что большая часть программистов — не идиоты и сразу видят тенденцию, заменяя операцию на сложение уже после первой реализации.
Да и к тому же, будем честны: JS использует огромное количество людей и вряд ли хотя бы треть из них когда нибудь писала на языках типа Lisp или Haskell. Подобного рода сахар оценила бы лишь маленькая ниша разработчиков, который тащятся от разных функциональных плюшек, да и те, скорей всего, в свободное время пишут на ClojrueScript.
Во всех вещах нужно соблюдать баланс. По-моему, проверка входных данных — обязательное условие только для торчащего наружу кода, либо кода, работающего с User-Input'ом. В случае, если в написанном вами потрясающем компоненте упадет null-reference exception по вине вашего тиммейта, вы сможете высказать ему лично вместо того, чтобы проверять на null все и вся.
btw, то, что вы предлагаете, называется Defensive Programming.