Как мы улучшаем жизнь нашим Бэкендерам
В первой из серии статей поделюсь планами по улучшению процессов разработки бэкенда. Рассказываю о том, что планируем автоматизировать, описать и улучшить.
В первой из серии статей поделюсь планами по улучшению процессов разработки бэкенда. Рассказываю о том, что планируем автоматизировать, описать и улучшить.
Не заметил у вас пункта о требованиях:
Что я считаю очень важным документировать для заказной разработки - это окончательные, детальные требования к приложению, то есть, как же в итоге должно быть. Если это не документировать, то очень сложно потом бывает что-то починить или не сломать при развитии, потому что знания об итоговых требованиях как назло оказываются в голове человека, которого с нами сейчас нет. Приходится читать код, изучать данные в базе и логах, что затратно и всё равно не гарантирует полного понимания всех требуемых вариантов использования.
По теории, это знание раскрывается тестами, но практика показывает, что всё тестами не покроешь по причине их затратности. Описать же 100% требований текстом вполне посильно, а при наличии шаблона и навыков - и недолго.
Да, вы правы - покрывать все тестами в наших планах нет, потому что они слишком затратны для большинства клиентов. Документация по логике у нас идет вместе с документацией запросов API. В них объясняются требования, которые ожидает бэкенд и его ожидаемое поведение. Для этой документации мы как раз-таки будем составлять шаблоны и регламенты по написанию. Вы еще подразумеваете, что бэкендер должен по шаблону в документе с ТЗ описывать свою работу?