Feel free to create pull requests to add content. Open issues to discuss ideas, or get clarification.

We should be on the same page

Чтобы front-end отдел превратился во front-endman-а.

Он скрывается во front-end отделе.

Он не совершает ошибок, его код всегда идеален.

Он следует лучшим стандартам и использует лучшие практики.

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

Он SuperDRY. Все, что он сделал один раз в следующий сделает в три раза быстрее.

Он знает все героические принципы.

Основные принципы front-endman-а это:

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

Описание модульного принципа смотри тут

Все, ... автоматизировать, ... автоматизировать.

Тестирование, развертывание проекта, настройка ОС, приготовление кофе, должно быть максимально быстрым и требовать минимальных телодвижений со стороны разработчика.

• Intermediate english level
• HTML5, CSS3, JavaScript, SVG
• Responsive Web, SCSS, BEM
• Git
• HTTP(S), RESTful APIs, SSH
• NPM, Webpack, Gulp
• ES6, TypeScript
• Basic terminal usage, Personal text editor (WebStorm, Vim, Sublime Text, etc.)
• Test automation
• Data structures & Algorithms
• GOF Design patterns, Architectural patterns
• Regular Expressions
• SOLID, YAGNI, KISS etc

Тут больше

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

Создание архитектуры ведётся в draw.io

На планирование архитектуры в обязательном порядке выделяется от 8-ми часов.

При разработке архитектуры нужно:

• Выбрать стек технологий
• Разбить проект на отдельные модули
• Описать работу сервисов
• Продумать взаимодействие между сервисами и модулями

При написании модуля избегать сильной привязки к окружению.

Работу с сервисами выносить в корневые модули страниц. Исключать вызовы сервисов в компонентах (input, select, dropdown).

Все строковые значения (url, идентификаторы) выносить в constants.

Любые функции общего назначения (форматирование даты, подготовка данных) выноситься в helper.

Get методы и функции должны возвращать значение.

Все проекты сопровождаются README.md файлом в котором описаны:

• Название проекта
• Короткое описание
• Homepage
• Ссылку на систему баг трекинга
• Инструкция по установке зависимостей и настройке окружения
• Команды для:
  • Старта разработки. Запуск watch-еров
  • Сборки
  • Запуска тестов
• Указаны основные технологии
• Указаны поддержка браузеров

Если заказчик не определил поддержку браузеров, то по умолчанию мы поддерживаем:

Last 2 ✔	Last 2 ✔	11+ ✔	Last 2 ✔	Last 2 ✔	Last 2 ✔

"browserslist": [
  "> 5%",
  "Last 2 versions",
  "ie >= 11",
  "not ie_mob <= 11",
  "not op_mini all"
]

• .gitignore
• .*lint
• .env - Описывает переменные окружения для node.js проектов
• .babelrc
• .editorconfig - Синхронизирует настройки редакторов. Hужно установить плагин для своего редактора, если его нет.

package.json находится в корневой директории и является стартовой точкой проекта.

Для линтинга кода package.json имеет несколько обязательных dev-зависимостей.

{
  "name": "project-name",
  "version": "0.0.1",
  "scripts": {
    "start": "Start development process",
    "publish": "Create build for production",
    "test": "Run tests (unit, lint, ...)",
    "stylelint": "stylelint \"**/*.scss\" --syntax scss"
  },
  "dependencies": {
    "name": "version"
  },
  "devDependencies": {
    "name": "version"
  },
  "browserslist": [
    "> 5%",
    "Last 2 versions",
    "ie >= 11",
    "not ie_mob <= 11",
    "not op_mini all"
  ]
}

Тут больше package.json

Для разметки страницы используется HTML5.

Для написания стилей используется шаблонизатор SCSS

Для поддержания code style подключается файл конфигураций StyleLint

Настройки StyleLint формируются из правил StyleLint и дополнительных плагинов:

• stylelint config standard - основа для правил StyleLint
• stylelint-scss - правила для линтинга .scss файлов
• stylelint-no-unsupported-browser-features - проверяет поддержку браузером написанных правил
• stylelint-z-index-value-constraint - позволяет установить максимальное и минимальное значение для z-index
• stylelint-declaration-strict-value - плагин, добавляющий правило согласно которому необходимо определённые свойства (цвета, шрифты, z-index) указывать только через переменные

Для запуска StyleLint необходимо установить зависимости

# Install dependencies
npm i -D stylelint stylelint-config-standard stylelint-no-unsupported-browser-features stylelint-scss stylelint-z-index-value-constraint stylelint-declaration-strict-value

