Как писать высококачественные функции — именование/комментарии/надежность

JavaScript

В этой статье я объясню, как писать высококачественные функции с точки зрения именования функций, аннотаций и надежности.

PS: Эта статья намного проще и понятнее, чем предыдущая.

введение

Прежде чем писать вторую, позвольте мне кое-что сказать. За то, что я написал ранееКак писать качественные функции — сбить гору и встряхнуть тиграВ области комментариев к статье я прочитал все вопросы, заданные моими друзьями, и поэтому написал вопросы и ответы.

Вопросы и ответы включеныissues, нажмите на ссылку нижеTP :

Как писать качественные функции -- Вопросы и ответы

Если у вас есть какие-либо вопросы по поводу моего ответа, вы можетеissuesОбсуждение этой статьи не будет размещено на Nuggets.

PS: Хотелось бы упомянуть о перепечатке некоторых пабликов (Nuggets, Qiwu Weekly и т.д.), т.к. статья была неправильная в начале, а потом паблик аккаунт не синхронизировался, и тогда я ничем не мог вам помочь изменить его, поэтому я нажал на статью в паблике и прочитал ее.С теми еще ошибками, но чувством бессилия, молча в моем сердцеob: Спасибо арендодателям за перепечатку, так тому и быть.

Что ж, без лишних слов, приступим.

именование функций

Как видно из картинки в начале статьи, именование и кэширование — две большие проблемы в информатике.

Сегодня я хочу поговорить об именовании функций.Хотя область именования функций узка, идея та же. Можно заимствовать из других форм.

Я прочитал главу о переменных в Энциклопедии кода, а также целенаправленно прочитал некоторый исходный код, напримерlodash , ramdaбиблиотека этих функций. Теперь, основываясь на некоторых своих личных наблюдениях, я обобщил некоторые вещи, которые, по моему личному мнению, могут помочь вам полностью решить проблему именования.best practice.

PS: хотя имя переменной значения не имеетbest practice, а вот для именования фронтенд-функций я лично считаю, что может быть полный наборbest praticeДа, послушай меня.

В чем проблема с текущим именованием функций интерфейса?

В чем проблема? Я имею в виду такие отраслевые стандарты, как верблюжий регистр, классы с заглавными буквами и конструкторы, символы подчеркивания,$Ожидание не является узким местом. Настоящие узкие места — это детали, которые вы не замечаете или замечаете, но бессильны сделать. Например:

  • Различия в английском слове
  • Не знаю, как повысить точность именования из нескольких измерений
  • никаких вспомогательных средств

Далее следует краткий и лаконичный анализ.

PS: Я не буду упоминать общеизвестные отраслевые стандарты, такие как горб.

Различия между китайским и английским языками

Почему вы так говорите, потому что я думаю, что это самая большая проблема с текущим именованием. Не так много приятелей с хорошим знанием английского языка, многие люди не могут освоить набор грамматических правил для английских имен, говоря прямо, ваше знание английского языка не может достичь уровня иностранцев, которые могут писать по-английски.styleимя.

Почему нельзя назвать его по-китайски?

Есть три причины:

  • Основная проблема использования пиньинь: китайский пиньинь неоднозначен, и вы дрожите, когда думаете об этом.
  • Проблема использования китайских иероглифов: Хоть вспомогательные инструменты и доведены до совершенства, но их нельзя популяризировать, и они не могут соответствовать международным стандартам, грубо говоря, слишком малы, и иностранцы не умеют с вами играть .
  • Цепочка презрения образовалась (эмммм).

Трудности в английском языке

Самая большая трудность заключаетсяНе будет.

Я приведу вам пример, вы знаетеreactЖизненный цикл его таков:

  • componentDidMount

  • componentWillReceiveProps

  • shouldComponentUpdate

Многие спросят, зачем использоватьdid, зачем использоватьwill. Хорошо, помните, и все кончено, и через некоторое время просили интервьюер, а потом я подумалob:даcomponentMountedили что...

