Языки и линтеры — почему вас это должно волновать
Зачем меня слушать?
В Container Labs я обычно работаю с 10–15 репозиториями в месяц. Я работаю с несколькими разработчиками по всему миру с разным опытом и этапами профессиональной карьеры. Как соучредитель этой новоявленной технологической компании, я решил попробовать свои силы в написании блогов, как это делают некоторые.
Я боролся с тем, на какую тему написать в первую очередь, но, как и в случае с хорошо разработанным программным обеспечением, решение пришло само собой, как только я взял с полки одно из своих кредо. Будь проще.
Как я могу писать об оркестровке контейнеров, бессерверных группах обеспечения доступности баз данных или о чем-то еще, если не начну с основ? Итак, сегодня я собираюсь сделать именно это, я собираюсь поговорить о кодовых словах и о том, почему вас должно волновать, как они выглядят.
Они все языки собаки
Давайте погрузимся прямо в Javascript.
Весь приведенный выше код функционально одинаков, нет никакой разницы в том, как он будет вести себя при выполнении. Так какого черта Уилл, какое это имеет значение? Я рад, что вы спросили вас, анонимный читатель, вы, так что очень рад.
Языки программирования — это такие же языки, как французский, немецкий, английский и т. д., поэтому давайте рассмотрим несколько примеров некоторых английских кодовых слов.
Для тех, кто свободно говорит по-английски, все это, вероятно, имеет смысл. Это все разные способы сказать одно и то же. А теперь представьте, что вы читаете книгу, написанную 10 разными авторами. Они даже не получили главу для себя, иногда каждое предложение было из другого. Представьте, как психологически тяжело было бы это читать. Не было бы последовательности! Словарный запас, структура предложений и многое другое будут другими. Эту книгу будет в лучшем случае интересно читать, если вообще возможно.
Итак, вы должны спросить себя:
- Хочу ли я, чтобы моя кодовая база была интересной или функциональной?
- Меня волнует, если новому разработчику потребуется больше времени, чтобы выучить все диалекты?
- Меня волнует, следуют ли существующие разработчики каким-либо стандартам и что это за стандарты?
- Меня волнует, легче ли читать запросы на вытягивание? (он же быстрее, с большим вниманием к функциональным изменениям, а не запаху кода)
- Я задаю правильные вопросы?
Хорошо… Так как?
На мой взгляд, лучший способ обеспечить соблюдение стандарта стиля кода — это использовать линтеры. Линтер — это инструмент, который считывает файл конфигурации, содержащий ваши правила стиля, и идентифицирует код, нарушающий эти правила. Существует три основных способа использования линтеров в кодовой базе.
- Вы можете запустить его вручную, и он выдаст все нарушения в репозитории.
- Вы можете запускать их по запросам на вытягивание (только новый код)
- Обычно вы можете интегрировать их в свою IDE, и вы будете получать предупреждения при открытии файла с нарушениями.
Третий способ мне больше всего нравится, потому что он имеет самую короткую петлю обратной связи. Откройте файл, посмотрите, что не так, в идеале исправьте все проблемы в этом файле, идите дальше. Когда вы записываете новые файлы, он будет предупреждать вас, когда вы идете. Когда вы открываете запрос на вытягивание для проверки ваших изменений, код уже соответствует согласованным стилям, и жизнь рецензента становится намного проще.
Назвать несколько
Все приведенные ниже линтеры интегрируются с Atom, Visual Studio и Sublime.
Рубин
Javascript
ESLint, JSHint, Flow (ладно, не совсем линтер. Flow — это статическая проверка типов от Facebook, но зацените)
Другие линтеры
Список Github Clean Code Linter
Это обертка
Я не могу не подчеркнуть, насколько выбор набора правил, использование линтера и (мягкое) соблюдение стандартов помогли сохранить здравомыслие мне и моей команде. Мы можем двигаться быстро, легко переключаться между проектами и делать это с улыбкой на лице.
Если вам понравилось читать мою первую попытку вести технический блог, хлопните мне в ладоши, и я напишу еще.
