在现代软件开发中,好的代码是不可能的吗?[关闭]


19

看起来,即使开发人员工具变得更加牢固和强大,编写好的代码也已成为挑战。即使这些工具功能更强大,代码质量也没有得到改善。我提出了两个重要因素,时间更少,项目更复杂。由于我们今天使用的工具功能更强大,因此更容易编写更复杂的代码,但是由于没有时间进行计划并且不回头,会降低代码质量,并增加错误和维护量。并不是说我们以前没有编写复杂的代码。是我们编写了更复杂的代码。

我的问题是:考虑到我们拥有更强大的语言和工具。

  • 为什么编写好的代码更加困难?
  • 因素,时间和复杂性是否对此有所贡献?
  • 方法是否正确实施?

我考虑的项目类型是具有较大复杂性和业务逻辑的企业应用程序。“好代码”的定义是个人的,请不要卡在“好代码”的解释中。

Answers:


34

正如DeMarco和Lister在大约20年前在Peopleware中所说的那样,失败的软件项目绝大部分不是由于技术挑战而是社会学问题而失败。在过去的几十年中,无论我们的工具有多大改进,这种情况都没有改变。

管理不善,不切实际的期望,未能找到合适的人选和/或不让他们去做他们的工作,因此未能留住他们;不适合软件开发工作的工作场所和工具;未解决的个人冲突;政治 ; 这些只是一些可能使项目从一开始就注定要失败的典型问题。

为什么编写好的代码更难?

我不太相信现在写好的代码确实比几十年前要难。实际上,与机器代码或汇编相比,我们现在主流的一切都更容易处理。只是我们可能需要生产更多。

仅仅是因为提及因素,时间和复杂性吗?

是的,随着我们工具功能的增强,可以实现的复杂性肯定会增加(并且会继续增加)。换句话说,我们不断突破界限。在我看来,这与30年前解决当今最大的挑战同样困难。

OTOH自从这个领域发展非常迅速以来,与30年前相比,现在存在着更多的“小”或“已知”问题。这些问题从技术上(应该)不再是挑战,但是...在这里输入上述格言:-(

此后,程序员的数量也大大增加了。至少我个人认为,经验和知识的平均水平已经下降,这仅仅是因为不断到达该领域的大三学生要比接受教育的大四学生要多得多。

方法是否没有正确实践?

恕我直言,当然不是。DeMarco和Lister对big-M方法论有一些苛刻的话。他们说没有方法论可以使项目成功,只有团队中的人可以。OTOH他们所赞扬的small-m方法与我们现在所知的“敏捷”非常接近,后者正在广泛传播(恕我直言是有充分理由的)。更不用说单元测试和重构这样的良好实践了,这在十年前还没有广为人知,如今,即使是许多毕业生,也都知道这些。


2
不要成为语法纳粹或除“不切实际”(在第二段中)以外的任何东西都不是一个词。我认为您的意思是“不切实际”。

我只能支持“初级”问题。我是其中的一员,我当然希望我有一位导师来帮助我。值得庆幸的是,今天有Internet提供,Amazon和SO也提供了帮助,但仍然...
Matthieu M.11年

1
+1:同样值得注意的是,由于工具/技术/方法的快速变化和增长,在一定程度上,我们每年至少都是初中生。经验只允许某些兽医比某些jrs更快地加快速度。
史蒂文·埃弗斯

我拒绝认真对待这一问题,除非我们没有正式的规则将漂亮的代码与丑陋的代码区分开。
shabunc 2012年

17

自温伯格(71)和布鲁克斯(72)以来,与在不切实际的期限内进行编码和处理技术债务有关的问题已为人所知。在此之前,很难在线上找到文献,但是我可以肯定的是,有旧的CDC,IBM和NASA报告都说过同样的话。


1
+对于“技术债务”和参考。
阿米尔·雷扎伊

10

我认为我们都有自己的想法和“良好规范”的门槛。但是,有一些共同导致的问题:

  • 错误使用“让它起作用,然后加以改进”的意思是说,我们留下了无效代码和同一方法的10个不同变体,其中每个变体在代码库中仅使用一次。这些东西似乎从来没有被清理过。
  • 缺乏时间和预算。客户希望在3个月内获得100个新功能,其中一些是不平凡的,并且他们不想在看不见的东西上花费任何金钱。
  • 缺乏关怀。让我们面对现实吧,一些开发人员比其他人更关心代码的外观和行为方式。有关示例,请参见第一个要点。
  • 我们真的不知道如何创建“好的代码”。我对好的代码的概念在不断发展。我十年前认为还不错的东西不再那么好了。
  • “好的代码”是一种价值判断。除了“有效”之外,没有已知的错误,其他任何关于好的代码的标准本质上都是一个见解。

最后,我认为追求更好比追求“好”或“最好” 更好。如果我们在那里看到最好的代码,我们会这样认出吗?


1
+1好点。通过“好的代码”,我并不是指完美的代码。完美的代码不存在。“好的代码”是一个不会让您头痛的代码,例如,它经过深思熟虑。
阿米尔·雷扎伊

1
关于“良好代码”成为移动目标的要点。但是,我不同意它只是一种价值判断。我相信干净的代码比混乱的代码更容易进行单元测试,扩展和维护,因此从长远来看更便宜。当然,由于在典型的西南软件项目中我们通常不对对照组进行双盲测试;-),对此只有传闻证据,而没有科学依据。
彼得Török

