谈谈我对 可读_可扩展 等6个概念的理解
1.可读性
可读性指的是：人类读者对于源代码的功能意图、流程控制和操作运行是否容易把握。可读性之所以重要，在于程序员会把大部分时间，花费在阅读并试图理解和修改现存源代码上面，而不是编写新的源代码。
影响代码可读的因素包括但不限于：
不同的缩进风格（空白），注释，任务分解，命名约定——用于各种对象，诸如变量、类、子程序。
Fans：以前为了提高程序设计能力，从网上下载了一些项目，比如中国象棋、五子棋等。绝大多数都太恶心了。
罪状至少有以下几条：
a.注释太少。一大段代码连个描述也没有。
b.代码结构混乱。if else太多搞的人受不了。
c.命名不规范。命名没有一个统一的形式，用词不够准确。
Fans的做法：
a.按照Sun公司制定的规范，结合主流开源框架的做法，尽量编写JavaDoc注释。
b.对每一个大点的项目，都写点文档。大致描述下项目的架构或者代码结构。必要的话，画点架构图或者流程图。
c....
2.可维护
软件的可维护性是指理解、改正、改动、改进软件的难易程度。通常影响软件可维护性的因素有可理解性、可测试性和可修改性。
1.可理解性
可理解性是指维护人员理解软件的结构、借口、功能和内部过程的难易程度。
2.可测试性
可测试性是指测试和诊断软件错误的难易程度。
3.可修改性
可修改性是指修改软件的难易程度。
Fans：可维护的概念比较宽泛，包括了可读-可扩展等很多概念。
运维相关或者持续开发升级一款产品的人，理解可能更深一点。
Fans的做法：
把一款软件或者工具的使用方法写清楚，搞个使用手册或者帮助手册之类的。
3.可扩展
可扩展性是软件设计的原则之一，它以添加新功能或修改完善现有功能来考虑软件的未来成长。
Fans：
应该学习一下设计模式；研究一下框架；请教有经验的大牛。
Fans的做法：
1.尽可能配置化。如果有必要，就将程序中的一些参数（比如数据库路径等），接口的实现类等放在配置文件中。
文本格式，xml格式，属性文件格式都可以吧。要因地制宜。
- public abstract class StringUtils {
- // 封装了一个静态方法
- public static boolean isEmpty(String str) {
- return str == null || str.length() == 0;
- }
- }
将一个功能，比如检测一个字符串是否合法，可以写成一个工具函数，public static boolean checkSql(String sql) ，
也可以定义一个接口。
3.可扩展的关键就在于考虑到变化。
根据已有经验，把那些容易改变的东东 封装好，尽量减少其它代码或模块对它的依赖。
4.移植性
Fans：移植性的关键在于 减少对具体平台或软件的依赖，即不要把程序绑定到某一具体的事物上。
比如：a.写C/C++程序时，数据类型的定义不要和某种平台绑定了，据说要使用 size_t之类的，以前学过一点，现在忘了。o(︶︿︶)o
b.文件操纵，不同操作系统文件路径分隔符不一样，要使用 变量，不要硬编码。
c.写访问数据库的程序时，使用标准SQL语句。万一，不同数据库的写法不一样呢？比如分页语句mysql是limit，oracle是rownum 。
5.兼容性
Fans：Windows程序，经常会有这方面的问题。有的软件只能在XP上运行，而不能在Win7上运行。
以前写程序的时候，经常弹出来一个对话框，缺少某个dll。非常恶心。
6.可复用性
Fans：可复用分为很多种，根据不同的分类标准，有如下分类
思想复用：设计模式，架构经验等。
代码复用：
a.函数复用：比如上面字符串判断的那个例子，检验字符串是否合法，读取某个文件。
b.类复用：比如java.uti.ArrayList,直接继承或者组合，可以实现其它的数据结构。
c.模块复用：Apache POI组件，专门用来处理doc，excel等格式的文档，这样就可以使用Java操纵doc等很多格式的文档了。
d.系统复用：mysql-front等MySQL数据库管理程序。以前Fans也写了一个，只不过功能非常弱。
Fans：可读性，可扩展，可维护，移植性，兼容性 等很多概念，都和 复用性 有关。即存在 交集。
可复用是软件产业价值得以实现不可或缺的一部分，可复用是软件不同于硬件等实物的重要区别。
Fans的做法：
1. 认真学习和研究设计模式，拼命研究Struts2等开源框架。
2. 将自己写的工具类和开源框架等工具类 中有价值的，放在一起，经常参考。
比如文件操作相关的，非常常用，一次编写，处处使用。
3. 将自己已有的心得体会，已有的编程技能和技巧等东东 日志化。
4. 写点需求文档、设计文档等。
------------------------------------------------------------------------------------------------------------------
本文写得比较浅显，也不够全面，但是比较具体，有些地方可以借鉴。(*^__^*)