在编码标准方面与项目负责人存在分歧[关闭]

因此，我与过去1年的项目负责人一起致力于一个新项目。

最初，我们有自己的子项目，这些子项目位于单独的git repos中，我与他的代码几乎没有交互，因此代码的气味不会打扰我。大约6个月后，由于我在该项目中发挥了更大的作用，因此我开始维护他的代码并向其中添加功能。

现在，我是两个子项目的首席开发人员（团队正在成长；他仍然在我之上），这些事情困扰着我，我想照顾他们，但被拒绝了：

1. 没有花括号，大写函数，混合引号用法（带有隐藏逻辑的双引号和单引号），不使用===，具有巨大功能的巨大类。底线可能更好。
2. 依靠PHP的选项来关闭通知/警告。代码中充满了未经检查的变量和数组键用法。变量在ifs内部定义。

以上两个问题的论点：

1. 不想对人强制执行编码风格。
2. 被视为一种语言功能，可以使代码更短/更有效。

我认为需要制定一些规则，并且代码应具有防御性。我提供了使用PHPStorm的默认设置进行格式设置，使用花括号和社区认可的命名约定的功能。

我想使两个项目使用相同的准则，因为它们是密不可分的。

我错了吗？我会强加我的个人喜好吗？

如果您有充分的理由说明自己为什么会更好（以及使用他可能会遇到哪些主要问题），那么我认为您不是在强加个人喜好，而是试图建立一个成功的项目。

如果他能提出更强硬的理由，为什么他会变得更好，以及它将阻止您的问题阻止哪些问题，那么他会让您为难。

体面的高层管理人员应该能够看出其优点，但是这些是他们将（并且应该）关注的要点：不是对开发人员来说更容易，还是“不想强迫所有人像机器人一样工作”（是一个荒谬的观点，但不要将其用作高层管理人员的痛苦点）。他们（应该）关心项目的持续稳定性。

根据我上面的评论：

如果他是项目负责人，那似乎意味着基本上是他的电话。

那是我的想法。如果您想更改标准，但他没有坚持下去，要么a）弄清楚如何超越他，b）去其他地方工作，或者c）尝试做些什么小事而又不会激怒他太多了。

只有当您有理由说明为什么应该有更好的标准时，超越他才能发挥作用。

基本上：

• 你不喜欢他的编码风格。那是你的权利。
• 他发现它OK喜欢它，并认定支出天/周/数更多的只是调整的风格是浪费时间。那是他的权利。

让自己穿上鞋子。除了使公司付出大量金钱（您的薪水）之外，您的努力还有什么好处？他总是这么挑剔吗？他不认为现在还有更多重要的事情要做吗？

基本上，您必须找到可以忍受的某种妥协，否则您的恋爱关系就会变糟。这也很大程度上取决于您如何与他交流。把你的自我放在一边，尝试是有帮助的...因为最后你问他的事情，你想，不是说他有兴趣。换句话说，你问他一个人情。

这也往往取决于如何你问。例子：

你想要什么：

使代码更漂亮

没什么好说的：

您的代码很糟糕

说什么：

如果我能够使两个项目（仅基础知识）保持一致，那将花费我一天的时间，我将不胜感激。

你想要什么：

不再有未经检查的警告

没什么好说的：

您的代码很糟糕

说什么：

我知道摆脱这种警告的一种快速方法。然后，通过重新启用它们，我们可以更快地检测到将来是否会发生故障。

最后：

我知道这不是优先事项。因此，一旦高优先级的东西先摆在桌面上，我就很乐意这样做。

或者，如果那不能解决或者您与他的关系不好，请考虑离开。如果您现在无法解决问题，将来就不可能变得更好……并将您的自我放在一边。

边注

我认为，对高级人士宽容更为普遍。他们知道，无论如何，代码将在十年或两年内被破坏（因为技术的变化，API的变化，团队，业务合作伙伴，需求，全球决策等）。他们的自我意识更少，专注于让它发挥作用而不是完美。尽管我倾向于自我完善，但我不能怪他们。

这可能会引起争议，但是...

我们进行了交谈并同意不同意并将其升级为更高的管理层

决不。曾经 做。这个。永远 每次您这样做，都会使我们所有人倒退十年。这将是这样的：

