如何学习软件工程

3、软件咨询：新兴的行业，不过要有实力和广交朋友才行。

========================================================================================================

学了1个学期的软件工程课，终究知道了个软件工程的大概。学的时候总觉得很抽象，理解起来好像不难，但总是摸不着头脑1种很茫然的感觉。学习的进程中和1个宿舍的同学1起做了个小型管理系统的开发，觉得还是有点收获的，对开设这门课的意义也有所领悟，现在就将我对这门课的体会和在项目开发进程中遇到的1些问题简单的归纳1下。希望在以后的学习中不断的提高吧。

曾以为程序就是软件，软件就是程序。现在知道了2者的不同的地方，这是学习这门课程第1个收获。事实上在软件开发的初期阶段这也不能说是毛病的。那个时候开发的软件都比较简单。固然可以把软件理解成程序，直到软件作坊的出现，使软件在程序的基础上加了个说明。之前做过的1些小型的软件比如加密软件，我也只是在程序旁边附上1个软件的说明，看来已很接近作坊了。不过大的项目没有接触过，用软件工程的方法还是第1次。我想也是程序的不断复杂化致使了软件危机的产生，使得人们不能不探索新的解决方法。

这个时候软件工程应运而生了。

我们为何需要软件工程呢？上面已给出了1些缘由。专业点讲，软件工程终究是为了实现“软件制造业”的社会化,工业化大生产,提高其劳动生产效力。只有如此,软件业才能实现社会化,工业化大生产,才能“做大做强”。没有管理的设计是失败和混乱的设计，没有设计指点的编程是无序的繁忙的。根据开发的软件的范围，应当适当程度的应用软件工程化的思想，需要灵活，毕竟我们开发的软件大多数是中小型的，大型的其实不多见（我是这么认为的）。但只要触及人员间的交换和沟通，或多或少都要需要软件工程才能更有效力，工作成果更稳定。

掌握软件工程化的思想 ，对负责软件开发的管理人员（领导）更加重要。曾看到过这么1句话，“坐在指挥台上，如果甚么也看不见，就不能叫领导。坐在指挥台上，只看见地平线上已出现的大量的普遍的东西，那是平平常常的，也不能算领导。只有当还没有出现大量的明显的东西的时候，当桅杆顶刚刚露出的时候，就可以看出这是要发展成为大量的普遍的东西，并能掌握住它，这才叫领导。” 软件工程将有能力的人团结在1起，然后把他们变成工人，由于工业化的生产是效力最高的。这就是根本所在。没有软件工程管理，简直就是乱来，就好象缺少宏观控制的国家1样，会乱78糟。

我们已知道软件和程序是两个不同的概念，软件除程序还要有使用和保护该程序所需要的全部文档。包括需求文档、设计文档、测试文档、保护文档和使用手册。

软件开发特别是大型软件是1项浩大的工程,需要几个人、10几个人、几10个人乃至几百个人合作开发几个月、10几个月乃至几年。要保证系统的调和性、统1性和连续性,就需要在开发之前制定严格、详细的开发规范。开发规范的制定需要花费1定的时间和精力,但是"磨刀不误砍柴功",它相当于把今后开发进程中开发人员都要遇到的问题提早做了1个斟酌。有了开发规范,在后续的开发进程中,设计人员就没必要每次斟酌如作甚1个字段命名,编程人员也没必要去想某个程序的结构和布局应当 怎样,测试人员也有了判断程序对错的标准。开发规范在项目开发工作中起着事前约定的作用,需要所有开发人员共同遵照。它束缚开发人员的行动和设计、编程风格,使不同子系统和模块的设计、编程人员达成默契,以便构成全部系统的和谐步调和统1风格,也便于今后的系统保护和扩大工作。

在实际中开发软件首先应当斟酌的是是不是可行的问题。但在这个实习中其实根本没必要，既然已选好了题目，而终究也不要求能够运行，钱、软硬件资源不成问题，固然可行。主要斟酌的技术问题。

下面就软件开发的各个阶段分别谈点看法。

需求分析就是要肯定自己要做甚么，应当怎样做，心里有个底。需求是通过与用户充分交换和自己的创造力,去发明软件规格说明的进程。如果没有双方对需求进行分析，可能出现项目设计出来的东西或终究提交的可交付物根本就不是客户所需要的，或有相当的差距。所以用户和开发人员在需求上要达成1致性。在这个实习项目中只是给了几个要实现的功能。也没有真实的用户。凭大家的想象给出1个比较好的需求有点难。

