梧州八方网络科技有限公司
 建站热线:0774-2661286
您的位置:首页 -> 资讯中心 -> 软件技术

软件架构引言之项目管理的问题(3)

2014-02-21 14:43:04  来源:  编辑:admin

在上文的三个“xx设计”中,架构设计的时间最难控制和估算,概要设计和详细设计因为就是直接从需求条目演化而来,而且容易细化(以后我会有文章专门讨论),所以虽然也是属于“设计”这种“非线性”工作,但是“可控性”要比“架构”强很多。从个人的项目维护经验来看,维护过程中产生的问题,有相当一部分是因为用户需求突破了原先架构的能力所致,而正是这种问题,才是拖延时间最长,引起客户反映最强烈,也是维护人员最痛苦最头痛的问题。因此,“架构设计”我把它归类到“非线性”工作中,而且是“难点”工作。

 

  我看到很多的公司软件部门都叫做“研发部”,用英文说就是research and development的部门,但是我很少看到有公司把research和development分开做两个部门的。这有什么关系呢?从上文我们可以看到,研究是一种非常耗费资源的工作,而且风险(尤其是技术风险)很大,很可能因为一个小技术难题不能突破而导致整个架构推翻重来,而开发的风险则要小得多,可控得多;另外一个大的区别就是研究并不直接创造价值,而开发则跟公司的收入密切相关。基于这两个理由,就足够把“研究”和“开发”完全分开成两个部门了。其他当然还有许多的区别,比如考核方式等。

 

  分开之后的工作如何分配?很简单,就是把“软件架构”和其他有难度的“非线性”工作统统交给高手云集的“研究”部门去做;具体项目相关的业务和实现(“线性”的工作)交由“开发”部门去做,因为他们对技术要求不高,而且成本较低。说到这里,我是不是在主张每一个公司都需要专人去“研究”技术呢?恰恰相反,我主张大部分公司都不需要设立“研究”部门,至少大部分公司不要去研制甚至试图研制所谓“自己的”软件架构。因为软件架构相比具体业务有一定的独立性,并没有一种“特别适合”于某类业务的“软件架构”存在,即使有,它也是应该经过N个项目的M年考验之后才会出现(N*M>10年)。我相信SAP会有这样的架构,但是国内公司基本不会有(也许有,但是请大家理解我的怀疑)。现在市面上有很多开源的架构存在,选一个吧,然后去培训你的员工,不断地培训,指导他们能够熟练地将这个架构应用到项目中去为止,即使这样,你的总花费也还远远小于请一个“高手”开发一个失败架构的投入。

 

  如何来选择一个现成的架构已经不在文章讨论范围之内了,因为我接下来要谈的是“如何开发一个自己的架构”,不过也不用慌,如果你的开发语言是java的话,那么恭喜你,很多好用的开源架构都是java的,比如spring MVC,struts/webwork,tapestry;如果你用的是.net平台,那么微软已经帮你做了一个浅层的封装,或者干脆用.net的petshop或者Duwamish的架构就可以了。


上一篇:软件项目开发流程图

下一篇:软件架构引言之项目管理的问题(2)

联系我们

官方微博:http://weibo.com/wzbafang

咨询QQ:2818188008

咨询热线:0774-2661286

官方微信:八方网络

扫一扫访问手机版

关注微信公众号

 
QQ在线咨询
咨询热线-周经理
0774-2661286
咨询热线-黎经理
0774-2661286