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

cookie

1. Записываются строкой

2. Удаляются датой в прошлом

3. Записывать с настройками

   1. Домен

   2. Время жизни

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

1. Когда удаляется пачка объектов на которую уже нет ссылки - это занимает время

2. Удаляется всё, на что нет ссылки

3. Если 2 объекта ссылаются друг на друга - они удаляются при отсутствии внеш. ссылок

4. Есть Краткосрочная и Долгосрочная память

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

1. LINK

2. Удаление элементов DOM на которые есть ссылки

   • ссылки на ячейки - сохраняет всю таблицу

   • ссылки на DOM узлы

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

• Используем чистые функции

• Используем функции высшего порядка (map, reduce).

• Используем небольшие абстракции.

• Много мелких абстракций могут легко собираться в одну большую мощную вещь.

• Примеры link

Code Standarts

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

• организация файловой структуры

• linter

Тестирование link

• Блочное (модульное, unit testing)

  • тестируем компонент, функцию

  • тестируем независимо от других, зависимости подменяем mock объектами

• Интеграционное тестирование

  • вызывается код взаимодействия нескольких классов

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

  • на тесты не влияет рефакторинг кода

  • Допустим в присланных документах есть несколько разделов. Тогда в спецификации мы можем указать, что у разбираемого документа должны быть разделы с указанными именами: Введение, Текст статьи, Заключение, Литература

• Системное тестирование

  • ручное тестирование: формализовать взаимодействие пользователя с GUI в коде, подменяя часть зависимостей mock-объектами

  • использовать специальные инструменты для записи действий пользователя с пом. библиотек

  • на каждый use case пишется по скрипту, который описывает действия пользователя

• Code coverage link

  • Степень покрытия кода в %

  • Смотреть важно то, что вы не покрыли, а не сколько

  • покрытие 50% и меньше означает тот уровень тестового покрытия будет такой же, как и при отсутствии тестирования

VCS

• Принципы

  • распределенные и централизованные link

  • централизованные: репозиторий проекта существует в единственном экземпляре и хранится на сервере

    • CVS, Subversion

  • распределенные (Git и Mercurial)

    • позволяют хранить репозиторий (копию) у каждого разработчика

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

• Git

  • fast forward - (one note)

  • rebase

  • cherrypick - копирование комита

  • отмена комита link

Estimations

• Сеть оценок для планирования в Scrum (Scrum pocker) link

  • Есть некая таблица выполненных историй распределенных по Story points

  • добавляйте только «типичные истории»

  • помещать истории в сетку после того, как мы завершаем работу с ними (чтобы был реальный опыт)

• Story point link

  • Во-первых, напомните всем, что оценка в «Пунктах» (“попугаях”, story points) – это сравнительная оценка, которая показывает «размер» требований относительно друг друга. Т.е. важны относительные значения и не может быть эталона. «Пункты» не имеют физических единиц измерения.

  • Во-вторых, проведите калибровку, т.е. приведите всю команду к единому пониманию размеров, чтобы представление о «пунктах» были у всех одинаковы. Для этого вам нужно взять те запросы, которые ваша команда уже делала в течение последних 3-4 недель. Распечатайте на отдельные карточки или выпишите на отдельные листики код (ID) и краткое название, чтобы все могли определить, о чем идёт речь. После этого разложите карточки в ряд, от самых лёгких до самых сложных. Сравнивайте запросы между собой и оценивайте их размер.

• Scrum pocker

  • Владелец продукта выбирает элемент для оценивания из Бэклога продукта и читает его описание команде.

  • Члены Команды разработки обсуждают элемент и задают уточняющие вопросы Владельцу продукта, который отвечает на них.

  • Каждый оценивающий тайно выбирает карту, соответствующую его оценке.

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

  • Если все оценивающие выберут одинаковую карту, значит, согласие достигнуто, и согласованное число становится оценкой данного элемента Бэклога.

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

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

  • После обсуждения происходит возврат к п.З, и процедура повторяется до тех пор, пока не будет достигнуто общее согласие.