设计进程就是将你肯定的需求想办法用代码去实现。这个进程是交给程序员做的。设计可能会用到很多方面的知识。软件终究的目的是要用户使用。因此在程序设计时必须立足于操作简单、实用,并真正能为用户解决实际的业务问题。不能由于怕编程麻烦而将程序功能设计得过于简陋。这个进程可能会对已完成的需求分析做些改进乃至颠覆。为每一个模块肯定采取的算法。然后就是根据算法写代码。之前觉得写代码是最麻烦得事情，现在才发现写代码原来只是软件开发中最简单的1个步骤。到目前为止学了C，C++，还有java，熟习的还是面向进程的C，面向对象的软件开发回有待于实践。在这个小项目的开发中由于没有要求写代码，所以也没有使用哪一种程序设计语言的问题。但我想既然面向对象的软件开发有着比传统的开发没法比拟的优点加上现在java风行全球，连比尔盖茨都说java是目前为止最优秀的计算机语言，学着用java开发感觉好点。看来以后要好好的学java了。

软件交付之前必须要测试。测试是保证程序质量的1项重要工作。但测试只能证明程序有错,而不能证明程序无错。所以任何软件系统都不能保证内部没有毛病。为了确保软件系统的安全与可靠性,1方面要加大测试力度,另外一方面要捉住测试重点。程序又是测试的重点。1个合格的测试员应当很熟习他人的思惟。但感觉程序员应当很反感测试员。软件开发是1项建设性工作而软件测试是1项破坏性工作。1个曾做过测试的如是说，“做测试，我感到最多是在和程序员在吵架”。我觉得测试的基本要求就是找生产品的缺点，用简单明了的方式表达给开发人员，心平气和才好办事。不管怎样，有了破坏才能使软件的免疫能力强起来。测试占了开发1半以上的时间和资源。

我在实习小项目中做的是测试的工作。由于没有源代码，所以只能做静态测试。测试进程感觉很不好。摆在我眼前的只有个软件需求文档和详细设计文档，而且需求分析1大半也是我写的。现在才发现需求分析当时写的有多么的低劣。很多的问题都没有斟酌到。而且发现设计文档中的软件初始结构图根本不是依照需求分析给出的数据流图转化过来的。详细设计文档呢，跟整体设计差不多，乃至连整体设计的1些要求都没有，比如接口的描写，从头到尾没有提到过。面对着那份详细设计报告，我无从下手，甚么都没有。每一个模块的细节都没有斟酌。还是1个最最基本的框架。可事到如今又能怎样办，总不能把原来的抛弃自己在测试之前重新做个详细设计吧，只好硬着头皮测了。测试完成后感觉没1点收获。还不如看看书上的白盒子测试的例子体会多1点。报告打印了1点成绩感没有。

软件保护是软件生存期中的最后1个阶段。实习没有这方面的要求。保护也不像其前面的几个阶段理论成熟。但保护不是1天两天就可以解决的问题。自从软件开始工作，保护就历来没有停止过。所以保护是1个耗人力物力最多的1个阶段。具体保护的方法应当根据软件的开发方法来具体肯定。保护是为了软件能健康准确更好的运行，但在保护的同时也可能由于开发方法的缺点致使保护产生1大堆的副作用乃至可能使得情况变得更糟，会得不偿失。所以保护马虎不得1定要慎重对待。

总的来讲，软件工程还是门不成熟的学科，在很多方面有不尽人意的地方，它在软件开发领域的作用还没有充分的发挥出来。特别在我国，软件产业发展滞后，只占国民经济的很小1部份。听说在美国，软件产业在国民经济中的比重仅次于汽车产业。我从1些国内的1些论坛上考到有些程序员总抱怨说公司开发软件根本不重视软件工程的技术。所以有些人说软件工程没有用途。但我想随着软件范围的日趋壮大，软件工程技术1定会愈来愈遭到开发人员的重视。固然软件工程理论的成熟还有待于IT界广大软件开发人员的共同努力，需要从实践中摸索规律总结经验，但可以相信软件开发工程化的思想绝对是先进的，科学的。相信以后软件工程的技术和理论会为大型软件的开发做出更大的贡献。同时更希望我国的软件开发者们为我国的软件产业的发展做出杰出的贡献。

软件工程各个阶段的任务

需求分析：

不是具体的解决问题。而是准确地肯定软件系统必须做甚么，必须具有哪些功能等问题。

概要设计：

