软件开发核心心得
在一个有效的组织中,必定拥有杰出的一线人才。软件设计也是一样的,一线人才的素质决定了软件的质量。从敏捷的观点来看,代码是检验软件过程是否有效的最终标准。目前为止,以及在短时间的未来,我们都不太可能完全脱离代码进行软件设计。所以,软件过程中的任何一个活动都是为了能够产出优秀的代码。所以,代码才是核心。
1. 代码是软件开发的基础
编码是软件开发过程中最基本、最底层的技艺,然而也是最重要的技艺。任何一个领域的专家都需要花费大量的时间来进行基本技艺的锻炼,木匠需要花费大量的时间来锻炼他们对各种工具的掌握,厨师则需要练习刀工和火候。程序员也是一样的,对我们来说,语言的各种特性必须要了然于胸。而对软件的管理也需要从代码做起。
从2000年到现在,国内兴起了一股软件工程热,需求管理、配置管理、甚至CMM。面对纷至沓来的各种方法学、UML、OOA,大家似乎已经热衷于这些概念本身了,却往往忽略了软件开发中最基本的元素:代码。在和很多软件组织的接触过程中,我们认为大多数组织急切需要的并不是这些工程理论,不是说这些理论不重要,而是这些组织的症结不在于此。很多的组织连代码的质量都管理不好,又何谈其它呢?代码管理是基础的基础,从管理的角度上来看,任何一个组织的管理都需要一个从上至下的管理过程,有基层的管理人员,也有高层的管理人员。对代码的管理就是软件开发中的基层管理,它起到的作用就是能够把需求、设计的思路贯彻到最终的代码中。
“管理无大事”。对软件的管理也是一样,大部分的问题都是由于很小的原因引起的。例如,一个产品如果后期在debug上花费了大量的时间,那么,这种现象是由于什么原因引起的?一种可能的原因是前期的代码设计中对代码质量的把握不严。每一次代码功能的演化并不会产生太多的问题,但是当代码累积越来越多的时候,问题也就慢慢出现了。那么如何解决呢?可以加强QA的力量,也可以引入复审,还可以引入单元测试。总之,要有一种方法对代码进行控制。
软件的开发过程就象是一部精密的机器,任何一个环节的变化,都会对其它的环节产生影响。把软件过程按照瀑布的形式进行划分是一种分解的处理思路,但同时我们还应该看到不同活动之间的相互影响。软件开发中的生命周期模型也是一个层次模型,从业务建模一直到软件实现,需要跨越数个层次,同样会出现执行不力的情况,例如,代码设计偏离需求、偏离设计的情况比比皆是。
如何避免这种情况呢?这就需要我们从源代码的角度,反思其上游的实践活动,是否足以约束代码设计?就拿XP来说,他解决这个问题的方式是尽快的进入代码开发阶段,从代码开发中发现问题,并在下一轮的开发中解决。这种思路是正确的,但XP毕竟是方法论,他不会告诉你过于细节的东西,尽管XP已经提供了大量面向代码的实践。因为方法论的抽象级别比较高,使得他必须舍弃部分的细节。而这篇文章告诉你的,就是这些细节。就像我们在下一节中讨论的例子,需要在代码中加入对异常的处理,那么,异常的源头在哪里呢?是需求,在需求中,我们发现了一些业务的非正常的处理序列,发现了一些业务实体的限制性的要求,所以在代码实现中,就需要有相应的异常处理。在例如,一个优秀的异常处理,还需要让客户端程序员了解可能发生的异常,以保证不同代码间正确的集成。
2. 面向对象的代码
面向对象的代码已经在现在的软件开发中占据了主流的位置,面向对象的思路也有其优势所在,就像后文所讨论的,面向对象代码有着非面向对象代码的很多优势,而软件业中很多新的思潮的产生,也都是基于面向对象语言的,所以我们关注的代码将是面向对象代码。
面向对象的思想来自于抽象数据类型。对于面向对象来说,它最重要的改进就是把世间万物都描述为对象,而类则描述了同一种对象的特征,而不是像传统的开发方法那样,按照机器指令的执行顺序来进行设计。当然,面向对象代码最终仍然是要按照时序来执行的,但是从程序员的角度看来,面向对象代码更侧重于对象之间的交互,多个对象各司其职,相互协作以完成目标。而面向对象技术的发展,也是朝着更加贴近我们世界观的方向发展。从这点来看,有人说完全没有程序设计经验的人学习面向对象可能会更加的容易,因为他不需要从原先的时序程序的桎梏中摆脱出来,但这未必是事实。面向对象决不是一种简单的程序设计思路。这是我们的观点,也会在下文中反复的论证。
和所有的职业一样,程序员,或者是面向对象程序员,始终坚持的一点就是严谨。你会看到各种各样优秀的代码,但那决不是一次能够写成的,要不断的尝试,不断的改进。为什么重构和测试优先是敏捷方法中很重要的一项实践?因为程序员不是神,他们需要慢慢改进他们的代码。虽然罗马不是一天能够建成的,但是在编写面向对象代码的过程中,有一些实践是需要坚持的,它体现了我们所说的严谨。
3. 编写并管理面向对象的代码
编写优秀的面向对象代码并不是一件容易的事情,优秀的OO代码如行云流水,糟糕的OO代码让人觉得浑身起鸡皮疙瘩。编写优秀的OO代码要求程序员有一定的自我修养,能够以抽象的思路看待问题,找到问题的核心并对问题域进行分解。它强调的是一种解题的思路,但这个解不是唯一的。
典型的例子是设计模式,设计模式确实给了我们以很大的启发,通过它,我们能够了解到优秀的代码是如何用于解决实际问题的。但是是不是你必须在软件中照搬设计模式呢?如果你这么做,那么你对设计模式的理解仍然不够。我曾和在建筑行业的朋友聊起Christopher Alexander的建筑的永恒之道。他很兴奋的告诉我,那确实是一本很好的书,能够引发人很深的思考,但是现在也有另外的一种观点,认为美仍然是无形的,应该发自建筑师的内心。对这句话我思考了很久,其实建筑是给人使用的,因此最重要的是它能都给人带来的价值,隐含在其中的那种活生生的气质,这是建筑师文化底蕴的外在表露。所以,Christopher Alexander在那本书中的目的,也是为了找到一种总结自己观点的方法,来总结自己对人文的认识。至于现在大家对他的思路提出了质疑,那也是一件好事,这说明大家对建筑之道的认识到了新的高度。建筑是这样,软件中的模式也是一样的,我也曾热衷于研究模式的使用,直到某一天我猛然惊醒,与其沉迷于模式的表面形式,为什么不去研究隐藏在它背后的文化底蕴呢?武侠小说中常说无招胜有招,模式的应用也应当到达这个境界,你如果可以在不经意间应用模式的思想,那又何必拘泥于模式的形式呢?
编写优秀OO代码虽难,但还有更难的事情,就是让整个开发团队都产出优秀的OO代码。我们刚才说了,OO对问题的解不是唯一的,但各个不同的优秀解汇集到一起,可能就是一个糟糕的解,这是风格和架构的问题。你如何在团队中制定制度,营造氛围,让优秀OO代码成为团队最终的成果?这些问题,在我看来,要比CMM难得多,这个问题并不是靠花钱就能够解决的。如果能够解决这个问题,这个团队的创造力一定是惊人的。
4. 面向对象软件开发过程
普通的软件开发过程和面向对象开发过程有着很大的不同。回想我们在非面向对象中开发过程中,最经常采用的任务分配方法就是以软件模块为单位,这样的好处是分配简单,不同任务之间耦合程度低,容易操作。坏处是几乎无法做到重用,也缺乏整体性的设计。而面向对象软件开发则不同,它是以类、类集合作为基本单位的。类之间关系错综复杂(虽然我们提倡低耦合的设计,但类之间的关系仍然是相对复杂的)。这种情况下程序员之间相互协作的要求就非常之高,这种关系如果处理恰当,则能够完全体现出面向对象的威力,否则,那将会是一场大灾难,面向对象的软件开发过程要养成一些好的习惯:
4. 1 尽量简化和稳定客户端。
个人编程可以是一种享受,但团队开发始终是一项严谨的职业活动,因此多考虑别人,不要设计复杂的接口,虽然你省事了,但这会给理解和使用你的接口和人造成障碍。
4.2 准备一份简洁的文档,并保持更新。
随便一种形式的稳定,可以是代码,可以是UML图,也可以是纯粹的文字(估计没几个程序员喜欢这种形式)。只要它能够传达你的代码的目的,那就足够。记住,更新代码后,同时更新你的文档。过期的文档不仅是废纸这么简单,它会给其它人造成麻烦。切记!
4. 3 尽可能多的考虑异常和错误的情况。
写出一个功能并没有什么,但是要把这个功能写的非常的完善那就很难了,因为你需要考虑各种各样的情况,正常的、非正常的。所以,写完一个类的定义应该是,完成编码和稳定,并通过原定的测试。本文摘自惠集网.