Рассказываем, как мы с фронтенд-разработчиком Дмитрием Балаевым @manmo убираем Legacy, какими Open Source конфигурациями для ESLint пользуемся и как статический анализатор кода повлиял на развитие разработчиков нашей компании.

Что такое Legacy и откуда он берется

Legacy code — это тяжело поддерживаемый, некачественный или устаревший код, в котором невозможно разобраться (или можно, но очень долго). Часто под Legacy подразумевают код, которая команда получает в «наследство» от предыдущих разработчиков. Но не все так однозначно: код, который [хорошие] команды разработки передают заказчику, Legacy назвать нельзя, потому что в таком коде разобраться можно быстро и легко.

Основные причины Legacy:

• Поддержка проекта с уже написанным кодом.

  В жизни любого разработчика наступает момент столкновения с «мамонтом». Мы работали над проектом, где код был написан еще в 2000 году. Тогда ни о каком ES6 нельзя было даже мечтать. За 20 лет на поддержке того проекта сменились сотни разработчиков. Каждый из них писал так, как ему удобно, используя свою методику и удобные технологии. Из-за подобных ситуаций не получается единый стиль написания кода, зато получаются костыли в JS-коде, неправильно используемые переменные в CSS и многое другое.  

• Лень разбираться в чужом коде и делать рефакторинг.

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

• Нет четкой схемы работы и должного контроля на проекте.

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

• Нет Code review со стороны тимлидов.

  Четкие инструкции не отменяют человеческий фактор, поэтому даже в очень сильных командах нужны Code review. Нет Code review — есть Legacy и постоянные ковыряния в Pull Request’ах. Нужно помнить стилистику каждого проекта, а для разработчиков это тяжело. Code review должно решать эту проблему.

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

Как убрать Legacy

Есть ряд инструментов, которые помогут сделать рефакторинг и «подогнать» код под единые стандарты. В этой статье мы рассмотрим несколько статических анализаторов кода (далее SCA) – они анализируют программный код без ее реального выполнения. 

JSLint — это SCA с веб-интерфейсом для программ на языке JavaScript, проверяющий их соответствие стандартам оформления кода. Его разработал американский программист и предприниматель Дуглас Крокфорд (Douglas Crockford) в 2002 году. Дуглас занимается разработкой языка JavaScript. Он популяризировал формат данных JSON и разработал различные инструменты, связанные с JavaScript, такие как JSLint и JSMin. После установки анализатор сразу готов к работе. Недостатком является то, что JSLint не настраивается и не расширяется. Официальная документация очень слабая.

JSHint используется при разработке программного обеспечения для проверки соответствия исходного кода JavaScript правилам кодирования. JSHint был создан в 2011 году Антоном Ковалевым как форк проекта JSLint. В данный момент Антон работает инженером по безопасности в Medium. JSHint имеет хорошую документацию и простую интеграцию в редакторы. Из минусов — сложно определить, какие правила вызывают ошибки.

ESLint — инструмент для выявления проблемных шаблонов, обнаруженных в коде JavaScript. Он был создан Николасом Закасом (Nikolas, Zakas) в 2013 году. Николас участвовал в разработке Yahoo! User Interface (YUI) library, создал Cookie Utility, Profiler, YUI Test, три его книги о JavaScript переведены на русский язык. С помощью анализатора ESLint можно устанавливать правила поиска ошибок и легко их находить. Для него доступно множество плагинов, любое правило можно переключить, многие из них имеют дополнительные настройки. Результат получается предсказуемым, плюс ко всему у ESLint удобная поддержка ES6 и реактивных фреймворков.

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

Как настроить ESLint

При создании проектов на современных фреймворках анализатор уже может быть встроен при первоначальных настройках. К примеру, при инициализации нового проекта на Nuxt система предлагает установить ESLint:

Чтобы установить ESLint в уже существующий проект, нужно добавить его через npm “npm install eslint –save-dev” и создать файл настроек “.eslintrc”. Для мгновенной подсветки ошибок можно настроить редактор кода. Дополнительные плагины также устанавливаются через npm. 

В сети можно найти множество Open Source конфигураций для ESLint. Это обычные node.js пакеты с префиксом “eslint-config-”, которые содержат в себе только конфигурацию ESLint от конкретной компании/команды/разработчика. Например, можно легко использовать готовые конфигурации от Google или Airbnb.

Иногда может понадобиться отключить правила в конкретном месте или файле. Это можно сделать несколькими способами:

/* eslint-disable */
	console.log(‘test’);
/* eslint-enable */

или 

console.log(‘test’); // eslint-disable-line

также можно отключать конкретные правила:

/* eslint-disable no-console */
	console.log(‘test’);
/* eslint-enable no-console */

или

console.log(‘test’); // eslint-disable-line no-console

// eslint-disable-next-line no-console
console.log(‘test’);

Не все разработчики согласны с внедрением ESLint, так как привыкли писать код по-своему и не хотят перестраиваться. Бывали случаи, что некоторые разработчики просто забивали на правила, делали пулл с ошибками. В данном случае может помочь библиотека pre-commit, которая не позволяет сделать коммит, если есть ошибки. Но это может привести к тому, что кто-то отключит определенные настройки или сам ESLint. В таком случае поможет только должный контроль и Code review на проекте.

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

Что в итоге

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

Вот как на нашу компанию повлияло внедрение ESLint:

• Экономим времени на поддержке проектов порядка 30%.

• Быстрее и легче обучаем новых сотрудников/стажеров/джунов. Они сразу видят как писать более чистый код.

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

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

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