“只要有效”是规范吗？[关闭]

看到我最近的问题： 编程是在竞逐低谷时的一种职业吗？

我的最后一家商店没有流程。敏捷本质上意味着他们根本没有计划如何开发或管理他们的项目。这意味着“嘿，这是大量的工作。请在两周内完成。我们节奏快且敏捷。”

他们发布了他们知道有问题的东西。他们不在乎事情是如何写的。没有代码审查-尽管有几个开发人员。他们发布了他们知道是错误的软件。

在我之前的工作中，人们只要有工作的态度就可以了，这很好。当我要求重写我在本质上探索该规范时编写的某些代码时，他们拒绝了。我想重写代码，因为代码在多个地方重复了，没有封装，并且人们花了很长时间来对其进行更改。

所以从本质上讲，我的印象是：编程归结为以下几点：

1. 阅读有关最新工具/技术的书
2. 基于此，将代码丢在一起，避免编写任何单独的代码，因为公司不想“保留自定义代码”
3. 显示它，然后继续进行下一个操作，“只要它有效”。

我一直告诉自己，下一份工作我要去找一家更好的商店。它永远不会发生。如果是这样，那么我会感觉卡住。技术总是在变化；如果这里唯一的专业发展是阅读最新的MS Press技术书，那么您在10年的时间里已经建立了什么，但是对各种技术都有肤浅的认识？我担心：

1. 拥有专业水准的最佳方法
2. 在这种情况下如何发展有意义的知识和经验

您间接发现了我认为成为优秀开发人员的关键方面：在“ 只要有效 ”和精心设计的优雅代码之间取得平衡。

就像在政治中一样，将自己的立场摆在频谱的一端要容易得多，而不是在中间采取微妙的立场。我遇到的大多数开发人员都属于以下两类之一：编码牛仔黑客和建筑宇航员。我试图在两者之间取得平衡。这并不像听起来那么容易。

为了更直接地回答您的问题，是的，我认为“只要有效”通常是常态。但是换一种方式来看：您处于很好的位置，可以教育您的同事并尝试引入一些更好的做法。但是不要走极端，记住为什么我们都这样做：解决客户的问题。

>>在我上一份工作中，人们只要有工作的态度，就可以了。

也许我在这里只是少数，但我持相同的态度，我坚信重写某些内容应该有明确的证据说明我们为什么需要这样做。我并不是说“ uf，我不喜欢它的编码方式”之类的东西-每个开发人员都对代码有偏好。我们要重写的部分应该存在一些问题：

• 性能问题
• 发现的错误多于系统其他任何部分
• 开发人员在此部分上工作时会花费更多时间
• 等等

对于任何人决定发布错误的软件，敏捷不承担任何责任；人类是。

就是说，您非常重视质量，这很好。我相信您是一个完美主义者，如果您不赶上最新技术，那么您会担心自己的价值。

问题在于，完美主义导致拖延，拖延导致平庸。

这就是为什么企业将优先考虑诸如上市时间之类的东西，并使用敏捷以可预测的速度快速交付价值的原因。

由于您没有描述公司的业务策略，因此我认为您应该首先向经理提出有关问题。

通过与他们的目标和计划保持一致（他们雇用您来帮助他们实现目标），您将可以更好地了解自己如何为他们做出贡献，而不必专注于自己的目标和个人目标。

我敢肯定，通过尝试understand他们的价值，您将能够分享自己的价值，这将是富有成果的合作的开始。

而且，如果您发现他们不知道自己在做什么，那么唯一的选择就是退出。

这完全取决于您要构建的内容。如果您要建立一个仅在线一个月的微型网站，并且您有九天的时间来构建它，那么可以，只要它可以工作就可以了。

如果您要为FA-18系统编写电传飞行算法，则最好尽可能完美地构建它。

大多数技术答案都是如此……这取决于。

