1. Team vote on this weeks refactoring candidate |
Simple yet effective, team members will "know" which areas that are troublesome and use the last developed stories as judgment of "pains".
2. Refactor where changes are frequent
When encountering bad code, write a simple comment:
//Refactor me pleeaase
private String generateXml(Session session, int depth, string prefix)
Second time a developer in the team encounters this code, he needs to refactor it..
What? No! Gaaaah...
This approach will keep code frequently changed clean, but with a heavier start up cost 🙂