我怎么能巧妙地指出同事的工作是不好的呢？

Question

作为我的第一份工作，我加入了一家初创公司，有少量的开发人员。

我主要和另一个人一起工作--我们现在叫他保罗吧。我们是我们队中仅有的两位开发人员。

他比我早一年就加入了公司，差不多是在公司成立的时候，并且在我们公司的核心部分建立了相当一部分，并得到了管理层的大量认可。

然而，看看他的代码，我意识到这是不好的。我是说真的很糟糕。

他几个月后就学会了崩溃编程，老实说，他仍然是个糟糕的程序员。他不知道如何理解列表(我们主要使用python )、类继承(或任何与oop相关的内容)，也不知道如何使用git。

例如，目前他的一种旧代码需要2小时才能完成cron工作，这会产生大量的if语句，我相信使用正则表达式可以将这些语句缩小到10分钟。

但显然职场政治是存在的，我不能明目张胆地说他的代码是我们问题的症结所在。我的组长不知道如何编码，而且，我也不能说“他在编码方面真的糟透了，他的代码糟透了。”

然而，问题需要修正--在某一时刻，我觉得我需要说“你的代码真的很糟糕，我需要重写它，因为你仍然会做很糟糕的重构工作”。

如何巧妙地提起这件事？

Answer 1

您可以尝试(与您的同事或管理层)就代码质量进行交谈，但如果您的同事有提供足够质量的记录，那么他们可能会置若罔闻，除非管理层已经自己发现了问题。

如果需要付出代价(除非你实际上是一个更快、更彻底的开发人员，而不仅仅是更慢和更彻底的开发人员)，否则管理人员对“正确”完成的事情不感兴趣，或者对将来的维护不感兴趣(除非您是一个更快更彻底的开发人员)。

所编写的绝大多数代码都是质量差、寿命短、轮子的重新发明，并支持那些运营质量通常同样差、寿命短、与许多其他企业相同的企业，而老板通常通过对代码的投资不足来最大化他们的利润(至少在短期内如此)。

此外，执行时间并不是代码质量的重要指南--老板不是按小时支付计算机费用，而是按小时支付给开发人员。

只有在市场竞争激烈的情况下，质量才会在有监管和强制执行的情况下才会显现出来，无论你是在用粉笔和灰泥掺杂面包，还是在设计经营企业的系统，质量都是如此。

Answer 2

看起来你已经拥有了一切你需要改变的东西。

在代码基中选择一个当前引起问题的点，例如花费太多的时间，并声明应该重写它以使其更快。没有必要把你的同事称为“糟糕的程序员”来完成这件事；事实上，最好解释一下“这件事写得很匆忙，我们现在应该投入人力时间来正确地重做它”。除非你的目标是摆脱另一个人，或者在管理层眼中获得地位，否则这就是你所需要的。

Answer 3

既然你不是这个人的老板/经理，也不可能被雇佣来负责他们的工作质量，这是只有通过管理才能解决的问题。

当然，任何情况下的工作质量都应该关系到任何企业和任何管理者，因为它通常会影响到客户满意度、收入、花费的时间、遵守最后期限的能力、企业的声誉以及对其未来运营/盈利能力的各种风险或威胁。

然而，这些问题需要与团队领导/经理讨论--只有与决策者合作才能解决这一问题，因为他们是唯一有权阻止这种情况发生的人(例如，你可以帮助你的同事，但那个人可能会离开，找到一份更好的工作，然后雇主可能只会雇佣一个同样糟糕或糟糕的人，你就会再次回到原地)。

管理层是那些对你和他所生产的工作的质量负有最终责任的人，也是其他参与其中的人；他们“拥有”它--这是他们决定雇用谁、可接受的质量水平以及可接受的工作实践等事情的地方，所以你的同事的表现和他们工作的质量是一项管理责任。

向管理层提出问题是完全合理的，如果你认为有些问题需要他们意识到，并对企业产生负面影响，但这必须从商业的角度而不是从技术的角度来处理。同时，也要准备倾听管理层的意见，以防他们有任何理由不想采取行动或不想改进事情。

在任何讨论中，只需提出工作本身的具体结果，并避免讨论创造这一成果的人(同样，如果其他人碰巧雇佣了另一位技术水平完全相同的开发商，这些问题也很容易适用于他人；在同事能够改进之前，公司必须提供变革的动力，那么同事需要随后跟进，因为这将是管理层的要求)。

在任何讨论中，看看错误、错误、粗枝大叶的工作、糟糕的工作习惯等是否会产生负面结果或损害企业。任何半称职的经理都应该足够聪明，知道谁应该负责，而不需要这样的讨论退化为一场指责游戏或指责。重点还应放在如何改进这些事情和吸取经验教训-即新的工作实践、工具和指导方针，以避免这些问题。

例如，提高质量的一个非常好的方法是确保任何新工作的“已完成定义”包括全自动测试覆盖范围。您可以找到其他自动化工具和技术，如静态代码分析器，这也有助于提高质量。同样，关注的是工作实践而不是人；也不要忘记，即使是最优秀的软件工程师也总是有大量的自我改进的空间，所以把这看作是提高公司的标准，而不是一个人。

此外，要记住，如果客户满意，而且业务正在盈利，不良的工作实践并不总是被视为一个问题。改变思维需要具体的、连贯的推理，这必须得到经验证据的支持--这可能意味着你需要从你自己工作的新的/改进的工作实践开始，这样你就可以证明事情变得更好了。

要做出改进总是很困难的--不要指望任何改变都会很快发生，也不要期望一帆风顺。最终，你是一个需要达到(甚至可能超过)工资水平的雇员。协同工作。保持开放的心态。成为一个杰出的倾听者。做一个强有力的沟通者。好心点。要理解。投入时间成为你想要改进的事情和你想要介绍的实践的专家。您可以努力成为企业中的其他人(包括管理人员)，了解良好的软件开发实践的优点，以及明智、现实、务实的步骤，说明他们如何处理它以及为什么。

许多非技术人员并不直观地理解软件工程问题是如何与业务问题联系在一起的；事实上，许多业务人员认为"IT“是消耗资金的必要开销；对他们的前景敏感。同时也要意识到，许多技术人员不一定对避免技术债务的典型商业理由有足够深刻的理解--至少没有足够好的理由来为其辩护。

在这个行业中，有很多人都会受益于更多关于软件工程的知识，所以考虑鼓励他们去读一些书，比如神话中的男人月，务实的程序员，以及干净的程序员。

如果你自己没有读过这些书，那么我会向那些人寻求指导；如果你想成为变革的推动者，那么你需要深入地沉浸在关于软件开发实践的书籍中，因为你会有很多非常困难的论点要赢；你只能通过自己确定问题来赢得这些论点--即使这些改进没有改变公司的文化，你也可以提高自己。