Какой яркий пример, гм, продолжайте читать, а в конце есть шокирующие (чрезвычайно) поразительные (ибо) ответы.

Как сделать имена в английском стиле

Черное лицо, как это сделать?

Брат, читай больше о знании английской грамматики в средней школе или средней школе. Например, я приведу вам самый простой пример, и вы будете знать.

componentDidMountдаreactи т. д. хуки жизненного цикла, но почему они так называются?

componentWillReceivePropsПочему он так назван?

Ответ на картинке ниже:

Обратите внимание на картинку вышеdidпредставляет собой простое прошедшее время,willПредставляет простое будущее время.

Затем мы энциклопедируем простое прошедшее и простое будущее время, а затем, как показано:

Простое прошедшее время:

Будущее время

Посмотрите на красную стрелку выше,didУказывает на простое прошедшее время, время указывает на время, когда происходит действие, используется здесь, чтобы подчеркнуть значение крючка, один разmountВыполните эту функцию в случае успеха. Ты сразу понял, хорошо?willТо же самое справедливо.

Ничего не говори, иди хорошенько посмотри английскую грамматику в средней школе.

Назван по результату, возвращаемому функцией

Это небольшая функция, напримерshouldComponentUpdate, Зачемshouldнаверху.

Поскольку значение, возвращаемое этой функцией, является логическим. Тогда мы можем понять, что это вопрос, который говорит нам в форме вопроса, что здесь есть неопределенность, и нужно судить, обновлять ли по возвращаемому значению.

Что касается английской грамматики вопросов, старые утюги должны читать больше книг по грамматике (слезы).

С помощью инструментов

с гугл переводчиком

Гугл переведи это не для того чтобы сказать, все поймут

с кодельфом

Это артефакт, используемый для поиска имен переменных в различных проектах с открытым исходным кодом, чтобы предоставить вам ссылку.

адрес:unbug.github.io/codelf/

соответствует имениVSCODEТак же есть плагины, как ими пользоваться пусть друзья узнают сами.

Как избежать неоднозначности и нечитаемой функции именования

Возможно, вы назвали функцию. Когда другие люди увидят эту функцию, они будут сбиты с толку и не поймут, что это за имя. Они могут только догадываться.

например я изramdaЯ нашел функцию в исходном коде, код выглядит следующим образом:

var forEachObjIndexed = _curry2(function forEachObjIndexed(fn, obj) {
  var keyList = keys(obj);
  var idx = 0;
  while (idx < keyList.length) {
    var key = keyList[idx];
    fn(obj[key], key, obj);
    idx += 1;
  }
  return obj;
});
export default forEachObjIndexed;

Эта функция называетсяforEachObjIndexed,Когда я увидел это название, я выглядел растерянным?Во всяком случае, первый раз, когда я его увидел, я был растерян, какого черта, какого черта, а потом я перешел к исходному коду, только из комментариев к функциям в исходниках Знайте, что он делает, аннотация функции выглядит следующим образом:

Посмотрите, как подробно, конечно, это для вывода документов, но это дает нам очень хорошее решение. То есть:

Если вы действительно не можете понять, как его назвать, или вы уже знаете, что это отстой, например, слишком длинное, например, трудное для понимания, то не пытайтесь сейчас. Напишите, что вы думаетеokимя, а остальное оставьте вам, чтобы писать заметки. НапримерforEachObjIndexedПервая часть комментариев — это общее введение и описание всей функции.

Если ваши имена функций плохие, то общее введение и описание функции очень важно в настоящее время. Вы должны хорошо справиться с этой частью, если ваш уровень английского не очень хорош, то вы можете честно писать по-китайски. Эта часть сделана, даже если вы назовете эту функцию двумя строками текста или марсианским текстом, не беда, это не большая проблема.

Классификация имен функций

