Пишите лучший код быстрее и уменьшайте головную боль

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

"Я убеждена! Просто начни меня ».

Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям. - Мартин Фаулер

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

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

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

Лучшие практики

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

Когда

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

В идеале рефакторинг должен выполняться как третий этап практики Test-Code-Refactor.

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

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

Весь цикл должен занять 5 минут, но не более часа. Это лучшая практика в разработке программного обеспечения, которая называется Разработка через тестирование (TDD). Выполнение рефакторинга в этом быстром цикле позволяет сосредоточиться на небольшом наборе кодов. Избегайте откладывания рефакторинга, так как рефакторинг большого количества кодов требует больше времени, сложнее и часто не завершается из-за сжатых графиков.

Используйте инструменты

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

Чтобы реализовать единообразные стили кодирования, мы рассмотрим два самых популярных / де-факто линтера: ESLint для Javascript и TSLint для Машинопись репозиториев.

Как эти линтеры помогают в рефакторинге?

1. Для единообразия кода, если работает команда разработчиков.

2. Развивать хорошие навыки программирования, например, давать хорошие имена для функций, классов, переменных и т. Д.

3. Написать более структурированные компоненты.

4. Выявить распространенные ошибки программирования.

5. В привлечении новых разработчиков в проект.

Настройка ESLint для вашего проекта JavaScript

ESLint - это инструмент для выявления и составления отчетов о шаблонах, обнаруженных в коде ECMAScript / JavaScript, с целью сделать код более согласованным и избежать ошибок.

Рекомендуется установить ESLint локально, чтобы все плагины или общие конфигурации были доступны в одном проекте. Однако вы также можете настроить его глобально.

Предварительные требования: Node.js (^8.10.0, ^10.13.0 или >=11.10.1), npm версии 3+.

Вы можете установить ESLint с помощью npm:

$ npm install eslint --save-dev

Затем вы должны настроить файл конфигурации:

$ <project folder> eslint –-init

После инициализации в каталоге вашего проекта будет сгенерирован .eslintrc.json.

Давайте попробуем запустить ESLint на этом примере кода, который создает простой сервер Express.

eslint server.js

А вот код после исправления ошибок и предупреждений.

Для получения дополнительной информации о правилах ESLint перейдите по ссылке https://eslint.org/docs/rules/

Настройка TSLint для вашего проекта TypeScript

TSLint - это расширяемый инструмент статического анализа, который проверяет код TypeScript на наличие ошибок читабельности, удобства обслуживания и функциональности. Он широко поддерживается современными редакторами и системами сборки и может быть настроен с вашими собственными правилами, конфигурациями и средствами форматирования lint.

  1. Установите TSLint
npm install tslint typescript --save-dev

2. Создайте базовый файл конфигурации (tslint.json)

tslint –init

Здесь у нас есть простой класс TypeScript, который возвращает время в часовом поясе UTC.

Давайте запустим TSLint на этом примере класса TypeScript.

tslint -c tslint.json “src/util/*.ts”.

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

После исправления ошибок код становится намного менее загроможденным и более понятным.

Вот несколько хороших наборов правил TSLint, которые вы можете использовать.

  • Tslint-immutable - правила TSLint для отключения мутации в TypeScript
  • Tslint -istent-codestyle - правила TSLint для обеспечения согласованного стиля кода в TypeScript
  • Tslint-sonarts - правила поиска ошибок, основанные на продвинутых моделях кода, чтобы выявлять трудно обнаруживаемые ошибки в TypeScript.
  • Tslint-clean-code - набор правил TSLint, вдохновленный руководством по чистому коду.
  • Rxjs-tslint-rules - правила TSLint для RxJS

Защитная сетка

При рефакторинге существует вероятность того, что вы вводите регрессию, если не используется автоматическое тестирование. Автоматическое тестирование предупредит вас о любых регрессах, которые вы невольно вызвали из-за смены кодов.

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

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

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

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

Пример

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

Трудно читать код

Подумайте, насколько сложно понять следующие два кода. Что пытается сделать этот код? Как это реализовано?

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

Легко читаемый код

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

Примечание: ключи объектов в loadOnStartup.js намеренно неправильно названы. Обоснование объясняется здесь.

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

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

Почему константы в loadStartup.js неправильно названы? Обычно эти значения поступают из постоянного хранилища, такого как база данных SQL, но в этом примере они упрощены до константы. Не всегда возможно получить хорошие имена из внешних источников, но все же полезно переименовать их в коде.

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

Поиск ошибок

На самом деле в кодах есть ошибка. Заметили? Основная функция get или getSingaporeanAgents возвращает пустой массив. Он должен вернуть ['011', 'Agent 47']

Когда название ясно, легче находить ошибки. Чтобы найти ошибку, вам нужно только сузить круг до функции, которая реализована неправильно. Довольно просто понять, что в функции filterBySingapore есть ошибка. Строка 24 должна проверять значение agentCode, а не agentName.

Найти эту ошибку в трудночитаемом коде из первого примера - гораздо сложнее. Чтобы найти ошибку, нужно будет проследить переменные. Это будет сложнее и займет больше времени.

Рефакторинг кода помогает команде разработчиков сэкономить время на отладку.

Вывод

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

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

Атрибуция

Особая благодарность Элизабет Лумбан из IBM Garage Singapore, которая стала соавтором этой статьи.

использованная литература

Принесите свой план в IBM Garage.
Готовы ли вы узнать больше о работе с IBM Garage? Мы здесь, чтобы помочь. Свяжитесь с нами сегодня, чтобы обсудить со специалистом Garage вашу следующую большую идею. Узнайте о нашем методе IBM Garage Method, сообществах дизайнеров, разработчиков и стартапов, в которых мы работаем, а также о наших глубоких знаниях и возможностях.

Запланируйте бесплатное посещение в IBM Garage.