我被迫编写错误的代码。如何保存我的脸？[关闭]

我只是一个初级开发人员，但是我的工作迫使我使用非常糟糕的PHP代码（想想您所见过的最糟糕的PHP代码；然后再考虑糟糕两倍的代码）。我通常会尝试修复错误并与代码库抗衡以添加新功能。有时，我被勒令让事情尽快运行，而这往往涉及肮脏的骇客。

该产品以前是开源的，我担心它将来可能会开源。如果有人（尤其是潜在的雇主）能在某些变更集旁边找到我的名字，我会感到ham愧。我该怎么做才能保护自己的好名声？

我不确定这是否有意义，但我要补充一点，我的老板和同事都不想承认代码不好，但是我不确定我是否可以为此责怪他们-对于许多人来说，这就是他们的第一份工作。

罗马不是一天建成的，但您可以成为一名出色的“童子军”。每次您触摸代码时，都要比以前更好。使用明智的函数名称，良好的编码标准并在工作时添加体面的注释并不需要花费很多时间。

我认为危险在于认为这是全有还是全无。仅仅因为您不能花费时间来编写精美的代码，并不意味着您必须完全放弃并编写垃圾。

同意S.Lott的评论*（一次：）：没有人强迫您编写错误的代码。事情是，初级开发人员。通常（该网站也应为此负责）迷失在最佳实践，“美丽的代码”，……任何您想称呼的东西中……而他们却没有做很多事情；否则他们会完成但浪费大量时间。通过告诉他们编写错误的代码（这也是行得通的），它比“通过它”得到的更多，只是使他们交付了东西。随着时间的流逝，一个初级开发人员（现在不再是:)很快就想出了一个快速而又肮脏的解决方案，但是花了其余的时间来改进它。随着时间的流逝，您会学到更多，并且在某个时候开始提供快速而肮脏的解决方案，这些解决方案实际上是好的代码。

但是，如果您从一开始就尝试编写完美的代码，则很可能会花费很多时间，而几乎没有做任何事情。

所以……写出不好的代码，……很多……几乎行不通的代码，然后进行迭代。每次迭代都好一点！

没有人第一次写完美的解决方案。

* 这是较短的评论。

代码注释是您的朋友。

每当您由于压力而不得不写一些廉价的文章时，只需说一句“由于时间限制，该代码执行X。理想情况下，我改为执行Y。-羞愧一号，2011年7月5日”

然后，如果潜在的雇主看到了它，他们就会意识到您更喜欢编写优质的代码，但是您也愿意根据业务需求调整编码风格。大多数雇主都将这两者视为好事。

这取决于他们如何强迫您。

以我的经验，有两种可能性：

您会因为时间紧迫，遗留代码等而感到压力。

在这种情况下，正如大多数其他答案已经说过的那样，“优化冷静”取决于您。您可能没有时间将代码库重写为MVC，但是作为第一步，例如，您可以停止手工粘合SQL，而是写一个nice execute_sql($query, $params)，它为诸如fetch_customer($filter_params)等的抽象奠定了基础。记住，一切顺利最终，您的老板会提早获得产品，因此在未来和现在的投资时间上只有一个矛盾。

当您设置正确的上下文时（“在6个月之内，没有多余的时间，我将整体代码重构为MVC”），您应该在代码上留下自己的名字，并像治疗师一样自豪，这可以教会中风患者如何再说一次。

您被明确命令以您认为不合适的方式实施它

试图将视图与模型分离的尝试无法幸免，因为“它太复杂了，为什么不执行简单的SQL查询呢？”。您execute_sql之所以罐装是因为“有纪律的编码人员不需要”。

这种情况糟透了。以我的经验，通常是因为微观管理和团队领导而升职的原因是政治原因，而不是他们的成功。真正的问题是，您要负责一些您无法控制的事情（代码）（必须按照自己的方式去做）。最好的解决方案是解决根本原因（即，您被视为咕gr声）。第二好的解决方案（以我的经验，这是通常的解决方案）是退出。

好处是，在这种情况下，您的名字无论如何都不会被公开，因为团队领导者将所有成功归功于他。

我非常有信心您的老板要求您快速交付一些东西，但并不是您要付出额外的努力使它故意变坏。这意味着，每当您在糟糕的代码和稍差的代码之间做出选择时，而这两个选项都将花费相同的时间来实施，那么您会选择差一点的坏选项。这是短期解决方案，完全不需要任何努力。