Наконец, давайте поговорим о классификации нейминга, которые являются некоторыми из моих личных взглядов.

Почему я говорю о классификации имен функций, потому что мы часто видим, что функции именуются именно так (очень часто в исходном коде). Например:

- $xxx()
- _xxx()

Такое имя функции с различными префиксами выглядит не очень хорошо. Такой нейминг лично мне кажется очень несуразным, но почему такое название, на самом деле это беспомощный ход передка.

Основная причина в том, чтоJSЯзык не поддерживает приватные переменные, поэтому его можно использовать только_или$Чтобы обеспечить соответствующую невидимость для внешнего мира, решите эту проблему путем лечения симптомов, а не первопричины.

Поэтому я разделил имена интерфейсных функций на две категории следующим образом:

Первая категория: функции, которые не хотят подвергаться внешнему доступу (например, только для внутреннего использования).

Вторая категория: подвергаемые внешнему доступу функции (различные функции метода)

Мое личное мнение на данный момент находится примерно в этих двух категориях.

PS: Здесь я не учел имя функции, инициализируемой Symbol, например следующий код:

const ADD = Symbol('add')

[ADD](a, b) {
  console.log('a + b')
}

оSymbolИспользование , вы можете понять сами, я не буду принимать во внимание этот частный случай.

PS: Что касается этого беспомощного шага, когда вы узнаете больше, вы обнаружите, что нет способа сделать это во внешнем интерфейсе (шаблоны проектирования хороши,hackметод тоже хорош) может полностью решить указанную выше проблему, поэтому иногда приходится использовать_И т. д., потому что, когда ни один из них не может решить проблему, более простой путь более популярен, и это реальность.

Суммировать

Подводя итог передовому опыту:

Изучайте английскую грамматику в младших и старших классах средней школы. Именование функций в проектах с открытым исходным кодом не так сложно понять. Благодаря изучению грамматики и помощи инструментов именование функций в основном может быть решено. Если вы столкнулись с именованием, которое не может быть четко опишите цель написанной функции, пожалуйста, убедитесь, что функции хорошо прокомментированы, независимо от того, насколько длинное или сложное имя функции, если есть хорошие комментарии, это приемлемо. В конце концов, вы не хотите называть это так сложно для понимания, но ваши возможности ограничены, поэтому вы можете использовать китайский язык, чтобы аннотировать его, и эффект тоже отличный.

Как обеспечить качество функций с помощью хорошего именования функций, я уже почти сказал, ответ в тексте, как использовать инструменты, как понять грамматику именования на английском языке, как повысить точность именования значений с помощью многомерного секса и удобочитаемость. Давайте вкратце поговорим о текущей классификации именования фронтенд-функций, давайте поэкспериментируем и используем ее на себе.

PS: Я не буду говорить о некоторых моментах, которые я знаю, таких как глагол + существительное, существительное + глагол, верблюжий падеж и т. д., четко описываю назначение функции, это не болевая точка, я сказал всю боль точки, а также рассказал о лучших практиках.

аннотация функции

Давайте поговорим об аннотациях функций: с одной стороны, аннотации улучшают читабельность, а с другой стороны, аннотации можно использовать для других целей, например для создания онлайн-документации. Качественная функция, без комментариев не обойтись, но это не значит, что ко всем функциям нужны комментарии. Богатые богаты, бедные шикарны, важные или сложные функции, затем дайте хороший комментарий, простые или неважные функции, вы можете не оставлять комментариев или дать простой комментарий. Бессмысленно говорить пустые слова, давайте взглянем на современные методы аннотирования функций.

PS: Обратите внимание на слова, которые я использовал выше, если вы считаете, что эта функция плохо названа, то вы должны дать хороший комментарий.

Давайте поговорим о некоторых стилях аннотаций некоторых известных пакетов npm.

Так же, как перед написанием диссертации в вузе нужно прочитать много литературы, так и мы, давайте взглянем на несколько известныхnpmКак пакеты играют с аннотациями.

