Please log in to watch this conference skillscast.
Even in an agile world, specifications often go too far and describe solutions with too many details; all these premature decisions constraint the implementation and remove opportunities. There is a remedy: refactoring the specs, even before refactoring the code.
In the TDD cycle, refactoring is the art of restructuring the code to make it simpler, without changing its behavior at runtime. A key part of refactoring is to recognize and extract duplications.
Refactoring is very useful at the code level, and it is even more powerful when applied during business analysis or functional architecture. Cyrille will show you how the practice of refactoring directly "at the business domain level" can simplify the problem, and therefore the resulting implementation code, by orders of magnitude. This means much less code to write, to test and to maintain, and much fewer defects as a result.
Join Cyrille as he shares 5 patterns on how to refactor at the business-domain level, such as "Make It Systematic" and "Degenerate Case." He will also explore some limits and the required mindset.
This approach of refactoring has been used on several real-world projects and is derived in particular from DDD and Specification by Example.
YOU MAY ALSO LIKE: