in reply to Re^4: Nobody Expects the Agile Imposition (Part VI): Architecture
in thread Nobody Expects the Agile Imposition (Part VI): Architecture
Actually, I think re-write in the Joel sense means even more than that.
It generally means starting from scratch to achieve the same overall functionality, and usually, the same external interfaces. But with the express intention of improving the internal structuring and architecture, with the laudable goals of improving readability/maintainability/extensibility. This is often approached top down.
Joel's point is that approaching these latter goals this way often goes ary, because in the process, many mistakes made and long since corrected in the original design and implementation, are made again.
The refactoring process tends to be a bottom up, more constrained process, that improves r/m/x-abilities of individual functions or classes by cleaning up their implementations whilst retaining the fixes and extensions previously applied that lead to the need to refactor in the first place.
Often, this type of refactoring needs to be applied as a multi-pass, step-wise refinement process to achieve best effect, but the advantage is that--done properly--you avoid large scale changes in any one step that are likely to cause extensive breakage.
The difference between the two approaches is--or at least, certainly should be--far more than politically expedient terminology.
|
|---|