История изменений
Исправление Manhunt, (текущая версия) :
В адекватной разработке когда соблюдается SRP и другие хорошие методологии, и есть хотя бы минимальный план развития продукта код как правило пишется один раз, покрывается тестами и нужды менять в нём API больше не возникает.
Это все красиво звучит на словах, либо можно найти в редких отдельно взятых компаниях. В основной массе сегодня «ажайл» и постоянное изменение бизнес-требований на всех этапах разработки.
Если код спроектирован грамотно, постоянное непредсказуемое изменение бизнес-требований не приводит к необходимости постоянно весь код переписывать. В условиях аджайла, это одно из главных требований к архитектуре. Достигается это, как писали выше, в частности благодаря SRP (хоть как по мне, остальные принципы SOLID не менее важны).
Что касается юнит-тестов, то они фиксируют контракт методов/классов. Это очень важно при рефакторинге: благодаря юнит-тестам удается заранее выявить нежелательные изменения в контракте.
Написание юнит-тестов одновременно с кодом облегчает первоначальную отладку нового кода: баги легче и быстрее повыловить в отдельно взятом юните, чем на задеплоенной огроменной системе интеграционным тестом.
Написание юнит-тестов одновременно с кодом повышает качество кода: сильносвязную лапшу тестировать неудобно, и появляется стимул её структурировать.
Исходная версия Manhunt, :
В адекватной разработке когда соблюдается SRP и другие хорошие методологии, и есть хотя бы минимальный план развития продукта код как правило пишется один раз, покрывается тестами и нужды менять в нём API больше не возникает.
Это все красиво звучит на словах, либо можно найти в редких отдельно взятых компаниях. В основной массе сегодня «ажайл» и постоянное изменение бизнес-требований на всех этапах разработки.
Если код спроектирован грамотно, постоянное непредсказуемое изменение бизнес-требований не приводит к необходимости постоянно весь код переписывать. В условиях аджайла, это одно из главных требований к архитектуре. Достигается это, как писали выше, в частности благодаря SRP (хоть как по мне, остальные принципы SOLID не менее важны).
Что касается юнит-тестов, то они фиксируют контракт методов/классов. Это очень важно при рефакторинге: благодаря юнит-тестам удается заранее выявить нежелательные изменения в контракте.
Написание юнит-тестов одновременно с кодом облегчает первоначальную отладку нового кода: баги легче и быстрее повыловить в отдельно взятом юните, чем на задеплоенной огроменной системе интеграционным тестом.
Написание юнит-тестов одновременно с кодом повышает качество кода: сильносвязную лапшу тестировать неудобно, и появляется стимул ее структурировать.