5 ms·
I understood it differently. As in: there is always a reason for the fence but you never know whether it is justified or not without understanding it. Don’t tea
by Joeri 8y ago
I understood it differently. As in: there is always a reason for the fence but you never know whether it is justified or not without understanding it. Don’t tear down the fence until you understand why it was put there for the wrong reasons.
- carlmr 8y agoTrue, but what I think s_kilk was getting at is that sometimes (especially in software) a bad developer will put a "fence" somewhere without a reason. And if that person already left the company, maybe you can never find out why. That's why it's important to start with some testcases of required behavior, and then refactor only code that is supported by tests. Because sometimes the fence is there for a reason, but often it's not.
- dasil003 8y agoEven bad developers have reasons, you may not be able to divine those reasons but they may be legitimate. The would-be refactorer would do well to consider carefully what the reason might have been, even if a git-blame reveals a less-than-excellent contributor. As an programmer I always try to capture these reasons in my commit messages, after a decade of doing this I’ve gotten a lot of thank you notes years after leaving a project, and I’ve even reminded myself details about my own thought process that I had otherwise would have long forgotten. One thing I’ve learned by having long tenures is that context change over years is much more likely the reason for nonsensical code than developer stupidity.
- SketchySeaBeast 8y ago> some testcases of required behavior, and then refactor only code that is supported by tests The difficulty is making sure that you have all the requirements and aren't missing any, and once a system gets big enough, that gets really difficult.