What to do when Your Colleague Creates Spaghetti Code
https://blog.ndepend.com/colleague-creates-spaghetti-code/
同事写了难以维护的代码该怎么办？是否马上冲上去和他争辩？还是默默地忍受？又或者是私下地重构他的代码？
But your organization might also throw “Angry Bill, the unit test hater” at you and tell you that he’s the senior developer, like it or not. Suddenly, dying on the “clean code” hill becomes a less clearcut choice. （假设组织里面有这么一个人，Bill, 特别讨厌单元测试，而且他还是一个资深开发人员。这样看上去做clean code似乎就不太容易）
Make a Data-Based Case 尽可能地多做研究，用数据支持自己的论点，否则自己看上去是带有偏见的。
Having read my disclaimer, there you sit, convinced that Bill is slowly poisoning each codebase that he touches. His vertical and horizontal spacing infuriates you, his public method semantics offend your sensibilities. His code is just… ugly… to the point that you nearly detect a physical odor from it. You might even think he’s doing it to spite you.
As much as you hate it, are you sure it’s bad? Are you editorializing at all when you describe it as spaghetti? I mean, how do you know? Have you charted the entry and exit points and graphed out the dependencies? Or do you just not like it because he does things much differently than you?
It’s not that I doubt you. It’s that you can bet most people you make your case to will doubt you, especially Bill. If you don’t arm yourself with some data about the code, you’ll look spiteful when you state your case. And if you don’t back the data with supporting references that aid your case in declaring it a problem, you’ll do little better.
Do some research before going any further and make sure you can justify your accusations.
Ask Yourself, “Just Who Do I Think I Am?” 如果自己在公司中的位置并不是那么重要的话，那么最好还是闭嘴，否则即便是胜利了也只是pyrrhic victory, 自己损失会很严重。
Ask this question because you can be sure someone else will. Sure, you’ve built a bulletproof case, leveraging static analysis, expert opinions, and industry trends. That’s all fine and good.
But you’re about to accuse Bill — Bill! — of writing spaghetti code. Bill, who started with your company when they had carrier pigeons instead of emails, and who singlehandedly built the original version of the software with nothing more than COBOL, baling wire and duct tape. Just who do you think you are, anyway?
Seriously, this matters. You need to consider your role. If your team looks to you as technical leadership and a mentor, then going to a new team member and saying, “your methods are pretty complex — try to keep this thing called cyclomatic complexity under 3” presents no problem. Everyone, newbie included, expects you to do this in your role. But if you’re the newbie and the junior developer saying the same thing to the mentor, it’s going to get ugly.
I can hear your indignant protest that “roles shouldn’t matter when there’s an empirical demonstration of rightness!” Honestly, I agree with you. And I imagine HR will want to hear all about it at your exit interview.
Arguing from a position of relative inexperience exacts a political toll from you — even when you’re right. Have these battles at your own peril, and check out the term pyrrhic victory to understand what happens even when you win one.
Offer Alternatives and Outcomes 自己要提出问题的解决办法，否则只是无意义的抱怨
Let’s assume that you’ve built a decent factual case and accurately sized up the organizational capital at your disposal. You have enough of a case to proceed and enough credibility that people will listen to your case.
Don’t actually proceed until you can offer some kind of solution. Simply walking over to Bill and saying, “I’ve been doing a lot of research and here’s a lengthy treatise on why your code is terrible,” will only demoralize him. Instead, you need to prepare by having alternatives ready to offer. “You have a tendency to write enormous methods, but you can actually take a lot of those local variables and extract classes with them as fields.” Now, you’re offering a plan of action.
But go beyond that as well, and complete your case. Once you’ve shown Bill the better way, make sure you can then prove (or something close) better results will follow. Get creative. Maybe pull someone over and ask them how long it takes them to understand the old method and the new, broken-up classes. Whatever you have to do, help the “aha” moment along by offering benefit.
Humility, Diplomacy, and Leading By Example 不要让自己的想法禁锢自己，理性地看待自己所持的观点。
You’ve built a case, stated it, and demonstrated it alongside value offered. Don’t let that go to your head.
You don’t want to take the attitude that “my way is right and yours is wrong.” Rather, you want to let the data do the talking and decouple you and Bill, as humans, from the code that you have written. You’ve read a lot and learned from smart folks that better outcomes occur this way. You’re not an expert, but you’ve had good results yourself if he wants to take a look. Here, look, you’ll show him if he’s interested.
Do your best to adopt something of a patient mentor stance, but without implying that one of you is better or more experienced… even if you clearly are better and more experienced. The subject shouldn’t be you and Bill, but the relative merits of various techniques. You’re just a couple of peers discussing them.
A Closing Philosophical Note on Spaghetti Code Clean Code并非技术正确与否的客观问题，更像是能提高软件开发效率多少这种主观问题。有时候你需要take big picture来看待这个问题。
I touched on this in the beginning of the post, but I’d like to restate it here. “How can I get Bill to stop writing spaghetti code” is only superficially a technical problem. In reality, it presents a human problem.
You can have the right of it without making any difference. Or, you can browbeat Bill and entrench him further. You can send him angry emails, undo his commits, “reject” his stuff at code review, and work against him. That will demoralize him and torpedo everyone’s progress.
Simply put, you can’t alter Bill’s behavior without a whole lot of dealing with Bill. So, whatever route you take, understand that your question is one of persuasion and not technical correctness.