主要任务是肯定软件的整体结构和数据结构，并定义模块间的接口。也就是肯定该软件系统有哪些模块组成，每一个模块的功能是甚么，这些模块的调用关系是怎样的。同时还要设计整体数据结构和数据库结构，即软件系统要贮存甚么数据，这些数据的结构及他们之间的关系等。

详细设计：

主要任务就是给出整体结构中每一个模块完全的算法描写，把功能描写转变成精确的结构化的进程描写。即该模块的控制结构是怎样的，先做甚么，后做甚么，有甚么样的条件判定，有甚么重复处理等，用相应的表示工具把这些控制结构表示出来。

编码：

就是把详细设计说明书中每一个模块的控制结构转换成计算机可接受的程序代码，即依照选定的语言，把设计的进程性描写翻译为源程序。

测试：

测试按不同的层次可分为单元测试、组装测试、确认测试和系统测试几个步骤。

单元测试是查找各模块在功能和结构上存在的问题；

组装测试时将各个模块按1定顺序组装起来进行的测试，主要是查找哦啊各模块之间接口上存在的问题；

确认测试时按说明书上的功能逐项进行的测试，决定开发的软件是不是合格、能否交付用户使用等。

下面是在水木软工上的对话。有兴趣的可以看看，全文触及工程与科学之间的差异，软件工程的工程本身的分析，项目经理的行动和强弱势项目经理的1些问题。

btw：里面有著名的钱5哥的回复，呵呵。

☆─────────────────────────────────────☆

别笑我弱大家讨论讨论，呵呵

我老听说“要以工程的方法来开发软件..."等等类似忠告。可以我怎样也不能领会工程的真
正意义。
我能想到的就是"more pratical"和理性。由于在我的理解中传统的工程(就是类似于建小区
)的产物都是实证的都必须是可行的都必须是经得起考验的。与之相对的就是夸夸其谈的艺
术的创意的只需要设计不重实现的，这些方向要的是纵横捭阖天马行空。
两项相较：1边是海水1边是火焰，1边是理性与冷静，1边则是感性与豪情。1边是控制
1边是纵情。

而我们研发软件，同建房子1样，不但要设计，更要能实现。终究的工件必须是经过客户用
户检验的，这个检验也是有标准的，不存在公说公有理婆说婆有理的情况。

软件工程的提法反应了当时软件开发屡遭失控打击的情势下，永不停止学习的软件人向传统
行业鉴戒经验的决心。自此以后，估算技术丈量技术地位急剧高升?

各位是怎样理解这个软件工程中的“工程”的？有无人讲讲来龙去脉，freestyle。^_^

但是软件工程中有方法论进程论，这算不算传统工程理论的1部份？


☆─────────────────────────────────────☆
   qingrun (青润) 于  (Thu Jan 14 21:10:42 2010)  提到:

不弱。能深入思考工程两个字的含义是很有必要的。
不思考工程两个字就来做软件开发的人，容易形而上学，更容易僵化的处理新的概念和新的方法论，借用老毛同志的话就是，容易本本主义。呵呵
不过，你这个话题太大，bbs上做这样的讨论，需要大量的文字输入，得不偿失，呵呵。
辩论或讨论的时候，思辩进程和响应回途经长，价值不大，这样的问题应当斟酌别的讨论情势会比较好1些。

【 在 ihomd (ihomd) 的大作中提到: 】
: 别笑我弱大家讨论讨论，呵呵 
: 我老听说“要以工程的方法来开发软件..."等等类似忠告。可以我怎样也不能领会工程的真 
: 正意义。 
: ................... 
☆─────────────────────────────────────☆
   blueslc (Thomas) 于  (Thu Jan 14 23:04:41 2010)  提到:

Engineering is a cooperative game of invention and communication.
from <Agile software development - the cooperative game>
这本书有1章讲工程和软件工程，说的很好，我试侧重复1下看看了。
进程中有创新的才是工程，没有的话就是生产而已，在传统领域，很多工程其实只是生产而已，没有甚么难度。比如造房子，造第1座房子是工程，如果造一样的第2座，那就是生产。造第1座的难度，肯定比第2座要大很多
软件由于其独特性，每个软件都不1样，所以软件工程，要和你造第1房子作对照，而不是第2座。
【 在 ihomd (ihomd) 的大作中提到: 】
: 别笑我弱大家讨论讨论，呵呵 
: 我老听说“要以工程的方法来开发软件..."等等类似忠告。可以我怎样也不能领会工程的真 
: 正意义。 
: ................... 



