【困惑】为什么软件会越来越臃肿

nt941

本人对编程略知一二，按照我极其有限的知识，软件的更新版在资源的使用上应该比旧版更有效率，比如在内存的使用上，新版可能会解决旧版的内存泄漏等问题，而算法的改进更会使软件的效率（功能、性能和使用的硬件资源之比）产生质的提高，这样即使软件功能、性能有了提高，其消耗资源却可能保持不变甚至变得更少……
但事实上，我们看到几乎所有的软件（包括操作系统和应用软件）都是越来越庞大、臃肿，离我喜欢的轻灵、敏捷的软件风格越来越远……
当然，相信软件作者也在效率上花费了一定的心思，但在这方面花费的精力相对对功能和“外形”的追求恐怕还要差一些，至少，根据我的了解，软件工程现在更强调的是程序的可读性（清晰性、易懂性），而不是算法的先进性、程序编写的技巧性……（理由是现在的硬件已经很发达了，没必要为了节约一点内存等资源而牺牲可读性或“浪费”太多精力），这导致编写程序成了一件机械、繁琐的事情，以致有了“软件蓝领”这个词，这与软件业的“个人英雄”时代程序员们绞尽脑汁研究如何把程序写的最短而又功能最强、如何榨干硬件的最后一滴油形成鲜明的对比！
当然，这种现象和软件的规模越来越大、种类越来越多有关，但恐怕也与多数程序员心里已经放松甚至没有了“节约使用资源”那根弦有关。让我感到高兴的是，近年来看到越来越多的“迷你版”、“绿色版”软件出现，说明人们已经越来越意识到“硬件发展——》软件肆意使用——》硬件再发展——》软件更臃肿”这种无谓（一定程度上是）的技术更新的盲目性，认识到这个过程从某种角度来说是一种智力、资源浪费……
我的一个软硬件造诣都颇高的朋友曾经对我说过：“我怀疑微软和英特尔达成了一种私下里的协议，那就是不断更新自己的产品以互相促进其新品的销售——即使这种更新是不必要的”，我想微软和英特尔一定不会有这种协议或默契，但无意间造成了这个结果却是有可能的……
总之，我觉得程序员还是应该把软件的效率放在至少不比其他目标低的地位上，就像我们的生活越来越好了但是也不应该浪费一样……

哇，本来是吃饱了没事想上网玩一下，没想到写了这么多！我纯属胡扯，大家不要介意……

spare

你说的程序员是谁？象操作系统什么的，都是那些人在做，里面要做很多兼容性的东西，当然程序只会越来越大。
如果你做一个软件，要面向很多用户，做的用户越多，你越发现你的软件就越大，因为你要考虑的问题不是一个判断就解决的，可能要做成很多的样式在里面，程序不会越来越大，那才叫奇怪呢。

nt941

spare兄：
我自己也说自己是胡扯嘛。
软硬件肯定是要不断发展的，软件的体积的膨胀是个必然的趋势，我也没有异议，只是我觉得现在许多程序员已经不注意节约硬件资源了，写程序时只考虑功能能否实现，很多可以优化的地方都不优化……当然这是说的像我一样的低水平的程序员，可这样的程序员也不少啊，也会对整个软件业的发展方向产生影响啊……

hzzp

写程序的总想自己是最有能力的,最有兼容性的,所以@@@@@@@

fqgreen

许多程序员越来越依靠硬件计算速度的提高而不是语言的优化，这是个普遍的问题

nt941

我觉得我们传统的软件工程教材的指导思想有问题，就是过于强调程序的可读性、结构性，而忽视了效率。
近年来好像兴起了一种叫“敏捷软件开发”的软件工程思想，好像对程序员的个性、创造性的尊重有了很大的提高，不知是不是在鼓励提高软件效率……

nt941

QUOTE:

Originally posted by fqgreen at 2004-8-26 09:43 PM:
许多程序员越来越依靠硬件计算速度的提高而不是语言的优化，这是个普遍的问题

知我者，fqgreen兄也！我就是对这种现象有意见，才说了那些废话啊。

nt941

唉，说到底就是个软件效率问题，我的表达能力真差啊！

songxin

嗬嗬，楼主还年轻啊。

要知道，一行程序就是一行程序的钱啊。。。知道了这条真理，什么都能理解了。

fqgreen

做编程的人只得佩服，逻辑思维强，转行都比别的专业方便~~只可惜我的脑子~~~555555......

redsea

QUOTE:

Originally posted by nt941 at 2004-8-26 09:45 PM:
我觉得我们传统的软件工程教材的指导思想有问题，就是过于强调程序的可读性、结构性，而忽视了效率。
近年来好像兴起了一种叫“敏捷软件开发”的软件工程思想，好像对程序员的个性、创造性的尊重有了很大的提高， ...

只要软件公司的验收标准里面没有软件体积大小, 只有时间, 功能, bug 等, 那程序员管他体积大小呢.   至于执行速度, 应该有一些软件的一些部分应该是的验收标准的, 除此之外, 就没有了.

