|
|
|
|
|
by logicalmonster
1189 days ago
|
|
To me, it depends on the refactoring involved. If your coworker is refactoring code and making it buggy and also making it harder for the rest of the team to understand, that might be a bit of a problem. When working in a team, you follow common conventions you agree on for a reason. Rebuilding something for the sake of making it say 5% cleaner is often a bad business decision. No matter how well you think you're testing something, any non-trivial system is going to have some edge cases and crazy things that messing around with is going to cause you headaches. But if a system is a complete fustercluck and long-term progress is harmed with how convoluted it is, then spending a lot of time refactoring it seems wise. A good engineer has the judgement to know when tinkering with existing code is the smart thing to do. |
|