看起来我们当前对“好的代码”的定义都碰巧一致。但是,我看到了一些出色的API设计示例,这些示例使我的工作变得轻松很多-但该库没有单元测试。这并不意味着它没有经过测试,只是没有任何东西可以使测试自动化。我为此留了空间。
Berin Loritsch 2011年

8

为什么编写好的代码更难?

因为软件越来越多地建立在抽象层之上。每一种声称使开发更容易,更快的新技术只会增加开发人员需要理解的复杂性。现在,这些抽象可以极大地提高生产力,但是如果您不了解它们试图隐藏的内容,那么它会使软件更容易受到错误和质量下降的影响。


+1非常好,新工具可以提高生产率,这可能会导致更高的复杂性。
阿米尔·雷扎伊

1
+1。也称为“泄漏抽象法”。:)
Bobby Tables

6

在现代软件开发中,好的代码是不可能的吗?

确实,这是不可能的。但由于某种原因,您已经听说过。

绝大多数项目的范围远远超出了人脑的能力。这就是为什么人们提出抽象的想法的原因,即不断隐藏细节并爬上更高的抽象树,直到分支的密度(要处理的信息量)降低到可接受的水平。

我们已经做到了,解决了复杂性问题,但是并没有消除我们之前遇到的更大的问题。

对于我们来说,它仍然太复杂了。

为了创建高质量的解决方案,我们需要能够同时查看和理解所有内容,也就是说,所有模块都有很大的用途,而实现细节却很少。一次查看所有差异,在所有可能的情况下查看每段代码,并同时优化整个代码库。

我们将永远无法做到这一点。

如果我们做不到,我们将永远不会产生高质量的代码。

经理将看到少量的模块,但不知道每个模块的内部问题和局限性。

模块程序员将了解局部限制,但无法在更大的范围内对其进行优化。

没有办法在管理人员和程序员之间(甚至在程序员之间)交流理解。即使有,人脑的能力也无法应付。

除了继续尝试(徒劳的练习)之外,我们无能为力。让我们保持代码或多或少的可操作性,享受生活。


我喜欢这个答案,即使它不是以悲观,宿命论的语气写的……
Timwi

1
@Timwi:真的不悲观。本来可以减轻您的负担。:)

4

我否认你提出这个问题的前提。编写出色的代码比以往任何时候都容易,因此,我们正在解决的问题要比以前解决的困难得多。

