Как происходит разработка веб приложений у профи?

Question

[Alex_Master]

Часто сталкиваюсь с проблемой багов, девелоперы не всегда их сами находят. Даже после прохождения тестировщиками кейсов все равно всплывают какие-то баги, которые никто не заметил.

У меня сейчас следующая схема разработки:
Dev на отдельном сервер ведется разработка и проводятся основные тесты девелоперами.
Pre это версия продукта на боевых серверах и с боевым окружением, но с копией реальной базы данных. На ней проводятся пред-релизные тесты продукта тестировщиками.
Prod - продакшен.

Деплой/миграции базы/версионность - все настроено автоматически. Руками не делаем.

Один коллега посоветовал мне сначала писать тесты, а потом уже под них писать код. Мы так еще не делали, хотим внедрить. Действительно ли это эффективно?

Подскажите как происходит веб разработка у настоящих профессионалов? Где можно почитать на эту тему?
Хотелось бы делать все по фен-шую, видеть меньше багов, быстрее и эффективнее работать :)

Буду рад помощи. Спасибо.

P.S. Так-же интересно ваше мнение о софте для контроля версий, разработки, миграции, тестирования и пр. Какой стек лучше всего :)

Comments

[Dimonchik]

"ни разу не ловил рыбу с профессионалами"

Answer 1

[sim3x]

Один коллега посоветовал мне сначала писать тесты, а потом уже под них писать код. Мы так еще не делали, хотим внедрить. Действительно ли это эффективно?

Да, так пишется меньше кода :)

Только в последовательность выглядит так
0. Пишем тест под новый функционал
1. Стартуем тесты = прогон тестов должен занимать до 2 сек
2. Видим новый проваленный тест
3. Фиксим его

Но в любом случае, сначала заводится тикет в багтрекере, потом вешается на себя, потом делается "гит пулл", а уже после того добавляется код

Различные среды дев/прод/тест должны готовится автоматом + должны быть в виде готовых образов для виртуалок или для докера.
Последовательность: пишется скрипт для сборки образа, отправляется в репозиторий, ночью или моментально машина, ответственная за образы, собирает его и разраб может ею пользоваться.
ИМО дев/прод/тест не должны различаться на данном етапе - все модификации окружения должен проводить софт, который ассоциирован с ЯП/средой, в которой ты занимаешься разработкой. Допустим ты работаеш с нодой и тебе нужны пакеты для оптимизации цсс - npm install а на продакшене такое не нужно и ты делаешь npm install --production

Но все ети заморочки не добавляют скорости разработки - они не дают разводить на проекте бардак и, теоретически, повышают качество кода

Answer 2

[Марк]

TDD на практике встречается довольно редко, чаще код пишут сорт оф одновременно с тестами.

С багами мы боремся сейчас так:

* «первая линия» – юнит-тесты
* автоматические интеграционные тесты: эмулируют пользователя, елозят мышкой, жмут кнопки. Проверяют несколько сотен наиболее востребованных сценариев.

Это всё происходит в CI каждый коммит. Дерево всегда должно быть «зелёным»: если тесты не проходят, задачей с самым высоким приоритетом становится починка.

Затем (перед релизом) наступает:

* мануальный QA
* догфидинг: компания всё время использует собственный продукт. Таким образом, ручным тестированием занимаются вообще все, в той или иной степени.

Comments

[Артур Нуруллин]

Первая линия - "юнит тесты", по нужде, идут моки вместо реальных данных.
Вторая линия - "интеграционные тесты", это не то что кликаеться, елозиться, тут идет проверка с базой данных.
Третья линия - "функциональные тесты", это тесты, где елозится мышка, проверяеться конкретный функционал приложения/бэекенда в браузере(привет Selenium).
Четвертая линия - "перформанс тесты", по надобности, если должно быть все быстро.

В таких вещах как фреймворки есть только "юнит" и "функциональные" тесты.

Answer 3

[Sergey]

Подход "Разработка через тестирование" действительно помогает сосредоточиться на выполнении конкретной задачи. Из плюсов:
- разработчик знает конкретные критерии "приемки" задачи
- выстраивается хорошая практика покрытия тестами

более подробно о подходе можно посмотреть в вики

Answer 4

[Сергей Рогожкин]

Нет никаких сферических "профи" и "не профи". Каждый разработчик пытается выявить и решить противоречия, пробует разные техники. С тестами (даже написанными через 2 недели после) вы будете чувствовать себя гораздо комфортнее психологически. Просто пишите тесты хоть тушкой, хоть чучелом. Но это тактический прием.

Более важно, полагаю, предусмотреть и поддержать максимальное количество сценариев(юзкейсов) использования продукта, причем наиболее простыми средствами. Главный показатель качества: попали в паттерн привычного поведения пользователя и сделали ему лучше. Количество багов нельзя рассматривать в отрыве от сути продукта.

Убрать редкие и сложные фичи, которые нужны 10% пользователей может дать для качества больше, чем все тесты.