Коммиты против тестов
Я недавно разрабатывал новую функциональность и хочу рассказать, как это было. Задача довольно объёмная, но раскладывается в цепочку последовательных шагов. Основная часть работы заняла 2 дня, но перед этим я успел подумать, что и как делать. Я сам вносил изменения в 3 компонента, ещё с 3 компонентами нужно было взаимодействовать, один из них существенно менял мой коллега.
Так как я сам придумывал и сам программировал, то на письменной постановке задачи мы сэкономили. Если бы у нас было время и я мог бы сделать только постановку задачи, то у меня легко получилось бы 4 разных подзадачи, которые можно было бы теоретически отдать разным людям. К сожалению, 3 из них были бы достаточно маленькими, а 4-ая - весьма объёмная. Это из-за того, что в одном компоненте всё завязано на новую таблицу в базе данных. Если создание таблицы сделать отдельной задачей, то оставшиеся изменения разбились бы на 3 маленьких кусочках.
3 основных коммита я сделал в первый же день. Дальше по коммитам можно восстановить, какие баги пришлось поправить. Первый баг был тривиальный и давал о себе знать потоком ошибок в логах, исправил сразу в одну строчку.
Дальше обнаружилась проблема, которая потребовала передачи ещё одного параметра для компонента, разработкой которого занимался мой коллега. Первый коммит не помог, потому что надо было передавать в JSON только строки, а я засунул число. Исправил ещё одним коммитом и это уже был 2 день разработки. Надо признать, что это косяк в проектировании и не очень понятно, как его было избежать. Наверно, если бы я выделил день на то, чтобы подробно всё расписать, то у меня были бы шансы заметить проблему и принять меры, но без гарантий.
Дальше было 3 тривиальных проблемы (2 были связанны с SQL), которые я сразу исправил за 3 небольших коммита.
А вот дальше случилась проблема интеграционного характера, которая поставила меня в тупик, 4 коммита ушло только на то, чтобы улучшить логи в попытках разобраться. И после этого я внезапно заметил, что ищу файл без расширения, а он с расширением, тривиальный коммит сразу решил проблему. С большой вероятностью помогла бы хорошая спецификация.
Дальше последовательно открылись ещё 3 проблемы, которые я легко исправил 3 коммитами. В одном месте потребовалось понимание предметной области, но так как у меня уже скопился некоторый опыт, то я сразу разобрался. На этом закончилась основная разработка.
К сожалению, через неделю оказалось, что в предметной области я ещё плохо разбираюсь и потребовалось ещё 3 небольших коммита, чтобы это исправить. Самая большая боль, как это можно было предотвратить - непонятно, с нашей точки зрения эту беду нельзя увидеть.
Итого, очевидно, что разработчик должен самостоятельно проверять свой код. Если бы перед каждым моим коммитом тестировщик должен был бы завести тикет, мы бы не то что в 2 дня, мы бы в 2 недели не уложились. У нас по каждому коммиту происходит обновление в интеграционном контуре и это очень удобно. Разворачивание на локальной машине в нашем случае имеет существенные ограничения.
Если смотреть по количеству, то большинство ошибок можно было бы поймать юнит-тестами. Тут есть некоторое смещение терминологии, речь идёт о тестах одного компонента, но это компонент со своей базой и REST-интерфейсом. И если бы разработчиков было много, то такие тесты приносили бы пользу, Васе не нужно было бы ждать, чтобы Петя дёрнул его сервис, чтобы увидеть, что ничего не работает.
Однако, нужно заметить, что самые трудные для исправления ошибки носят интеграционный характер и поймать их простыми тестами нет шансов. Для их предотвращения лучше писать более ясные спецификации. Это не решит проблему полностью, но я не верю, что можно успешно работать программистом и не сталкиваться время от времени с необходимостью разобраться в чём-то нетривиальном.
Так как я сам придумывал и сам программировал, то на письменной постановке задачи мы сэкономили. Если бы у нас было время и я мог бы сделать только постановку задачи, то у меня легко получилось бы 4 разных подзадачи, которые можно было бы теоретически отдать разным людям. К сожалению, 3 из них были бы достаточно маленькими, а 4-ая - весьма объёмная. Это из-за того, что в одном компоненте всё завязано на новую таблицу в базе данных. Если создание таблицы сделать отдельной задачей, то оставшиеся изменения разбились бы на 3 маленьких кусочках.
3 основных коммита я сделал в первый же день. Дальше по коммитам можно восстановить, какие баги пришлось поправить. Первый баг был тривиальный и давал о себе знать потоком ошибок в логах, исправил сразу в одну строчку.
Дальше обнаружилась проблема, которая потребовала передачи ещё одного параметра для компонента, разработкой которого занимался мой коллега. Первый коммит не помог, потому что надо было передавать в JSON только строки, а я засунул число. Исправил ещё одним коммитом и это уже был 2 день разработки. Надо признать, что это косяк в проектировании и не очень понятно, как его было избежать. Наверно, если бы я выделил день на то, чтобы подробно всё расписать, то у меня были бы шансы заметить проблему и принять меры, но без гарантий.
Дальше было 3 тривиальных проблемы (2 были связанны с SQL), которые я сразу исправил за 3 небольших коммита.
А вот дальше случилась проблема интеграционного характера, которая поставила меня в тупик, 4 коммита ушло только на то, чтобы улучшить логи в попытках разобраться. И после этого я внезапно заметил, что ищу файл без расширения, а он с расширением, тривиальный коммит сразу решил проблему. С большой вероятностью помогла бы хорошая спецификация.
Дальше последовательно открылись ещё 3 проблемы, которые я легко исправил 3 коммитами. В одном месте потребовалось понимание предметной области, но так как у меня уже скопился некоторый опыт, то я сразу разобрался. На этом закончилась основная разработка.
К сожалению, через неделю оказалось, что в предметной области я ещё плохо разбираюсь и потребовалось ещё 3 небольших коммита, чтобы это исправить. Самая большая боль, как это можно было предотвратить - непонятно, с нашей точки зрения эту беду нельзя увидеть.
Итого, очевидно, что разработчик должен самостоятельно проверять свой код. Если бы перед каждым моим коммитом тестировщик должен был бы завести тикет, мы бы не то что в 2 дня, мы бы в 2 недели не уложились. У нас по каждому коммиту происходит обновление в интеграционном контуре и это очень удобно. Разворачивание на локальной машине в нашем случае имеет существенные ограничения.
Если смотреть по количеству, то большинство ошибок можно было бы поймать юнит-тестами. Тут есть некоторое смещение терминологии, речь идёт о тестах одного компонента, но это компонент со своей базой и REST-интерфейсом. И если бы разработчиков было много, то такие тесты приносили бы пользу, Васе не нужно было бы ждать, чтобы Петя дёрнул его сервис, чтобы увидеть, что ничего не работает.
Однако, нужно заметить, что самые трудные для исправления ошибки носят интеграционный характер и поймать их простыми тестами нет шансов. Для их предотвращения лучше писать более ясные спецификации. Это не решит проблему полностью, но я не верю, что можно успешно работать программистом и не сталкиваться время от времени с необходимостью разобраться в чём-то нетривиальном.