# Подготовка пройдёно

#### cookie

1. Записываются строкой
2. Удаляются датой в прошлом
3. Записывать с настройками&#x20;
   1. Домен
   2. Время жизни

#### Сборщик мусора

1. Когда удаляется пачка объектов на которую уже нет ссылки - это занимает время
2. Удаляется всё, на что нет ссылки
3. Если 2 объекта ссылаются друг на друга - они удаляются при отсутствии внеш. ссылок
4. Есть Краткосрочная и Долгосрочная память

#### Утечки памяти

1. [LINK](https://habr.com/ru/post/309318/)
2. Удаление элементов DOM на которые есть ссылки
   * ссылки на ячейки - сохраняет всю таблицу
   * ссылки на DOM узлы&#x20;
3. Создаваемы глобальные переменные без var (тут поможет use strict)
   * Помнить о необходимости обнулять переменные
4. Таймеры и callback-и

   ```
   var someResource = getData();
   setInterval(function() {
   //    ... do smth with someResource
   }, 1000);
   ```
5. Замыкания в некоторых случаях

   ```
   var theThing = null;
   var replaceThing = function () {
   var originalThing = theThing;
   var unused = function () {
    if (originalThing)
      console.log("hi");
   };
   theThing = {
    longStr: new Array(1000000).join('*'),
    someMethod: function () {
      console.log(someMessage);
    }
   };
   };
   setInterval(replaceThing, 1000);
   ```

#### Блокирующий CSS

1. Разделить на CSS кт. нужен сразу: шапка, верх страницы и остальные
2. Разделить CSS по media, стили для печати, стили моб и desktop вёрстки
3. Загружать асинхронно с помощью preload и onload
4. Critical CSS
5. Загрузка стилей для каждого блока прямо перед рендерингом блока

### Functional Programming [link](https://habrahabr.ru/post/154105/)

* Используем чистые функции
* Используем функции высшего порядка (map, reduce).
* Используем небольшие абстракции.&#x20;
* Много мелких абстракций могут легко собираться в одну большую мощную вещь.
* Примеры [link](https://bitbucket.org/Vlasakh/jinterview/wiki/Functional%20programming)

### Code Standarts

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

### Тестирование [link](https://habrahabr.ru/post/81226/)

* Блочное (модульное, unit testing)&#x20;
  * тестируем компонент, функцию
  * тестируем независимо от других, зависимости подменяем mock объектами
* Интеграционное тестирование
  * вызывается код взаимодействия нескольких классов
  * важен только результат взаимодействия, а не детали и порядок вызовов
  * на тесты не влияет рефакторинг кода
  * Допустим в присланных документах есть несколько разделов. Тогда в спецификации мы можем указать, что у разбираемого документа должны быть разделы с указанными именами: Введение, Текст статьи, Заключение, Литература
* Системное тестирование
  * ручное тестирование: формализовать взаимодействие пользователя с GUI в коде, подменяя часть зависимостей mock-объектами&#x20;
  * использовать специальные инструменты для записи действий пользователя с пом. библиотек
  * на каждый use case пишется по скрипту, который описывает действия пользователя
* Code coverage [link](https://habrahabr.ru/post/231583/)
  * Степень покрытия кода в %
  * Смотреть важно то, что вы не покрыли, а не сколько
  * покрытие 50% и меньше означает тот уровень тестового покрытия будет такой же, как и при отсутствии тестирования

### VCS

* Принципы
  * распределенные и централизованные [link](https://goo.gl/jKPULq)
  * централизованные: репозиторий проекта существует в единственном экземпляре и хранится на сервере&#x20;
    * CVS, Subversion
  * распределенные (Git и Mercurial)
    * позволяют хранить репозиторий (копию) у каждого разработчика
    * центральный репозиторий, в который будут отправляться изменения из локальных
* Git
  * fast forward - (one note)
  * rebase
  * cherrypick - копирование комита
  * отмена комита [link](https://githowto.com/ru/undoing_committed_changes)

### Estimations

* Сеть оценок для планирования в Scrum (Scrum pocker) [link](https://habrahabr.ru/post/167983/)
  * Есть некая таблица выполненных историй распределенных по Story points
  * добавляйте только «типичные истории»
  * помещать истории в сетку после того, как мы завершаем работу с ними (чтобы был реальный опыт)
* Story point [link](https://tim.com.ua/2010/10/how-to-estimate-in-story-points/)
  * **Во-первых**, напомните всем, что оценка в «Пунктах» (“попугаях”, story points) – это сравнительная оценка, которая показывает «размер» требований относительно друг друга. Т.е. важны относительные значения и не может быть эталона. «Пункты» не имеют физических единиц измерения.
  * **Во-вторых**, проведите калибровку, т.е. приведите всю команду к единому пониманию размеров, чтобы представление о «пунктах» были у всех одинаковы. Для этого вам нужно взять те запросы, которые ваша команда уже делала в течение последних 3-4 недель. Распечатайте на отдельные карточки или выпишите на отдельные листики *код (ID) и краткое название*, чтобы все могли определить, о чем идёт речь. После этого разложите карточки в ряд, от самых лёгких до самых сложных. Сравнивайте запросы между собой и оценивайте их размер.
* Scrum pocker
  * Владелец продукта выбирает элемент для оценивания из Бэклога продукта и читает его описание команде.
  * Члены Команды разработки обсуждают элемент и задают уточняющие вопросы Владельцу продукта, который отвечает на них.
  * Каждый оценивающий тайно выбирает карту, соответствующую его оценке.
  * Как только каждый оценивающий выберет тайно нужную карту, все оценивающие одновременно показывают свои карты, обозначающие их личные оценки.
  * Если все оценивающие выберут одинаковую карту, значит, согласие достигнуто, и согласованное число становится оценкой данного элемента Бэклога.
  * Если же оценки расходятся, члены команды приступают к обсуждению, чтобы выявить любые недоразумения и высказать свои предположения.
  * Как правило, обсуждение начинается с просьбы к тем оценивающим, которые поставили высокие и низкие оценки, пояснить или обосновать свои оценки.
  * После обсуждения происходит возврат к п.З, и процедура повторяется до тех пор, пока не будет достигнуто общее согласие.
