Обычно при кодировании прототипа вы можете быть немного менее осторожны со своими стандартами тестирования и кодирования. Цель состоит в том, чтобы быстро что-то сделать, чтобы доказать концепцию или начать обсуждение различных аспектов проекта. Если вы решите, что это невозможно, или решите пойти в другом направлении, вы приложите меньше усилий, чтобы получить решение. Опытные образцы имеют иной стандарт качества, чем готовый (или находящийся в стадии разработки) продукт.
Иногда вы берете прототип и просто переводите его в реальный продукт. Это действительно зависит от того, насколько тщательно структурирован прототип. Часто лучше всего использовать прототип в качестве концепции и начать все заново, создавая реальное приложение, используя ваши обычные процессы и стандарты. Таким образом, ваш продукт не «заражен» короткими путями, которые вы использовали для быстрого получения прототипа. Также сложнее быть уверенным в том, что вы адекватно протестировали при модернизации прототипа модульными тестами, потому что гораздо проще просто написать несколько «нормальных» тестов и не допустить этого, особенно если сложный для тестирования код тестировать сложно. , Написание тестов перед написанием кода и использование анализа покрытия помогает убедиться, что вы одновременно адекватно протестировали его и продумали проект с точки зрения тестируемости.