• 高级经理1：“我们被要求处理这个问题，等等，关于编码标准和浪费时间的事情。”

• 高级经理2：“他们要我们解决他们的书呆子草皮战争，是因为？”

• 高级经理3：“因为他们是那些无法沟通，不关心/不了解/了解业务价值的婴儿，所以*？”

• 高级经理2：“一定是这样。谁来打高尔夫球？”

然后是您和老板的绩效评估时间：

“ [老板的高级经理]：很抱歉，但是您担心您无法管理直接报告，而且您可能未遵循最佳做法（即使我不知道该怎么做，只是输入一些巨型词使软件正常工作”）

“ [对您的高级经理]：很抱歉，但是您担心与您的同事关系不佳，并且在遵循您的直接主管的指示时遇到了麻烦。”

这就是为什么我们所创造的价值与我们相比被少付的原因。**

您需要要么A）克服它，要么B）转到一家商店，该商店的标准与您的喜好稍有不同。FWIW，我会做B（并希望继续使用不允许这种暴行的语言）。但是，除非涉及非法或潜在灾难性事件（存在安全漏洞），否则决不要将技术争议升级为诉讼。仅仅令人讨厌就不会减少***。

*为了使那些会阅读并误解的人，我并不是说OP和他的老板是这样的（我知道代码质量/易读性直接影响业务的底线），我是说他们会被非技术管理人员视为这样。

**对于那些认为我的高层管理人员无知的家伙是不切实际的人，请了解经理（理想地）关心我们以管理代码的方式来管理人员。他们可能对技术问题一无所知，但他们认识人，这就是给他们带来争议的更多原因，因为A）他们可能没有资格解决，B）你们两个可以说应该能够在没有帮助的情况下解决让你看起来不好

***是的，我认识到技术债务可能堆积到使企业破产的地步。我只是不认为花括号会救您（也就是说，我从不忽略花括号，并且强烈希望其他花括号也不会）。

恕我直言，您面对的是“正在运转”的开发人员，而不是一个愿意照顾他们的下一个开发人员的人。他的论点毫无价值。

您所说的关于他的代码的全部只是他的原始懒惰。使项目遵循相同的编码标准非常严格。你不是机器人；你是工程师；你应该很严格。

您可以通过一些示例来指出，在阅读他的代码时很难，这对您来说是一个巨大的生产力损失，但是我不知道如何将其带给他。

但我可能会回答您一些问题：

它正在工作，没有改变的意义

我的建议：如果他真的很钝，不想头上的东西，那就放手。等待错误/错误/演变在他的项目中发生。当它出现时，只需修复并重写以适当方式修改/添加的部分代码即可；不要去找他说什么 他不会将您的编码风格强加于您，因为您无论如何都不是机器人。

在处理项目时，必须设置优先级。

首要任务是与同事相处。优先级＃1紧随其后。然后是优先事项，例如可运行，可测试，经过测试，记录，可维护的代码等。接着是另一个巨大的空白，然后是编码标准。

更改现有代码以符合新的编码标准确实在优先级列表中很少。

PS。“微优化”与“超高速计算机”：完全错误的论点。反对微优化的论据不是计算机速度快，而是因为微优化浪费了时间，这意味着您没有时间追求真正的节省。

PS。如果只花一天的时间进行更改，使代码对您来说看起来更好，但却使您的同事不满，并使您成为敌人，那么您就浪费了一天时间来降低生产力。

PHP不是我们行业中最精英的群体。实际上，您在批评他可能来之不易的软件系统。您的专业水平比他高。

然后，如果您没有责任来改进代码，则只有一种解决方案：继续。

我不知道您所处的当前PHP市场，但您可能首先会有所不同。也要学习一些炒作语言，或像C＃这样的小众市场。

您可能无法获得出色的工作，但是您将在专业上走得更远。因此要有耐心，并做一些自学。安全的钱。然后在您的项目中要求一些余地，或接受一些工作机会。

我很难相信＃1是他不想更改编码标准的真正原因。如果您拥有代码库，则应该能够执行您（以及其他开发人员）所同意的任何编码标准。如果您与其他开发人员达成共识（假设负责人不再从事任何开发工作），那么除了以下方面，他没有理由真正关心他：

