基于Internet的软件工程策略[转贴]

bamfox

基于Internet的软件工程策略

转自：
http://www.kupage.com/wpm/10/20020904/1451080000001qm5nypl.htm

[code:1]基于Internet的软件工程策略


来源：   作者：



　　Internet的发展和应用正在不断超越人们的想象，融入社会生活的各个角落，将对各行各业产生深远的、不可逆转的影响。针对软件产业而言，Internet时代对于软件开发进度提出不断增长的挑战性要求，并产生了许多新思想和新观念，对原有的一些传统软件工程理念带来了冲击，Linux的成功开发实践、开放源码思想的不断普及、大教堂和市集型开发模式的碰撞等都是最直接的体现。显然，如何使得软件企业能够从容面对时代的变迁，把握Internet所带来的机遇和挑战，具有重要意义。

　　近年来，开放源码思想在国际上越来越受到人们的重视，在这个思想下已经成功开发了一系列著名软件，比如Linux就是其中典型代表。开放源码思想与Internet有着内在的天然联系，通过二者的有机结合能够将许多人的智力集聚到一起，反映了一种新的软件开发思路，本节试图探究其成功经验。



　　相对传统软件工程而言，开放源码社区似乎没有准备接受或实践现代软件工程过程，但他们的确在开发适用于特定用户团体的软件，这些软件通常是极具价值的、可靠的、被广泛接受的和高可用的。那么，究竟什么样的开发过程正在开放源码社区中被常规应用和实践呢？一项研究表明，有五种软件开发过程在开放源码社区得到广泛应用：
　　1) 需求分析和说明
　　2) 受控的版本管理、系统构建和按阶段的增量发布
　　3) 维护被看作是演进式开发、重新精练细化和重新发行
　　4) 项目管理
　　5) 软件技术转移



　　以上每个过程都与传统软件工程规定体现出不同之处，而且没有哪个过程应被独立构造或凌驾于其他过程之上。更进一步，这些过程相互之间通常是并行开展的，而不象传统软件生命周期模型中那样严格的或部分的按序进行，开放源码软件开发从本质上讲是一种复杂的由社会-技术过程、开发条件和动态产生的开发上下文所组成的网络，以Internet为基础支撑平台，并随着Internet的发展而不断完善。



　　对于许多开放源码项目而言，开发人员对于是否遵循了某种规定的软件工程方法和过程并不关心，有些项目甚至没有特定的用户和发布截止期限，但是诸如“经常发布”、“简化设计”、“测试”、“编码标准”、“集体参与”等基本原理却被本能地执行着。



　　对于开放源码软件协同开发原理的经典论述来自开源社区领袖之一的Eric Redmond的《大教堂与市集》一文，在该文中作者形象地将传统的严格管理的软件开发活动比喻为构筑大教堂的行为，而将分布于Internet之上的开放源码社区的协同开发活动则看作是市集行为，作者根据亲身经历系统地论述了市集型开发的基本方法和哲学问题，阐释了开放源码社区成功的内在原因，对于传统软件开发不无借鉴之处，比如“早发布、常发布、听取用户的建议”、“把用户当做协作开发者和Beta测试人员”、“聪明的数据结构和笨拙的代码要比相反的搭配工作的更好”、“最好的设计不是再也没有什么东西可以添加了，而是再也没有什么东西可以去掉”、“好程序员知道该写什么，伟大的程序员知道该重写（和重用）什么”等等。



　　目前，人们对于基于开放源码的Internet协同开发实践还缺乏深入研究和理解，但是已经得到越来越多的软件工程人士的关注，并取得一定的研究成果。一个软件工程研究小组在过去5年中深入研究了几个大型的开放源码系统的体系结构和进化过程，包括Linux、GCC、VIM、Mozilla和Apache，发现他们与类似的商业系统之间表现出令人感兴趣的不同之处，比如，开放源码软件的体系结构通常是可浏览的以允许开发人员进行交互，对于那些可能阻碍程序理解（因为程序员通常是分布在Internet上各个角落互相独立的工作）的体系结构部分进行特殊声明；从同类的开放源码软件如Web服务器中可以提取其共性的参考体系结构，而在商业软件公司中却难以通过Web服务器体系结构获得几种不同的实现；开放源码软件的体系结构和开发模式是导致其超线性增长的主要因素，并且被尽可能设计的易于移植，其发行版通常不是针对特定平台，而是将各种平台的共性抽象到一个发行版中，通过配置工具来帮助构建系统。



　　另外，针对如何借鉴开放源码项目的经验用于指导商业软件项目也有相关研究成果，该项研究表明，尽管完全利用开放源码开发模式来代替传统商业软件开发模式目前看来还不太可能，但无疑可以相互借鉴经验教训而获得收益。研究人员认为，一些可供商业软件项目借鉴的开源项目经验包括：



　　人员组织——开源项目通常由很少的核心成员完成多数开发和升级任务，这一点与商业软件开发类似，但差别在于这些任务是如何在核心小组内分配的。开源项目通常是自发形成，职责的分配是基于对开发人员如何看待他们在项目中的角色的推理而确定，并不是硬性指派产生，这一点无疑对于商业软件的管理具有借鉴意义。