☆─────────────────────────────────────☆
   qingrun (青润) 于  (Thu Jan 14 23:23:36 2010)  提到:

这个对照似乎应当是科学研究与工程对照，科学研究是造第1座房子，然后工程才是重复后面的房子进程，呵呵。
我个人认为，这本书里面讲的这个工程的解释应当是完全毛病的。它混淆了科研与工程之间的差异。

☆─────────────────────────────────────☆
   qingrun (青润) 于  (Thu Jan 14 23:27:44 2010)  提到:

评论1下这句话：但是软件工程中有方法论进程论，这算不算传统工程理论的1部份？
我记得我的blog上有1片关于软件工程重新定义的文字上（我对软件工程领域划分的认识之1，地址：http://blog.csdn.net/qingrun/archive/2006/12/21/1451598.aspx ），和1个在河南某大学的老师产生了争辩，通过评论和评论回复的方式争辩了几近1整天，其实说的就是1两个小时就能够说完的东西。
对这个话题和这个话题中各方面包括的内容做了比较深入的讨论。

☆─────────────────────────────────────☆
   qlw (钱5哥) 于  (Thu Jan 14 23:43:55 2010)  提到:


工程和技能相对应。工程的基础是可以丈量，曾复印过1张施工队的进度和报价
上面将投入、工时、本钱算的清清楚楚。这和动辄可能延期的软件开发有天壤之别

但是软件工程也是很困难的，丈量到现在似乎也没有甚么人提出来与时俱进的方法
工程化终究致使了文档化和僵化。因此出现了敏捷进程 - 动身点是简化传统的工程
思路，从而回归到产品化的正确道路上。但是在解决范围扩大的问题方面还是有
些问题。早1些的CASE、组件化、软件工厂等概念，虽然盛极而衰，但是留下了
包括pattern、UML在内的遗产，对工程化有不小的帮助。

工程化首先要求可以重用，如果至今1直用主机+Cobol+DB2，则我深信现在已
工程化好久了，惋惜目前是Linux+虚拟化+云计算的时期，本来弄的那套玩意早就
过时了，工程化还遭到技术成熟性的制约！

可以看看Gartner的Hyper Cycle，现在M2M已开始预热了。看到这类玩意，不由
心说，“工程化又远了”

供讨论

☆─────────────────────────────────────☆
   timshaw (写啥呢？真矛盾) 于  (Thu Jan 14 23:58:08 2010)  提到:


我再讲些感想。

软件工程是如此的复杂，风险是如此的高，弄到65%的软件项目延期，30%的项目直接取消。
跟传统工程的按时交付率差别如此之大。
缘由有2：
第1是软字，软的就像女人的奶子客户都想捏成自己想要的形状。很多客户都不知道到达随意捏的程度需要吃多少木瓜，这类客户和软件提供商的沟通有点巴别塔。
其 2在原软件工程固有的复杂性。传统工程正如我开始所说，设计和实现相分离，劳斯莱斯的design和implementation是完全个裂开的。而软件 项目中design和implementtation是如此的不可分家，每个实现者都在自己的范围内进行design。

和传统工程比 较，软件工程的轨迹必定是守破离。大乱时期，我们需要1个框架，是以学习传统工程，但由于上面两点，渐渐的，软件工程变异出自己的特性，我认为这里可以分 为3个层次：进程论/方法论/最好实践和反模式，这些都是那些重视丈量估算的传统工程所没有的。渐渐的终究发展出自己的1套理论，和传统软件工程完全不同 的理论。在这里，丈量不是最重要的，最重要的是革新，是重构，是抽象，是沟通是融会而不是分而治之不是人为构筑壁垒。


☆─────────────────────────────────────☆
   timshaw (写啥呢？真矛盾) 于  (Fri Jan 15 00:21:24 2010)  提到:

那肯定啊，但是主要指点思想还是IOC和分而治之。
说起这个就想起而2战的通用，短时间内就是用IOC理念造就了如此多的飞机。。。。

【 在 canper (洗衣粉) 的大作中提到: 】
:  车盲，不了解，不过我想造车设计师也不是画完图纸就完事的吧，也要参与样品车的组装，调试。 

☆─────────────────────────────────────☆
   canper (洗衣粉) 于  (Fri Jan 15 00:26:47 2010)  提到:


 我觉得软件中设计和编码分开也是完全可以的，但其实不表示这样就能够下降编码人员的水平，和设计者可以不参与到编码阶段中。

  我想配合设计师1起组织样品车的技术的工资也不是和普通工人1个档次的。