固定代码库样式现在是您时间的最佳利用吗？

我确定您有可交付成果。在其他代码库中的各处遍历和改进样式将花费多少时间？如果您通过错误地修复样式而引入错误该怎么办？从鲍伯叔叔那里：

当然可以清除错误的代码。但这非常昂贵。随着代码的腐烂，这些模块相互暗示，从而创建了许多隐藏和纠结的依赖关系。寻找并打破旧的依赖关系是一项艰巨而艰巨的任务。

像这样改进代码样式几乎永远不会把时间作为独立的sprint项。我喜欢进行这类改进的方法就是所谓的“睦邻政策”：不要四处寻找可以找到的所有样式和逻辑结构，因为您可能会花费尽可能多的时间，并且仍然会没有完成。取而代之的是：每当您对代码的一部分进行更改时，都应在其中固定样式，并使其比所发现的更好。如果由于代码设计不当而难以实现某个功能，请修复样式以使自己不受阻碍，而不是为此大吃一惊。

这样，每次更改：

1. 除技术完美主义动机外，还有商业动机
2. 不会被视为大量的时间投资（因为这不是！）
3. 养成良好的文体习惯，正是因为您和您的团队正在逐步
4. 不会对代码库造成很大的风险，因为您不会一次更改太多

从现在开始的几个月后，您将抬头，发现“糟糕的一揽子计划”已经不再那么糟糕了，您的老板会发现他的团队更快乐。但是因为这不是直接的对抗，所以它已经完成了，他也没有什么可抱怨的，因为您没有在他的脑海中浪费时间在待办事项列表中添加一个大型重构项目。他可能永远不会告诉您您是对的，但这毕竟不是目标（对吗？）。

询问有关您的线索的这些问题。

• 他们习惯于独自工作还是与一个很小的团队一起工作？
• 他们主要在这家商店编码吗？
• 他们习惯于做出决定吗？
• 他们习惯于“仅仅完成它”吗？
• 他们编写了大部分代码吗？

如果答案是“是”，那么我将描绘一幅特定类型的首席程序员的照片。如果它与您的经验相匹配，也许会帮助他们进入头脑。如果不是，请忽略此答案。

这是从第一天开始就在这里工作的人，在相同的代码库上从事多年的工作，习惯了自己的方式，并且对其他方式没有太多的经验。

他们在编写代码时不会考虑其他人，因为这对他们来说都是有意义的。当然，他们写了，或者他们花了多年的时间来理解它。

他们认为编码风格是个人喜好，而不是减少维护和错误的工具。在讨论编码风格时，他们会努力听取您的观点，因为他们可能从未想过为什么要以自己的方式做事。他们会听到的是“我想用自己的方式做”或“我想用新颖，新颖，时尚的方式做”。

他们有自己的风格。长期以来，他们一直以相同的方式进行操作，因此他们的所有工具和编辑器以及大脑都按照自己的风格进行了微配置。偏离此样式将与这种精心安排但非常脆弱的工作方式相冲突。尝试更改会引起对他们的编辑器，工具，他们喜欢的工作方式或“难以阅读”的抱怨。他们拒绝更改，因为他们将自己紧紧包裹在现状中，无法更改。

这是从未正确学习过软件工程和软件体系结构的人。他们只是将一切有效地凑在一起。

您遇到的是人员问题，而不是技术问题。

您将不得不重新培训您的潜在客户，否则您将不得不退出。

进行管理是不得已的手段。既有 @JaredSmith指出的原因，也有可能会输。这个家伙花了很多年为他们赚钱。他写了他们的公司。他被无数火扑灭了。对你来说，他是制作意大利面条的牛仔厨师。对他们来说，他是建立并拯救公司的英雄。

要重新培训，您必须...

• 获得他的信任。
• 弄清楚他的想法。
• 解决他对变革的恐惧。
• 使更改变得更加容易。
• 证明这对他更好。

认真对待他的风格，进入自己的头脑。向他询问。他为什么以自己的方式做事？他看书时会看到什么？它如何与他的工具互动？他如何遍历代码？了解所有这些事情将使您了解并解决他的反对意见。