我不想选择任何特定的供应商,但是将Windows 1.0与Windows 7进行了比较。后者包含的代码多出数千倍,但是两次崩溃之间的平均时间却增加了一百倍。从Windows 3.1开始,我们应该能够在Word文档中嵌入Excel电子表格,但是如今,它实际上或多或少地起作用了。

不希望陷入“如今的鸭子类型和虚拟机让您生孩子”的情绪,我建议您不知道在80年代写出好的代码有多难:TINY,SMALL和HUGE内存模型,覆盖,非租用OS呼叫(不停)。摆脱所有这些。


讨厌脱离话题,但我个人认为Windows 1.0至3.11实际上非常稳定,这可能是由于它们缺乏复杂性。Windows最崩溃的版本是95、98和ME。当然,在其他方面哪些版本是“好的”是另一回事。
Timwi'1

在小型计算机或大型机而不是低功耗系统上进行编码又如何呢?您参考的问题与Intel 8086模型有关...
Paul Nathan

@Paul,我最常涉及的是8086问题,因此在我看来,这些问题很大。但是,按现代标准,即使是在大型机上编写软件的工具也非常粗糙。与emacs相比,编辑器通常更接近edlin。直到1982年,我才在IBM硬件上使用NUROS(内布拉斯加大学远程操作系统)。使用“虚拟”打孔卡对作业进行编程和运行。而且,让我们不要忘记Y2K错误,这些错误主要是由于存储限制引起的。
查尔斯E.格兰特

2

现代应用程序比他们20 - 30年前,因为他们的环境是更丰富,更灵活更复杂。

DOS程序通常处于紧密循环中,等待用户的下一次按键,然后调用相应的代码,然后返回以等待下一次按键。

您无法完全使用鼠标的任何现代应用程序都存在严重的解释问题。而且事情可以以任何顺序发生,因为用户完全有可能键入,单击鼠标并继续键入,同时在应用程序中更新RSS提要时向用户显示最新的输入内容。

与您只需要考虑用户的按键相比,所有这些多任务处理本质上要复杂得多。这使得编写真正好的代码变得更加困难。

希望当研究人员从开发人员的角度弄清楚我们如何使多任务程序更易用时,这可能会有所缓解,但就目前而言,我们对每个人都想做的好,但仍不了解如何做它。


+1“现代应用比20
Amir Rezaei

2

在我看来,软件已经扩展到可以填充可用的处理器速度,内存,磁盘和编程时间。可以断言那是因为该软件可以完成更多的工作。好吧,我敢肯定它确实可以做得更多,但不足以证明膨胀。

我认为有一个古老的科学定律值得记住:

自然讨厌真空。

弗朗索瓦·拉贝拉斯(法国和尚和讽刺作家1494-1553)


1

实际上,我认为在过去的十年中,编写好的代码(即按预期工作且可维护的程序)变得更加容易。现在可用的工具更好,库更成熟和全面,硬件变得更快,因此我们不必使用优化技巧。

那我们为什么不呢?

IMO的主要原因是我们不断寻找滥用事物的方式和借口。我们没有采用老式的,简单的,可能很无聊的方式(例如创建Windows可执行文件),而是突破了可能的界限,而寻找例如重新创建诸如PhotoShop之类的内容作为Web应用程序的方式。为什么?因为我们可以。或者至少我们是这样认为的。


1
我不同意这样的含意,即应避免创新,绝不应该淘汰老式的技术或方法。最好停止编写任何程序,然后使用我们拥有的...
Timwi

Timwi:我并不是反对创新。这就是编写好的代码似乎如此困难的原因。
user281377 2011年

1