【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 那肯定啊，但是主要指点思想还是IOC和分而治之。 
: 说起这个就想起而2战的通用，短时间内就是用IOC理念造就了如此多的飞机。。。。 


☆─────────────────────────────────────☆
   timshaw (写啥呢？真矛盾) 于  (Fri Jan 15 00:31:14 2010)  提到:

我觉得软件行业革新的动力就是融会相互学习没法剥夺的学习，而传统行业是分而治之，缺少对流缺少沟通。软件行业如果没融会没沟通，基本上就夕阳了。
我们之所以如此酷爱这个行业，就在于我们喜欢沟通交换喜欢延续改进而不是得过且过。

【 在 canper (洗衣粉) 的大作中提到: 】
:  我觉得软件中设计和编码分开也是完全可以的，但其实不表示这样就能够下降编码人员的水平，和设计者可以不参与到编码阶段中。 
:   我想配合设计师1起组织样品车的技术的工资也不是和普通工人1个档次的。 

☆─────────────────────────────────────☆
   canper (洗衣粉) 于  (Fri Jan 15 00:32:05 2010)  提到:

 不过一样的事情如果放到建筑业就不是那末回事了，设计师画完图纸就完了，没有必要建1栋房子来验证自己的设计。

  如果是服装业呢，好像也要做出样品来看看效果。


【 在 canper (洗衣粉) 的大作中提到: 】
:  我觉得软件中设计和编码分开也是完全可以的，但其实不表示这样就能够下降编码人员的水平，和设计者可以不参与到编码阶段中。 
:   我想配合设计师1起组织样品车的技术的工资也不是和普通工人1个档次的。 




☆─────────────────────────────────────☆
   canper (洗衣粉) 于  (Fri Jan 15 00:33:10 2010)  提到:


 这个，我还真说不上酷爱
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 我觉得软件行业革新的动力就是融会相互学习没法剥夺的学习，而传统行业是分而治之，缺少对流缺少沟通。软件行业如果没融会没沟通，基本上就夕阳了。 
: 我们之所以如此酷爱这个行业，就在于我们喜欢沟通交换喜欢延续改进而不是得过且过。 




☆─────────────────────────────────────☆
   canper (洗衣粉) 于  (Fri Jan 15 00:35:22 2010)  提到:


 在斟酌1个问题，1个好的汽车工程师不需要具有技师的技能。
 1个好的服装设计师不1定是个好裁缝。


 但是1个好的软件设计师不是1个好的编程人员就不靠谱了

【 在 canper (洗衣粉) 的大作中提到: 】
:  不过一样的事情如果放到建筑业就不是那末回事了，设计师画完图纸就完了，没有必要建1栋房子来验证自己的设计。 
:   如果是服装业呢，好像也要做出样品来看看效果。 




☆─────────────────────────────────────☆
   timshaw (写啥呢？真矛盾) 于  (Fri Jan 15 00:36:00 2010)  提到:

这就是软件业的design和implementation不可分离的特点啊。

【 在 canper (洗衣粉) 的大作中提到: 】
:  在斟酌1个问题，1个好的汽车工程师不需要具有技师的技能。 
:  1个好的服装设计师不1定是个好裁缝。 
:  但是1个好的软件设计师不是1个好的编程人员就不靠谱了 
: ................... 



☆─────────────────────────────────────☆
   canper (洗衣粉) 于  (Fri Jan 15 00:38:02 2010)  提到:


 但是1个好的软件工程师不需要是1个好美工，哈哈
【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 这就是软件业的design和implementation不可分离的特点啊。 




☆─────────────────────────────────────☆
   timshaw (写啥呢？真矛盾) 于  (Fri Jan 15 00:39:49 2010)  提到:

这里的design不是指UI design,而是指 architecture啊。
【 在 canper (洗衣粉) 的大作中提到: 】
:  但是1个好的软件工程师不需要是1个好美工，哈哈 




☆─────────────────────────────────────☆
   qingrun (青润) 于  (Fri Jan 15 14:25:48 2010)  提到:

这 样的实验我做过，02年8月，南京地税金力4期项目上，我从上海带了5个人过去参加tp当年的团队，后面给了我两个星期做1个模块实用性原型，成都那边给 了我1个美工，我这边自己做模型开发，设计完成后，分给了1个做页面，1个做数据库，我做业务控制层，1个人做银行接口的扣款，1共8天不到全部弄定，1 次性通过测试。
做界面和数据库开发的人完全是在我给定的模型导出的代码上进行的，我们做了1次设计变更，构成了1个独立的直接对象数据的写入类。
所以，我1直定义的编码人员就是印度的那种编码层次就足够了。
不是说设计人员完全脱离编码，而是对1些创造性和创新性或说有1定难度的编码是需要设计人员写好的，类似于过去传统软件工程中提出的微代码的开发阶段所完成的内容。
这样，就能够完全地实现代码设计的分离。实现我们的对印外包。

【 在 canper (洗衣粉) 的大作中提到: 】
:  我觉得软件中设计和编码分开也是完全可以的，但其实不表示这样就能够下降编码人员的水平，和设计者可以不参与到编码阶段中。 
:   我想配合设计师1起组织样品车的技术的工资也不是和普通工人1个档次的。 



☆─────────────────────────────────────☆
   qingrun (青润) 于  (Fri Jan 15 14:28:53 2010)  提到:

1个好的汽车工程师也需要好的技师的配合，在做1些设计的时候，需要他们才实现设计，然落后行验证，取得验证结果后，对设计进行调剂和优化――我的本专业材料学就是干这个的，现在大多数同学都在汽车行业，嘿嘿。

【 在 canper (洗衣粉) 的大作中提到: 】
:  在斟酌1个问题，1个好的汽车工程师不需要具有技师的技能。 
:  1个好的服装设计师不1定是个好裁缝。 
:  但是1个好的软件设计师不是1个好的编程人员就不靠谱了 



☆─────────────────────────────────────☆
   qingrun (青润) 于  (Fri Jan 15 18:10:17 2010)  提到:

不管我们做甚么软件，这个软件大部份都是此前已有人做过的，或有过类似的，或最少是在原理上已被证明过的，如果非要强调，应当说，科学是对原理的验证，而工程是对原理的实现。
难度有可能实现比推理进程更难，所以，在科学领域的很多学科上都有大量至今还没法验证的假定，这是客观存在的，假定常常需要很多条件满足后才可能被验证，所以，那本书上说的工程的所谓概念是完全毛病的！！！

【 在 blueslc (Thomas) 的大作中提到: 】
: 但对软件开发，对开发者来讲，我们常常都是在造第1座房子，有时候还是在原来房子的基础上加层，更加困难



☆─────────────────────────────────────☆
   ilovecpp (cpp) 于  (Fri Jan 15 23:48:23 2010)  提到:

【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 我再讲些感想。 
: 软件工程是如此的复杂，风险是如此的高，弄到65%的软件项目延期，30%的项目 
: 直接取消。 
: 跟传统工程的按时交付率差别如此之大。 

传统工程真有这么牛？

787的延期，Larabee的延期，业界巨头数10亿美元轻易打水漂。

1部美国军机发展史，就看见3个词：延期，超越预算，项目取消。

软件工程喜欢拿盖房子作比。盖房子真是这个时期最接近软件工程的传统工程？

我父母是电子工程师。我的直观印象是，电子产品的开发决不像盖房子，倒是和
软件开发的进程颇多相似的地方。

和传统工程比，我们做得真的更差吗？

诸多疑问，难以厘清。



☆─────────────────────────────────────☆
   qingrun (青润) 于  (Sat Jan 16 11:23:17 2010)  提到:

对 于国内来讲，我们和国外的差距主要在管理意识上，而不是技术层面；由于管理意识的差异，引发的投资方对软件系统的渴望和要求有了非常大的变化，国内的传媒 方面对国外软件项目的报导，也包括国外对自己的软件工程实行的报导也都大多集中于成功的例子，加上随着大家对科技进步的奢望，总认为软件应当能做到甚么什 么模样，应当能解决甚么甚么问题，却忽视了软件本身最需要解决的根本问题：数据积累。
国外的软件行业走过了超过我们3倍以上的时间，他们积累的数据基础远远不是我们目前能够比拟的。
对 美国来讲，由于几次世界大战都没有到他的本土，他的企业和经济的延续性在全球范围内都可以算是最好的，其数据的保持也是最好的，而我国，大部份企业都是 80年以后重建的，更多的数据在2战，文革中全面毁灭，没有剩下甚么，我们所能研究到的数据积累能超过10年的都不多，而且大部份是未信息化处理的原始数 据，但是同时，国内的宣扬为了取得眼球的注意力，更多的关注在国外已成功地项目和目前的技术积累和产品状态下，所以，附带而来，传统行业在信息化的时候对 我们的期望就处于1个相对太高的水平线上，因而就带来了意识与技术现实的直接冲突，加上可投入研发资金和积累的时间问题，因而这个矛盾就更加剧烈了。
所以，不是我们做得不够努力，而是环境太过于刻薄了。
虽然说解决这些问题不是不可能但是，需要多方面的配合和引导，涉足点太多，就超越了这个话题了。呵呵