Стиль комментария egg.js

Из рисунка мы видимegg.jsСитуация с аннотацией входного файла, давайте не будем судить, является ли это своего родаdocПравила аннотации для инструментов (не обращайте внимания на детали). Давайте взглянем на его характеристики аннотаций и посмотрим, отличается ли он от стиля аннотаций в вашем представлении. Характеристики аннотаций к этому входному файлу просты и аккуратны. Будет ли эта идея усвоена? Когда вы в будущем будете заниматься проектами с открытым исходным кодом, эти идеи могут вдохновить вас.

Продолжайте смотреть на картинку ниже:

Это абстрактный базовый класс, который показывает автора [Yiyu He] Стиль его комментариев на момент написания класса. Что мы можем узнать из этой картины? Есть следующие моменты:

Первый пункт: правила аннотации для конструкторов, правила аннотации для выражений.

Второй момент: выбор комментариев, некоторые переменные нельзя комментировать, некоторые нужно комментировать, нет идеи комментировать все переменные.

Посмотрите еще две интересные картинки:

Посмотрите на стрелки на двух картинках выше, все они указывают на одного и того же автора [fengmk2] , мы смотрим на его правила аннотации функций. Почувствуйте разницу, подумайте, почему на первой картинке нет пробелов, на второй есть пробелы, а возвратthis, как многие привыклиthisпрямо аннотируется какObjectТипы.

lodash.js

Когда дело доходит до аннотаций функций, мы должны сказатьlodash.js.但是写到这,我发现这块要是加上去的话,第二篇的文字就又超了,那这里就不再说了,大家自己看看源码分析一下吧(这操作真香)。

Мысли о создании онлайн-документации с помощью аннотации

Некоторые люди говорят, что аннотации должны быть очень стандартизированы и удобны для других, например, использованиеjsdocЖдать . Мое личное мнение вот такое, для некоторых не нужен опенсорсwebпроект, не обязательно использоватьjsdoc, по следующим причинам:

  1. громоздко, нужно следитьjsdocправила приходят
  2. По моему мнению,jsdocНавязчивые правила документации должны быть записаны в коде.

Здесь я думаю, если вы хотите написать руководство по аннотации, для больших проектов я рекомендую использоватьapidoc, потому чтоapidocЭто не навязчиво и не требует прописывания правил в коде, вы можете записать все правила в файл. Я не буду говорить, как его использовать, просто ищите нужную информацию самостоятельно.

Но для общих небольших проектов нет необходимости писать отдельную копиюapiдокументация. Если это открытый источник, то то, что вы должны учитывать, сначала нужен официальный сайт с открытым исходным кодом, вы увидите официальные сайты с открытым исходным кодом в Интернете, на самом деле, этот мир не хватает колеса, вы также можете также Сделайте такой сайт в ближайшее время, давайте посмотрим, как это так.

Сначала давайте посмотрим наtaroИсходный код, вы найдете следующую картинку:

Вот секрет создания статического веб-сайта, выполните этоnpm run docsВот и все. используетсяdocusaurusПакет, если вы его не знаете, вы можете найти его самостоятельно.

Тогда вот вы видите картинку ниже:

Как видно из рисунка, содержание документа исходит изdocsкаталог, которыйmdДокументация, документация по проектам с открытым исходным кодом — все здесь.

Конечно, есть и соответствующие документы, размещенные непосредственно в соответствующем каталоге кода, напримерant-designКак показано ниже:

Просто поместите документ прямо в каталог компонентов.

Отсюда мы можем узнать, как реализованы официальные сайты популярных проектов с открытым исходным кодом и как писать документы. Вы можете сказать, что это не имеет ничего общего с аннотациями функций, но, похоже, что-то с этим связано, поэтому я не буду много говорить здесь, просто испытайте это на себе.

Мои личные привычки делать аннотации