# Run linting
stylelint ./path/to/styles/*.scss --syntax scss

При разработке стилей используется BEM методология.

Код должен соответствовать требованием Airbnb.

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

В ESLint конфиг подключаеются дополнительные модули:

• eslint-config-airbnb-base - правила eslint по стандарту airbnb
• babel-eslint - babel парсер для eslint
• eslint-plugin-compat - проверяет поддержку браузером

Для запуска ESLint необходимо установить зависимости

# Install dependencies
npm i -D eslint eslint-config-airbnb-base babel-eslint eslint-plugin-compat

# Run linting
./node_modules/.bin/eslint ./path/to/scripts/*.js

React приложения соответствуют всем правилам ES6+ приложений. Также необходим установить зависимости для линтинга React приложений:

• eslint-plugin-react - Плагин с правилами ESLint для приложений на React

npm i -D eslint-plugin-react

В проекте используется файл конфигураций ESLint для React приложений.

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

Подключенные *Lint файлы будут делать невозможным билд/коммит проекта без соблюдения их правил.

• ESLint
• React ESLint
• StyleLint
• TSLint

Правильно подключенные git-hooks сделают невозможным коммиты/выливку проекта без прохождения предварительно установленных вами тестов. В простой установке git-hooks нам поможет husky, по ссылке есть более подробное описание, как можно его использовать.

npm install husky --save-dev

Дописываем необходимые команды в наш package.json

{
  "name": "project-name",
  "version": "0.0.1",
  "scripts": {
    "start": "Start development process",
    "publish": "Create build for production",
    "eslint": "./node_modules/.bin/eslint ./path/to/scripts/*.js",
    "stylelint": "stylelint ./path/to/styles/*.scss --syntax scss",
    "lint": "npm run eslint && npm run stylelint",
    "test": "jest"
  },
  "husky":{
    "hooks": {
      "pre-commit": "npm run lint",
      "pre-push": "npm run lint && npm test"
    }
  }
}

Дополнительная информация по ссылке в заголовке

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

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

При продакшн сборке все TODO комментарии удаляются.

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

Comments – Do not write comments for what you are doing, instead write comments on why you are doing. Specify about any hacks, workaround and temporary fixes. Additionally, mention pending tasks in your to-do comments, which can be tracked easily.

При продакшн сборке все комментарии удаляются.

Please make short pull requests. Save your code reviwer

Во время инициализации проекта создается основная ветка. С бесконечным жизненным циклом.

master - содержит версию с текущим релизом.

Ветка master может изменяться только по средствам merge request.

Для каждого таска или баг фикса создается feature ветка от master ветки.

$ git checkout -b myfeature master

Feature ветка должна сливаться с master веткой через merge request.

Feature ветку можно назвать любым именем, кроме bugfix-*, master.

Bugfix ветку нужно назвать bugfix-[name].

Read me

Первое, что должен проверить ревьювер - работает ли функционал так, как должен.

• Распространить знания по команде
• Научиться думать, как остальные члены команды
• Повысить качество и поддерживаемость кода

Отлов ошибок нужно предоставить тестам

Следование code style-у должен проверять *lint-ер. Это повысит читаемость кода и упростит его поддержку.

Find problems, Not solutions

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

Code review - high priority task.

Максимальное время на ревью 1 час. Далее код отправляется на доработку или принимается

Не просматривай более 500 строк кода за раз

Если что-то копируется больше 2-х раз, это может быть копипастом

• Работает ли функционал так как описано в требованиях
• Maintainability
  • Читается ли код как проза
  • Нарушения семантики - делает ли класс/метод то что написано в его названии
• Тестируемость
• Логические ошибки
• Архитектурные ошибки
• Возможности для упрощения, использования паттернов.
• Idiomatic - используются ли все возможности языка, фреймворка
• Использование плохих практик
• Team code convention
• No hard coding, use constants/configuration values
• Зависимости между классами/компонентами/модулями. Везде ли они нужны?
• Reliability - отлов исключений
• Security
  • Are all data inputs checked (for the correct type, length, format, and range) and encoded?
  • Where third-party utilities are used, are returning errors being caught?
  • Are output values checked and encoded?
  • Are invalid parameter values handled?
• Performance
• Usability & User experience

Don't make me think

Одна цель - один коммит

Title - коротко описывает функционал.

Description - описывает что было изменённо, на что нужно обратить внимание. Содержит описание таска.

Не squash коммиты до окончания ревью

Делай code review самостоятельно перед коммитом (просматривай git diff)

Постарайтесь ответить на каждый комментарий

Merge request должен содержать не более 400 строк кода

Удаляйте закомментированный код. Его можно легко восстановить с помощью VCS.

Используйте комментарии в merge request. По окончанию code review сообщите от этому автору в личном сообщении.

Instead of explaining the entire solution to developers during the code review process, simply share the links of relevant websites or encourage them to research on the internet by providing keywords.

Read me

На этапе оценки проекта важно включить минимум 30% тестирования основного функционала.

Наличие или отсутствие тестов может зависеть от пожеланий заказчика.

Для тестирования кроссбраузерности используется BrowserStack.

Для работы с ним нужно установить chrome extension, прописать в настройках расширения https://www.browserstack.com/

и зайти в общий BrowserStack.

В случае, если BrowserStack занят, страница будет заблокирована, пока BrowserStack не освободится.

Все пожелания по расширению оставляем тут

• CORS check

При разработке UI делается акцент на качество UX. Вот некоторые примеры хорошего UX:

• Закрывать попапы по нажатию esc
• Возможность ходить по всем элементам управления с помощью tab
• Возможность управления стрелочками в селекте
• Реакция на focus
• Активная ссылка не должна нажиматься дважды
• Вывод сообщений об ошибке

У нас тут больше

Смотри здесь

TODO: Describe modules principle

Suggestions/improvements welcome!

Task list for implementation here