从长远来看，与您的老板交谈。解释一下在这里投资15分钟如何在这里节省时间。确保您有令人信服的示例-而不是类型“如果我在这里做到了这一点，我希望我明年能够再做另一件事”，而是“在这里，我做了这件事，并且因为其中，我花了三个小时才找到问题所在；如果我以这种方式做到这一点，该错误将立即显现出来。” 这里的警告是：虽然优雅且可维护的代码感觉更好，更高效，但有时却并非如此。在某些情况下，草率的快速修复是完全合理的：有时您正在编写一次性代码，有时则使过时的垃圾活着，等待真实的事物。有时候，适当解决方案的好处不会

如果其他所有方法均失败，请去找另一份工作。

没有人强迫您编写错误的代码。您可以扭转这种局面并使之成为积极的局面。政策和程序的先驱变更。而且您也不能永远都是“是”的男人/女人。如果他们说要在一天结束前使用功能x，请告诉他们这是不可行的，但要说明为什么确实不需要。出现问题时，请提供解决方案。不只是视而不见，或更糟的是……增加了它。

您的开发商店并不是第一个有严格期限的公司，同时仍然希望维护精心设计的代码。

任何公司都需要在编写出色的代码，大量文档和单元测试以及在合理的预算和时间范围内将产品推向市场之间找到平衡。

世界上最好的代码在发布之前是否过时并不重要。

务实是要寻求这种平衡。目前，快速修复功能可能在商业上至关重要，但这并不意味着总是如此。

要获得这种平衡，需要大量的经验（比大多数编码员都多）。无论哪种情况，都非常容易。寻找中间道路更加困难。

我并不是说你的老板是对的。作为编码人员，有一种尝试不断创建漂亮的代码的诱惑，而这在商业上是不可行的。牢记这种诱惑可能会帮助您认识到其中一些黑客行为还算不错。

足够的时间后，大多数代码将包含针对特定情况的hack，这些hack的成本太高，无法重构为通用框架。

我想补充一点，您不应该像现在一样继续操作，什么也不说，只是骇客而入。

您需要站起来并指向具体代码，并告诉他们对此有何看法。具体并使用代码指标备份您的声明。没有什么比声称一个代码是不好的而感到尴尬了，而实际上却不是，您只是不了解正在做什么。

我确信有很多免费工具可用于php代码分析 http://en.wikipedia.org/wiki/Code_analysis

另外，当然这是 http://en.wikipedia.org/wiki/Code_smell

仔细阅读，总结一下您可以在应用程序中找到的内容，当然还列出了替代方案。不站出另一种（最好是）更好的方法来站起来大喊“我不喜欢这样做的方法”是一种不好的做法。

快速入侵会花费金钱。并且不要完全消极地看待它-您现在可以从这项工作中学到很多东西，并且可以从下一次的经验中受益。

hth

首先，您确实要使用某种源代码控制，对吗？如果没有，从那里开始。它会首先为您提供帮助，并很快被团队中的其他成员所采用。

如果您具有源代码管理，则不应在代码中输入名称，而应在公司中输入名称。在错误的代码中，通常将修订历史记录放在文件顶部的注释中，这最好委托给源代码管理。

现在，关于代码质量，您将无法以巨大的方式对其进行更改。慢慢地，一个接一个地为不同问题添加新方法。如果操作正确，它将节省您一些时间，您将使用它来改善整体质量。

举一个我的例子，我曾经在一个Perl / CGI应用程序的项目中间，所有HTML都在代码中。整个应用程序位于单个文件中，没有清晰的结构。没有任何版本。我首先配置一个CVS存储库（当时没有SVN），然后为客户提供一个Web界面。最初，我是自己处理同事的承诺。然后，我将所有方法拆分为不同的模块（文件）。那时，同事们开始采用CVS。然后，我将HTML移出了代码。然后，每次我不得不对代码的某些部分进行更改时，我都花了一些时间来重构其中的一些内容。最终，开发速度大大提高，客户非常满意。他们会要求进行外观更改，而不是告诉我们“这将需要2天”，

但是，这种方法仅在您完全掌握了全部代码后才有效。如果您不了解全局，那么如果应用程序的某些部分仍然难以理解，则会使您的工作非常困难。

最后，完全重写有时是唯一的解决方案，但是通常很难证明其管理成本。

由于您是初级开发人员，因此这实际上是一件好事。被扔进一大堆代码的混乱之中，将带给您更多关于不该做的事情的知识，而不仅仅是只编写完美的“干净”代码。利用这种情况，学习如何重构不良代码并将其缓慢转换为更易于管理的代码。并且不要抱怨它必须尽快。这就是重点-在紧迫的期限内做事时学习重构和清理代码。毕竟，只要有无穷的时间，任何人都可以编写完美的代码。