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

Библиотека, которую мы собираемся рассмотреть, называется Redux, Контейнер предсказуемого состояния для приложений JS. Уроки, которые мы извлекаем сегодня, должны переводиться независимо от библиотеки, которую вы выбираете для изучения. Но у Redux небольшая кодовая база, что делает его отличным местом для начала этого пути. Если вы не знакомы, Redux - отличный инструмент для управления состоянием для внешнего интерфейса ваших приложений. Он прекрасно работает с библиотеками пользовательского интерфейса и фреймворками, такими как React, Angular и многими другими.

Заявление об ограничении ответственности - В этой статье не будет как, что такое или почему Redux. И это не глубокое погружение в исходный код Redux. Мы просто заглянем под капот и посмотрим, что мы можем узнать, глядя на профессионально написанный код.

Подождите ... так почему мы хотим исследовать любую кодовую базу? Рад, что ты спросил! Я думаю, что этот процесс принесет много пользы. Как новый разработчик, вы, вероятно, начали свое путешествие по программированию с некоторых руководств, а затем (надеюсь) вы сразу же приступили к созданию собственных проектов. Промыть и повторить. Но закономерность заключается в том, что вы, вероятно, строите эти проекты с чистого листа. Это здорово, и вы чувствуете себя воодушевленными тем, что сделали с нуля, но, вероятно, это не будет вашим рабочим процессом в реальном мире. На работе вы будете работать с существующими базами кода и не хотите, чтобы первая профессиональная база кода, на которую вы положили глаз, была базой кода вашей новой компании. Чтение и навигация по существующему коду - это отличные навыки от его написания. Вы захотите потратить время на оттачивание обоих этих навыков. Что хорошо, так это то, что вам будет удобнее ориентироваться в коде, написанном другими, но вы также получите доступ к новым методам и передовым методам написания кода на профессиональном уровне! В этой статье я поделюсь некоторыми из этих уроков, которые я извлек из этого процесса.

Коротко в сторону - я хотел бы указать на дополнительное преимущество того, что мы здесь делаем (хотя в этой статье это не является предметом внимания). Заглянув под капот инструмента, который мы используем на практике, мы получим лучшее понимание этого инструмента и большую уверенность в нем, когда будем использовать его. Не знаю, как вы, но я попал в разработку по двум причинам. Я люблю строить, и мне нужно знать, как все устроено. Последний здесь важен. Когда вы понимаете, как что-то работает, вы действительно можете владеть этим. Когда появляется эта ошибка, указывающая на ваш магазин Redux, вы можете расслабиться и сказать себе: я видел внутреннюю работу этой штуки, которую использую. Я точно знаю, чего он хочет, что делает и что возвращает. Обладая этими знаниями, вам будет легче увидеть проблему, которую вы создали в своем коде ... вы дали ему то, чего он не хотел! Ошибка: раздавлен; Дофамин: удар.

Хорошо, этого достаточно, давайте взглянем на код. Вы можете просмотреть исходный код прямо в GitHub или клонировать код на свой компьютер.

mkdir ReduxClone
cd ReduxClone
git clone https://github.com/reduxjs/redux.git

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

Теперь, когда вы немного поработали и знакомы только с JavaScript, вы можете увидеть незнакомый код. Вы заметили, что большинство расширений файлов .ts? Redux написан на TypeScript, а не на JavaScript. (В дальнейшем я буду называть TypeScript и JavaScript TS и JS соответственно.) Но пока не приступайте к делу, это наша первая возможность для роста. Давайте сразу перейдем к документации TS, и мы увидим, что Весь допустимый код JavaScript также является кодом TypeScript. Звучит хорошо. Но если весь действительный JS - это TS, мы можем сделать вывод, что все действительные TS не обязательно являются JS. Итак, давайте получим поверхностное понимание того, что такое TS и как мы можем ожидать, что это будет выглядеть. Здесь мы не изучаем TS, мы просто хотим знать, как в нем ориентироваться.

Давайте посмотрим на справочную документацию, предоставленную TypeScript. Перейдем прямо к разделу TypeScript для программистов JavaScript:

Например, чтобы создать объект с предполагаемым типом, который включает name: string и id: number, вы можете написать:

const user = {
  name: "Hayes",
  id: 0,
};

Вы можете явно описать форму этого объекта с помощью объявления interface:

interface User {
  name: string;
  id: number;
}

Затем вы можете объявить, что объект JavaScript соответствует форме вашего нового interface, используя синтаксис типа : TypeName после объявления переменной:

const user: User = {
  name: "Hayes",
  id: 0,
};

Поскольку JavaScript поддерживает классы и объектно-ориентированное программирование, то же самое делает и TypeScript. Вы можете использовать объявление интерфейса с классами:

