LINUX.ORG.RU

История изменений

Исправление Manhunt, (текущая версия) :

В адекватной разработке когда соблюдается SRP и другие хорошие методологии, и есть хотя бы минимальный план развития продукта код как правило пишется один раз, покрывается тестами и нужды менять в нём API больше не возникает.

Это все красиво звучит на словах, либо можно найти в редких отдельно взятых компаниях. В основной массе сегодня «ажайл» и постоянное изменение бизнес-требований на всех этапах разработки.

Если код спроектирован грамотно, постоянное непредсказуемое изменение бизнес-требований не приводит к необходимости постоянно весь код переписывать. В условиях аджайла, это одно из главных требований к архитектуре. Достигается это, как писали выше, в частности благодаря SRP (хоть как по мне, остальные принципы SOLID не менее важны).

Что касается юнит-тестов, то они фиксируют контракт методов/классов. Это очень важно при рефакторинге: благодаря юнит-тестам удается заранее выявить нежелательные изменения в контракте.

Написание юнит-тестов одновременно с кодом облегчает первоначальную отладку нового кода: баги легче и быстрее повыловить в отдельно взятом юните, чем на задеплоенной огроменной системе интеграционным тестом.

Написание юнит-тестов одновременно с кодом повышает качество кода: сильносвязную лапшу тестировать неудобно, и появляется стимул её структурировать.

Исходная версия Manhunt, :

В адекватной разработке когда соблюдается SRP и другие хорошие методологии, и есть хотя бы минимальный план развития продукта код как правило пишется один раз, покрывается тестами и нужды менять в нём API больше не возникает.

Это все красиво звучит на словах, либо можно найти в редких отдельно взятых компаниях. В основной массе сегодня «ажайл» и постоянное изменение бизнес-требований на всех этапах разработки.

Если код спроектирован грамотно, постоянное непредсказуемое изменение бизнес-требований не приводит к необходимости постоянно весь код переписывать. В условиях аджайла, это одно из главных требований к архитектуре. Достигается это, как писали выше, в частности благодаря SRP (хоть как по мне, остальные принципы SOLID не менее важны).

Что касается юнит-тестов, то они фиксируют контракт методов/классов. Это очень важно при рефакторинге: благодаря юнит-тестам удается заранее выявить нежелательные изменения в контракте.

Написание юнит-тестов одновременно с кодом облегчает первоначальную отладку нового кода: баги легче и быстрее повыловить в отдельно взятом юните, чем на задеплоенной огроменной системе интеграционным тестом.

Написание юнит-тестов одновременно с кодом повышает качество кода: сильносвязную лапшу тестировать неудобно, и появляется стимул ее структурировать.