忽略质量/标准的软件开发人员是否对公司更好？[关闭]

选择不将代码优化，标准和最佳实践作为重中之重的软件开发人员，是否比那些担心优化，编码标准和实践的执行不如准时完成任务的开发人员创建更多有用的代码？

在进行个人绩效评估时，这些不同的方法有何比较？

这些样式在同行评鉴中如何比较？

在SDLC期间影响您的团队实施更多最佳实践的最佳方法是什么？

不，他们只会在当下得到项目所有者的尊重。

他们将因以下原因而被浪费多年：

• 未来的维护者
• 未来的测试人员
• 未来的项目所有者，
• 未来的经理，
• 以及将来涉及代码库的几乎所有人员。

他们甚至可以从以下方面获得相同的待遇：

• 当前的测试人员
• 当前的技术文档作者。

错误的二分法：质量是正交的。

                高品质低品质

获利的真棒草图

无利可图的iffy火灾第一

号最佳实践是最好的，因为，根据定义，他们帮助把工作更正确，在更短的时间，能够更快modifcation的道路工程，所以无论他们是保证降低利润。当然，您的经理可能会开出他们认为最佳但实际上并非最佳的做法，或者他们可能会误判客户将支付的费用和未支付的费用-然后所有赌注都消失了。

编码标准比较棘手。可能会给您的编码员开出太多细节，从而降低效率。但是，凭经验，从保持肛门的微观管理中讲出有用的指南变得非常容易，因此同样适用：实际最佳实践总是值得的，伪最佳实践通常不值得。

除非你有一些代码优化通常是不值得做测量你的瓶颈，确认这样做的优化是必要的和测量你的巧招确实满足了性能与rquirement。否则（主要是）这是不值得做的，因此不是最佳的。

我是否同意那些不关心代码优化和实践的开发人员？ 没有。

他们会做他们需要做的工作吗？是。

企业就是要赚钱，而赚钱的唯一途径就是发布产品。这通常意味着项目有严格的进度，这意味着做某事的最佳方法可能不是做某事的最快方法。

尽管我不同意这种开发方式，但是如果发布产品，公司可能会认为它是值得尊重的。

不，我会发现远离那些欣赏这些弊端的公司的最快途径。

是的，不是，这有点令人望而却步，但这是最佳做法，而不是完美的实践。理想情况下，您应该不断地遵循它们，但是总有一种情况是企业希望将其需求放在产品需求之前。

维护人员会讨厌您，但老板会爱您。

最佳做法有点像常识，每个人都同意每个人都应该了解它，直到任何两个人开始详细讨论它为止。没有两个人完全同意这个定义，也没有适用于所有情况的逻辑真相。

您是否正在编写太空卫星的制导系统（可能不是）？然后，在这种工作中，地狱不会出现质量差/执行代码永远不能被接受的情况。

您是否正在为一次性市场推广而编写一个一次性网站（您可能也没有这样做，或者您不会问这个问题，但是它比卫星广告更有可能）？然后是地狱，是的，通过任何必要的手段在最后期限之前将那一堆绒毛排除在外，下一任营销总监可能还是会与另一家公司做其他事情。您不是艺术或科学的人-得到报酬。

介于两者之间的其他一切：可以协商，特别是只要开发人员可以得到初始支持。

在您偏爱的任何圣物出现之前，他/她/他们/它以奇迹般的方式定义了开发实践，对于不直接负责生死决定的任何项目，将有很大的辩论空间如此微不足道，可抛弃。

标记生命的最佳实践之外的所有内容通常更像是公司政策，客户要求或个人意见。他们中的许多人是目前许多人都同意的个人观点，但这并不能使它成为所有情况的不变指南。

他们为公司赚多少钱值得商bat。如果一定程度上可以重新审视有问题的代码，维护成本将会增加，并且人们会不满意。高昂的长期维护成本要比预先进行适当的维护昂贵。

他们得到多少尊重可能取决于具体情况。但是在某些时候，有人会注意到。

不关心这些事情可能会在短期内使公司赚钱，但从长远来看，可能会花更多的漏洞修复和维护代码使公司付出更多的钱。

如果竞争公司急于同时将类似产品推向市场，有时可能需要快速工作，但此类行动的未来成本应谨慎考虑。

