Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Chesterton’s fence is the axiom for understanding the why of the system before refactoring.


The flip side of that is that refactoring can be a surprisingly effective tool for understanding.


Sometimes by breaking prod. You learn what you didn't understand very quickly then.


A non prod breaking scenario I have seen - only towards the end of a fairly long refactoring exercise, when tests for certain edge cases start failing, you finally understand the full purpose of the code you are refactoring.


Not to fall into the obvious trope too much, but: Your legacy code has tests for edge cases? I'm happy when it has any tests. More often, it's untested and I write the tests myself before refactoring the implementation.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: