我如何（机智地）告诉我的项目经理或首席开发人员该项目的代码库需要认真的工作？

我刚刚加入了一个（相对）小的开发团队，该团队已经在一个项目上工作了几个月（甚至不到一年）。与大多数开发人员加入项目一样，我花了头几天来回顾项目的代码库。

由于缺乏一个更具描述性的术语，该项目（中型到大型ASP.NET WebForms内部业务线）是一场灾难。编码标准存在三个立即值得注意的问题：

1. 该标准非常宽松。它描述了更多的什么不该做（不要使用匈牙利表示法，等..）比来办。
2. 并非总是遵循该标准。到处都有与代码格式不一致的地方。
3. 该标准不符合Microsoft的样式准则。我认为，偏离框架开发人员和语言规范最大贡献者所制定的准则没有任何价值。

关于第3点，也许这让我感到更加困扰，因为我花了一些时间来获取MCPD，重点是Web应用程序（特别是ASP.NET）。我也是团队中唯一的Microsoft认证专家。由于我在所有的学习，自学和在职学习（包括为认证考试做准备）中所学到的东西，因此我还发现了项目代码中的一些实例，这些实例根本无法完成。最好的办法。

我只在这个团队工作了一个星期，但是我发现他们的代码库有很多问题，我想我会花更多的时间在以“他们的方式”来做事上，而不是在那时例如，从事一个遵循更广泛接受的编码标准，体系结构模式和最佳实践的项目。这使我想到了一个问题：

我是否应该（如果是，我应该如何）向我的项目经理和团队负责人建议该项目需要进行重大翻新？

我不想走进他们的办公室，挥舞着我的MCTS和MCPD证书，说他们的项目的代码库很烂。但是我也不想保持沉默，而不必在他们的垃圾代码之上编写垃圾代码，因为我实际上是想编写高质量的软件，并且我希望最终产品稳定且易于维护。

您可以花时间争论您的案件；或者您可以花时间清理。

选择干净的代码和敏捷软件开发原则，模式和实践，并在系统上工作时将所学知识应用到其中。最终，人们会注意到（好还是坏）。

编辑 还签出有效处理旧版代码

根据您的描述，似乎问题主要出在不遵循编码标准和命名问题上。到目前为止，这不是一场灾难。相比之下，这确实是一场灾难。

也许您已经习惯并要求高标准？在那种情况下，任何与完美的背离都可以视为失败。这是一个陷阱，当您的需求很高时很容易陷入陷阱，但是保持对事物的看法很重要。

我建议您将其描述为一种改进，并帮助团队更新其准则并指导他们开始将其用于实际。我真的很喜欢使用“完成的定义”作为质量基准，而创建一个本身就是一支伟大的团队。但是我认为您不应为此付出更多，至少不应该作为新的团队成员。

绝对不要挥舞您的MCSD，人们只会坦率地嘲笑您，MS证书很不错，但绝不是专业资格！

轻轻松松加入新团队，寻找机会，随时随地提出建议。

等到获得土地后，再排成一队。

您可能会认为问题出在您身上。您提到的三件事中没有一个值得对应用程序进行彻底的修改。它们只是挑剔的细节。

请记住，应用程序的目标不是拥有漂亮的代码，而是解决业务问题。当然，拥有一致且遵循良好标准的代码固然很好，但缺少代码并不是浪费整个代码库的理由。仅仅因为发动机油腻，并不意味着需要对其进行改造。

看，每个人都讨厌他们没有编写的每个代码库。实际上，如果您等待三年并查看自己的代码，您也会讨厌它，并认为它需要完全重写。事实是，事实并非如此。除非您能证明花费数月的时间使代码在美学上令人愉悦，而不是构建功能来增加业务价值，否则您可能会误入歧途。

没有什么说您只需要编写代码就行了，因为代码库中可能有一些代码。而且，没有什么能说代码很烂，因为它不符合您的宠物风格。只是在处理工作部分时进行重构，并在处理新内容时编写好的代码。

这些事情可以担心，但是如果您是团队中的新手，请不要动摇，直到您建立起对它们的信任为止。

看来您已经挑选了三件事（相对）来烦恼。我还有其他事情要担心：

• 该代码是否有据可查？
• 该代码是否符合规格/设计文档？
• 该代码有效吗？
• 易于理解代码的作用吗？
• 您是否正在考虑将该代码库的大部分提交给TheDailyWTF？

你去那里已经一个星期了？我不确定您是否知道足够向项目经理提出任何建议。即使您怀疑该团队的代码和实践是“不好的”，随着时间的流逝影响这些事情的最好方法是逐渐获得他们的信任和尊重。进入一个项目，并在一周后告诉团队需要重写其代码，这不是获得信任和尊重的好方法。

在最初的几个月中，请专注于树立更好的榜样，并询问有关他们为何以某些方式做事的问题。当您问这些问题时，请注意您的语气。如果您是“万事通”的新人，那么当您真正有能力影响事情的完成方式时，没有人会在以后听到您的意见。

随着时间的流逝，如果您的代码确实“更好”，其他开发人员将会看到。他们将开始向您提供资源，帮助他们修复问题，然后向您征求有关他们应该如何做事的建议。届时，您将可以很好地告诉团队（和管理层）您对编码标准等的看法。此过程需要多长时间会因组织而异。在一个非常适应的环境中，可能只有几周，而在更加坚决的文化中，可能要花费数月甚至数年。一次建立一个人的影响力。

您永远不会从事新工作，因为您会认为代码库是完美的，并且一切都以“正确”的方式完成。学习接受这一点。您对遗留代码所做的一切就是重构并一点一点地前进。在您不了解他们为什么做他们所做的事情之前，您不希望重构某些事情。同样，没有人会向您支付固定工作代码的费用，因此您必须为增加成本和花费时间之前为什么需要工作提出一个业务案例。无论如何，当您需要对代码进行更改时，最好等待重构代码。您可能没有选择他们在某些事情上使用的方法，但是如果可行，请在更改它和引入新的错误时非常小心。特别是当您没有被要求更改它时。

一个星期后，您就无法对他们的经营方式提出重大建议。如果您现在提起事情，人们会嘲笑您，永远不会认真对待您。首先用一些好的代码证明自己，然后人们会更倾向于倾听。

坦率地说，没有人关心您是Microsoft认证专家。任何有丰富经验的人都将获得该认证的不良程序员视为好人。我并不是说要获得认证会让您看起来很糟糕，我是说我们对他们没有太多的信任，因为我们没有看到他们有效的地方在向我们展示谁是优秀的程序员。

我可能会走上试图弄清楚如何提出建议的意图，以至于您可能最终无法充分证明自己的立场。在创建该提案时需要考虑以下几个问题：

• 进行您在此描述的各种更改可获得多少业务价值？
• 您是否考虑过一些选项，例如从头开始重新编写应用程序，修改现有代码以使其精简，或者随时间推移进行少量更改？
• 您知道现在需要什么功能和错误，这些功能和错误会阻止您进行所需的更改吗？

虽然我很高兴想要修复较差的代码库，但必须对此加以权衡，以使其从业务角度出发有意义。

您目前无法防止该错误代码，因此您将不得不弄清楚如何包含该错误代码。

项目经理和团队负责人只会在意它是否起作用。他们的下一个担心将是当他们要求您进行更改并想知道为什么“简单”的事情要花这么长时间时。那就是你进来的地方。

现在从一致性问题开始。无论当前使用哪种潜在的标准方法，都请尝试识别它，看看是否无法强制执行。如果您从方法论入手，再没有其他人会熟悉，那么您会遇到很多麻烦。

其他团队成员可能想要获得认证，您将是一个宝贵的资源。希望他们至少要改进，并期待您向他们展示方法。

抱怨匈牙利表示法不会引起您的同情，这可能是优先事项清单上的最后一场战斗。

我同意您需要对此保持谨慎。您需要在团队中建立声誉，然后才能提出批评并提出代码或流程的深刻更改。我只是暂时记录一下我的发现和建议，并借此机会了解团队成员和管理层，进行自由讨论，但不拒绝讨论是否转向质量问题，编码问题等，有时甚至抛出我自己提出了一些问题（但是以一般的形式，没有太过针对我在此代码库中看到的任何具体问题）。这样，我可以了解团队成员的意见并找到潜在的盟友。

在最好的情况下，您可能会发现团队中的很大一部分（和/或管理层）都遇到了与您相同的问题，只是没有主动采取措施解决这些问题，或者没有管理层给予的资源。如果需要的话，您在一起还有更多话要说服管理层。

正如@Mike所建议的那样，确实需要自己进行一些清理，但是同样，最好耐心等待。如果开始得太快，您可能会疏远其他团队成员，他们可能会将其视为个人批评。经理也可能会考虑进行广泛的代码清理/重构，这表明您没有充分专注于实际任务。因此，在更认真地进行之前，您应该获得一些重构的任务。较小的本地更改可能也可以。

另外，要说服管理层，您需要业务依据。很少有关于编码风格不一致的描述来管理。您需要向他们展示提议的变更可以为公司带来什么价值-底线是现金。如果您可以就各种拟议变更的成本与长期收益进行令人信服的计算，并表明总体平衡显然是有利的，则您的机会得到了显着改善。

自己做。如果您重视某些编码样式，请使用违反编码样式的代码。从源代码管理中检出一段令人反感的代码，将代码重新设置为样式的空白要求（例如），并使用消息“遵循样式指南中的空白规则”来提交更新的代码。

一周后，您可能最糟糕的事情就是直接与管理层联系。他们很可能在代码中花了很多时间，并为此感到自豪。您可能会以严重的“全部了解”而离开。

如果我是您，我会做的就是不断改进。随着您对它的熟悉和开发的不断深入，您将有机会对其进行改进。到那时，我将开始向其他同事展示您所做的工作的好处。此后，当召开新模块的设计会议时，请提出您认为最佳方法的论据。

老实说，存在标准是有原因的，但是，如果它行之有效，那么在我的书中（特别是一周后），其价值会提高100倍。如果您打开代码并看到大量的逻辑错误或此类错误，我会更担心。

不要直接用这个“问题”去管理。

首先，与您的同事交谈，并从他们那里找出为什么事情就是这样。然后，您可以更好地评估是否存在问题。您可能会对所学的知识感到惊讶。您可能还会发现盟友希望将其清理干净。

如果您一开始不知道如何到达目的地，那么走出困境就会困难得多。

这里已经有很多好的建议，而且我不烧你的桥，直到你像其他人一样证明了自己的第一意见。我要补充的是，在与团队成员进行深入讨论之前，先与项目经理或团队负责人疏远。并在此之前向他们表明，您应该受到重视。

听起来这也更像是您在代码中遇到的风格问题。接管别人的代码并习惯他们编写代码的方式只是保持工作的一部分，即使这是琐碎的事情，例如他们格式化的方式。把你的一个“婴儿”交给别人，让他们用肮脏的手弄乱它，甚至更糟……

如果最终不仅仅如此-问题不仅仅是功能上的问题-如果您要去团队负责人/下午，最好在将来可以节省金钱和精力的地方提出返工的需求开发项目。好旧的重构。