среда, 15 октября 2014 г.
Работа над проектом
Работа над проектом
- Сбор требований и составление ТЗ
- Проектирование макета и дизайн
- Верстка
- Программирование
- Тестирование
- Релиз-деплой
- Следующая итерация
Всё начинается с таска
- Bugzilla, GitHub, JIRA, Mantis, Redmine, …
- Позволяют отслеживать статус выполнения задачи и затраченное не неё время
- Получать оповещения об изменениях
- Составлять план ведения работ и релизов
Проектирование макета
- Начинайте с эскиза
- Используйте сетки
- Разбивайте всё на отдельные слои
- Учитывайте разные длины слов в разных языках. Например: Скачать, Завантажити, Download, Indir
- Не злоупотребляйте с кастомными шрифтами
Верстка
Заводите отдельные таски для верстки и программирования
- Требуйте реальные тексты для рыбы
- Используйте сервера приложения с моками
- Среда разработки должна быть доступна в виртуальных машинах
- Автоматизируйте процесс сборки html, css и js файлов: grunt, bash, make-файлы, …
- Используйте готовые сетки: anygrid, bootstrap, …
- Используйте динамические сниппеты (emmet, шаблоны в редакторе)
- Выделяйте общие блоки
- Делайте блоки максимально независимыми
Программирование
- Разворачивайте на виртуальной машине систему аналогичную продакшин
- Процесс «разворачивания» приложения должен быть максимально автоматизирован и документирован
- Данные из хранилища должны быть легко заменяемы на моки
- Используйте готовые фреймворки
- Выделяйте общие компоненты в независимые модули
- Покрывайте тестами основные страницы и компоненты
- Создавайте API с автогенерируемой документацией
- Версионируйте API и до последнего поддерживайте обратную совместимость
- Создавайте рабочее окружение удобное для всех членов команды разработки
- Именуем ветки в соответствии с номерами тасков
- Много коммитим в форк / ветку, после завершения сквошим
- Финальный коммит берем из "Commit message"
- Автоматически собираем ченжлог со списком тасков-коммитов перед релизом
Тестирование
- Тестирование должно проходить на отдельном инстансе приложения, доступному по отдельному URL
- Тестовый сервер должен быть полностью аналогичен продакшн
- Приложение развернутое на тестовом сервере должно вспоследствие "as is" с точностью до байта переноситься в продакшн
Релиз-деплой
- Автоматизировать можно как угодно: grunt, bash, make-файлы, мы используем deb-пакеты
- Собираем автоматически пулл-реквесты через Teamcity
- Travis CI, Jenkins, GitHub Web-hooks, …
- Изменения должны разворачиваться в продакшине максимально атомарно
Резюме
- Принимайте участие в обсуждении ТЗ, дизайна и технических моментов
- Бейте задачу на подзадачи и создавайте дерево тасков
- Старайтесь держать чистой, но полной историю изменений
- Севера разработки должны быть легко поднимаемы и требовать минимальной настройки
- Упрощайте процесс сборки и релиза до максимума
- Сбор требований и составление ТЗ
- Проектирование макета и дизайн
- Верстка
- Программирование
- Тестирование
- Релиз-деплой
- Следующая итерация
Всё начинается с таска
- Bugzilla, GitHub, JIRA, Mantis, Redmine, …
- Позволяют отслеживать статус выполнения задачи и затраченное не неё время
- Получать оповещения об изменениях
- Составлять план ведения работ и релизов
Проектирование макета
- Начинайте с эскиза
- Используйте сетки
- Разбивайте всё на отдельные слои
- Учитывайте разные длины слов в разных языках. Например: Скачать, Завантажити, Download, Indir
- Не злоупотребляйте с кастомными шрифтами
Верстка
Заводите отдельные таски для верстки и программирования
- Требуйте реальные тексты для рыбы
- Используйте сервера приложения с моками
- Среда разработки должна быть доступна в виртуальных машинах
- Автоматизируйте процесс сборки html, css и js файлов: grunt, bash, make-файлы, …
- Используйте готовые сетки: anygrid, bootstrap, …
- Используйте динамические сниппеты (emmet, шаблоны в редакторе)
- Выделяйте общие блоки
- Делайте блоки максимально независимыми
Программирование
- Разворачивайте на виртуальной машине систему аналогичную продакшин
- Процесс «разворачивания» приложения должен быть максимально автоматизирован и документирован
- Данные из хранилища должны быть легко заменяемы на моки
- Используйте готовые фреймворки
- Выделяйте общие компоненты в независимые модули
- Покрывайте тестами основные страницы и компоненты
- Создавайте API с автогенерируемой документацией
- Версионируйте API и до последнего поддерживайте обратную совместимость
- Создавайте рабочее окружение удобное для всех членов команды разработки
- Именуем ветки в соответствии с номерами тасков
- Много коммитим в форк / ветку, после завершения сквошим
- Финальный коммит берем из "Commit message"
- Автоматически собираем ченжлог со списком тасков-коммитов перед релизом
Тестирование
- Тестирование должно проходить на отдельном инстансе приложения, доступному по отдельному URL
- Тестовый сервер должен быть полностью аналогичен продакшн
- Приложение развернутое на тестовом сервере должно вспоследствие "as is" с точностью до байта переноситься в продакшн
Релиз-деплой
- Автоматизировать можно как угодно: grunt, bash, make-файлы, мы используем deb-пакеты
- Собираем автоматически пулл-реквесты через Teamcity
- Travis CI, Jenkins, GitHub Web-hooks, …
- Изменения должны разворачиваться в продакшине максимально атомарно
Резюме
- Принимайте участие в обсуждении ТЗ, дизайна и технических моментов
- Бейте задачу на подзадачи и создавайте дерево тасков
- Старайтесь держать чистой, но полной историю изменений
- Севера разработки должны быть легко поднимаемы и требовать минимальной настройки
- Упрощайте процесс сборки и релиза до максимума
Методы регулярных выражений
- экземпляры RegExp:
/regexp/.exec('строка')
null или массив ['всё совпадение', $1, $2, ...]
/regexp/.test('строка')
false или true
- экземпляры String:
'str'.match(/regexp/)
'str'.match('\\w{1,3}')
- эквивалент /regexp/.exec, если нет флага g;
- массив всех совпадений по строке, если есть флаг g
(внутренние группировки игнорируются)
'str'.search(/regexp/)
'str'.search('\\w{1,3}')
позиция первого совпадения или -1
- экземпляры String:
'str'.replace(/old/, 'new');
В строке замены поддерживаются следующие спецсимволы:
$$ вставляет значок доллара "$"
$& подстрока, совпавшая с регэкспом
$` подстрока до $&
$' подстрока после $&
$1, $2, $3 и т.д.: cтрока, совпавшая с соответствующей
скобочной группировкой
'str'.replace(/(r)(e)gexp/g,
function(matched, $1, $2, offset, sourceString) {
// чем заменить matched на этом шаге?
return 'замена';
});
/regexp/.exec('строка')
null или массив ['всё совпадение', $1, $2, ...]
/regexp/.test('строка')
false или true
- экземпляры String:
'str'.match(/regexp/)
'str'.match('\\w{1,3}')
- эквивалент /regexp/.exec, если нет флага g;
- массив всех совпадений по строке, если есть флаг g
(внутренние группировки игнорируются)
'str'.search(/regexp/)
'str'.search('\\w{1,3}')
позиция первого совпадения или -1
- экземпляры String:
'str'.replace(/old/, 'new');
В строке замены поддерживаются следующие спецсимволы:
$$ вставляет значок доллара "$"
$& подстрока, совпавшая с регэкспом
$` подстрока до $&
$' подстрока после $&
$1, $2, $3 и т.д.: cтрока, совпавшая с соответствующей
скобочной группировкой
'str'.replace(/(r)(e)gexp/g,
function(matched, $1, $2, offset, sourceString) {
// чем заменить matched на этом шаге?
return 'замена';
});
Устройство HTTP
<схема>://<логин>:<пароль>@<хост>:<порт>/<URL‐путь>?<параметры>#<якорь>
Структура протокола
<Метод> <URI> HTTP/1.1
<Заголовки>
Referer: http://www.yandex.ru/
</Заголовки>
<Тело сообщения>
param=value&a=1&b=2&c=3
</Тело сообщения>
Коды состояния HTTP
- (1xx) Информационные ответ
- (2xx) Ответы успеха
- (3xx) Ответы перенаправления
- (4xx) Ошибки клиента
- (5xx) Ошибки сервера
Заголовки HTTP
- General Headers
- Request Headers
- Response Headers
- Entity Headers
HTTP/1.1 200 OK!
Date: Mon, 17 Sep 2012 13:05:11 GMT!
Transfer-Encoding: chunked!
Connection: keep-alive!
Pragma: no-cache!
Cache-Control: no-cache, no-store, max-age=0,
must-revalidate!
Server: nginx!
Vary: X-Real-SSL-Protocol!
Content-Type: text/html; charset=UTF-8!
Expires: Mon, 17 Sep 2012 13:05:11 GMT!
Content-Encoding: gzip!
Структура протокола
<Метод> <URI> HTTP/1.1
<Заголовки>
Referer: http://www.yandex.ru/
</Заголовки>
<Тело сообщения>
param=value&a=1&b=2&c=3
</Тело сообщения>
Коды состояния HTTP
- (1xx) Информационные ответ
- (2xx) Ответы успеха
- (3xx) Ответы перенаправления
- (4xx) Ошибки клиента
- (5xx) Ошибки сервера
Заголовки HTTP
- General Headers
- Request Headers
- Response Headers
- Entity Headers
HTTP/1.1 200 OK!
Date: Mon, 17 Sep 2012 13:05:11 GMT!
Transfer-Encoding: chunked!
Connection: keep-alive!
Pragma: no-cache!
Cache-Control: no-cache, no-store, max-age=0,
must-revalidate!
Server: nginx!
Vary: X-Real-SSL-Protocol!
Content-Type: text/html; charset=UTF-8!
Expires: Mon, 17 Sep 2012 13:05:11 GMT!
Content-Encoding: gzip!
Про тестирование
Unit-тесты – тесты, проверяющие корректность работы отдельных модулей программы.
Плюсы unit-тестов
- Можно запустить сразу после внесения изменений в код – позволяют найти дефект сразу после его создания.
- Могут служить документацией к коду.
- Упрощают процесс рефакторинга.
Минусы unit-тестов
- Их надо писать.
- Их надо уметь писать.
- Их надо поддерживать.
Но даже если все компоненты по отдельности работают правильно, то это ещё ничего не значит.
Интеграционные тесты – тесты, проверяющие корректность взаимодействия отдельных модулей друг с другом.
Плюсы интеграционных тестов
- Находят баги, которые не могут быть обнаружены unit-тестами.
- Запускаются после сборки проекта и позволяют быстро обнаружить проблемы взаимодействия.
Минусы интеграционных тестов
- Все минусы unit-тестов
Приёмочные тесты – тесты, проверяющие работоспособность системы целиком. В реальном окружении, с реальными данными, на реальных сценариях.
Плюсы приёмочных тестов
- Находят баги, которые не могут быть обнаружены unit- и интеграционными тестами.
- Позволяют оценить работоспособность продукта целиком.
- На этом уровне с продуктом могут ознакомиться будущие пользователи.
Минусы приёмочных тестов
- Самые высокоуровневые – сложнее локализовывать проблему
- Занимают больше времени
- Обнаруживают проблемы с некоторой задержкой
Функциональное тестирование – проверка работы кода/продукта на соответствие требованиям. Проверка логики работы.
Конфигурационное тестирование на клиенте – проверка работоспособности на различных конфигурациях. Для веб-сайтов – в разных браузерах.
Конфигурационное тестирование сервер-сайда – проверка работоспособности в окружении, максимально идентичном продакшену (железка, OS, утилиты, библиотеки, конфиги, версии).
Нагрузочное тестирование – проверка работоспособности под нагрузкой (одновременная обработка большого потока запросов).
Тестирование производительности – проверка скорости работы системы.
Причём:
- Необходимо измерить длительность полного цикла «запрос-ответ». Оценить общее время, обратить внимание на отдельные этапы.
- То же самое – под нагрузкой
- В пользовательских условиях (сетевые условия).
Тестирование безопасности.
Тестирование юзабилити – тестирование удобства использования.
Тестирование стабильности – тестирование стабильности работы под нагрузкой, длительное время.
До кучи:
– Volume тестирование
– Stress/Recovery тестирование
– Spike тестирование
– Localization тестирование
– Compatibility тестирование
– и т. д. и т. п.
Способы тестирования
Ручное тестирование – выполнение тестов вручную или с помощью скриптов. Ручной анализ результатов.
Плюсы ручного подхода
- Более информативно – замечаются дефекты рядом
Минусы ручного подхода
- Долго
- Дорого
Автоматическое тестирование – выполнение с помощью скриптов или инструментов. Оценка результатов проводится автоматически.
Плюсы неручного подхода
- Удобно и легко
Минусы неручного подхода
- Тесты нужно писать и поддерживать
- Тесты выполняются «в лоб»
- Сами тесты/скрипты/инструменты могут содержать баги и порождать ложные результаты
Инструменты
Функциональное, приемочное тестирование:
- Selenium
- TestComplete
Функциональное, unit тестирование
- подбирается под используемый язык
Нагрузочное тестирование/тестирование производительности:
- Яндекс.Танк
- Jmeter:
Как сымитировать плохую сеть:
- Fiddler
- Charles
- Утилита tc: man tc
Плюсы unit-тестов
- Можно запустить сразу после внесения изменений в код – позволяют найти дефект сразу после его создания.
- Могут служить документацией к коду.
- Упрощают процесс рефакторинга.
Минусы unit-тестов
- Их надо писать.
- Их надо уметь писать.
- Их надо поддерживать.
Но даже если все компоненты по отдельности работают правильно, то это ещё ничего не значит.
Интеграционные тесты – тесты, проверяющие корректность взаимодействия отдельных модулей друг с другом.
Плюсы интеграционных тестов
- Находят баги, которые не могут быть обнаружены unit-тестами.
- Запускаются после сборки проекта и позволяют быстро обнаружить проблемы взаимодействия.
Минусы интеграционных тестов
- Все минусы unit-тестов
Приёмочные тесты – тесты, проверяющие работоспособность системы целиком. В реальном окружении, с реальными данными, на реальных сценариях.
Плюсы приёмочных тестов
- Находят баги, которые не могут быть обнаружены unit- и интеграционными тестами.
- Позволяют оценить работоспособность продукта целиком.
- На этом уровне с продуктом могут ознакомиться будущие пользователи.
Минусы приёмочных тестов
- Самые высокоуровневые – сложнее локализовывать проблему
- Занимают больше времени
- Обнаруживают проблемы с некоторой задержкой
Функциональное тестирование – проверка работы кода/продукта на соответствие требованиям. Проверка логики работы.
Конфигурационное тестирование на клиенте – проверка работоспособности на различных конфигурациях. Для веб-сайтов – в разных браузерах.
Конфигурационное тестирование сервер-сайда – проверка работоспособности в окружении, максимально идентичном продакшену (железка, OS, утилиты, библиотеки, конфиги, версии).
Нагрузочное тестирование – проверка работоспособности под нагрузкой (одновременная обработка большого потока запросов).
Тестирование производительности – проверка скорости работы системы.
Причём:
- Необходимо измерить длительность полного цикла «запрос-ответ». Оценить общее время, обратить внимание на отдельные этапы.
- То же самое – под нагрузкой
- В пользовательских условиях (сетевые условия).
Тестирование безопасности.
Тестирование юзабилити – тестирование удобства использования.
Тестирование стабильности – тестирование стабильности работы под нагрузкой, длительное время.
До кучи:
– Volume тестирование
– Stress/Recovery тестирование
– Spike тестирование
– Localization тестирование
– Compatibility тестирование
– и т. д. и т. п.
Способы тестирования
Ручное тестирование – выполнение тестов вручную или с помощью скриптов. Ручной анализ результатов.
Плюсы ручного подхода
- Более информативно – замечаются дефекты рядом
Минусы ручного подхода
- Долго
- Дорого
Автоматическое тестирование – выполнение с помощью скриптов или инструментов. Оценка результатов проводится автоматически.
Плюсы неручного подхода
- Удобно и легко
Минусы неручного подхода
- Тесты нужно писать и поддерживать
- Тесты выполняются «в лоб»
- Сами тесты/скрипты/инструменты могут содержать баги и порождать ложные результаты
Инструменты
Функциональное, приемочное тестирование:
- Selenium
- TestComplete
Функциональное, unit тестирование
- подбирается под используемый язык
Нагрузочное тестирование/тестирование производительности:
- Яндекс.Танк
- Jmeter:
Как сымитировать плохую сеть:
- Fiddler
- Charles
- Утилита tc: man tc
среда, 1 октября 2014 г.
Как остановить браузер перед переходом на другую страницу через JavaScript
Для того, чтобы Chrome или другой браузер не очищал Network debugger необходимо в консоли браузера выполнить следующий код:
window.addEventListener("beforeunload", function() { debugger; }, false);
Это код поставит Chrome на паузу перед загрузкой новой страницы и перенесет вас на точку остановки в debugger.
window.addEventListener("beforeunload", function() { debugger; }, false);
Это код поставит Chrome на паузу перед загрузкой новой страницы и перенесет вас на точку остановки в debugger.
Подписаться на:
Сообщения (Atom)