看起来，即使开发人员工具变得更加牢固和强大，编写好的代码也已成为挑战。即使这些工具功能更强大，代码质量也没有得到改善。我提出了两个重要因素，时间更少，项目更复杂。由于我们今天使用的工具功能更强大，因此更容易编写更复杂的代码，但是由于没有时间进行计划并且不回头，会降低代码质量，并增加错误和维护量。并不是说我们以前没有编写复杂的代码。是我们编写了更复杂的代码。
我的问题是：考虑到我们拥有更强大的语言和工具。
我考虑的项目类型是具有较大复杂性和业务逻辑的企业应用程序。“好代码”的定义是个人的，请不要卡在“好代码”的解释中。
Answers:
正如DeMarco和Lister在大约20年前在Peopleware中所说的那样，失败的软件项目绝大部分不是由于技术挑战而是社会学问题而失败。在过去的几十年中，无论我们的工具有多大改进，这种情况都没有改变。
管理不善，不切实际的期望，未能找到合适的人选和/或不让他们去做他们的工作，因此未能留住他们；不适合软件开发工作的工作场所和工具；未解决的个人冲突；政治 ; 这些只是一些可能使项目从一开始就注定要失败的典型问题。
为什么编写好的代码更难？
我不太相信现在写好的代码确实比几十年前要难。实际上，与机器代码或汇编相比，我们现在主流的一切都更容易处理。只是我们可能需要生产更多。
仅仅是因为提及因素，时间和复杂性吗？
是的，随着我们工具功能的增强，可以实现的复杂性肯定会增加（并且会继续增加）。换句话说，我们不断突破界限。在我看来，这与30年前解决当今最大的挑战同样困难。
OTOH自从这个领域发展非常迅速以来，与30年前相比，现在存在着更多的“小”或“已知”问题。这些问题从技术上（应该）不再是挑战，但是...在这里输入上述格言:-(
此后，程序员的数量也大大增加了。至少我个人认为，经验和知识的平均水平已经下降，这仅仅是因为不断到达该领域的大三学生要比接受教育的大四学生要多得多。
方法是否没有正确实践？
恕我直言，当然不是。DeMarco和Lister对big-M方法论有一些苛刻的话。他们说没有方法论可以使项目成功，只有团队中的人可以。OTOH他们所赞扬的small-m方法与我们现在所知的“敏捷”非常接近，后者正在广泛传播（恕我直言是有充分理由的）。更不用说单元测试和重构这样的良好实践了，这在十年前还没有广为人知，如今，即使是许多毕业生，也都知道这些。
自温伯格（71）和布鲁克斯（72）以来，与在不切实际的期限内进行编码和处理技术债务有关的问题已为人所知。在此之前，很难在线上找到文献，但是我可以肯定的是，有旧的CDC，IBM和NASA报告都说过同样的话。
我认为我们都有自己的想法和“良好规范”的门槛。但是，有一些共同导致的问题：
最后，我认为追求更好比追求“好”或“最好” 更好。如果我们在那里看到最好的代码，我们会这样认出吗？
为什么编写好的代码更难？
因为软件越来越多地建立在抽象层之上。每一种声称使开发更容易，更快的新技术只会增加开发人员需要理解的复杂性。现在，这些抽象可以极大地提高生产力，但是如果您不了解它们试图隐藏的内容，那么它会使软件更容易受到错误和质量下降的影响。
在现代软件开发中，好的代码是不可能的吗？
确实，这是不可能的。但由于某种原因，您已经听说过。
绝大多数项目的范围远远超出了人脑的能力。这就是为什么人们提出抽象的想法的原因，即不断隐藏细节并爬上更高的抽象树，直到分支的密度（要处理的信息量）降低到可接受的水平。
我们已经做到了，解决了复杂性问题，但是并没有消除我们之前遇到的更大的问题。
对于我们来说，它仍然太复杂了。
为了创建高质量的解决方案，我们需要能够同时查看和理解所有内容，也就是说，所有模块都有很大的用途，而实现细节却很少。一次查看所有差异，在所有可能的情况下查看每段代码，并同时优化整个代码库。
我们将永远无法做到这一点。
如果我们做不到，我们将永远不会产生高质量的代码。
经理将看到少量的模块，但不知道每个模块的内部问题和局限性。
模块程序员将了解局部限制，但无法在更大的范围内对其进行优化。
没有办法在管理人员和程序员之间（甚至在程序员之间）交流理解。即使有，人脑的能力也无法应付。
除了继续尝试（徒劳的练习）之外，我们无能为力。让我们保持代码或多或少的可操作性，享受生活。
我否认你提出这个问题的前提。编写出色的代码比以往任何时候都容易，因此，我们正在解决的问题要比以前解决的困难得多。
我不想选择任何特定的供应商，但是将Windows 1.0与Windows 7进行了比较。后者包含的代码多出数千倍，但是两次崩溃之间的平均时间却增加了一百倍。从Windows 3.1开始，我们应该能够在Word文档中嵌入Excel电子表格，但是如今，它实际上或多或少地起作用了。
不希望陷入“如今的鸭子类型和虚拟机让您生孩子”的情绪，我建议您不知道在80年代写出好的代码有多难：TINY，SMALL和HUGE内存模型，覆盖，非租用OS呼叫（不停）。摆脱所有这些。
现代应用程序是比他们20 - 30年前，因为他们的环境是更丰富，更灵活更复杂。
DOS程序通常处于紧密循环中，等待用户的下一次按键，然后调用相应的代码，然后返回以等待下一次按键。
您无法完全使用鼠标的任何现代应用程序都存在严重的解释问题。而且事情可以以任何顺序发生，因为用户完全有可能键入，单击鼠标并继续键入，同时在应用程序中更新RSS提要时向用户显示最新的输入内容。
与您只需要考虑用户的按键相比，所有这些多任务处理本质上要复杂得多。这使得编写真正好的代码变得更加困难。
希望当研究人员从开发人员的角度弄清楚我们如何使多任务程序更易用时，这可能会有所缓解，但就目前而言，我们对每个人都想做的好，但仍不了解如何做它。
实际上，我认为在过去的十年中，编写好的代码（即按预期工作且可维护的程序）变得更加容易。现在可用的工具更好，库更成熟和全面，硬件变得更快，因此我们不必使用优化技巧。
那我们为什么不呢？
IMO的主要原因是我们不断寻找滥用事物的方式和借口。我们没有采用老式的，简单的，可能很无聊的方式（例如创建Windows可执行文件），而是突破了可能的界限，而寻找例如重新创建诸如PhotoShop之类的内容作为Web应用程序的方式。为什么？因为我们可以。或者至少我们是这样认为的。
上一次有人什么时候不编写漏洞利用程序或研究使用汇编程序搞砸了（不算内核黑客和ASIC专家）？在C核心库中发现了多少个bug？几乎没有。我要说的是，人们有能力编写出色的代码。更好的工具和语言只会减少它的“必需”而更多的“可选”。并不是说我认为我们所有人都应该编写出非常糟糕的代码，但是当我想到复杂的逻辑构造时，没有人会梦想在汇编中编写带有哈希数组的东西。必须使用一种“更好”的方式来处理逻辑，而不是使用复杂的构造。即使代码很漂亮，有时方法也不是那么优雅。我认为这可以解决您提到的问题。好的代码并非总是组织得很好，
我认为这是因为更好的工具和更快响应速度的计算机意味着我们希望每单位时间的最终产品复杂性比几年（或几十年）要多得多。因此，应用程序的复杂性不断提高，我们对合理的生产力水平的假设也在不断增长。
在我工作的地方，开发人员总是很着急（因为总是有更多客户想要的东西，然后他们才有空）。因此，只需进行最少的编辑即可复制大量代码块，而无需付出任何努力来真正理解它们。当然会出错。我只是看到一个错误得到修复，一个开发人员复制了一些我优化过的代码，却没有意识到使优化有效的假设并不正确。
所有这些都归结为内部（我们自己的期望）以及我们组织的期望。我们尝试在尽可能短的时间内做尽可能多的事情。不可避免地会导致错误。
此外，计算机的响应能力还鼓励用户快速进行快速编辑，然后进行编译和测试。在过去的旧时代（例如35年前），周转非常缓慢，以至于我会打印出代码（然后是打孔卡），然后在提交卡片组之前对代码进行手动遍历。现在，我们只需编辑编译和执行。因此，通过有条不紊的代码演练，我们会发现很多错误，现在我们依靠编译器和/或单元测试套件来捕获它们。
代码质量没有提高
请不要卡在“好代码”的解释中
伟大的逻辑重言式。
代码不会变得更好，因为人们一直在移动“好”的定义。
如果您不能讨论“好的代码”，那么您将无法进行比较，并且您真的无法决定它是否是“挑战”。