如果流利的编码员无视良好做法，那么他的流利程度对他不利吗？[关闭]

我正在开发一个相当大且有错误的应用程序-由于它的编写方式（我将为您提供详细信息，但是在您可以想到的大多数领域中它都违反了规则），如果不进行重大重构就几乎不可能开发它。

该应用程序的重要部分是由实习生，n00bs等创作的；但是在高级开发人员中也有一个程序员，尽管谦卑，但他留下的代码也是可疑的，也许还是以不同的方式。

当然，他的代码往往会在大多数时间完成工作，但通常是很隐秘的，需要重新发明轮子（例如，使用大型自定义方法来完成相当普通的SQL db备份）等。基本上，不必要的混乱以及大量的过度设计

让我想到，如果不是其他素质的陪伴者，作为一名高技能的编码员（我故意不使用“开发人员”一词，假设它表示更多的技能）实际上可能是有毒的。

假设这是真的，我能想到的一些原因是：

• 如果您轻松编写代码，则感觉（或实际上实际上是短期内）可以更快地就地找到自己的解决方案，而无需使用库，既有功能等。
• 如果有足够的经验来轻松维护复杂程序的心理形象，则不太倾向于将其拆分为模块，层等。

因此，我的观点是，如果一个流利的编码人员恰好是一个不良的开发人员，那么他们的流利性不仅不能弥补后者的不足，反而会带来更大的危害。

你对那个怎么想的？是真的吗（如果有，程度如何）？

如果您轻松编写代码，则感觉（或实际上实际上是短期内）可以更快地就地找到自己的解决方案，而无需使用库，既有功能等。

是。我一直是那个家伙。而且我了解到这是一件可怕的事情。

对您来说一切都很好，您不必学习新知识。

但是您团队的其他成员呢？他们变得非常依赖你。他们无法在Google上搜索“ Clive's Quicky ORM”以获取有关您编写的对象关系映射器的帮助。

然后是他们需要雇用新人的一天，他们无法寻找具有Clive Quicky ORM经验的人。

最后是离开的那一天，有人注意到您的ORM中存在错误。它将在那里，因为您没有整个人测试和修复产品的社区。

是的，学习Hibernate可能比编写轻量级内容花费更多的时间。但是，这样做的好处实在太大了，恕我直言。

•如果您轻松编写代码，则感觉（或实际上实际上是短期内）可以更快地在现场找到自己的解决方案，而不必求助于库，已有功能等。

精通语言，但不熟练。甚至还不是一个强大的编码器。它只是在完善一项技能（语言知识）而让另一项变得生锈（图书馆知识）。反之亦然，但更容易发现。

•如果有足够的经验来轻松维护复杂程序的心理形象，则不太倾向于将其拆分为模块，层等。

那只是伪装成一种技能的懒惰。将您正在积极从事的工作放在脑子里并不需要太多的努力。找到合适的接缝并沿着它们拆分代码确实需要技巧。那些说将所有内容都放在一个地方更快或更佳的编码人员通常看不到要拆分的项目。

只需确保这不是因为他一直在“如果您的键盘没有被点击，您就没有工作”的环境中工作。我们都回顾代码，想知道我们在想什么。另外，这家商店是否在重构其代码？那可能是他没有得到的奢侈。

但是，我们确实需要脱离我们的第一个想法（您可以坐下并提出建议），并做更多的规划，研究和思考。解决每个小问题的诱惑很诱人，整个项目都被这种做法打乱了。没有人愿意付钱给人们修理那些“不会坏”的东西，所以为什么要重构。

编辑：让我们确保不惩罚那些碰巧知道答案的人。有些人会流利，并能快速编写出良好的代码。关键不是要这样解决所有问题。

100％。

愤世嫉俗的看待方式是，这类编码器实际上使大多数开发人员都在工作，并修复了一些根本性的错误，以至于您可以花数千个开发人员的时间而不必半途而稳定，灵活，安全，模块化或[您最喜欢的软件属性]系统。这些系统具有很多特质，因此即使已经拥有95％的功能并拥有一个活跃的社区，迁移到其他对象的想法也被认为是荒谬可笑的。

简而言之，流利的编码员所造成的损害要比成群的竞争者多得多，但通常要付出多年的代价。他们通常只是干自己的工作（由其他人定义）。

如何判断您是开发人员还是编码人员？我想这是不可能的，但是每次您找到一种在不降低质量的情况下简化代码的方法时，您就朝着启蒙迈出了又一步。

您描述的问题基本上是NIH（“在这里未发明”）-还有其他症状吗？

有时可以通过小组讨论来解决NIH，尤其是将其隔离到一个或两个人的情况下（“ Joe在使用标准库进行SQL备份方面有一定经验-您怎么看，Joe？”）。与您直接去找那个人并说“嘿！使用标准库，虚拟的！”相比，这可能会减少对抗性。:)

经历过您的处境和造成类似情况的我都理解您的无奈，但我认为您的问题的答案是平淡的“否”。流畅性不能保证程序员会产生可维护的代码。由于荒谬的预算和时间限制，组织经常迫使程序员提供设计和实施不佳的软件。流利的程序员可能会偷工减料，只有程序员关心的是交付客户确实关心的东西。显然，这在实践中并不好，但是可悲的是，大多数程序员在其职业生涯的某个时候都必须面对这一现实。流利的程序员也有可能只是懒惰或自满。我能说一口流利的英语，但是使用语会更轻松，更有趣。

至于使用他人的代码或滚动自己的论点，我认为这实际上取决于使工作最出色的原因。如果“最佳”意味着在两周内交付六个星期的项目，有时“最佳”不会考虑样式和可维护性。这就是我们重构和完善的原因。另外，开发人员必须了解第三方代码方面的可用内容，并且他们必须知道如何使用它，并相信它可以正常工作并得到适当的支持/维护。鉴于有成千上万的可选框架，库和API用于使用这些东西的任何流行开发范例，最终可能会花费更多的时间，精力和压力，而不仅仅是滚动自己的。此外，我确实发现了第三方代码无法完全满足我的需要的情况-就是在这种情况下

我在那条船上（遗留的流利地编写代码），而且我自己流利的类型已有一段时间。

“快速而肮脏的”解决方案的最大障碍总是在以后需要添加更多内容时。当您需要更多功能时。没有结构，您只能做很多事情。在那之后，它崩溃了，重新安排它的成本很高（虽然令人满意，但并没有得到真正的赞赏）。

基本上，您必须警惕任何可能成为“可行解决方案”的问题，这些问题随时可以由急切的销售人员出售。原来是“还没准备好！-可以用，不是吗？” 难题。