极乐殡葬网

德泰诺科技

世纪兴

建站资讯

沈阳软件开发究竟难在哪?

沈阳软件开发拥有更好的编程语言将使软件开发变得更加容易和高效,在汇编或 Fortran 时代,这种观点无疑是对的。但是,语言现在已经足够好,可以在其他地方找到主要的困难,从而找到改进的机会。编程仍然很困难,但是由于与所使用的语言无关的原因。

当你有一系列连续任务时,将适用阿姆达尔定律。它告诉我们,仅通过加速一项任务就可以加快整个系列任务的执行速度有一个严格的限制。假设沸水需要10分钟,然后煮意大利面又需要10分钟。如果你想找到一种更快煮沸水的方法,那么你晚餐的时间绝不会少于面食所需的10分钟。强大的燃烧器永远不会提供超过2倍的加速比。通用公式是,如果某件事占总时间的p部分,则你永远无法获得大于1 /(1 – p)的加速比。如果一部分工作占用了90%的时间,则p = 0.90。将零件优化为零时间将使整体工作速度提高1 /(1 – 0.90)= 10倍。阿姆达尔定律的关键在于,要获得的最佳加速受要优化的零件尺寸的限制。由于许多原因,编程很困难。为了简化,我们可以将使难以处理的事情视为必须顺序执行的任务。毕竟,人类不是很擅长多任务处理。在任何给定的时间点,你都在使用构建工具,阅读文档,编写代码或参加会议。或者编写代码而不是关注会议。你一次应对一个挑战,因此阿姆达尔定律大致适用1。如果你设法将构建时间减少到零,那么你的项目只会更快地完成。你的生产率仍然受到完成项目所需的所有其他因素的限制。将程序计划转换为计算机可以运行的内容曾经非常困难。很久以前,这涉及到将程序一直转换为1和0并繁琐地输入它们。我不知道这花了多少时间,但是为了论证(和简单的数学运算),我们假设这是编程工作的90%。这意味着更好的告诉计算机做什么的方法(例如Python)可以使编程效率提高10倍之多。但是现在我们有了更好的语言。告诉计算机做什么的时间更少-我们有望实现生产率的提高。将程序计划转换为代码不再需要90%的时间。现在(再次为辩论起见)仅需要10%的时间。这意味着你现在可以通过简化该部件而获得的最大改进仅为1.11倍。这是过去2倍的加速倍数的81倍!这是因为其他90%的软件开发工作都是艰巨的任务,而更好的编程语言不会(直接)使这项工作变得容易。

我的意思是说,编程很难与编程语言无关。为了理解其中的原因,我们先假设不需要操心与计算机相关的东西,你只需要告诉你的朋友要做些什么。你不能作弊,不能让他们依赖常识性的东西,你必须替他们做出所有的决定。你会发现你需要很长时间才能解释关键的背景信息。你的朋友将需要了解程序可以在现实世界中使用的东西(“好,所以我们将这些东西称为捆绑商品,你可以在其中购买捆绑商品中的所有产品并获得折扣”)以及你所拥有的东西决定程序应该执行的操作(“如果用户只返回捆绑包中的一个…”)。必须解释首字母缩写词和术语,还必须讨论外部因素(“制造商规定我们销售产品的价格是非法的,但并非由他们决定我们为产品做广告的价格,所以……” )。你的朋友需要知道所有可能出现的情况,有大量的小细节需要处理,例如用户不能在购物车中输入负数个产品。用户可能会尝试做出所有可能的行为,会发生各种可能的事情,例如包裹在运输过程中弄丢了,你会发现有大量的边界情况需要告诉你的朋友。用几种不同的方式向你的朋友解释所有这些困难。首先,你必须了解与该计划相关的所有实际细节(有些产品,它们可能缺货,可以打折,等等)。其次,你必须了解所有有关程序在每种可能情况下应执行的操作的决定。第三,你必须以你的朋友会理解的方式来传达所有这些信息。这意味着你需要充分组织思想以使它们易于消化。如果你撰写论文或博客文章,你将知道传达大量信息并非易事!请注意,到目前为止,没有任何工作涉及到任何计算机,也没有涉及编程语言。理解世界如何运转,知道程序应该做什么以及组织这些想法的表达都是艰巨的任务。