没有要求的东西, 干吗费那么大劲? 费那么大劲, 搞不好时间还超出了, 要被炒鱿鱼了, 呵呵.

Pentium 5

现在存储介质和传输速度已经不是问题，所以很多作者已经不重视优化了。当然，随着发展，体积膨胀也是必然的。

aznarble

QUOTE:

Originally posted by nt941 at 2004-8-26 09:23 PM:
本人对编程略知一二，按照我极其有限的知识，软件的更新版在资源的使用上应该比旧版更有效率，比如在内存的使用上，新版可能会解决旧版的内存泄漏等问题，而算法的改进更会使软件的效率（功能、性能和使用的硬件资 ...

软件更新版本的主要作用是：
1、提供更新更好的功能
2、修正以前版本存在的问题
3、对软件的运行进行各种优化和改善

通常，花在1和2方面的精力比3要多得多，这是综合各种因素考虑的一个结果。

aznarble

QUOTE:

Originally posted by nt941 at 2004-8-26 09:45 PM:
我觉得我们传统的软件工程教材的指导思想有问题，就是过于强调程序的可读性、结构性，而忽视了效率。
近年来好像兴起了一种叫“敏捷软件开发”的软件工程思想，好像对程序员的个性、创造性的尊重有了很大的提高， ...

程序的的可读性、可维护性、扩充性在较小规模和单兵作战中很难得到体现，但是随着代码量的增长（例如100000行以上）和参与编码人员（20人以上）的数量急剧增加的场合（尤其是使用软件配置管理实施版本控制和基线控制的场合），可读性、可维护性、扩充性绝对是第一需要的，为了维护可读性、可维护性、扩充性而记录的文档更是重中之重。

通常程序使用的算法越复杂，效率越高，在语句表现形式上就越复杂和晦涩难懂，在提高运行效率的同时，也容易增加缺陷产生的几率和修正的成本（尤其在涉及接口的场合，缺陷成本越到后期，越呈几何级数增长，甚至成为不可控制）。通常会权衡利弊，优先以可读性、可维护性、扩充性为主。

中国的很多程序员都会嘲笑印度企业的代码人员写出来的代码如何如何的简单和不懂算法（引自CSDN），然而恰恰是这种极其具备竞争性的可读性、可维护性、扩充性的代码（当然还包含卓越的过程控制能力、设计技术和测试技术）成就了印度软件业的飞速增长和辉煌。

至于极限编程XP，个人认为是基于快速原型的一种高度扩展，这个可以专门另说。

[ Last edited by aznarble on 2004-8-26 at 22:29 ]

aznarble

不知道楼主在这个帖子里的意思主要偏向于评论狭义的软件开发（专指编写代码），还是偏向于广义的软件开发（整个软件开发过程，尤其是多人集团式大规模软件开发），赫赫

nt941

楼上兄弟看来是高手。
我的意思主要是指编写代码，但编写代码的指导思想不就是软件工程吗？
就像上面某位朋友说的，现在除了“一些软件的一些部分”有对执行速度的要求外，一般软件验收标准里没有软件大小或效率的要求，而据我所知，有速度要求的地方一般多是访问后台数据库的场合，而这种场合保证速度的手段主要好像不是算法本身的优化，而是操作数据库的技巧……
总之据我在软件业短短的、浅浅的一点经历，我觉得很多程序员没有把编程当作一种艺术，而仅仅是当作“制造业”，他们往往不去深究程序的细节（能否提高资源使用率、能否缩短程序行数、能否提高执行时间……），而是靠CPU强大的运算能力和巨大的内存去换取功能的实现（所以我们常常见到软件对硬件的要求动辄是“256M以上内存”、“PIII 800以上CPU”等等），愚以为这样的做法是不负责任的、低效的（君不见，即使在专门网里还有多少兄弟在使用T20、600甚至更老的机器！所以程序员们把臃肿的程序推给强大的硬件去处理是在偷懒，俺以为）。当然，强调程序的可读性是软件规模膨胀导致的，但它往往成为程序员们不进行算法和程序优化的一个借口（尤其是在中国，程序员们被当作苦力用，公司的经济利益迫使他们必须尽快地拿出程序，在这种情况下让他们把写程序当作一种艺术，的确是有点强人所难）。
总之我认为目前中国的软件开发业存在些问题（可能国外也有吧），不知极限编程是不是对这种情况的反思的结果……

aznarble

QUOTE:

Originally posted by nt941 at 2004-8-27 08:06 AM:
楼上兄弟看来是高手。
我的意思主要是指编写代码，但编写代码的指导思想不就是软件工程吗？
就像上面某位朋友说的，现在除了“一些软件的一些部分”有对执行速度的要求外，一般软件验收标准里没有软件大小或效率 ...

赫赫，我不是高手，只是这几年在软件开发上的一些感受而已。
编写代码的指导思想，并不能代表整个软件工程，而只是软件工程中的一部分。
软件工程同普通的制造业既有区别，也有很大的联系，其中这个“人”的因素很多。

