理想的软件设计标准
前几天一个朋友提到我的博客中空空如也。确实,到园子里也有段日子了。确实也该放点东西了。要不也太对不起DUDU了。这几天又比较清闲,将读书笔记及自己的心得记录下来
McConnell 大侠说如果设计能实现如下目标,那么就是非常好的设计了。
一:最少的复杂度
简单来说,就是要易于理解。McConnell特别还指出了要避免“聪明的”设计。 另外我们在设计某处的时候要能够安全的忽视其它部分才算合格。
二:易于维护
这点主要是为做维护工作的程序员着想的,不过我们写的代码,大多数时候做维护的还是自己吧。如果你能一看函数名或代码就能了解它们的作用的话也就OK了。
三:松耦合
作为软件设计的军规之一。各部分的关联越少意味着你在测试,集成,维护的时候可以轻松不止一点点。
四:可扩展
套用句"古话":做软件唯一就是变化。如果你的作品是不可适用变化的话,基本上就可以贴上不合格的标签了。也许你会说我改代码就可以了。当然可能要修改代码,但面向对象的设计原则里有条,类是可扩展还不可以修改的。扩展一般是通过继承来是想的。而修改特别是接口往往会引起许多莫名其妙的问题的。总之:你在给自己软件加功能的时候不要对底层甚至架构大动干戈就对了。
五:高扇入
扇入?扇入是什么东东?我以前还真不知道(我专业是物理学,半路出家写代码的!)仔细一看原来就是指被其它类或方法引用。那高扇入也就是说你这个类/方法...被很多其它类引用了。也就是利用率很高了。按照我的想法如果段代码我连写了三次,我就会把它单独作为一个方法或类
六:低扇出
扇出自然就是引用其它类或方法了.按Bob大叔的说法,扇出越高,类就越不稳定,因为任何一个引用对象出问题了,这个类也就会出问题。另外McConnell 说了:引用超过约七个就算高扇出了.
七:可移植
这点我觉得大家设计的时候还是得MVC啊。要不哪天客户要求你从B/S转为C/S你就有的忙了。这点我觉得喜欢在页面写逻辑的兄弟得特别注意了。虽然看起来没有双击就写代码那么爽,可实际还是能省不少事的。
八:精简性
能少不多,你不能觉得工厂模式爽,就有事没事都加上,这是不对的。另外写《移山之道》的邹欣也说过,程序员不能觉某个功能可能有用你就加上.因为这会增加测试等方面的任务,而且程序员认为用户会喜欢的往往用户偏不喜欢
九:层次性
层次性,最常见的就是大家说的三层架构了。好处有几个,你换了数据库而不必管上层。另还有一个就是更好的分工。经验不足的小伙子写的初级代码可以禁闭起来。以后想重构就重构,想换掉就换掉。也就减少了复杂度了。
十:使用标准技术
这样会给大家熟悉的感觉.如使用相同的框架,代码风格应该使用相同的标准,可以套用设计模式的就套用一下咯,不要自己整个新的花样出来,毕竟看熟悉的东西容易理解。
代码大全上就这么十点,我觉得还可以加上一点,
十一:高内聚
也就是说一个类特别是一个方法应该专注于一件事。比如你的 I男朋友可以有陪女朋友()方法,但就不可以有写代码()方法。因为写代码()方法是I程序员接口才有的.
而在陪女朋友()方法中你不可以顺便就将花钱这个操作加在里面,因为偶尔有一次陪女友是陪她在家看电视的,自然也就不需花钱了.