MVP и юнит-тесты
В руководствах для стартаперов часто пишут — забейте на идеальный код, не пишите юнит-тестов во время разработки MVP.
По-моему, не писать тесты — это то же самое, что отказаться от фигурной скобки или от отступов в коде. Конечно идеальный код писать действительно глупо — кому он нужен, если проект не запустился?. Но вот тесты — важная вещь даже для founders code.
Дело в том, что на этапе MVP критично важна скорость изменений — вы должны очень быстро выкатывать кучу сырых фич. А выкаченная фича — это когда код написан, выложен на прод и выполняет свою работу.
И если первые два пункта без тестов получаются немного быстрее (в первую неделю), то последний начинает тянуть вас вниз: программист без внешней помощи не может уследить за работоспособностью созданной им системы. И закрытые задачи начинают открываться обратно.
В компании из трех человек начинаются избыточные процессы вроде «приемки задачи», когда CEO будущего единорога садится и проверяет код за программистов. Ну а что, не станете же вы нанимать QA, чтобы тестировать MVP?
Самый хороший вариант — вообще не писать сложного кода на начальных этапах. Разместите свою бизнес-логику на каких-нибудь готовых движках, на худой конец напишите serverless. А если уж взялись пилить функциональность — покройте тестами хотя бы API. И пишите тесты не когда-нибудь потом, а до первой строчки кода.
В руководствах для стартаперов часто пишут — забейте на идеальный код, не пишите юнит-тестов во время разработки MVP.
По-моему, не писать тесты — это то же самое, что отказаться от фигурной скобки или от отступов в коде. Конечно идеальный код писать действительно глупо — кому он нужен, если проект не запустился?. Но вот тесты — важная вещь даже для founders code.
Дело в том, что на этапе MVP критично важна скорость изменений — вы должны очень быстро выкатывать кучу сырых фич. А выкаченная фича — это когда код написан, выложен на прод и выполняет свою работу.
И если первые два пункта без тестов получаются немного быстрее (в первую неделю), то последний начинает тянуть вас вниз: программист без внешней помощи не может уследить за работоспособностью созданной им системы. И закрытые задачи начинают открываться обратно.
В компании из трех человек начинаются избыточные процессы вроде «приемки задачи», когда CEO будущего единорога садится и проверяет код за программистов. Ну а что, не станете же вы нанимать QA, чтобы тестировать MVP?
Самый хороший вариант — вообще не писать сложного кода на начальных этапах. Разместите свою бизнес-логику на каких-нибудь готовых движках, на худой конец напишите serverless. А если уж взялись пилить функциональность — покройте тестами хотя бы API. И пишите тесты не когда-нибудь потом, а до первой строчки кода.