При проверке кода разработчики редко получают достаточно времени, чтобы по-настоящему понять каждую его строку. Вместо этого мы должны быстро обдумывать различные ситуации, в которых этот код может стать проблемным. Поэтому каждый раз, когда я проверяю код, я ищу определенные моменты, которые помогут мне быстро его понять.
Эта статья поможет вам осознать, как вы можете написать предельно хороший код, чтобы другие разработчики могли лучше его понимать. Эта статья даст вам краткое введение в некоторые методы, которые я использую при разработке своих компонентов, и покажет, как вы можете сделать то же самое.
Совет № 1: Всегда используйте prop-types для определения всех реквизитов в ваших компонентах
prop-types - проверка типов во время выполнения для объектов React и подобных объектов. prop-types поможет вам проверить, передается ли требуемый тип prop в ваш компонент или нет.
Если в ваш компонент не передан правильный тип конкретной prop, пакет выдаст предупреждение в консоли вашего браузера:
Из приведенного выше предупреждающего сообщения довольно ясно, что мы передаем строку в компонент Hello, но компонент ожидает, что сообщение prop будет иметь тип array.
Совет № 2: Используйте displayName, чтобы определить конкретное имя для вашего компонента
Строка displayName используется в сообщениях отладки. Если вы не используете displayName в своих компонентах, вы должны начать делать это прямо с этого момента.
Обычно, если вы отлаживаете свой компонент с помощью инструментов разработчика React, вы увидите компоненты, потому что они выведены из имени функции или класса, который определяет компонент. Однако, если вы оказались в ситуации, когда у вас есть два компонента с одинаковым именем (button, dropdown, и т. д.), вам может потребоваться переименовать ваши компоненты. В противном случае вы не сможете их различить.
Вы можете решить вышеупомянутую проблему, используя displayName. Просто переименуйте компоненты, используя эту функцию.
В приведенном выше примере вы можете видеть, что, хотя имя класса является Component, вы увидите имя «Hello» в инструменте разработчика React, поскольку его Hello имеет в качестве displayName.
Это очень полезная и недооцененная функция в процессе отладки.
Совет № 3: используйте линтер, чтобы сделать ваш код проще
Если вы волнуетесь о своем здравомыслии, то вам следует использовать линтер в своей кодовой базе.
Линтер поможет вам сделать ваш код похожим на код других разработчиков в вашей компании. Следуя строгому набору правил, вы можете быть уверены, что вся база кода будет строго согласованной. Например, вы можете заставить других разработчиков использовать точки с запятой в конце строки. Если этого не произойдет, то линтер выдаст ошибку или предупреждение на основе ваших настроек.
Я рекомендую использовать ESLint, но вы можете выбрать любой другой вариант, который подходит вашим потребностям.
Совет № 4: просмотрите свой собственный код перед созданием запроса на извлечение
Независимо от того, исправляете ли вы ошибку или разрабатываете новую функцию, есть вероятность, что вы внесете изменения и быстро создадите запрос на извлечение, когда спешите. Проблема в том, что вы даже не можете просмотреть свои изменения. В результате вы можете пропустить некоторые места, которые вы могли бы изменить и улучшить.
Исходя из моего личного опыта, после просмотра моих собственных изменений, становится очевидно, что иногда я мог сделать код более производительным, сделать его более модульным и разбить большие функции на несколько меньших.
Совет № 5: Ваш первый проект не всегда лучший
Многие из вас уже знают это. Первая итерация не всегда лучшая. Вы должны взглянуть на свою первую итерацию кодирования и подумать о возможностях, которые вы могли упустить.
Одним из способов решения этой проблемы может быть разработка Test Driven Development (TDD), которая является отличным инструментом, но редко применяется. Если вы придерживаетесь подхода TDD, ваша первая итерация может стать лучшей. Но вы всегда должны искать лучший подход.
Потратьте время на то, чтобы подумать о том, как вы хотите действовать, даже до написания одной строки кода, и когда вы закончили с реализацией функции или исправлением ошибки, посмотрите на свои изменения и подумайте, как вы можете сделать все еще лучше.
Совет № 6: разделите ваш код на несколько небольших функций
Разделение ваших больших функций на несколько меньших сделает более мелкие функции больше пригодными для повторного использования. Их также станет намного проще тестировать.
Вы также можете создать множество служебных файлов, которые помогут вам удалить дублирующийся код из нескольких файлов.
После создания нескольких файлов посмотрите на них, и вы увидите, что есть много повторяющихся строк кода. Вы можете взять эти строки, чтобы создать служебный файл. Затем вы можете повторно использовать один и тот же файл утилиты в нескольких файлах.
Совет № 7: Создайте несколько файлов вместо записи большого файла
Просмотр одного большого файла всегда сложнее, чем просмотр нескольких небольших файлов.
Если вы разделите свой код на несколько небольших файлов, и каждый файл будет содержать только одну логику, то рецензенту будет очень легко просмотреть этот файл.
Совет № 8: Будьте очень осторожны при именовании ваших файлов
Еще одна вещь, которую вы должны хорошенько запомнить состоим в том, что если вы называете свои файлы в соответствии с работой, которую они выполняют, это также поможет вам в будущем, как и другим разработчикам. Таким образом будет гораздо проще понять, что на самом деле делает тот или иной файл.
Посмотрев на имя файла, другие разработчики должны понять, что файл должен делать.
Например, dropdown.js – это хорошее имя, но оно очень общее, и если вы используете его в нескольких местах в одном каталоге, вы можете назвать его примерно как topDropdown.js, bottomDropdown.js. И это плохо.
Лучшим способом будет префикс их с задачей, которую они должны выполнять. Например, userDropdown.js, fileDropdown.js и т. д.
Совет № 9: Всегда пишите тесты для своего кода
Я не могу не подчеркнуть важность этого момента. Тесты должны являться завершающим этапом каждого вашего кода.
После разработки функции вы можете почувствовать, что она работает. И она в самом работает. Но могут быть (и, скорее всего, будут) неудачные случаи, когда вам кажется одно, но на самом деле все происходит совсем иначе. Именно тесты помогут вам определить такие случаи.
Очевидно, что написание тестовых примеров увеличит время, необходимое для написания кода. Но это всегда поможет вам устранить потенциальные ошибки, которые могут возникнуть в будущем.
Вы должны уделить время написанию тестов, если вы по-настоящему заботитесь о своем приложении.
Совет № 10: не злоупотребляйте обработчиком ошибок кодовой базы
В React 16 представлен лучший способ обработки ошибок с помощью функции, называемой Error Boundaries.
По сути, Error Boundaries являются инструментами React, существующими для мониторинга ошибок JavaScript в любом месте своего дочернего дерева компонентов. Они фиксируют найденные ошибки и выводят резервный пользовательский интерфейс вместо сбойного дерева компонентов.
Если логика резервного интерфейса присутствует в вашем компоненте ErrorBoundary, вы можете инкапсулировать свой компонент внутри этого компонента ErrorBoundary.
Это хороший способ показать резервный интерфейс для ваших ошибок. Но вам не нужно оборачивать все ваши компоненты компонентом ErrorBoundary.
Вы можете разместить компоненты ErrorBoundary только в нескольких стратегических местах, где они вам нужны.