程序设计究竟是做什么事情的

面向功能强调数据在计算机中功能,程序架构的基本结构是函数。对于数据本身表现的它在客观世界的意义必需在函数中用标志来进行判断。函数重载,就是对同一功能不同概念的管理方法。是一种先功能再概念的思考问题的方法。

面向对象强调数据在客观世界所表达的意义,程序架构的基本结构是类。对象是程序中对客观存在的事物的数据抽象,与客观存在的事物一对一的映射,对象是类的实例化,类是对象的定义是概念性的抽象。我想接口就是对不同事物中相同功能(行为)的管理,以便于程序架构。

比如。咬是一种行为,狗能咬,人能咬,在客观世界中有张嘴的就能发生咬这个行为,
如果你先分析人,狗等再从人,狗等这些看到共同的行为咬就是一种面向对象的分析法,面向过程的反向分析法。反过来,先分析咬,再分析咬是谁发出来的这就是面向过程分析法,面向对象的反向分析法。

数据结构|设计模式,就是基于不同语言的基本结构为了方便架构的所产生的不同技术。如果你是基于函数来架构就是面向过程(功能)的设计,基于类(概念)来架构就是面向对象的设计。

你不管是用什么语言来写代码,不管向种方式来架构,在的计算机体系来说计算机依然只能是二进制数据,只是经过不同的数据翻译才能在人机交互的时候显是出我们能看得懂的、有意义的信息。软件设计核心总会是数据及它本身在客观世界中的意义的管理方法论。

而对我们这些应用别人半成品来开发的中国人,很多技术就变得多余。从B/S结构来说,我们都是B端.从C/S结构来说我们都是C端,描述是数据意义,软件的功能开发,软件的肉体。S端才是做数据管理,软件的效率的开发,软件的灵魂。

[该贴被bookview于2008-08-29 15:00修改过]

楼上最后一段有些极端: 而对我们这些应用别人半成品来开发的中国人,很多技术就变得多余....

站在前人的基础上思考创新,才是灵魂,不要心里老是嘀咕别人给你打包里面的东西,总是想自己也来弄个,人类文明是共同的,老外不至于因为使用了你的四大发明,心理总是嘀咕不踏实。创新才是灵魂。

我只不过是个做点业务软件的人,我干嘛要从头弄一个基础设置库再来开发呢?完全可以通过购买等途径使用已经是产品级别的东西。只有业务才是我自己的。
没错我觉得acegi不方便,但我不必再开发一个认证管理的东西来支撑我的业务,只要改改acegi,拿点现成的零件出来就好了。
要是什么东西都得亲力亲为才能用,这个过程可以无限下降到电脑零件的级别,先要生产出一批零件,然后弄个CPU内存等等装配一台电脑,然后开发个操作系统,再整个应用服务器出来,最后架设企业应用。有现成的拿来用就是了,对我来说只有企业应用才是一个个完全不同的,显然也不可能相同,对企业来说也是只有企业应用才是他们最后想看到的,他们并不想知道我们在用什么,只要我们做的能够满足他们提出的这样那样的随时变化的条件就行了,我想总不至于先分析一下他们的需求,开发一个专门处理他们业务的CPU,等到需求变化时再开发另一个,性能是上去了,时间没了,市场没了,钱也没了。

这是事实,为什么现在写代码的门槛越来越低,写出来的东西自己都不知道是怎么实现的。一个从来没接触过的设计的高中生都能经过短暂的培训,就能用一个千锤百炼过的框架写出完成功能的配置文件,特别在开发商业化的软件,这些东西也就行了,其他的技术不是多余是什么。
又没有说使用达人门的东西来写代码不好,我只是想说说我们虽然能写出看起来还很好用的软件,其实骨子里对设计的本质的了解还差的远呢,我们只是站在程序设计的一个点上,是用别人的设计做设计。又没说在前人的基础来创新不好,创新是一个语言功能进一步强大,更加有生命力必需具备的,一个语言无法创新的或者没人愿意为他来创新的话基本这个语言也就完了。
当然自己没有用到知识不是在程序设计的整个过程中没有用,而是在我们这环节中不必要用,用的话就是复杂化程序设计。事情的成功是环环相扣的,存在就是合理的,现在的数据库管理系统都发展到这么成熟了,为什么在有些时候用文件来存储数据依然是最好的选择呢?当然当你选择了你的选择就会约束你处理问题的方式,约束你的思考方向。
[该贴被bookview于2008-08-30 11:38修改过]