　　非正式交流——在Internet协同开发活动中非正式交流对于项目成员间的协调极其重要，邮件列表、论坛等是常用工具，无论开发人员在文化、地域和时区方面是否存在差异。商业软件应借鉴这种做法，而不必拘泥于严格的、形式化的交流渠道。



　　增强的用户支持——许多用户都同意这种观点，即多数商业软件公司在进入售后支持阶段时就可能面临悲惨的失败命运。而开源项目的用户支持工作却有良好成绩，因为大量的用户愿意提供关于开源产品的反馈信息。因此，商业软件项目应增强用户之间、用户与开发者之间的交互，从而获得改进的售后支持以及更有意义的错误报告。



　　显然，随着人们对于基于开放源码的Internet协同开发模式的不断研究和深入理解，必将对未来的软件工程实践产生极其深远的影响。以下按照传统软件工程领域的常规做法，对于开放源码软件的协同开发活动总结出所谓“最佳实践”，以增进读者的感性认识：



（一）技术交流



　　软件开发人员需要花费大量时间用于相互之间的通讯交流，清晰和高效的技术交流对于维持团队间的同步和允许掌握关键知识的个人在需要时利用其知识都是必需的。开放源码社区的一个基本原则是技术交流应当在公共论坛中进行，邮件列表是开放源码交流的基石。不仅如此，开放源码项目需要在精确交流技术细节和小组决策方面得到支持



（二）版本控制、文档管理和发行



　　任何软件开发项目都需要版本控制，开放源码项目在这方面更是需要强大灵活的支持，以使得许多并行的开发人员可以同时工作在相互重叠的文件集上。开放源码项目也需要设计文档、技术文档和用户文档方面的标准模板，并需要一个良好组织的Web站点来发行这些文档。但是，开放源码项目的本质要求这些文件可供全世界访问，同时日常管理成本则被最小化，维护工作被分配给整个开发社区中的成员。



（三）质量保证



　　开放源码软件产品取得令人瞩目的质量水平，这一点在封闭源码开发世界被认为是最困难和最耗费资源的软件开发工作之一。开源软件取得高质量的原因主要包括以下三方面：（1）开发人员是根据自己在相关应用领域的兴趣和知识来自我选择的；（2）开发人员对于项目需求心照不宣，因为他们自己就是软件的用户；（3）技术交流（包括错误报告）是公开进行的。此外，调试工作也由于被分解到许多具有不同知识背景的人手中而更高效。



（四）构建和测试管理



　　开源项目的开发活动是在许多开发人员中发生的连续和并行的行为，有时某个开发人员的更改可能与其他开发者进行的更改发生冲突，通常情况下版本控制活动能够解决这些冲突，但是有时却不行。那些被开发用来支持软件经常自动构建和测试的工具成为帮助尽早发现这类逻辑冲突的强大工具。



（五）项目管理



　　任何项目都需要明确的目标、资源配置和进度安排，开源社区采取独特的、灵活的方式来解决这类问题——共享的“TO-DO”列表用于跟踪那些需要完成的任务，个人的“TO-DO”列表帮助开发人员保持进度，里程碑列表则基于用户和开发者的反馈设置了灵活截止期限。



（六）知识管理



　　知识是区分开发高手和初学者的最具价值的资源，高效地共享知识则是开源社区成功的关键所在。清晰地管理知识可以帮助减少初学者的学习曲线，从而降低潜在贡献者的入门壁垒，同时自动地将专家用于培训他人的负担降至最低限度。[/code:1]

Fujinsan

好文章！将收入ML开发培训教材。

bamfox

[quote:845426d167="Fujinsan"]好文章！将收入ML开发培训教材。[/quote]

Fujinsan船长，这个要是能在开发组内讨论一下就好了。还是你把这个拿去和开发组的成员沟通一下，这样，好慢慢形成一个开发运作的机制。再晚了，我们就可能被大浪给打翻了。

这样，我们就慢慢的走了上正轨。就会赢得更多的支持。

Fujinsan

晕啊！我顶多是“公社人力资源专题站”这条小渔船的摇桨人而已，对于ML项目，我连乘客都不是啊。我也只能从人力资源角度为ML项目作一点后勤工作、尽一份心力罢了；我年纪大了，头脑迟钝了，也已不适合在ML项目内部做技术性很强的事情了。

在很多开发能力比较成熟的公司，项目经理都是从经验丰富、具有专业特长的开发人员中成长起来的，开源软件项目的组织者更是如此了。我相信，随着ML项目进一步开展下去，项目团队的组织协调和沟通交流自然而然会强化起来，只要开发者们脑子里有软件工程的概念，只要大家用对待软件包组织管理技术一样的态度对待项目的组织协调技术，ML的开发模式、ML项目团队的组织机制一定会日益完善起来的！

建议ML项目团队在1.2正式版发布后好好讨论一下如何组织2.0开发的问题，尽量把可能的问题考虑到，尽早找到解决的办法，这样或许会避免不必要的损失。