上一次有人什么时候不编写漏洞利用程序或研究使用汇编程序搞砸了(不算内核黑客和ASIC专家)?在C核心库中发现了多少个bug?几乎没有。我要说的是,人们有能力编写出色的代码。更好的工具和语言只会减少它的“必需”而更多的“可选”。并不是说我认为我们所有人都应该编写出非常糟糕的代码,但是当我想到复杂的逻辑构造时,没有人会梦想在汇编中编写带有哈希数组的东西。必须使用一种“更好”的方式来处理逻辑,而不是使用复杂的构造。即使代码很漂亮,有时方法也不是那么优雅。我认为这可以解决您提到的问题。好的代码并非总是组织得很好,


嵌入式系统专家编写了大量的汇编。
Paul Nathan

@Paul Nathan True
RobotHumans 2011年

0

我认为这是因为更好的工具和更快响应速度的计算机意味着我们希望每单位时间的最终产品复杂性比几年(或几十年)要多得多。因此,应用程序的复杂性不断提高,我们对合理的生产力水平的假设也在不断增长。

在我工作的地方,开发人员总是很着急(因为总是有更多客户想要的东西,然后他们才有空)。因此,只需进行最少的编辑即可复制大量代码块,而无需付出任何努力来真正理解它们。当然会出错。我只是看到一个错误得到修复,一个开发人员复制了一些我优化过的代码,却没有意识到使优化有效的假设并不正确。

所有这些都归结为内部(我们自己的期望)以及我们组织的期望。我们尝试在尽可能短的时间内做尽可能多的事情。不可避免地会导致错误。

此外,计算机的响应能力还鼓励用户快速进行快速编辑,然后进行编译和测试。在过去的旧时代(例如35年前),周转非常缓慢,以至于我会打印出代码(然后是打孔卡),然后在提交卡片组之前对代码进行手动遍历。现在,我们只需编辑编译和执行。因此,通过有条不紊的代码演练,我们会发现很多错误,现在我们依靠编译器和/或单元测试套件来捕获它们。


听起来像一家年轻的公司,但尚未得知最便宜的公司第一次就做对了……

Thorbjorn:令人惊讶的是它已经存在了近三十年。它实际上做得很好。当然,有些业务模型可以很好地响应客户的需求(有些),而有些则非常注重质量。真的很难兼得。
欧米茄半人马座

0

人们在产生好的代码方面如何变得更糟?

例如,如果您使用.NET和C#之类的语言(并且我意识到它不是唯一的平台/语言),我会认为由于Visual Studio中许多事情的自动化,良好的编码变得非常容易。环境。

如果有的话,我们现在拥有非常复杂的IDE能够指导我们完成编码和开发过程的事实,使得“好代码”更易于实现。

程序员现在可以专注于实际生成良好的结构,而不必花费大量时间仅输入方括号,大括号和新行并记住方法调用和类名。

我的两分钱。



-2

代码质量没有提高

请不要卡在“好代码”的解释中

伟大的逻辑重言式。

代码不会变得更好,因为人们一直在移动“好”的定义。

如果您不能讨论“好的代码”,那么您将无法进行比较,并且您真的无法决定它是否是“挑战”。


对我来说,“好的代码”可以减少错误的数量。现在,可以通过许多方式来实现。
阿米尔·雷扎伊

@Amir Rezaei:““好的代码”的定义是个人的”。“'好的代码'可以减少错误数量”。请仅选择一个定义,并更新您的问题以仅包含一个定义。
S.Lott

好吧,“好的代码”可以减少错误数量,这是个人的“好的代码”概念。我认为每个人都知道何时需要清理项目。
阿米尔·雷扎伊

@Amir Rezaei:这是我的观点。如果您不能(或不会)在问题中定义“好”,那么我们就无法进行比较。您可以声称错误数量相同。还有一些人可以声称错误的成本下降了。另一个人可以声称由于计划错误而导致的业务风险上升。没有对“好”的单一定义,我们都会谈论不同的事情。请更新问题。
美国洛特

良好的代码:它经过编译,通过测试,获得用户认可并投入生产。只是希望没人愿意改变它。
JeffO 2011年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.