等着together强大了,业务专家拿着它就能生成大把大把的可用代码并架设到服务器上,同时一并解决缓存、安全等问题,程序员对企业来说没用了,这才是企业希望的吧。企业应用的设计本质应该是业务上的本质而不是技术上的,所以只要工具足够强大,有业务专家就足够了。
但那时候还是得有人来开发together这个完全中立的东西,还是得有人开发应用服务器,还是得有人开发支持库。
我理想当中应该是together这种东西内部预置了一些解决方案,比方说ejb、ssh,只要专家们弄好了企业核心,就能选择一个方案来生成应用。

>我只是想说说我们虽然能写出看起来还很好用的软件,其实骨子里对设计的本质的了解还差的远呢,我们只是站
>在程序设计的一个点上,是用别人的设计做设计。

这是典型的向下思维,这个思维其实我已经说了很多遍,你用电视机,不必知道电视机怎么制造的,除非你想制造电视机,如果你想,你花力气,也是会了解,但是这个市场面很小,更大市场面是电视机使用,所以,我们软件教育就应该为这个使用市场服务。

我们是站在程序设计的一个点上,是用别人的设计做设计,这是对的,因为你做的设计就是创新,是别人创新的延伸,火药你设计发明了,你用来做鞭炮,别人继续再设计,发明火器,迎来一个人类文明新时代,你说老外会为火药的开始设计是中国人而一直耿耿于怀,甚至不屑于在火药上继续设计吗?

另外不要小瞧应用领域,应用实践是一切科学的来源,有些学问本来来自应用设计,用处大了,架子大了,上升为一个独立学派了,也至此开始离开应用了。

我们如果把“应用”看成一个对象,很显然,你的学问也是一个独立对象,当然不管你们是关联和聚合,至少和“应用”这个对象有界限区别。所以,很多人就开始厚此薄彼了。

只有站在应用第一线,才能颠覆别人的成就,这比你成天跟在别人屁股后研究人家手里设计原理要更强,是一种更巧的方法论。就象老外站在应用第一线,将火药用处颠覆,创造新的更大用处,如果请外星人来评奖,到底哪个贡献更大呢?

站在软件应用第一线,你就会发明发现OO方法,而OO方法颠覆了过去数据库方法,这又是一个成功案例,可惜,发现OO这个颠覆方法的又不是我们中国人,我们中国人的一部分还在向回看,心里惦记着人家数据库设计内部奥秘,一直琢磨怎么把它研究透彻,结果,人家已经到了OO时代,到了OO时代,你还没反应过来,这些都充分反映要么我们太笨,要么哲学方法论掌握就不到位,只顾低头做学问。

中国古人先秦诸子那么聪慧,特别是老子 道德经,更是人类巅峰,结果我们这些所谓后人却被繁缛细节羁绊,不能理解什么是大智慧,这些是我们落后的深刻原因。


[该贴被banq于2008-08-30 13:57修改过]

>只有站在应用第一线,才能颠覆别人的成就,这比你成天跟在别人屁股后研究人家手里设计原理要更强,是一种更巧的方法论。就 >象老外站在应用第一线,将火药用处颠覆,创造新的更大用处,如果请外星人来评奖,到底哪个贡献更大呢?

老子的道德经之所以伟大,是因为他强调了事情是发展变化的,而且注重渐变,而且描述了一个循环演变的过程,后来的诸子只取其中一环来进行深度研究。我们为什么要学习,无非就是更好的认识事物的本质,让事情住更合谐的方向发展。如果老外总要要到中国来进口的话,自己不懂原理,他怎么可能把火药变成炮弹,炸弹,怎么去改良火药。你用最原始的方法来制造火药的话,火药也不可能有现在这么多功能。发展变化是循环式的是一个相互作用的结果,最后物品与物品的功能才有质的变化。只能说我们国家的整个软件行业都处在一个学习的阶段,学习成绩要好就得做死的去做习题,背知识点。呵呵,把高中的习题交给交大师去做还一定能做出来呢。

