如何向你的同事证明他们编写了蹩脚的代码？
我发现继续从事目前的工作有些困难。
代码库最近变得有点疯狂（但绝对不是我见过的最糟糕的），并且我很难处理代码的某些部分。 我可能很愚蠢，但很可能只是因为它让我失去了开始从事一些难以推理的事情的动力。
我的老板已经知道我的想法 - 我表达了这样工作的感受。 他要求我提供错误的例子。 当我指出两三个小问题时，他说“是的，好吧”，但是重构花费了他很多钱，而且我们必须把产品推出来（这不是我第一次听到这种说法）。
我不得不承认，这些例子并不是最引人注目的，但问题实际上很难解释。 它由整个代码库中许多微小的“错误决策”组成。 （我们也看到这个问题绝对是主观的）。 例如，错误的命名、处理空值、样板文件、不使代码可重用（或相反）等等。 重新思考别人的代码来证明我会以不同的方式做它可能会很累人。
您对如何处理这个问题有想法吗？ 我有点厌倦了每次都必须去修改一个又快又脏的代码库！
I am finding somewhat difficult to carry on working in my current job.
The codebase has become a bit wild lately (but definitely not the worse I've seen), and I'm having a hard time dealing with some parts of the code. I could be stupid, but most likely it's just that it demotivates me a lot to start working on something that is hard to reason about.
My boss is already aware of my thoughts - I expressed what it feels like to work like this. He asked me to provide examples of what was wrong. When I pointed out two or three small issues, he said "yeah, ok" but that refactoring costs him a lot of money, and that we have to get the product out (not the first time I hear this).
I have to admit that the examples were not the most compelling, but the problem is actually tough to explain. It's made up of a lot of tiny "bad decisions" throughout the codebase. (We also see this issue is absolutely subjective). For instance, bad naming, dealing with nulls, boilerplate, not making code reusable (or the opposite) and so on. It can be tiring to re-think someone else's code over again to justify I would have done it differently.
Do you have thoughts on how to deal with this?
I am a bit fed up of having to go hacking around a quick 'n dirty codebase every time!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（16）
有时，你的程序员同事做事的方式与你截然不同，你可能觉得错误的事情实际上可能有积极的一面。 我们都有自己的学校。 我想我遇到过的程序员抱怨我不理解的事情，就像我自己觉得有些事情需要抱怨一样。
确保您可以将您的抱怨推断为具体的缺点。 如果没有其他原因，这样您就可以激励中层管理人员做出改进。 难以推断为可测量事实的事物通常源于品味/风格的差异而不是质量（有一些关于这个主题的书籍可供阅读）。 smacl 发布的答案有很好且具体的建议！
如果你能把你的担忧推论成一种真正的劣势，那么当人们说一个人必须“接受”这样的情况时，我真的不同意。 我不止一次接触过这个问题，我告诉你，重构并不是解决问题的办法。 重构只能解决症状。
接受这样的情况就等于说“质量差的产品线和昂贵且令人沮丧的维护是我的公司可以忍受的”。 当然这种情况很少发生。 然而，管理层（即那些对项目优先顺序有决定权的人）通常在技术上不知道问题是什么，或者为什么开发成本昂贵。 他们不应该为了这个问题。
这就是为什么您需要一个拥有技术领导、首席架构师、良好的组织结构和分层模型等的开发组织。经验丰富的软件专业人员，他们知道如果您忽略开发的某些方面，就会通向何方。 这是关于改变团队的“文化”。
要么你坚持你的公司并尝试从根本上改变你做事的方式，要么你找到另一个工作地点并确保你在面试过程中了解他们在日常开发中的具体工作方式。
祝你好运
Sometimes your fellow programmers do things very differently than you, and things you might feel are way wrong might actually have positive aspects. We all have our schools we come from. I think I've come across programmers who complain about things I don't understand equally as often that I myself have felt something needs to be complained about.
Make sure you can deduce what you complain about into a concrete disadvantage. If for no other reason so that you can motivate middle management about improvements to make. Things that are hard to deduce into measurable facts usually originates from difference in taste/style rather than quality (there are boooks to read about this subject). The answer posted by smacl have good and concrete advice!
If you can deduce your concern into a real disadvantage, then I really do not agree when people say that one have to "accept" situations like this. I've been exposed to this problem more than once, and let me tell you, refactoring is not the solution to the problem. Refactoring only fixes the symptoms.
Accepting a situation like this is the same as saying "bad quality product lines and expensive and frustrating maintenance is something my company can live with". This is ofcourse seldomly the case. However management (i.e. those with the go/no-go on what projects to prioritize) are very often not technically aware of what the problems are, or why development is expensive. They shouldn't have to be for that matter.
That's why you need a development organization with technical leads, chief architects, a good organisational structure and tiered model etc. Experienced software professionals who have seen where the road leads to if you ignore certain aspects of development. It's about changing the "culture" of your team(s).
Either you stick with your company and try to change how you do things from the roots, or you find another place to work and make sure you find out during the interview exactly how they work in every-day development.
Good luck
我最近遇到了一个非常相似的问题，一位朋友给了我一些建议，对我很有帮助。 他说：“别插手。”
他的意思是，你必须沟通这些问题，因为它们是真实的、代价高昂的问题，会在时间和金钱方面产生后果。 但是，当您进行沟通时，仅谈论对组织的影响。不要提及对您的影响，因为那样听起来就像抱怨一样，会被忽略。
例如：
不要让自己置身事外：
“其他开发人员使用这些晦涩的、误导性的标识符，然后我必须花几个小时检查代码，试图发现他们的意图。这意味着它占用了我很多时间。”
让自己远离它：
“对类和变量名进行一些重构，并围绕标识符建立一些编码标准，这将非常有帮助且具有成本效益。直接的回报将是每个人都更容易理解的代码库，从而导致更高的生产力。长期的回报是，如果在发布之前发现关键错误，那么我们将能够更快地修改代码并修复问题，那么可理解的代码库将非常重要。”
我希望这有帮助。
I recently faced a very similar problem and a friend gave me some advice that helped a great deal. He said: "keep yourself out of it."
What he meant was, that you must communicate the problems because they are real, costly problems with consequences in terms of time and money. But when you do communicate, talk only about the consequences for the organization. Do not mention the consequences to you, because then it just sounds like whining and will be ignored.
For example:
Not keeping yourself out of it:
"The other developers use these obscure, misleading identifiers and then I have to spend hours going over the code trying to discover what they meant. It's taking up a lot of my time."
Keeping yourself out of it:
"It would be very helpful and cost effective to do some refactoring of class and variable names and also establish some coding standards around identifiers. The immediate payoff will be an easier-to-understand codebase for everyone, leading to better productivity. The longer-term payoff will be that later we'll be able to modify the code and fix things faster. If a critical bug is discovered right before a release, an understandable codebase will be really important."
I hope that helps.
1) 让问题更加明显并获得管理层的支持
详细记录大约一个月内各种编码任务所花费的时间。 月底给老板分析和总结内容，即浪费时间，从而浪费金钱，以说明某种形式的改变是必要的。
2) 考虑一种具有成本效益的前进方式
例如； 不要重构整个代码库，而是将接口与实现分开，并在接口层强制执行更严格的标准，包括单元测试、命名约定等。 因此，每个程序员都可以有信心使用他们没有编写过的代码。 虽然这在一定程度上扫除了地毯下的垃圾，但它是为更大规模的重构做准备的好方法。
从管理的角度来看，重要的是工作流程不被中断，并且积极的结果是可见的，因此要进行相应的计划。
3) 与同事就长期改进达成一致
坐下来与其他程序员就未来代码的合理编码标准达成一致。
1) Make the problem more visible and get management buy-in
Keep a very detailed diary of the time spent on various coding tasks over the period of about a month. At the end of the month analyse and summarise the contents for your boss, i.e. time wasted and hence money wasted, to illustrate that change of some form is necessary.
2) Think of a cost effective way of moving forward
For example; Rather than refactoring the entire code base, seperate interfaces from implementations, and enforce tighter standards, including unit tests, naming conventions, etc.. at an interface layer. Thus each programmer can have confidence in using code that they have not written. While this is sweeping the crap under the carpet to a certain extent, it is a good way of preparing for larger scale refactoring.
It is important from a management perspective that workflow is not interrupted, and positive results are visible, so plan accordingly.
3) Agree longer terms improvements with your co-workers
Sit down and agree reasonable coding standards for future code with the other programmers.
也许您可以安排每月一次的会议，在这些会议上您可以展示好的和坏的代码。 显然，您不想指责，因此您希望使用基于您在项目中看到的内容的通用代码示例。 通过这种方式，您可以建设性地获得与您风格相同的其他人的支持。 您可能希望在会议后整理这些内容，以便人们可以轻松参考。
我认为指出问题和抱怨确实很容易，但指导人们并帮助他们改变需要付出努力。 这不是一件容易的事，但如果你在工作中缺乏动力，也许这会给你带来一股很好的动力。 你可能会在很长一段时间内学到一些东西。
Perhaps you could setup monthly meetings and at those meetings you could demonstrate good and bad code. Obviously you don't want to point fingers so you'd want to use generic code examples that are based off of stuff you saw in your project. This way you can constructively gather support from others in your style. You might want to compile these after the meetings so people can easily reference them.
I think it is real easy to point out issues, and complain but to mentor people and help them change requires effort. It isn't an easy task but if you are having trouble being motivated with your job perhaps this would give you a nice burst of motivation. You might learn some things a long the way.
你会发现这是司空见惯的事。 你能做的就是接受不同的人做事的方式不同。 当您修复错误或添加功能时，您将获得一个简短的窗口，显示应用程序中可以改进的子部分。 当您处理代码时，您可以使其变得更好，并且他们不需要知道您正在零敲碎打地改进代码。
不过要非常小心。 有时，代码的编写方式看起来像是“被黑了”，但解决了一个不容易辨别的错误。 特别是如果它是已经过尝试和测试的旧代码。
另一方面，抱怨只会让你被视为爱抱怨的人。 考虑一下您想要什么结果，以及什么行动最有可能产生该结果。 当您问“我可以做 X 天的工作但完全没有明显效果吗？”时，您总会听到答案“不”。
You'll find that this is common-place. What you can do is accept that things are done differently by different people. As you fix bugs or add features, you'll get a brief window into a sub-section of the application that you can improve. When you work on the code, you can make it better, and they don't need to know that you're piecemeal improving the code.
Be very careful though. Sometimes code is written in a way that looks 'hacked', but solves a bug that is not easy to discern. Especially if it is older code which has been tried and tested.
On another note, complaining will only get you viewed as a complainer. Think about what outcome you want, and what actions will most likely produce that outcome. You will always hear the answer 'No' when you ask, 'Can I do X-days of work for absolutely no noticable result?'
你可以放弃并希望找到更好的东西。
或者，您可以坚持下去，并在您可以控制的情况下尝试改进您可以控制的代码。 无论开发人员的意图有多好，如果有多个开发人员，那么按照有能力的开发人员标准来看，代码库将是“丑陋的”。 与其他开发人员合作，提高他们的能力，并在进行增强时重构代码。
You could quit and hope to find something better.
Or, you could stick it out and try improve the code that you can control, when you can control it. No matter how well intentioned the developers are, if there is more than one developer the code base will be "ugly" by a competent developers standards. Work with the other developers to improve their abilities and refactor code as you make enhancements.
对于初学者：
强制使用静态代码分析工具。 每种语言都有一些众所周知的工具。
展示一些重构前后的代码示例，并解释为什么您认为它更好。 尽量不要让任何人陷入困境。
由经验丰富的开发人员进行代码审查。
请记住，无论您如何尝试，有些开发人员都无法得到帮助...
如果有人以礼貌和开放的态度批评您的代码，您可能会学到一些东西。
如果
环复杂度/变更集/错误数量。 复杂的代码更有可能被破坏，导致更多的错误，从而导致更多的更改，从而花费更多的钱！
For starters:
Enforce the use of static code analysis tools. Every language has a few well known tools.
Show some before and after refactored code examples, and explain why you think it's better. Try not to put any one person on the spot.
Code reviews by experienced developers.
keep in mind, some developers can't be helped no matter how much you try...
If someone critiques your code be polite and open minded, you might learn something.
Cyclomatic complexity / number of changesets/bugs. Complex code is more likely to break, cause more bugs which causes more changes, which cost more money!
99% 的时候你永远无法选择与你一起工作的人。 并不是所有的关系都能成功，无论是有效的还是其他的。
如果您的项目足够分散，以便每个开发人员都可以为其他开发人员的需求做出贡献，那么程序员就不会踩到彼此的脚趾，这是最好的。
让人们改变他们的编码风格是很困难的。 这需要一个致力于此类事情的铸铁技术领导，并且当您提出它时会有所帮助。 管理类型无法做到这一点，领导层需要提供技术细节。
99% of the time you never get to choose the people you work with. Not all relationships work out, be they work or otherwise.
It would be best if your project was broken up enough so that each developer can contribute to a spec of what the other needs, so programmers don't step on each other's toes.
Getting people to change their coding style is hard. It takes a cast iron technical lead committed to such things and will help when you bring it up. Management types can't do this, leadership needs to provide technical details.
在我看来，您的代码问题并不像您的同事那么严重。 对你来说，强制做出你想要看到的改变可能会非常困难。 您最好的选择可能是开始更新您的简历并留意其他机会
It sounds to me like you don't have a problem with the code so much as your coworkers. It will probably be very difficult for you to force the changes you want to see. Your best bet would probably be to start updating your resume and keep your eyes open for other opportunities
我认为，一旦你陷入困境，你就没有很好的机会把事情做好，你只需要完成它们。 我想说，大多数开发人员不喜欢救火，想要理想的代码库，但在我看来，这需要您花时间预先规划系统。
我建议尝试与您的经理合作，以确保您现在认为缺乏的领域在下一个项目中也不会缺乏。 也许它让你处于领先地位，与同行进行更多的代码审查，也许它是对整个团队的进一步培训。
不管怎样，我认为这是我们大多数人都会经历的事情。 我确实同意其他人的建议，对此要谨慎一些。 我知道我昨天写的代码当时看起来很棒，现在回头看，可能可以找到 10 种其他方法来实现它并使其看起来更干净。
I think that once you're in the middle of the weeds, you do not really have a good chance of getting things done right, you just have to get them done. I would say most developers do not like firefighting and want the ideal code base, but in my opinion this requires you to spend the time up front planning the system out.
I'd recommend trying to work with your manager to ensure that the areas you feel are lacking now are not lacking in the next project. Maybe its putting you on the lead, having more code reviews with peers, maybe it is further training for the entire team.
Either way, I think this is something that most of us go through. I do agree with the other person advising some caution on this. I know that code I wrote yesterday seemed great at the time and looking back on it, can probably find 10 other ways to do it and make it look cleaner.
您是否考虑过将 fxcop 添加到自动化构建中以强制编码风格？ 除此之外，您可以尝试建议 TDD，这将赋予编写测试的任何人以确保每个类的接口都以特定方式构建的权力。
从我的脑子里，这就是我能想到的。
Have you considered maybe adding fxcop to the automated builds to enforce coding style? Other than that, you could try suggesting TDD which would give the power to whomever writes the test to enfore that the interfaces for each class are structured in a particular way.
Off the top of my head, that's all that I can think of.
生活中的事情并不完美，如果你开始挑剔，羽毛就会被激怒，人际关系也会恶化。
最好的方法是仔细选择你的战斗。 如果某件事足够小，请忽略它并接受它。 如果它很大并且值得（即管理层看到支持你的投资回报率），那就去做吧。
这很适合你的情况……
上帝，请赐予我平静去接受我无法改变的事情，赐予我勇气去改变我可以改变的事情，并赐予我智慧来区分这两者。
Things in life are not perfect and if you start nitpicking, feathers will be ruffled and relationships soured.
The best method is to pick your battles carefully. If something is small enough ignore it and live with it. If it is big and worthwhile (i.e. the management sees ROI in backing you) go for it.
This is apt for your situation...
God, grant me the serenity to accept the things I cannot change courage to change the things I can and the wisdom to know the difference.
我尝试做的一件事可能会对你有所帮助。 如果代码的一部分很糟糕，并且您提出的修复它的想法被认为是最好的，但给出了“没有时间”的借口，那么您为什么不重写它呢？ 说你自己的时间？ 如果你决定在这份工作上坚持一段时间，这只会对你有帮助。 只有你才能学习并成为一名更好的程序员。
请注意，这是一个好主意，我什至会说这是必需的，在签入之前对该更改进行完整的代码审查，并且您应该尝试安排签入时间，以便在发布的完整回归测试周期之前进行。 这样你的重构就得到了彻底的测试。 经过 6 个月左右的时间，它将开始显示出有益的影响，然后您可以要求为此分配时间，并提供证据支持。
One thing I try to do and it may help you. If a part of code is bad, and the idea you propose to fix it is agreed as best but "no time" excuse is given, why dont you rewrite it? say on your own time? If you decide on sticking around at that job for a while it will only help you. And only you will learn and become a better programmer.
Note that it is a good idea and I would even say required, to do a complete code review of that change before check-in and you should try to time the check-in so that it is before a complete regresion test cycle for a release. That way your refactoring is completely tested out. Over a period of 6 months or so, it will start showing a beneficial impact and you can then ask for time allocation for this, with proof to back it up.
唯一有可能说服管理层的事情是证明您所引用的感知问题变成了实际问题。
为了利用这一点，尽量将“抱怨者”的语气降到最低，也就是说，关注这对利润的影响，而不是它给你带来的感受。 指出您所做出的错误决定可能产生的后果。 如果这些后果发生，并且它们的成本比预先修复的成本更高，请温和地提醒管理层，您预见到了困难，并提供有用的建议，说明如何通过一些预先的努力来避免未来类似的成本。
问题是，在许多组织中，这些问题永远不会引起管理层关心的足够问题，或者即使他们这样做了，他们也不会看到你对问题的看法与实际问题发生方式之间的联系。 在这些情况下，您最终会显得像一个不必要的挑剔的技术人员，这不是您想要拥有的声誉。
所以我的建议是，选择你的战斗。 如果其他人即将泄露一些非常令人震惊的事情，那么你可以说出来，也许稍后会得到平反。 对于那些让你烦恼的小细节，恐怕你除了忍受之外无能为力。
The only thing that has a chance of convincing management is demonstrating that the things you are citing as perceived problems become actual problems.
To try to take advantage of this, try to keep the "complainer" tone down to a minimum, that is, focus on how this affects the bottom line rather than how it makes you feel. Point out possible consequences of poor decisions that you see being made. If those consequences come to pass, and they cost more than an up-front fix would have, gently remind management that you foresaw the difficulty and provide a helpful suggestion as to how future similar costs can be avoided with a little up-front effort.
The problem is, in many organizations, the problems will never cause enough of a problem for management to care, or if they do, they won't see the connection between your perception of the problem and the actual problem the way it occurs. In these cases, you end up seemin like a needlessly persnickety technical person, which isn't a reputation you want to have.
So my advice is, pick your battles. If there is something very egregious that others are about to let slip, then you can speak up and perhaps be vindicated later. For the little details that just grind away at you, I'm afraid there's not much you can do but put up with it.
向他们展示他们自己忘记的代码，伪装成你的代码，以供批评。
如果他们记得他们写过它，他们可能会流行起来......
Show them their own forgotten code disguised as yours for critique.
If they recall that they wrote it, they might catch on..
如果您与经理关系良好，您也许可以利用这一点让自己担任“高级”或“首席”开发人员角色。 您可以建议团队中的一个人负责代码库的技术领导，这将是最好的。 您的工作是审查其他人的代码，并在您认为有必要时要求他们进行改进。 如果你走这条路，一定要慢慢走。 如果你很快就提出很多要求，那么你最终可能会惹恼所有其他开发人员。
If you have a good relationship with your manager, you might be able to use this to work yourself into a "Senior" or "Lead" Developer role. You could propose that it would be best if one person on the team takes technical leadership of the code base. It would be your job to review the code of others and ask them to make improvements when you feel it is necessary. If you go this route, just make sure to take it slowly. If you ask for a lot very quickly, then you could end up pissing off all the other developers.