interface User {
  name: string;
  id: number;
}
class UserAccount {
  name: string;
  id: number;
  constructor(name: string, id: number) {
    this.name = name;
    this.id = id;
  }
}
const user: User = new UserAccount("Murphy", 1);

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

Давайте перейдем к src/createStore.js строке 244 кода Redux (возможны изменения):

try {
 isDispatching = true
 currentState = currentReducer(currentState, action)
} finally {
 isDispatching = false
}

Что же мы имеем здесь? Блок попытки, я знаю это, но что это за синтаксис finally и в чем загвоздка !? Я уже некоторое время использую операторы try ... catch, но никогда не слышал о блоке finally. Изучая новую концепцию, я люблю сразу обращаться к документации. В этом случае мы пойдем в MDN, чтобы прочитать об этом ... Таким образом, похоже, что после ваших операторов try and try ... catch будет выполняться блок finally. И мы уже знали, что можем использовать try… catch без finally. Итак, как заявляет MDN:

Это дает нам три формы для оператора try:

try...catch

try...finally

try...catch...finally

Теперь мы немного знаем о том, как это работает, но мне все еще трудно придумать вариант использования. Итак, давайте продолжим наши исследования по этому поводу. Давайте посмотрим, "когда использовать блок finally?" Мне нравится этот ответ на этот вопрос о переполнении стека:

Используя блок finally, вы можете очистить любые ресурсы, выделенные в блоке try, и запустить код, даже если в блоке try возникает исключение. Обычно операторы блока finally выполняются, когда элемент управления выходит из оператора try. Передача управления может происходить в результате нормального выполнения, выполнения операторов break, continue, goto или return или распространения исключения из оператора try.

Ах, теперь я понимаю ...

Я думаю, что ключевое слово здесь - «очистить» код. Я вспоминаю время, когда я кодировал loading… сообщение внешнего интерфейса, которое необходимо было отобразить до того, как загрузка изображения разрешилась. Сообщение о загрузке нужно было очистить в локальной области моей логики независимо от того, завершилась ли загрузка успешно или неудачно. В этой ситуации пригодился бы блок finally. Для меня это все. Узнавать новую концепцию всегда приятно. Но изучать новую концепцию и подключаться к ней таким образом, чтобы вы могли представить, как она улучшит вашу жизнь (и ваш код)? Что ж ... вот тогда я и взволнован.

Я также оставлю эту короткую статью здесь для некоторых интересных фактов о заключении finally.

Круто, к этому моменту мы поняли пару вещей. Давайте вернемся к исходному коду и посмотрим, к чему он нас приведет. Если мы вернемся к тому месту, где остановились, я замечаю то, что было темой всей кодовой базы. Комментарии. И их много. Более того, вы заметили, что существует целый каталог docs, посвященный только документации? Я думаю, что это важный вопрос с точки зрения того, чему мы можем научиться из профессионального кода, как новые разработчики. Как было сказано ранее, когда мы начинаем заниматься разработкой, очень часто мы работаем изолированно. Вы знаете, как добавить комментарий на своем языке, но, вероятно, чаще всего используете его в качестве инструмента для временной остановки выполнения некоторого фрагмента кода. Или, может быть, написать небольшую, не очень продуманную «заметку для себя» (подробнее об этом чуть позже). Но хорошо продуманные комментарии и документация - неотъемлемая часть процесса разработки.

Конечно, на работе это будет обязательным навыком. Возможно, вы это знаете, но все равно думаете: «Мне не нужны комментарии по поводу моего небольшого учебного проекта, который никто никогда не прочитает». Я и раньше попадал в эту ловушку. Вы пишете красивый блок кода, добиваясь именно того, что вы намеревались сделать. В этом столько смысла. Даже элегантно. Но позвольте мне сказать вам, что когда вы вернетесь к этому коду, примерно через 3 проекта и 2 месяца спустя, он будет не так ясен, как в тот день, когда вы его написали (если он вообще будет ясным). Это просто характер того, что мы делаем. Когда вы глубоко погружаетесь в проект, у вас в голове есть представление о том, как все разные части головоломки сочетаются друг с другом. Но как только вы отключитесь от кода на какое-то время, это может быть потеряно. Его, конечно, можно вернуть, но для этого нужно время. Время, с которым вы могли бы работать более продуктивно. Я хочу сказать, что комментарии - ваш друг. И, более конкретно, вы должны добавлять полезную документацию в свой код в то время, когда она в настоящее время нужна вам меньше всего (ловушка, о которой я упоминал ранее). Поступая так, ваше будущее «я» (и другие соавторы) поблагодарит вас, когда вы вернетесь в этот проект, чтобы найти что-то или внести какие-то изменения.

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

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

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