If the code is well architected, the contract between C and D should make it clear whether changes in D affect C or not. And if C is not affected, then B and A won't be either.

▲

throwaw12 an hour ago | parent [-]

> If the code is well architected

Big constraint. Code changes, initial architecture could have been amazing, but constantly changing business requirements make things messy.

Please don't use, "In ideal world" examples :) Because they are singular in vast space of non-ideal solutions

	▲	FartyMcFarter an hour ago \| parent [-]
		In that case your problem is bigger than just reviewing changes. You need to point the fingers at the bad code and bad architecture first. There's no way to make spaghetti code easy to review.