这取决于公司。但是，许多公司面临严重的竞争和时间压力。这是一个典型的原因。另一个可能是工作量很大，可能没有足够的人员。（存在人员不足的一些很好的原因，但这不一定是公司的错。）也就是说，一些组织无法设法摆脱湿纸袋。

我认为80/20规则适用于此。基本上，您需要忍受the脚的80％并逐步达到20％。但是，请意识到，即使他们也必须做出权衡。在企业中，绝对拥有绝对正确并不重要。重要的是您现在拥有它。

如果这里唯一的专业发展是阅读最新的MS Press技术书，那么您在10年的时间里已经建立了什么，但是对各种技术都有肤浅的认识？

那会很麻烦，但是在那十年中可能有一些值得注意的失败。我去过很多地方，我都记得在那儿工作时喜欢或不喜欢的一些非常具体的事情，因此会质疑在我的新工作场所再次拥有这些东西。有时，可能会有一些新的实践尝试，例如公司尝试实施Scrum或采用“测试驱动的开发”方法，这些可能是机遇，但不一定像在正式教室中那样被视为专业发展。

我知道在各个地方“只要它能起作用”以及各种牛仔编码策略都是很普遍的。在一些初创公司中，我已经看到了这种心态，如果公司还很年轻，以至于他们仍在试图冲淡他们真正想做什么的想法，这可能是有道理的。在我工作过的其他公司，还有更多的流程和成熟度，虽然我担心，但不一定很容易找到，虽然可能很不错。有些地方有一些流程，我必须去看看，“我喜欢。我会记住的，以备以后工作时使用，”而其他地方，我会去，“我真的不喜欢。我会注意以便将来避免这种情况。”

我在这样的一家商店工作了一段时间，正好赶上他们。有两到三年的应用程序存在已知错误，而这些错误实际上是无法解决的。考虑一个4,000行长的循环，并不断计算布局的宽度和高度。修复一段代码以一次修复一个问题将在其他地方导致20个问题，因为以前的开发人员通过使用幻数任意调整计算结果来帮助解决类似的问题。除了有毒以外，该代码别无其他描述。

我终于得到了一个新项目，老板告诉我可以使用此现有代码来处理布局。我以某种方式说服他让我“改变”它，所以他给了我一些额外的时间。我花时间写了一个设计良好的库来协助布局。从字面上看，这个新项目中的错误花了我10秒钟来解决。我什至在查看代码之前就可以找出问题所在，以查看出了什么问题。

我以为这会给我的经理带来一个转折点，但是我得到的只有拍拍反面，他实质上告诉我“我想您的方法也行得通”。

从那以后，我开始在另一家商店工作，这里的情况更好。问题是，你不能改变主意。只是去别的地方工作。

我仍然希望，在经济中存在一种进化过程，迟早会使这类公司破产。但是也许高科技的高速发展会带来太多新的利基，所以即使是弱小的竞争对手也仍然可以找到足够的“食物”。

如果您想增加在一个好地方工作的机会，请寻找一家拥有向许多客户销售产品的公司，而不是每隔几周就编写新产品。拥有一个良好的代码库并能够添加新功能而不会一直破坏现有代码应该引起更多的兴趣。

让我想起了我上大学的主要同伴。他参加了VLSI设计课程，并且在他的第一个作业中想到了一个组件，该组件的宽度约为微米，而长度则为1英里。模拟完美通过。

他对批评者的回答是：“我所知道的是我的狗屎行得通。”。

帕累托原理是一个很好的规范

我有一个80-20规则的项目的经验，并且效果很好。我认为回答“您在哪里为完美主义划清界限”这个问题也很有帮助。

