软件设计开发特征（软件开发自学步骤和方法）

随着北京爱狄特业务规模的不断扩大，iAMS产品研发团队规模也在水涨船高。新同事带来了新的战斗力，而学习和磨合也是不可或缺，趁着新鲜劲还热乎着，就赶紧给程序员们来了一次关于软件设计开发经验的培训会。在这里，我将其化为文字版本，以便大家参考和点评。

本文的主要内容有三个方面：设计、开发，以及由于特别重视而单说的质量和效率。

首先谈设计，在软件的设计中，最重要是什么，是精致美观的结构还是稳定高效的框架？都不是，更好的满足用户需求，永远都是最重要的，也永远都是设计中最核心的问题。用户的需求往往繁杂冗余、变更频繁、相互交叉甚至互相抵触，在承担了需求分析的设计师眼中，它们宛如在非洲大草原上肆意奔腾的野马想要跨越我们的大脑，腾空而去，留下千疮百孔的软件和半途而废的项目。我们需要一把缰绳使其乖乖听话，这个神奇缰绳就是概念完整性。

什么是概念完整性？不好理解？那先举个例子。

图1-米兰大教堂

米兰大教堂，位于意大利米兰市，是世界上第二大教堂，1386年奠基，竣工于1965年。

图2-科隆大教堂

科隆大教堂，是德国科隆市的标志性建筑物，始建于1288年，1880年建成。

这两座举世闻名的教堂有着相似的经历，设计风格为哥特式，开工时间在中世纪，经历了五六百年的施工直到近代才完成，然而它们的最终样式却各具特色。

米兰大教堂是欧洲人合力建成的，它的项目主导权辗转于法国人、意大利人和德国人之间。历任设计师有着不同的想法，最初的设计师采用了欧洲正流行的哥特风格，而到了16世纪他的继任者则觉得哥特是外来文化，应该使用本地风格。当时的米兰正是文艺复兴中心，所以我们能看到“罗马”式的圆柱和方尖碑。17-18世纪的巴洛克风格、19世纪的新古典主义，它们也强烈影响了教堂的建造工作，中间也有一些原教旨的设计师试图要复原最初的样式。所以今天我们能看到哥特式，巴洛克式，新古典式等不同时代和不同民族的建筑风格。

科隆大教堂的情况就描述起来简单了很多，它的历任设计师都坚持同样的信仰，绝对忠于最初方案，牺牲了自我的创意，获得了纯粹的设计。

两个教堂都是人类文明的瑰宝，当我们怀着崇敬的心情去欣赏时，我们的感受是不尽相同的。米兰大教堂繁美华丽，其构造风格各异，你不能试图用一个词去描述它。科隆大教堂则会让人觉得这就是哥特。其实说到这里我们的概念完整性已经呼之欲出了。

所谓的概念完整性就是指概念的表述是否能够完整一致。在这里作为教堂这个概念而言，两个教堂的概念都是极其完整的。但从建筑风格的概念而言，米兰大教堂由复杂不相容的细小概念组成，整体概念不完整。这种不完整性引来了很多严厉艺术批评，但这并不妨碍它受人尊敬和喜爱。因为它不只是作为建筑而存在，它完美的记录一个城市乃至一个文明的宗教、文化、科技的发展和变迁，它是精美的艺术品也是宝贵的历史资料。

如果我们建造一个现代玻璃外墙，内部装饰是罗马风格，家具来自宜家，但房顶是雕梁画栋、勾心斗角的传统中式建筑作为地标，那它只会招来大众的指责和唾弃，当然也没人愿意这么做。制造软件也是一样，我们不会花几个世纪的时间，也不是为了表现不同的文化而让博物馆收藏，甚至无法让人去理解其逻辑，我们只是为了方便用户完成他们的最重要的需求。概念完整性是指导我们处理需求到设计乃至整个软件生命周期的中心思想，凡是符合这个中心思想的都要认真执行，反之则去繁就简。

从MULTICS到UNIX，从企业ERP系统到大数据中心的建设，软件工程史上各种成功和失败的例子比比皆是。这些事实告诉我们，如果无法获取概念完整性，那么你的工程就注定前途渺茫。

那么如何辨别是否具有概念完整性？

——如果可以用简洁的方法解释说明它，它就具有。

OK，这很容易理解。那么如何获取概念完整性呢？

——专制

这听起来也许有点不可思议，尤其是对于经历了文艺复兴，自由主义泛滥，而且发明计算机科学的欧美人。但事实上正是他们首先肯定了这一点。想想我们知道的一些组织机构，那些可以对问题做出快速而持续一致的反应，那些可以更有效运用庞大的资源。是平均约每两年就可以推出一次DX新标准的微软，还是从1.0到2.0中间跨越了12年之久的OPENGL架构评审委员会？是有成立的专门公司的RedHat，还是那些发行自己Linux版本的某些开源社区？说到Linux，我又想起了那些让人头疼的桌面子系统，那些乱七八糟的问题你在Windows/MAC OS上通常不会遇到。而且即使Linux系统的生态体系中，Linux内核是一直在Linus Torvalds和它后继者Kroah-Hartman个人的领导下而一直发展至今的，而不是一个权利均等的投票式委员会。我这里的意思并不是说民主式的组织机构一定不好，而是说，对于概念的完整性，这种组织形式不太适用，除非它们还有个可以自主决策的委员长。

毫无疑问，在一个组织机构的内部，其意见是精彩纷呈或者大相径庭的，如果仅仅把这些都罗列出来，然后分头行动，那么事情虽然可能投入很多人力物力和时间，但必然失败。其原因就在于没有概念完整性，很多东西主体毫不相关甚至互相矛盾，从而妨碍整个事情的完成。为了防止这一点，我们可以把发言权交给每个人，但必须把决策权集中到少数人甚至一个人手中，。在软件行业中，我们称这种人为架构师。他的工作经验更长久，他的工作产物的生命周期要比开发人员的更长，他一直处理解决用户问题实现用户利益的核心地位，他“民主”的听取广大研发人员的意见，并“专制”的做出决断。决策是他应得的权利，也是他应该承担的重大责任。

最后我们看个漫画