Давайте поговорим о моем личном стиле или мнении об аннотациях функций (только для аннотаций функций).

доляVSCodeНесколько инструментов для аннотации

  • Better Commentsраскрасить аннотации
  • Document ThisАвтоматически генерировать комментарии
  • TODO HighlightвыделятьTODO, и может искать всеTODO

Конкретное использование не будет сказано, ниже приведена демонстрационная схема, идите и изучите ее самостоятельно:


Баланс написания и не написания комментариев

Мое личное мнение таково:

На удобочитаемость не влияет, сложность низкая, а функции, которые не мешают чрезмерно внешнему миру, не могут писать комментарии.

Комментарии для операторов выражений

В функции комментарий оператора выражения может быть проще, я обычно показываю его в виде следующего рисунка,//Далее следует краткое описание.

function add(a, b) {
  // sum ....
  let sum = a + b
}

Комментарии TODO

function say() {
  // TODO: 编写 say 具体内容
  console.log('say')
}

ИСПРАВЛЕНИЕ Примечания

function fix() {
  // FIXME: 删除 console.log方法
  console.log('fix')
}

аннотация функции

Вообще я разделил на обычные функции и конструкторы.

Обычные комментарии к функциям:

/**
 * add
 * @param {Number} a - 数字
 * @param {Number} b - 数字
 * @returns {Number} result - 两个整数之和
 */
function add(a, b) {
  // FIXME: 这里要对 a, b 参数进行类型判断
  let result = a + b
  return (result)
}

Примечания конструктора:

class Kun {
  /**
   * @constructor
   * @param {Object} opt - 配置对象 
   */
  constructor(opt = {}) {
    // 语句注释
    this.config = opt
  }
}

Суммировать

Из кода проектов с открытым исходным кодом можно узнать, что существуют различные стили комментариев, и иногда стили комментариев в разных моих проектах немного отличаются, но я постараюсь максимально сбалансировать комментарии и отсутствие комментариев. основные принципы приведенных выше замечаний по-прежнему должны соблюдаться.

Но как сказать, в комментарии нет серебряной пули.

Надежность функций (защитное программирование)

Вы все слышали о защитном программировании, верно?let it crash. Давайте посмотрим на абзац, следующую картинку:

Посмотрите на последнее предложение: после тестирования стольких сцен полоса все равно взорвалась (хахахахахаха, что случилось?).

Итак, мы видим, что ядром защитного программирования является:

Рассмотрите все возможные исключения и обработайте их соответствующим образом.

Но я лично считаю, что степень защиты зависит от того, насколько это важно. Вообще говоря, невозможно обработать все случаи, но эффективный способ повысить надежность вашего кода — программировать с защитой.

Думая о проекте

Я принял требование переписать (полностью реорганизовать) функцию привязки входа и регистрации апплета Suning.com WeChat и синхронизировать код с другими апплетами Suning (передача кода и помощь в разработке других апплетов).coderплавно завершить переход версии).

Важность этого проекта очевидна.Из-за большого количества пользователей и высокой степени риска необходимо рассмотреть множество сценариев, таких как:

  1. Поддержка не поддерживает резервную версию онлайн-версии, то есть требуется внешний интерфейс.ABСхема версии (при возникновении проблем в сети можно быстро переключиться на старую схему входа)

  2. Требуются различные подтверждения: графический код подтверждения, SMS-код подтверждения,ip, человек-машина, отпечатки пальцев устройства, контроль рисков, обработка различных исключений, отчеты об аномальных скрытых точках и т. д.

  3. Соображения на уровне кода. Благодаря оптимизации кода общее время отклика сокращается, а взаимодействие с пользователем улучшается.

  4. Как гарантировать, что сбой одного узла не повлияет на весь процесс входа в систему.

Вы обнаружите, что есть много моментов, которые необходимо учитывать, и как разумно выполнить это требование, довольно сложно.

