Мягкие навыки в JavaScript…
5 советов, как сделать ваш JS-код более коммуникативным
Для начинающих и профессиональных программистов
Научитесь справляться с крайними случаями принуждения
JavaScript - это клейкая лента Интернета.
- Чарли Кэмпбелл
1. Глубокое понимание языковых угловых случаев
Люди ненавидят JavaScript из-за угловых случаев? Всегда интересно наблюдать, как люди дезинфицируют весь язык из-за нескольких минусов. Все языки программирования имеют преобразование типов, поэтому все языки программирования имеют угловые случаи. Невозможно создать систему, в которой не было бы угловых вариантов.
Избегать принуждения - плохая практика. Простите за ложь, уклониться от этого невозможно! Не делайте вид, что пренебрегаете принуждением, используя строгое равенство (===). В конце концов, это своего рода принуждение. Начните изучать спецификации, а не смотреть учебники на YouTube о том, как пропустить, чтобы изучить принуждение. Сиди и учись. Мы должны изучить эти угловые случаи, а затем научиться эффективно управлять ими и обходить их.
Не ломайте голову, думая о том, есть ли в других языках угловые падежи и сколько. Сидеть и считать - это просто. Мы не можем сравнивать угловые случаи на разных языках и делать выводы. Приведу примеры самых рискованных угловых случаев:
Как видите, у нас есть куча угловых случаев с числами. И здесь мы получили нумерацию пустой строки, что является худшим случаем. У Null и undefined есть несколько странных угловых случаев, но не так плохо, как с пустой строкой. Многие ложные значения превращаются в числа, что не идеально. Но если бы можно было исправить этот случай с пустой строкой, чтобы пустая строка не приводила к числу, мы бы исправили большинство этих угловых случаев.
Последний, но тем не менее важный. У нас есть привлекательный угловой случай с Boolean. Я нашел этот пример в одном блоге разработчиков, и он меня заинтриговал. У вас не будет таких случаев на практике, но вы можете попробовать. Если вы создадите экземпляр объекта Boolean и дадите ему примитивное значение false, он будет вести себя так, как если бы он был правдивым. Почему это так? Причина проста. Мы не используем для него операцию ToPrimitive, но проверяем, определен ли пример в таблице ложных данных в документации.
Заключение: Обратите внимание на то, как вы используете основные объекты.
2. Самая злая часть принуждения JavaScript
JavaScript - не идеальный язык, но если бы мы могли исправить хотя бы одну вещь, большинство угловых случаев исчезло бы.
Думаю, проблема с пустой строкой. Но не только пустая строка становится нулем, но и строка с пробелом приводится к нулю. Почему так? Когда мы выполняем операцию с двумя числами, движок сначала удаляет все начальные и конечные пробелы - пространство вокруг строки, а затем происходит принуждение. Таким образом, строка с пробелом становится пустой строкой, а остальное вы знаете.
Я рассмотрю примеры, чтобы вы смогли сформировать правильную ментальную модель:
Одно важное замечание: Мы должны знать, что есть и второстепенные случаи, которые неочевидны, потому что они не являются частью обычных операций.
Давайте проверим следующий случай:
В случае нумерации логических значений у нас есть новый упущение. Возвращать 0 и 1 из этой операции - плохая идея. Вы думаете, что я сошел с ума, но я покажу, почему это было неправильным шагом. Посмотрим на примеры:
Давай займемся математикой. В первой строке у нас есть выражение, которое проверяет, меньше ли 1, чем 2. Все мы знаем, что это правда, и JS теперь тоже. Вторая строка кода также возвращает true.
Третья строка захватывающая. Если мы решим проверить, меньше ли 1, чем 2, меньше, чем 3, мы получим true, что является правильный результат. В этом случае что-то происходит случайно. Приведу еще один пример и постараюсь быть максимально точным:
Как что-то может произойти случайно? Я разделил принуждение на три отдельных процесса. В первом процессе мы проверяем, меньше ли 1, чем 2, что возвращает true. Это нормально. На следующем этапе у нас true меньше 3. Поскольку мы используем нечисловые (true) с оператором (‹), он будет приводить к числу.
В наименьшем и наиболее важном шаге у нас 1 (ранее преобразованное из логического значения в число) меньше 3. Видите, правильный результат случайно. Хороший совет - ничего не оставляйте на волю случая. Нам повезло в предыдущем примере, но как насчет этого:
Первые две строчки имеют ожидаемые результаты. Проблема с третьей строкой. Выражение вернуло false (что неверно). Как и в предыдущем примере, я разделю это на три отдельных процесса:
На первом этапе мы сравниваем, если 3 больше, чем 2, что возвращает true. На втором этапе мы сравниваем true и 1. Логическое значение (true) будет приведено к числу (1), поэтому на третьем шаге у нас есть сравнение двух одинаковых значений. 1 не больше 1, поэтому он вернет false.
Как видите, это неправильный подход к проектированию системы. Возможно, лучшим решением было бы сделать логическое приведение числа равным NaN.
Заключение: Неявное принуждение логических значений к числам было неправильным. Это был стиль программирования 1970-х годов, когда логическое значение превращалось в число, а затем с ним выполнялись числовые операции.
3. Примите стиль кодирования со всеми его плюсами и минусами.
Как видите, угловых случаев очень много. Мы подходим к перекрестку, где можем выбрать только два пути:
- Избегайте использования всего механизма, чтобы обойти угловые случаи или
- Используйте правильный стиль кодирования, который сделает наши типы и ценности более очевидными.
На мой взгляд, второй способ лучше, и я считаю, что это единственно правильный способ понять систему. Сообщество JavaScript зашло настолько глубоко, что они создали совершенно новые системы типов, такие как TypeScript или Flow. Никто не заставляет вас использовать систему типов. Достаточно принять правильный стиль кодирования, который сделает ваши типы и значения более очевидными.
Правильное использование принуждения JavaScript упростит вашу жизнь, а ваш код станет намного чище. Вы должны убедиться, что тип, участвующий в операции, ясен для понимания.
Иногда - плохая практика - разрабатывать функции, выполняющие 10 разных вещей, потому что у вас много углов, о которых вам нужно позаботиться. Это более надежное решение, позволяющее сделать вашу функцию более очевидной и управляемой.
Например, не используйте одну функцию для чисел и строк. Напишите пару отдельных функций, и вы будете знать, какие угловые случаи могут возникнуть и как с ними бороться. Мы выбираем, как наш код будет управлять нашими типами и как обрабатывать полиморфизм, перегрузку и т. д.
Не существует единственного решения каждой проблемы. Вы должны быть креативными и, конечно, понимать систему. Когда я говорю о JavaScript, я не сторонник шаблонов.
Заключение: Сначала изучите систему, а затем проявите творческий подход, чтобы сделать код более наглядным.
Динамический набор текста - это не слабость языка. На самом деле, это самое эффективное качество. Одна из основных причин востребованности JavaScript заключается в том, что этот язык адаптируется ко многим различным вариантам использования.
JavaScript - это первый в мире язык с множеством парадигм. В чем заключается сила мультипарадигмы? Это заложено в системе типов.
4. Культура развития навыков
Мне регулярно нравятся люди, которые говорят, что все, чему они научились, бесполезно, особенно когда они начинают работать с юниорами. Почему это так? Потому что юниоры никогда не поймут эти концепции.
Дело не в вашем опыте работы с технологиями (1, 2, 5 или 10 лет), все дело в вашем образе мышления и способе принятия правильной ментальной модели. Возможно, вы знаете более или менее о технологиях (в данном случае о JS), но это не значит, что вы глупы. Все зависит от вас и вашего желания понять систему и начать писать лучший код и использовать все доступные инструменты.
Вы должны использовать технологии соответствующим образом, писать код более явным и понятным. Если следовать этим образцам правил, меньше шансов неправильно понять кодовую базу другими коллегами (особенно младшими).
Проверка кода - отличный инструмент для мозгового штурма. Если кто-то не понимает, есть идеальный способ помочь ему / ей решить проблемы - использовать парное программирование. Это были несколько советов, которые помогли всем узнать, как работает эта технология.
Вывод: Цель одна, мы идем в одном направлении.
Ваш код должен быть формой общения, и есть эффективный способ общаться и хорошо понимать вариант использования движка. Если вы попросите читателя кода понять что-то в отношении инструмента, и он сможет понять эту строку кода, это будет их вложением.
Вы должны быть готовы тратить время на изучение нового. Как и в любой отрасли, ИТ не освобождаются от анонса новых технологий, различных методов программирования и т. Д.
Вывод: Избегать некоторых частей - ужасная идея, если вы не воспитываете в них сочувствие. Части в JavaScript, такие как типы, от которых все пытаются уклониться, будьте умны и изучите их, потому что вы быстро станете важным фактором.
5. Используйте вспомогательные добавки.
У вас есть некоторые дополнения, такие как документы и другие стандарты нотации, которые играют роль в улучшении процесса взаимодействия кода. Кодовая база - это пища для машины, но как насчет людей?
Использование дополнений как способа передачи идей - отличный ход для кодовой базы. Самый распространенный пример - использование комментариев к коду. Кто-то скажет вам, что вам не нужно использовать комментарии (код достаточно понятен). Итак, как мы можем понять кодовую базу без комментариев? Это слишком сложно понять, кроме создателя системы.
Комментарии к коду - отличный способ объяснить код. Люди скажут, что комментарии плохие, потому что они демонстрируют слабость. Основная проблема - это способ использования комментариев к коду. Люди используют комментарии, чтобы сообщить, "для чего нужен код". Это неправильное использование. Комментарии объясняют, почему эта операция (блок кода) существует и (иногда) как выполняется.
Вывод: Комментарии к коду полезны, но это не единственные инструменты, которые мы должны использовать. Не забывайте быть более ясным и точным при написании кода.