这一切都取决于客户。

喜欢快速又肮脏（通常更便宜）的客户不在乎将来会出现问题。

考虑内阁建设。

有些人会支付并欣赏优质定制橱柜。他们不在乎硬木抽屉和顶级硬件的额外花费。他们不介意构建和安装这些东西会花费额外的一周甚至一个月的时间。

许多人不会。许多人会选择从大型商店购买的廉价刨花板批量生产的产品。他们希望在2天内安装它们。到处都是很小的差距是完全可以接受的。他们不在乎他们会在10年后分崩离析。

因此，如果您的经理称赞能够快速又轻松地完成开发工作的开发人员，则您的客户不希望获得高质量的产品，或者经理在对客户撒谎。

只有时间会给出答案。做经理想要的或找到另一份工作。

没有永不。IMO代码优化，最佳实践和实际工艺是代码库中最重要的事情；没有它，整个东西就会变成淤泥，并用胶带固定在一起。这是不可持续的设计。这就像忽略了一个肿瘤，因为它很小并且您现在很健康。确保您现在身体健康，但几年后它就会成为绝症，因为您已经忽略了很长时间。

我不但做不带谁不关心这些事情开发商同意，但我有零尊重为他们的引导。无论我去了多短的时间，让我考虑离开组织的必由之路是由一个团队围绕，在这个团队中，我是唯一关心的人（如果不是整个公司中唯一的人）关于适当的软件工程概念。

好的阅读：http : //www.joelonsoftware.com/items/2009/09/23.html

但是恕我直言，一个人的最佳实践是另一个人的噩梦。对于外来者来说，每个不平凡的代码库都是噩梦。

无论您怎么想，都不要着急。

编辑：我不捍卫任何职位，具体取决于我可能倾向于任何一方的任务。

对公司更好？这取决于。

对于资金有限的初创公司来说，把它做好并付诸实践-没什么麻烦的，可以在以后有更多资源时解决。

对于许多用户依赖软件质量的成熟产品，应“适当”完成所有操作。

更适合个人开发者吗？其实无关紧要。只需执行与同事相同的操作，然后让管理层处理后果-这不是您的工作。如果您一直都在修补别人的垃圾，那么您会被认为很慢，当其他人被提升到您之上时，您将仍然是一个人。参加该计划，如果那很糟糕的话，可以出去玩。

取决于开发人员和项目/情况。

非凡的时代需要采取特殊的措施。

因此，如果我现在需要交付的东西，而某人正在过度设计企业级Java应用程序，该应用程序利用不少于14个最新的流行语框架，而一个简单的python脚本就可以完成工作，就比开发人员偷工减料并认为越野车代码会在正常情况下运行。

成为开发人员的一部分是灵活性。您不应该只是工具的奴隶，而是盲目地遵循实践-在某些情况下，它们总是会让您失望。知道何时打破和改变规则是许多经验之一，而且很有价值。

在您的情况下-如果在速度方面至关重要，那么他提供的价值比您还多，即使在考虑了日常维护成本的增加之后，他也应该得到更好的补偿。另一方面-如果您坚持清理他的烂摊子-您与管理人员之间存在沟通问题。

视情况而定。除了编码风格-没有其他借口。

很抱歉，但除了最重要的问题外，我将不同意该问题的大多数答案。

软件的主要价值在于它的灵活性。

我认为您不应无缘无故地重写别人的代码。如果您出于某种原因必须更改模块以实现功能，则无论是好是坏，您现在都是该模块的所有者。更改它，重写其中的一部分，重写所有它。

永远不要在灵活性方面产生低质量。没有什么可以扔掉软件中的任何东西。如果客户说它是临时的，并且在某个日期之后他们将不需要它，并且他们不在乎质量，则说“不好”或以书面形式告知您或您的任何其他程序员都不会更改代码它已部署到生产中，或者您有权提起诉讼。

我在这些答案中看到的最糟糕的假设是，某些干净的代码会以某种方式降低开发速度。对于任何实质性项目（超过6个小时的工作），长期来看（超过一周），干净的代码可以加快开发速度。我一次又一次看到它。

质量差的代码对专业和您的同事不敬。对不起，但事实如此。

因此，就灵活性而言，永远不要劣质！