PS: Что касается четвертого пункта, как сделать так, чтобы один узел вышел из строя и не повлиял на весь процесс входа в систему, в конце статьи есть ответ.

Далее я расскажу о некоторых своих личных взглядах на надежность функций.

Несколько способов повышения надежности фронтенд-функции

Надежность

существуетES6После появления , метод записи входных параметров функции был качественно улучшен и оптимизирован. см. код ниже

function print(obj = {}) {
  console.log('name', obj.name)
  console.log('age', obj.age)
}

printфункция, входной параметрobjпройти черезobj = {}установить значения параметров по умолчанию для входных параметров, тем самым повысив надежность входных параметров.

Но вы обнаружите, что если значение входного параметра по умолчанию равно{}, в этой функцииobj.nameбыло быundefined, что недостаточно надежно, поэтому давайте поговорим о надежности выражений в функциях.

Операторы выражения в функции должны быть надежными

Продолжая предыдущий пример:

function print(obj = {}) {
  console.log('name:', obj.name || '未知姓名')
  console.log('age:', obj.age || '未知年龄')
}

Если это так, то вы обнаружите, что оператор-выражение становится более надежным, но недостаточно хорошим, поэтому запись недостаточно абстрактна. Давайте немного отделим оператор-выражение другим способом. Код выглядит следующим образом:

function print(obj = {}) {
  const { name = '未知姓名', age = '未知年龄' } = obj
  console.log('name:', name)
  console.log('age:', age)
}

В этом случае кажется, что это лучше, но на самом деле это может быть более абстрактно, например,console.logупаковано вlogфункция, вызываяlog(name), завершитьconsole.log('name:', name)Функция , я не буду о ней здесь говорить, просто изучите ее сами.

Два уровня обработки исключений функций

Вышеуказанные пункты, лично я считаю, можно отнести к программному уровню, то есть:

Чтобы предотвратить проблемы до того, как они возникнут, в первую очередь не допускайте возникновения ненормального.

Но не забывайте, что всегда будет чрезвычайная ситуация, и есть еще один уровень плана, который нужно учитывать, а именно:

Исключение все еще происходит, как с этим бороться.

Были определены следующие два уровня, поэтому как лучше обрабатывать различные исключения и повышать надежность функции, лично у меня есть следующие мнения.

Получите этоtry/catchпринцип

Многие люди не знают, как им пользоватьсяtry/catch. Здесь я буду толкать принцип по моему личному мнению, в первую очередьjsработает наnode.jsпредоставляется в среде выполнения, в то время какnode.jsиспользуетсяC++написано.C++Он имеет собственный механизм обработки исключений, а такжеtry/catchиз . это значитjsизtry/catchБазовая реализация находится непосредственно через мост, вызываяC++изtry/catch.

а такжеC++изtry/catchУ него есть некоторые особенности, вы можете узнать об этом сами, например, одна из особенностей заключается в следующем:

try/catchМогут быть перехвачены только исключения текущего потока.

Так что это также хорошее объяснение, почемуJSизtry/catchМогут быть перехвачены только синхронные исключения, и ничего нельзя сделать с асинхронными исключениями (поскольку асинхронность выполняется в другом потоке).

Вот мой вывод и не представляет точного ответа.

Здесь я рекомендую блог:

Попробуйте отловить механизм обработки исключений в C++

Кому интересно, могут посмотреть.

Разумная обработка исключений

Вот несколько способов:

Первый способ: если это синхронная операция, вы можете использоватьthrowпередать исключение

См. код ниже:

try {
  throw new Error('hello godkun, i am an Error ')
  console.log('throw 之后的处代码不执行')
} catch (e) {
  console.log(e.message)
}

Сначала нам нужно знатьthrowИсключения доставляются синхронно, т.throwи использоватьthrowФункция, передающая ошибку, имеет тот же контекст.