>这是典型的向下思维,这个思维其实我已经说了很多遍,你用电视机,不必知道电视机怎么制造的,除非你想制造电视机,如果你 >想,你花力气,也是会了解,但是这个市场面很小,更大市场面是电视机使用,所以,我们软件教育就应该为这个使用市场服务。

正对Banq大师所举的例子来说,制造电视跟使用电视的群体,谁最终撑握着电视机新功能的开发?我想大部分人都会认为是制造电视的群体吧。谁在指引着新功能开发的方向?我想大家不会不赞同是电视机的使用者吧.什么是设计师,也只有制造电视的群体中才会产生设计师吧?对于一个国家来讲谁也不想每台电视机都是进口的吧?当然软件跟电视机来比有很大的不同,同时也说明了我们自己还没能力去做好软件的上层开发。

正是因为我们国家的软件产业中的高端,不愿意去花力气了解费力不讨好的事情,我们这些后辈还得天天去看翻译过来的资料,跟着别人跑人家说了算,而不是参考吸收。讲到这我不得不向让中国导弹理论达到国际先进水准的先辈们,不得不对毛主席那高瞻远瞩的思想致敬。不知道什么时候才能出理软件行业的<道德经>,希望在生前还能看到吧。

正如我认为软件设计核心总会是数据及它本身在客观世界中的意义的管理方法论,我想把类看成客观世界中的意义(概念的定义)不会有太多的反对意见吧.数据库跟OO的产生是不同的侧重点而发展出来的技术,数据库强调数据的管理,而oo侧重于的意义管理.如果把数据管理及意义管理看做软件一个进化的循环的话,数据的管理思想先进了对数据意义的管理当然也会跟着进化。我猜测,对于侧重表现出对意义的管理的java语言,java语言编译器应当有着强大的数据管理功能,设计编译器的时候有充斥着大量的功能代码吧。

[该贴被bookview于2008-08-31 00:51修改过]

就说数学吧,总去研究一些不等式,虽然我没念过大学,但我知道到了大学是有凹函数和琴生不等式可用的,本来一个对中学生困难的问题用更高级别的理论去解决就更容易,整天把那些中学的技巧弄熟,还有的不熟,又困难又没规律,还不如高级方法。再说平面几何,到了高中是有解析几何可用的,把低级别的几何技巧弄得再熟,在有计算机计算的条件下它也不如解析几何快,量化一下解方程就出来了。

所以大师到底还是大师,尽管他不会解一些高中的题目;中学生也终究是中学生,尽管他会一些大师不会的。

毛委员长还说过洋为中用,古为今用,取其精华,去其糟粕呢,这怎么不提呢?这不就是要继承先进的,摒弃落后的吗?导弹为什么要研究基础理论?因为人家不公开,软件为什么不完全需要这样?因为人家有大量公开的东西。

各人有各人的路,计算机领域里也不是只有一种业务软件,想做操作系统和服务器的当然也有,但是现在的情况也不能没有做业务软件的吧。

说白了就是每个人都想干什么,方向不同,知识体系也不同,工具也不同,平台的层次也不同。
一个做业务软件的不需要知道他的服务器上有多少晶体管,一个做计算机硬件的也同样不需要知道打折率是什么东西。

其实这些说词都偏离了我发这个贴子的本意,在这争论程序设计是怎么发展变化的,而不是讨论什么样的程序由什么环节组成,什么环节做什么事情达到什么目标;为什么要这么做,做好这些事情要学什么知识用什么方法,出现问题了去什么环节解决问题才是最好的选择。正入freebox说的‘一个做业务软件的不需要知道他的服务器上有多少晶体管’。但是如果没有人把服务器上的对晶体管变成能执行软件的环境,我想也没有软件设计这个行业了。

事情的发展变化就是由事情的各个环节其同作用的结果,如果我们对各个环节都没有一个从整体上统一的认识,片面的了解事情谈什么改良。

软件设计发展到现在什么要分层,为什么会出现框架,容器这些概念,这些东西在开发过程中起什么作用?在java程序开发中现在三件宝为什么会是“域建模”“设计模式”“框架”?这些达人们了解原因,但对于一个初学者确要经历过九死一生才能顿悟。为什么达人们不整理一下宝贵的经验,给初学者一个渐悟的引导。等到国外又出现什么新的方法大家又说它有多好,问个为什么,只能说XX大师说它好。如果我们有一个整体的认识,在使用过程中至少不会迷失方向,初学者至少有个渐悟的指导。