沈阳软件开发描述与规范:这里有一个容易陷入的心理陷阱。很容易错过描述和指定事物之间的区别。有了描述(“红色汽车”)后,你可以测试事物是否符合该描述(“是红色,但不是汽车”),但不足以告诉你如何制造一辆汽车。这就是规范的目的。创造事物需要做出很多决定。如果要记下每个决策的结果,则将有一个(杂乱无章的)规范。编写程序需要你做出这些决定,因此仅凭描述就行不通-你需要一个规范。当你有描述(“它应该列出文件”)时,很容易认为这是一个规范,因此应该很容易告诉计算机执行该操作。但是你遗漏了需要做出的数百万个微小决定(“文件应以什么顺序列出?它们应该各自按行吗?”)。当你去编写程序时,你不得不面对任何地方,你的规范实际上只是描述。计算机将不仅仅接受“绘制矩形”,它会想知道它应该在屏幕上出现在哪里,应该有多大以及用什么颜色制作。将想法转化为代码往往会揭示你尚未做出的决策。做出这些决定是一项巨大的努力。很容易就将这种努力的来源弄错了,将其归咎于编程语言,而不是承认一个简单的事实,即仅给出描述就很难创建规范。


回到计算机上:开发软件不仅仅是了解软件应该做什么并将思想转变为代码。计算机本身会带来程序必须解决的自身问题。你的程序必须在真实的硬件和网络上足够快地运行。该程序可能需要处理机器故障。工具和协议的复杂性给该领域增加了更多的问题。这些不是由向计算机解释做什么的过程引起的困难,它们只是需要解释的更多事情。你还必须脑子里运行程序的一部分。有时逻辑流就像故事一样容易遵循,但是有时,事件的顺序和要跟踪的状态会完全淹没你所能适应的东西。正确了解程序的详细信息–或在不正确的情况下进行修正–需要了解各种情况下程序本身的状态。编写代码可以使你当前对程序工作方式的想法具体化。但这并不意味着程序将停止更改。你会发现错误,需要新功能,并且需要更改现有行为。该程序的组织方式最初可能是起作用的,但这并不意味着它将永远是正确的结构。当你不可避免地发现自己并非千篇一律时,你最终将花费时间进行一些尝试,包括预测未来和清理剩下的混乱情况。


团队合作:如果你不只是自己编写程序,就必须与其他人一起工作。这带来了全新的挑战。项目的所有人员必须以某种方式组织起来,每个人都有自己的工作要做。你不希望其他人妨碍彼此,所以你必须分担工作。建立合理的分工需要了解程序的结构。康威定律适用。如果你有多个团队,事情会变得更加艰难。每个团队都有不同的目标,因此将针对不同的事物进行优化。一个对其他团队有利的决定可能会阻止你完成工作。从你那里了解桌子对面人员的位置并找到一个好的妥协是一项艰苦的工作,但需要做。在大型项目中,没有一个团队了解整个事情,更不用说一个人了。但是,你仍然必须弄清楚如何设计系统的各个部分并使这些部分组合在一起。这比你自己创建整个设计要困难得多。即使从实际编写代码中删除了几个步骤,与人打交道也是开发软件中非常重要的一部分。


如何打破?我们可以寻找阿姆达尔定律之外的方法。如果单独任务的速度不是完全独立的-如果你可以通过优化另一个任务来加快任务的速度-那么希望技术解决方案可以有所帮助。更好的语言和开发环境可能是我们需要的漏洞。如果允许程序由更少的人编写(例如,两个人代替一个团队,或者一个团队代替一个部门),则可以大大减少组织的开销。如果你亲自在该接口的两边编写所有代码,则无需开会就可以确定该接口。生产率的提高不仅会降低编写代码的成本,而且还会以降低其他任务成本的方式改变工作的形式。就是说,这条路可以走多远是有局限性的,因为一个程序员无法将企业所做的一切都融入他们的头脑。迭代速度是另一个杠杆。为了编写程序,你需要了解领域和要做出的决定。为了建立这种理解,你可以将所有细节收集到脑海中,然后将其安排到心理模型中。这是执行此操作的一种方法,但可能不是最有效的方法。另一种方法是基于明显的细节构建一个小的心理模型。然后,从该模型创建一个小程序,以将想法与现实进行对比。根据提供的反馈进行迭代,每次创建更丰富,更准确的模型。对于人们实际学习的方式,这似乎更好。为了使这种方法有效,你需要能够测试想法并快速获得反馈。理想状态是键入完成后,新代码便开始运行。对于一种更具表现力的语言会有意义地提高生产力,我并不特别乐观。我仍然希望能够有一个更好的开发环境。如果我们有更好的工具来理解现有代码,更快的开发迭代周期以及不太繁琐的“劳动”工作,那么它可能会有意义地改变软件开发的完成方式,而不是减少收益。


×