Если контекстная среда не используетсяtry/catch, но опять жеthrowЕсли возникнет исключение, программа, скорее всего, выйдет из строя.

еслиnodejs, в это время вы должны добавить уровень процессаuncaughtExceptionпоймать это неперехваченное исключение. обычно добавляютunhandledRejectionОбработка исключений.

Второй способ: если это асинхронная операция

Есть три способа:

  1. использоватьcallback,Напримерnodejsизerror firstстиль

  2. В сложных случаях используйтеEventспособ сделать это, вызывающий абонент слушает объектerrorмероприятие

  3. использоватьpromiseа такжеasync/awaitловить исключения

Теперь вопрос в том, как выбрать какой метод? Есть несколько принципов:

  1. Простая сцена, прямое использованиеpromiseа такжеasync/awaitловить исключения

  2. В сложных сценариях, например, при возникновении нескольких ошибок, лучше всего использовать это время.EventПуть

Третий способ: если есть и асинхронные, и синхронные операции

Как это сделать? В настоящее время я лично считаю, что лучше всего использовать последний синтаксис:async/awaitобъединитьpromiseа такжеtry/catchДля завершения захвата исключений как для синхронных, так и для асинхронных операций.

Четвертый способ: некоторая абстракция и инкапсуляция для обработки исключений

Абстрагирование и инкапсуляция функций, обрабатывающих исключения, также является способом повышения качества функций. Как абстрагировать и инкапсулировать обработку исключений? Есть несколько способов сделать это:

  • Первый способ: даnodejsНапример, обработка исключений обычно инкапсулируется в ПО промежуточного слоя, например, на основеexpress/koaOvengerine, как правило, промежуточная часть аномалии должна быть загружена в качестве последнего промежуточного программного обеспечения, цель состоит в том, чтобы зафиксировать возможные ошибки предыдущего промежуточного программного обеспечения.

  • Второй способ: на передний конец илиnodejsНапример, обработка исключений может быть инкапсулирована в модули, подобныеEventв своем роде.

  • Третий способ: используйте паттерн декоратора, чтобы украсить модуль обработки исключений для функции, например, обернув текущую функцию декоратором.try/catch.

  • Четвертый способ: использовать функторы в функциональном программировании (Monad) и так далее, чтобы унифицировать пакет обработки исключений, здесьMonadа такжеtry/catchВсе ведут себя как контейнер, что является довольно мощным подходом. отMonadСуществует много черных технологий обработки исключений, которые можно расширять, но я рекомендую использовать их с осторожностью, потому что не все могут в этом разобраться, и нужно учитывать общие технические возможности команды.

Чтобы разумно обрабатывать исключения, вы должны иметь возможность определить, какой метод использовать для обработки исключений.Я также говорил о конкретной ситуации выбора.Здесь я рекомендую блог:

Эволюция генератора обещаний обратного вызова Async-Await и обработка исключений

До сих пор я видел наиболее полный блог по обработке исключений, но я говорю здесь об основных моментах, которые я считаю более важными. Между ними все еще есть очевидные различия. Давайте интегрируем и поглотим их.

Как гарантировать, что сбой одного узла не повлияет на весь процесс входа в систему

Например, процесс входа в систему требует 4 проверки безопасности.Согласно обычному способу написания, если одна из них не проходит, то все они терпят неудачу, но это недостаточно надежно.Как решить эту проблему. Здесь я упоминаю об этом, многие люди могут не заметить.

Основная программа будет использоватьpromiseМетод цепной записи , записывается по-другому, предыдущий метод записи выглядит следующим образом:

Псевдокод выглядит следующим образом:

auth().then(getIP).then(getToken).then(autoLogin).then(xxx).catch(function(){})

После робастной настройки его можно записать следующим образом:

Псевдокод выглядит следующим образом:

auth().catch(goAuthErrorHandle).then(getIP).catch(goIPErrorHandle).then(function(r){})