☆─────────────────────────────────────☆
   blueslc (Thomas) 于  (Sat Jan 16 11:40:07 2010)  提到:

那软件的开发算是科学？还是算是社会学？很多事情都没有这么绝对的。
【 在 qingrun (青润) 的大作中提到: 】
: 不管我们做甚么软件，这个软件大部份都是此前已有人做过的，或有过类似的，或最少是在原理上已被证明过的，如果非要强调，应当说，科学是对原理的验证，而工程是对原理的实现。 
: 难度有可能实现比推理进程更难，所以，在科学领域的很多学科上都有大量至今还没法验证的假定，这是客观存在的，假定常常需要很多条件满足后才可能被验证，所以，那本书上说的工程的所谓概念是完全毛病的！！！ 





☆─────────────────────────────────────☆
   qingrun (青润) 于  (Sat Jan 16 11:56:03 2010)  提到:

软件开发是工程学的内容，绝对不是科学领域直接关联的内容，固然，1切都是在科学理论的指点或指引下完成的，这个事情，可以说是绝对的。
科学的概念和范畴是可以明确地东西。这个问题也是可以明确地，呵呵。

【 在 blueslc (Thomas) 的大作中提到: 】
: 那软件的开发算是科学？还是算是社会学？很多事情都没有这么绝对的。 


☆─────────────────────────────────────☆
   timshaw (写啥呢？真矛盾) 于  (Sat Jan 16 12:20:57 2010)  提到:

说起这个来，确切在管理意识上有些不匹配，举个很弱的例子
我之前有个非it的老大，买了个2w的asp源代码，后来几个项目非要我用这个asp源代码，1个项目下来用“不要改”阻击了我最少快20次提议。
他很难理解有现成的东西为啥不用，恍如另起炉灶或升级给就算是把他那小2w给浪费了会给他造成很多本钱费用似的。虽然我解释过很屡次。
弄软件有时候对本钱对质量的贡献，管理人员在管理层面上进程成层面上的运作不见得比技术人员关键。
此时，我想起1本书（应当是《软件工程的事实与错误》）前言中提到作者说过的1句话，大意是说他喜欢弄技术，很享受这类技术人的意见压倒管理者命令的状态。当时我觉得很可笑，我心想在中国你有立锥之地吗？


☆────────────────────────────────────☆
   timshaw (写啥呢？真矛盾) 于  (Sat Jan 16 12:22:05 2010)  提到:

昨晚上看到1本用友人写的书，说很多技术顾问不愿意随着销售出去吃喝玩乐，而销售经理又不好意思不叫，怕得罪啊。..
【 在 canper (洗衣粉) 的大作中提到: 】
:  我就1个写代码兼做工程的，整天和客户打交道 




☆─────────────────────────────────────☆
   qingrun (青润) 于  (Sat Jan 16 12:25:42 2010)  提到:

我去年年初就拍死了1个合作公司的市场，对技术人员太不尊重了，后来他们还过来找了我1次，希望我继续提供咨询和培训，我没理他，就没有再找我了。

【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 昨晚上看到1本用友人写的书，说很多技术顾问不愿意随着销售出去吃喝玩乐，而销售经理又不好意思不叫，怕得罪啊。.. 



☆─────────────────────────────────────☆
   qingrun (青润) 于  (Sat Jan 16 12:26:50 2010)  提到:

所以，在中国，有技术基础，又能谦虚做事的项目管理人员才可能把项目做的很好，单纯的强势或弱势项目经理都是不好当的。呵呵。

【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 说起这个来，确切在管理意识上有些不匹配，举个很弱的例子 
: 我之前有个非it的老大，买了个2w的asp源代码，后来几个项目非要我用这个asp源代码，1个项目下来用“不要改”阻击了我最少快20次提议。 
: 他很难理解有现成的东西为啥不用，恍如另起炉灶或升级给就算是把他那小2w给浪费了会给他造成很多本钱费用似的。虽然我解释过很屡次。 
: ................... 