找到他的主观异议的客观根源，使它们可行。“很难读”是主观的，它没有提供任何信息。你对此无能为力。客观地说，“我是色盲人员，语法突出显示不起作用”，它可以为您提供信息，您可以为此做些事情。我会推荐一本名为《入门》的书，以获取更多信息。

一旦找到了根本问题（他正在遇到的真正问题），请查看是否可以解决或缓解它。那不是问题。他们可能仍会因变化而产生情感问题，但至少他们不能再说这是一个实际问题。

一次做一点。这是多年来一直以相同方式进行操作的人。他习惯于查看代码中的某些模式并使用它们来理解它。突然更改所有这些模式会造成混乱。慢慢地使他们以已知的良好实践来加速工作会令人沮丧，您必须带他逐步进行。

提倡标准的社区风格。这消除了关于个人偏好的争论，并向他们施加了压力，要求他们证明为什么他们的不同风格会好得多。如果您打算招聘，则可以更轻松地整合新员工。

提倡自动代码风格。只需按一下按钮即可遵循正确的样式。使用以标准样式开头的工具，让您可以根据自己的喜好对其进行配置，并且可以通过按一下按钮来重新设置代码的样式。尽可能容易地遵循样式消除了许多关于遵循难度的争论。他们可以按自己喜欢的方式进行编码，完成后按一个按钮，它遵循其他人可以阅读的样式。

由于此人不在考虑他人的心态中，因此您将必须说明这些变化如何使他们受益。它可以很简单，因为“因为现在这是标准，您将不必再与下一个雇用的人进行这场斗争”。或者可以是“如果我们有测试，您可以更积极地更改代码，而不必担心更改”。或“如果有好的文档，人们就不必再对代码的工作方式感到困扰”。要使此方法有效，您必须知道他们想要什么-有些人喜欢被打扰，这使他们感到很重要。

这是一条漫长的路。您必须确定自己是否有耐心来管理和重新培训老板。将自己更多地看作是他们的老师，而不是沮丧的基础，您可能会对此感到更好。

我错了吗？

我不了解PHP，所以我无法做出直接判断，但是出于争论的缘故，我将假设您首选的编码样式比您遇到的代码“更好”，因为您的代码更加符合要求使用现有的自动化工具。

那么，建议改进编码风格就没错。

底线，不是我要使用的代码

拒绝使用不符合您的首选标准的代码可能会是错误的，而仅是在为公司工作时，您才同意使用其代码。最终，如果您提出的要求不符合您的喜好，那么辞职并不是“错误的”，因为这是您的权利，因此您可能会找到更好的工作。

我会强加我的个人喜好吗？

不，他是项目负责人，而你不是。这是他的电话，尽管在这种情况下，他是“下放”的。

作为子项目的首席开发人员，他可能还决定下放下来给您，并让您自由地为那些子项目和将来从事这些工作的同事设置编码标准。但是无论出于何种原因，他都强烈认为您不应该标准化。即使他在编码风格上是错误的，您也不能指望他没有允许您授权。

但是，由于他说“我不喜欢强制执行编码样式”，因此您至少可以以自己喜欢的样式编写新代码（并且已经这样做了）。最终，这可能会导致有机会展示您的风格的客观利益。那是第二次提出自己的理由的好时机。

您（我认为）也可以合理地要求编辑文件的人以已写入文件的样式进行编辑。这样，您就可以维护编写的文件中的标准。不幸的是，与此相反的是，您必须以他的风格编辑他编写的文件。

即使假设您有一个非常好的测试套件，因此可以相对安全地进行重构，仍然（公认地非常有限）仍然有理由不爆炸并重新设置整个文件的样式。主要的问题是试图合并，重新排序或还原在重大结构更改之前和之后所做的更改是一场噩梦。但是很可能在这个特定项目中几乎没有发生过。

[我的经理说，他不]喜欢对人们强制使用编码样式，因为我们不是机器人。

有没有想过为什么我们在编译并通过所有测试后不就将源代码扔掉？源代码是供人类使用的，不仅供人类编写，而且还供阅读。

迟早会有人回去阅读代码。也许他们需要更改它，也许要记录它，也许要重用它。随你。这将发生，并且如果所有代码都采用一致的样式，那么代码将更容易阅读和使用。

即使是不好的风格也总比没有好。