Точно настроенный код напрямую повышает надежность процесса входа в систему: даже если есть ошибка, ее можно передать следующему методу после обработки ошибки.

Я лично обработал обращение с исключением

Лично я считаю, что обработку исключений следует анализировать в соответствии с реальной ситуацией. Вероятно, существуют следующие точки зрения:

Учитывать ремонтопригодность проекта, технический уровень команды

В одном из своих требований я использовал более абстрактный метод обработки исключений, такой как функторы.Хоть я и продемонстрировал это (смерть), в результате пришлось внести изменения в последующие требования. Ну, это так интересно, потому что мой коллега не знаком с функциональным программированием.

Заранее оцените сложность и важность проекта.

Например, занимаясь относительно важным делом, я сначала не думал, что обработка исключений нуждается в таких деталях, и вообще в первой версии требования не предполагали много обработки исключений, но когда последующие требования итеративно оптимизируются , обнаружена обработка исключений.Их так много, что прямо приводит к необходимости переписать код, связанный с обработкой исключений.

Поэтому при оценке проектов в будущем мы должны научиться стараться заранее резервировать ямы в соответствии с важностью проекта.

Это также модель программирования на будущее.

Суммировать

Я много рассказываю о надежности функций (защитное программирование), в основном интерфейсных илиnodejsДавайте обрабатывать исключения обычным способом. Обработка исключений - задача не из простых.В работе приходится совмещать дела, чтобы определить подходящий метод обработки исключений.Короче говоря, много практиковаться, чтобы узнать правду.

Примечание

  • Эту статью относительно легко читать, она несложная, и вы получите некоторые преимущества, если внимательно ее поймете.
  • Возможно, объяснение неполное, если чего-то не хватает, поделитесь им в области комментариев и вместе продвигайтесь вперед.
  • С точки зрения надежности я не упомянул тестирование подразделения. Количество слов недостаточно для записи, и статья будет очень длинной. Я только рекомендую тестирование подразделения.Jest, согласно официальной документации сайта, исходя из идеи функционального программирования, проблема не большая.

Прошлые прекрасные статьи

Так сказать, после прочтения этой статьи вашgitа такжеgerritНет проблем.

Навыки мерзавцев и герритов в младших классах средней школы [резюме крупномасштабных боевых проектов и опыт CR]


О том, как читатьnpmИстория исходного кода пакета.

Боитесь читать исходный код пакета npm? Возьмите вас, чтобы раскрыть философию таро init

пасхальные яйца

Недавно я написал статью и обнаружил, что ее мало кто читает, но я думаю, что написал ее очень хорошо Эта статья определенно вдохновит и поможет большинству фронтенд-инженеров.

После волны огласки я хочу вдохновить больше фронтенд-партнеров, которые еще в пути:

Рекомендуемые книги и необходимые знания для фронтенд-инженеров в новую эру

общаться с

Помимо этой статьи, я уже написал две статьи из этой серии, и планирую закончить три статьи, но в зависимости от ситуации, последние все тяжеловесны, и их трудно7000Это сделано в словах, следующие несколько статей сделаны, я сделаю это сноваobМомент.

Друзья могут подписаться на мой блог Nuggets илиgithubполучать уведомления о последующих статьях серии.

Серия технических статей Nuggets вgithubПриведенное выше резюме выглядит следующим образом: если вы считаете, что это хорошо, нажмите звездочку, чтобы поощрить это, и яМиссия должна быть достигнута, продолжайте выпускать качественные статьи.

github.com/godkun/blog

Я терминатор исходного кода, и обмен технической информацией приветствуется.

также может войтиГруппа звукозаписи Front-end RhapsodyПроведите мозговой штурм вместе. Если вы хотите добавить, потому что она заполнена, вы можете сначала добавить меня в друзья, и я приглашу вас присоединиться к группе.

Язык ветра

Напоследок: уважайте оригинальность, пожалуйста, указывайте источник для перепечатки 😋