软件工程同样可以分为：做什么、怎么做和做的对不对这三个环节
做什么：需求分析
怎么做：设计和编码
做得对不对：测试和维护

编码能力，仅仅是作为怎么做这个环节的一部分体现。衡量编码能力的强大，对于个人来说，仅仅是对某些、某种开发语言的熟练程度、常用算法的熟练使用和精确理解、优化意识就可以了。但对于大规模集团式编码来说，在以个人能力为前提和基础之上，更需要严格的评审、统一的编码规范和高超的设计能力。而为了使严格的评审、统一的编码规范能够得到顺利的实施，代码的可读性、可维护性、可扩充性就变得相对重要了，但并不是否认了优化，两者是矛盾中的统一体。

有些跑题了，这里是软件使用，不是软件开发。我的发言就此打住。

nt941

谢谢aznarble兄指教！

timjan

关注中～～～～～～

climbmount

wintel联盟听说过吗？软硬件厂商狼狈为奸听说过吗？代码优化与缩短开发周期的矛盾听说过吗？

yukovan

总的来说，越底层的东西，对优化的要求越高。
恩 相比之下double e专业的人更关心优化，毕竟限制多了很多。
如果是cs专业的人么，对那些大规模的东西来说，代码的可读性、可维护性的确是非常重要的，在不影响可读性、可维护性的情况下做一些普通的优化就够了。
还有有很多用比较强大的工具做的二次开发，是不可能做什么彻底的优化的。

[ Last edited by yukovan on 2004-8-27 at 15:13 ]

nt941

请教：“double e”是何专业？

yukovan

electronic  engineering
随便举个例子5509dsp里边有64k的内存是一个指令周期可以访问两次的，剩下192k只能访问一次，那么怎么用就很有讲究了。
反正多熟悉熟悉硬件和汇编，对你的优化能力大有帮助。不过感觉对从事通常的软件业的人来说，优化并不是最主要的，优化带有很强的个人风格，而我感觉对大项目来说统一才是最重要的。

[ Last edited by yukovan on 2004-8-27 at 16:01 ]

aznarble

QUOTE:

Originally posted by yukovan at 2004-8-27 03:57 PM:
electronic  engineering
随便举个例子5509dsp里边有64k的内存是一个指令周期可以访问两次的，剩下192k只能访问一次，那么怎么用就很有讲究了。
反正多熟悉熟悉硬件和汇编，对你的优化能力大有帮助。不过感觉对 ...

同感同感，在“代码洪流”中，可读性、可维护性、可扩充性简直太重要了。

另外编程不仅仅是执行代码，注释和文档同样重要，甚至更重要。

nt941

谢谢诸位的指教。
另外， 我觉得软件变得越来越臃肿和软件厂商（程序员）盲目追求软件的功能全也有关，其实轻灵敏捷也是软件的一个很吸引人的地方。
比如本来小小的看图软件Acdsee现在把什么图像编辑等功能也加进来，导致软件体积的庞大和运行速度的降低，以至于现在很多人还是装老版的软件。其实软件的功能不在多而在精，看图软件做好看图功能就行了，如果需要图像编辑更多的人恐怕会去使用PS吧？
另外我觉得并非底层的软件优化的可能或必要性比“高层”软件大，而只是优化的方法不一样而已。比如同样需要排序操作，选用不同的排序算法会有不同的性能表现，这与上面兄弟说的内存操作是一个道理。

aznarble

QUOTE:

Originally posted by yichangzyr at 2004-8-27 08:50 PM:
是不是因为编序是按行数算钱的？

是的，行数折合人月，人月有单价。

yogibear

QUOTE:

Originally posted by nt941 at 2004-8-26 21:45:
我觉得我们传统的软件工程教材的指导思想有问题，就是过于强调程序的可读性、结构性，而忽视了效率。
近年来好像兴起了一种叫“敏捷软件开发”的软件工程思想，好像对程序员的个性、创造性的尊重有了很大的提高， ...

强调可读性，结构性（？？应该是模块化，追求最小的耦合度吧）是为了团队合作以及代码维护的需要。你写的代码不是给你一个人看的。

敏捷软件开发（是指agile program??)是为了更高效地满足用户需求的变化和适应越来越激烈的市场竞争。

采用那种方法要根据开发的产品的定位和实际需要来定。照抄《人月神话》里的，no silver bullet..

[ Last edited by yogibear on 2004-9-1 at 10:01 ]

sharpc8690

QUOTE:

Originally posted by nt941 at 2004-8-26 09:23 PM:
本人对编程略知一二，按照我极其有限的知识，软件的更新版在资源的使用上应该比旧版更有效率，比如在内存的使用上，新版可能会解决旧版的内存泄漏等问题，而算法的改进更会使软件的效率（功能、性能和使用的硬件资 ...

硬件和软件都在做大做强

功能丰富之后的弊端也不可避免

就像游戏

软件和硬件勾结的结局