正如完成产品流水线上的每个工序一样,我们也只是软件设计中的一道工序上的工人,处于什么工序只做什么事情,而不是做该是别人做的事情。真正能改良产品的绝对不会是工序上的工人,工人最多是出个宝贵改良的意见。

我想问的其实是的软件设计需要多少道工序,每个工序又是解决什么问题的要做什么事情的。不是书本让的说词,而是大侠们对自身经历过后一些的简单的思考,给我们这些后进的求道者一些指引吧了

我服务的行业是养不起一整套过程的所有开发人员的,他们找不到物理学家,无法去找电工,不能找一个CPU开发团队,不能找一个操作系统开发团队,也找不到一个应用服务器开发团,但是这些东西他们买得起,软件他们也买得起,只要他们觉得买到的软件足够应付他们的需求,他们也不必找我们,但是事实是他们的需求一直在变化,他们找不到一个现成的解决方案解决所有问题,在工具不发达的今天,他们自己暂时还不能通过定义业务来生成计算机代码,所以就有我们了。

工序的执行和工序的设计可是不同的,不能混淆这两个意义。不是说有了这些框架,拿着OO的Java工人就变成OO派了,真正的OO是要和业务员,和领域专家一起讨论才会知道的,当设计一个良好模型满足他们的需求变更时,工人就变成了设计师,他设计了这个工序,改良了工序的执行(能迅速响应各种需求变更)。没有应用场景也就没有模式什么的了,闭门造车做出来的系统是不能满足应用的,因为单靠自己是无法确认这个领域究竟是什么样的,只会造出来一个看着挺好,但实际用不上的软件。

可能一个Intel工厂里的设计者正在聚精会神地研究24核CPU是什么样的,因为他学的就是计算机电气电工,而另一些人正在讨论为什么这个销售模型即将崩溃了,因为他们学的就是开发业务软件。觉得自己在哪个位置是只有自己才知道的事情。

>正如完成产品流水线上的每个工序一样,我们也只是软件设计中的一道工序上的工人,处于什么工序只做什么事>情,而不是做该是别人做的事情。真正能改良产品的绝对不会是工序上的工人,工人最多是出个宝贵改良的意

工序: 1.分析建模 2.模型设计细化 (这两个工序需要Evans DDD) 3.架构(选择或设计) 3. 编码实现 4.测试调试 5.部署运行。

工人就是从第3个阶段介入。前面需要架构师和建模业务专家,也可以聘请专业咨询公司介入咨询。

整个工序前面3个阶段价值最高,也是70%贡献,但是现实中,这部分重视不够,这样,第4阶段就依赖测试工程师来补救,所以,为什么市场上测试工程师很热,这是由于错误的软件工程思路导致。

做事情一般分成目标,方法,行动三个方面。大家都知道这三个环节往往不会全都明朗,而且随着事情的发展变化,原本确定的方案也会变得不合时宜;特别是社会进入分工合作时代,加让大家对事物的认识原本就存在差异化,因此怎么么去管理,怎么去响应变化就成了各个行业优胜劣汰的重中之重。

<工序: 1.分析建模 2.模型设计细化 (这两个工序需要Evans DDD) 3.架构(选择或设计) 4. 编码实现 5.测试调试 6.部署运行。>

用目标(做什么),方法(怎么做),行动来做如下分析行吗?

(分析建模,模型细化)是强调分析目标吗?要管理什么数据,要有什么功能,是了解做什么。
(架构,编码实现,测试调试)是强调分析方法吗?怎么管理数据,怎么管理功能,是去想怎么去做的问题。
(部署运行)是怎么去执行。

如果是这样子分析可行的话,我觉得不是对前3不够重视,而是这没方面的杰出的人才,无法做出响应变化的需求分析。前面的工作没做好,再加上分工不明确,所以后面才要去补救,增加4,5的工作量,过度的要求第3,4步的能力还要去分析什么是变化的。

>怎么么去管理,怎么去响应变化就成了各个行业优胜劣汰的重中之重。

现在基本都是敏捷工程方法。

我个人认为敏捷工程一种用行动后的结果来分析真实需求的方法,在目标无法确定的时候依赖行行动后所得的经验。