☆─────────────────────────────────────☆
   keygen (贫贱夫妻百事哀) 于  (Sat Jan 16 12:29:09 2010)  提到:

技术牛的项目管理人员强势点，大家倒是很愿意接受的。哈哈
【 在 qingrun (青润) 的大作中提到: 】
: 所以，在中国，有技术基础，又能谦虚做事的项目管理人员才可能把项目做的很好，单纯的强势或弱势项目经理都是不好当的。呵呵。 




☆─────────────────────────────────────☆
   qingrun (青润) 于  (Sat Jan 16 12:34:02 2010)  提到:

那样会有1个问题出现，而且这个问题根本没法解决，那就是：
如果团队内有1个差不多1样牛的技术人员存在的话。

我曾在自动化所跟随过1个技术很牛的研究员，离开后，写了1系列好像是5篇相干文字在我的blog上，就是谈如何和1个纯技术的老板合作的话题。
和他的合作就存在1个很严重的问题，那就是：他情商太低，低到了公认的负值――有人说这还不够。
1个例子08年底到09年中期，他产生了两次学生集体叛逃的事件，第1次18个学生9个集体提出换导师，其中有两个博士，是我在的时候的弟兄，人很老实，都已博士第3或第4年了，你想一想，能把人家压迫成甚么模样才能逼人家做出这样的选择。呵呵。
技术上大家都服气，都认为他很牛，我出来后，提到他也都说，他技术上的确很牛，别的，大都1带而过，偶尔用类似上面的事件作证明来讲明1些，呵呵。
【 在 keygen (贫贱夫妻百事哀) 的大作中提到: 】
: 技术牛的项目管理人员强势点，大家倒是很愿意接受的。哈哈 






☆─────────────────────────────────────☆
   canper (洗衣粉) 于  (Sat Jan 16 13:41:40 2010)  提到:


 没有，每次出来他们都用力的和我说这是很健康的事情，不要想歪了等等。


 天地良知，我历来都认为这是很健康很健康的事情，但是健康的事情多了去了，又不见得1定要做。话说每星期打羽毛球我都没去，怎样就没人来和我解释：打羽毛球是很健康的事情。

【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 所以你在洗脚房里睡觉，他们估计在嘀咕:难道是要把妞送到他房里去? @_@ 
: 开个玩笑。 




☆─────────────────────────────────────☆
   SPQR (苍狼) 于  (Sat Jan 16 17:52:51 2010)  提到:

这是由于不会说话啊...
做销售的, 何至于这么不会沟通

【 在 timshaw (写啥呢？真矛盾) 的大作中提到: 】
: 昨晚上看到1本用友人写的书，说很多技术顾问不愿意随着销售出去吃喝玩乐，而销售经理又不好意思不叫，怕得罪啊。.. 




☆─────────────────────────────────────☆
   SPQR (苍狼) 于  (Sat Jan 16 17:54:29 2010)  提到:

打羽毛球是很健康的事情

【 在 canper (洗衣粉) 的大作中提到: 】
:  没有，每次出来他们都用力的和我说这是很健康的事情，不要想歪了等等。 
:  天地良知，我历来都认为这是很健康很健康的事情，但是健康的事情多了去了，又不见得1定要做。话说每星期打羽毛球我都没去，怎样就没人来和我解释：打羽毛球是很健康的事情。 






☆─────────────────────────────────────☆
   finely (finely) 于  (Sat Jan 16 20:55:03 2010)  提到:

你们都喜欢发长文 啊

我说个简短的，主要就是“工程”和“研究”之区分

工程就是干活，理论和工具都是现成的，用就是了

研究是高难度的创新，是制造理论和新工具的

软件从本质上讲，是个工程，但是1个复杂度极高的工程，以致于很难控制，所以需要1些理论和方法来控制这个工程。

【 在 ihomd (ihomd) 的大作中提到: 】
: 别笑我弱大家讨论讨论，呵呵 
: 我老听说“要以工程的方法来开发软件..."等等类似忠告。可以我怎样也不能领会工程的真 
: 正意义。 
: ................... 



☆─────────────────────────────────────☆
   SPQR (苍狼) 于  (Sat Jan 16 22:43:39 2010)  提到:

成心思

所以工程大致是(关键字)
1) 利用/制造 (输出是可以直接使用的实物)
2) 系统化的/方法论的

不是;
1) 研究 (输出是研究报告)

但是其实工程这个概念是不需要

生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