术语“帕累托原理”也可以指帕累托效率。 帕累托原理（也称为80-20规则，少数人定律和因子稀疏性原理）指出，对于许多事件，大约80％的影响来自20％的原因。 商业管理思想家约瑟夫·朱兰（Joseph M. Juran）提出了这一原理，并以意大利经济学家维尔弗雷多·帕累托（Vilfredo Pareto）命名。他在1906年观察到意大利80％的土地归20％的人口所有。他通过观察他的花园中20％的豌豆荚包含80％的豌豆来发展了这一原理。这是业务中的普遍经验法则。例如，“您80％的销售额来自20％的客户”。从数学上讲，在足够大的一组参与者之间共享某些东西的情况下，必须有一个介于50和100之间的数字k，以使“ k％被（100-k）％的参与者所占”。数量k可以从50（在均等分配的情况下，即100％的人口拥有相等的份额）到接近100（当极少的参与者占几乎所有资源时）。数学上80％的数字没有什么特别的，但是许多实际系统在中间分布不平衡的这一区域附近都有k。 帕累托原理仅与帕累托效率有切线关系，这也是同一位经济学家提出的。帕累托在人口中收入和财富分配的背景下提出了这两个概念。

链接到源

当我要求重写我在本质上探索该规范时编写的某些代码时，他们拒绝了。我想重写代码，因为代码在多个地方重复了，没有封装，并且人们花了很长时间来对其进行更改。

没有冒犯，但作为经理，我按以下方式阅读了该声明：

“当我要求两次重写我已经写好的代码的报酬时，我的公司不想付钱。我想多花些钱来清理我第一次写的时候的烂摊子，同事们因为生活困难而生我的气。”

如果您抱怨的是您自己的代码，那么您就没有什么可依靠的了。

更新

我了解此POV不受欢迎。但是，我也不认为这与专业开发人员的职责和态度完全不符。

如果您从一开始就编写了干净的代码（这样做的原因有很多-不管您是否认为自己的代码将要用于生产环境），那么这个问题就会少得多。

如果您在估算中包括了干净的代码和重构时间，那么您还将有时间表使代码库保持整洁。如果由于日程安排压力而您没有获得所需的时间-由于处理已发生的技术债务，您的未来估计应该会增加。

在某个时候，您的未来估计（或估计周围的不确定性）将使您有理由要求进行重写（当您的经理恳求您使过程加快时）。如果不是，则接受该企业已接受您的估计，并且宁愿支付当前的费用，也不愿更换。那纯粹是商业决定，而不是技术决定。

请记住，协商时间表的时间是在编写代码之前，而不是之后。编写代码（并“生效”）后，客户，经理和执行人员不希望看到另一笔接近或超过原始成本的“维护”账单。如果您对它的想法像企业所想的那样强烈，请随时根据自己的意愿重写它-这就是您要企业做的事情。

从您的经理的角度来看，给您安排重写的时间表会使他的工作陷入困境。当您无法交付产品或无法按照您所说的那样提高生产率时，那么他就是那个手拿包的人。与听您抱怨的不便相比，请猜测他会喜欢哪一种。

如果那是您可以做的工作，那么每次都专注于编写更好的代码，而不是回去再重写旧的代码。在将第三方程序包粘合在一起的范围内，您仍然可以进入一个质量范围。

如果您有时间并且想要改善所维护的现有组件的代码，那么只要您的工作可行，您是否可以在不征得许可的情况下就做它？将时间用于您使用下一个组件的下一个项目的估计中。

对于较低级别的编程，如果您无法从工作中获得学习的满足感，那么也许该是时候考虑一​​个开源项目了吗？

q303，我发现您的问题很有趣，并认为您可能会发现有关如何说服管理人员让开发人员解决技术债务的程序员问题，值得一读。

我认为通常是这样。可以理解，工作正常但性能欠佳的软件要比不工作的软件好得多。还有一种观点认为，“工作”的定义可能会根据每个人的看法和偏见而有所不同。当您实施新系统时，总会有人说他们觉得旧系统更好。而且，当您与开发人员交谈时，他或她很可能不愿承认曾从事糟糕的软件工作。