作者：飞云小侠    来自：CSDN

　　为了给朋友同事一些设计问题上的指导，特撰写此文，很多观点都是从别人的文章中获取，有些观点肯定也有偏颇，有些观点也仅仅是提出并没有做详细论述，请多拍砖，以便改正。

　　【概述】

　　在工作中，作为一个程序员或者一个设计师，总是要设计一些函数库或者一个框架，当然最经常的还是做项目，即使是一个项目，也会被经常改动，甚至交给别人改动。
　　当你做这些工作的时候，你的这些成果都是要给别人了解使用的，或者说给以后的你使用的，为了别人的方便或者为了自己的方便，我们要尽可能做好设计。
　　

　　【放正心态，任何东西都是不断发展的】

　　技术是日新月异的，每一天都有新的技术出来，正所谓"山外有山，人外有人"，每一个新的轮子出来，都可能比你要设计的轮子好，所以在设计的时候，应该了解一下是否已经有了类似的轮子，是否要设计一个新的轮子。

　　即使你的轮子已经设计好了，也不好认为自己的轮子一定比别人的轮子好，虽然你的轮子可能更适合你的实际使用。

　　技术在不断的发展中，你以及你的朋友/同事都在不断进步，"士别三日，当刮目相看"，所以不要认为你的水平一定比别人高，"尺有所短，寸有所长"，所以别人对你的函数库/框架提出意见，提出疑问的时候，请不要惊奇，不要反感，不要认为别人在"挑刺"，也许你的函数库/框架早就不适合当前的发展了。
　　
　　态度决定一切。你的领导或许更重视这一点。
　　
　　【必要的组成部分:单元测试，文档，实例，手册etc】

　　单元测试，文档，API Doc，手册，演示程序，Change Log，Readme，build。xml等等

　　有一天别人使用了你设计的函数库/框架，当你升级后，原来的项目却不能工作了，经过一天的调试，你终于找到了原因，原来是不小心写错了一个东西。

　　你肯定不希望上述的事情发生，那么请你写单元测试吧，这样既不浪费自己的时间，也不耽误别人的工作，何乐而不为。你花在写单元测试的时间/带来的乐趣和你升级后改正莫名其妙的错误的时间和苦恼相比，肯定更有价值。你看到单元测试的绿条，难道不感到高兴吗?!

　　如果你不能保证你的程序修改没有错误，不要指望你的同事认为你的错误是可以容忍的，他们在心里早就开始骂你了，呵呵。写单元测试吧
　　
　　看看任何一个知名的框架，都包含完善的文档，单元测试，示例程序，用户手册，那么请你也包含这些吧。哦，对了，请详细地写好JavaDoc，它很重要。
　　
　　使用你的框架/函数库的人如果到处去找使用方法，去找某个类(但是他不知道是否有这个类)，那么说明你的文档没有到位。如果你希望别人使用你的这个类或者功能，那么请写好文档，不要指望别人去读你的源码然后就能理解它是干什么用的。
　　
　　如果你做到这些，那么你的函数库/框架也有了"知名"的前提，难道不是吗?如果没有，我想是没法让别人更好地使用的。
　　
　　对了，有了这些东西，还要有一个良好的目录组织，这个也可以参考别的框架的组织方式。

　【借鉴成熟的设计，参考已有的项目】

　　1. 要做一个新的东西，没有想法。不要惊讶，我肯定先找一个现有的东西来借鉴。
　　
　　当然前提是不要重新发明轮子，或者是你有充分条件要重新发明一个轮子。
　　Struts，WebWork，Spring等等都是成熟的框架，不管你使用起来是否符合你的习惯。
　　在你成为大师之前，你的设计思想估计前人都已经提出并实践过了，所以要勇敢地去借鉴。"站在巨人的肩膀上"我们能更近一步。
　　
　　例如我们厌倦了在访问数据库时使用如下的代码:

　　try
　　{
　　//your code here
　　}
　　catch(Exception e)
　　{
　　//catch Exception
　　}
　　finally
　　{
　　//must do something
　　}

　　我们就可以借鉴Spring框架的JdbcTemplate类，看看它是如何利用回调函数来处理的。
　　
　　我们使用hibernate时是不是也会使用类似上面的代码，那么可以参考Spring框架的HibernateTemplate。
　　
　　借鉴也是一种捷径。
　　
　　警告:借鉴但不要抄袭，借鉴代码要注明来源，尊重他人也是尊重自己。
　　
　　2. 在实际的项目中，往往可以参考已经有的项目来做自己的设计。
　　
　　例如做一个网站，我不知道如何访问数据库，如何布局，如何分层，那么我们可以参考已经有的网站程序，看看别人是如何利用SiteMesh或者tiles布局，如何使用Hibernate来访问数据库或者使用已经封装好的JDBC类来访问数据库，如何利用Struts，WebWork或者其他访问来分层。

　　【遵守约定俗成的一些做法】

　　为了使别人更方便地使用你的东西，那么在设计一些通用的函数或者类的时候，请遵守通用的做法，不要与众不同，除非你的内部实现确实与众不同。

　　例如实现一个类似ArrayList的类，那么请不要这样写:

　　public int count()
　　{
　　return list.size();
　　}
　　public Item getItem(int i)
　　{
　　return list.get(i);
　　}
　　
　　而应该这样:

　　public int size()
　　{
　　return list.size();
　　}
　　public Item get(int i)
　　{
　　return list.get(i);
　　}
　　
　　当然每个人都有自己的想法，如果你非常认为你原来的方式比普通的好，那么请提供2套方式供别人选择。它不会给你带来麻烦，只是一个一看就懂的做法，不用怀疑，这样做有好处。
　　
　　很多类的设计都有一些约定俗成的做法，那么在你设计一个新类的时候，先借鉴一下吧，多看看JDK的源码/文档，看看别人是怎么实现的。这更有助于推广你的成果。
　　　　
　　【不要迷信权威】

　　在使用已有的框架或者函数库时，不要认为所有的东西都是正确的或者是最好的最好，肯定不是。没有完美的东西，已经存在的东西在设计的时候因为种种局限或者因为作者的水平，对现在来说肯定存在不合理的设计，或者过于理想化的设计，而不能满足实际情况。
　　
　　不迷信权威，才能到达新的境界。

　　【不要轻易排斥，不了解就不要草率发表意见，要严谨】

　　在网上经常看到。Net和Java的比较/火拼，或者是Struts VS Webwork或者是其他等等，非常之多。经常看到的是一方对对方的东西不甚了解，就开始批评，结果说不到点子上，反而被嘲笑一番。
　　几种技术的比较有时候是必要的，例如技术选型的时候。但是如果一些对这些技术根本不了解的人来选型，来评判，你能对结果信服吗?
　　存在就是合理，任何技术都有其存在的理由，虽然有些东西早就过时了，但是在当时它也是应运而生的。
　　几种技术，都是来解决同样的问题，但是问题也有很多方面，解决方式也有很多种，每个人的想法也都不一样，思路也不一样，所以没有绝对符合要求的技术，但是应该有符合你的技术，不符合你的技术不等于也不满足别人的要求。所以不要轻易排斥别的东西。
　　
　　在做技术比较的时候，如果你不了解，那么请不要轻易发表意见，至少你可以亲自去了解，去实践之后在发表你的意见岂不是更好。
　　
　　在发表意见的时候，也要严谨，不要轻易下结论，要经过求证，否则一旦错误只会让对手笑话，让你的同事看不起你。例如你说Hibernate3不支持jdk1。3，那么最好去好好找到你的证据，否则就会成为错误。(Hibernate3支持jdk1。3)
　　
　　作为一个技术人员，严谨应该是我们的习惯之一，无论做开发还是做设计。

　　【处理好你的异常】

　　异常处理是Java编程中非常重要的一个部分。建议在使用异常之前阅读或者。
　　
　　下面从书中摘出几条建议:
　　* 绝对不要忽略异常
　　* 千万不要隐藏异常
　　* 仅在不正常的情况下使用异常
　　* 对可恢复的情况使用可检查异常，对程序错误使用运行时异常(RunTimeException)
　　* 给方法引发的异常做文档
　　* 在详细信息里面包括失败捕获信息
　　* 使用finally避免资源泄漏
　　* ....
　　
　　在这里特别提出的是，在开发中要特别处理NULL的情况，否则经常引发NullPointException异常，在Java里这是一个最令人头疼的异常了。
　　如果你的程序因为一个NULL值，而报了几十个NullPointException的话，不但得让人烦死，而且还非常难以找到错误所在。所以在Java中一定要注意这个问题。
　　如果你的函数不允许Null值，那么可以截获它，抛出一个异常，或者给客户更友好的提示，难道不好吗?
　　
　　让我们来看一个例子:

　　public String getName(User aUser)
　　{
　　//如果aUser为Null，会发生什么情况
　　return aUser.getName();
　　}
　　
　　很明显，如果参数为Null，就会抛出异常。应该改为:
　　public String getName(User aUser)
　　{
　　if(null=aUser)
　　{
　　return "";
　　}
　　else
　　{
　　return aUser.getName();
　　}
　　}
　　
　　或者你要求参数不能为空，还可以抛出一个异常，强制使用者不能传入空值。
　　
　　还有经常被忽略的是RunTimeException和普通异常的区别，在Java中，这是一个特殊的异常类，程序中如果遇到这个异常，用户可以不截获它，而如果是其他的普通异常，就不许要截获它。我们的代码经常这么写:
　　try
　　{
　　//your code here
　　}
　　catch(Exception e)
　　{
　　//do warn
　　}

　　这样写的话，就截获了所有异常，当然也包括了RunTimeException。 在很多情况下，这是不合适的处理方式，我们只应截获必要的异常，而应该忽略RuntimeException。
　　
　　关于RunTimeException，在Spring中还有更好的利用方式，建议阅读Spring框架中在事务中对异常的处理代码，例如对Jdbc抛出的SqlException的转换。
　　
　　关于异常处理，我提出几点建议:
　　* 捕获异常而且再次抛出时要包含原来的异常信息
　　* 不要忘了RunTimeException，除非必要，否则不要用catch(Exception e)的方式捕获所有异常。
　　* 不要用异常做流程控制，异常的性能代价比较高昂。(对此，可能有人不同意。此处不详细讨论)
　　* 不要把异常处理都抛给别人，本函数有能力处理的就不要抛出。
　　
　　在此建议读者详细阅读或者。
　　
　　【过度依赖】

　　在定位错误的时候，经常遇到浏览了七 八个文件还是没有找到什么地方执行了真正需要的函数，这个时候就非常郁闷。A调用了B，B调用了C，C调用了D。。。。。。让人找不到北
　　
　　面对这样的程序，存在的问题不仅仅是定位错误麻烦，而且如果需要维护这样的函数库/框架，恐怕你的有非常高的统御能力才行，否则打死我也不去维护。
　　
　　那么我们自己最好不要写这样的程序出来给人用。

　　【滥用接口】

　　现在流行"面对接口编程"，这本身本来是不错，但是滥用接口的现象却经常发生。
　　"面向接口"，于是所有的类都有一个对应的接口，接口的函数声明和类一模一样，而且一个接口只有一个类来实现它。这样的面向接口有什么意义哪? (为了用Spring的事务的情况除外)
　　
　　根据"迪比特法则(Law of Demter)"，一个对象应当对其他对象有尽可能少的了解。一个接口内应该只定义对方所需要的方法，而不要把一些没用的方法声明放在接口里面。
　　
　　例如如下一个类:
　　
　　public class MyCounter
　　{
　　private int n1;
　　private int n2;
　　public MyCounter(int n1，int n2)
　　{
　　this。n1=n1;
　　this。n2=n2;
　　}
　　
　　public void setN1(int n1)
　　{
　　return this.n1 = n1;
　　}
　　public void setN2(int n2)
　　{
　　return this.n2 = n2;
　　}
　　public int getN1()
　　{
　　return n1;
　　}
　　public int getN2()
　　{
　　return n2;
　　}
　　
　　public int getResult()
　　{
　　return n1 + n2;
　　}
　　}

　　我们可以看到，这个类的主要目的是得到计算结果，所以正确的接口应该类似:
　　　　
　　public interface Counter
　　{
　　int getResult();
　　}
　　
　　但是很多情况下，经常是这样的接口:
　　　　
　　public interface Counter
　　{
　　int getResult();
　　int getN1();
　　int getN2();
　　void setN1(int n1);
　　void setN2(int n2);
　　}
　　　　
　　我们想一想，这样做有2个后果:
　　1. 除了getResult之外，其他的函数我们根本用不到，所以是多余的。
　　2. 如果我们要自己实现一个Counter，如果接口中仅仅定义了getResult，我们仅仅需要实现它就可以了。我们自己的类可能是多个数运算，有乘除加减等等各种运算，参数也有可能是一些数组。但是如果按照第二种方法声明接口的话，我们就必须实现后面的四个方法，如果这样的话，实现这样东西不仅没用，而且浪费时间。我们恐怕要大声骂娘了吧。
　　
　　所以，接口有好的作用，但是不要滥用。
　　■ 如果你的接口永远只有一个类实现，那么可能就没有必要用接口。
　　■ 你的接口只需要声明别人用到的函数即可。

　　【空接口的使用】

　　在接口使用的时候，空接口有2种情况:
　　1. 类似Cloneable，Serializable，他们往往是做一个标记，表示需要某个功能。当然你也可以这么用，来表示你的类具有某个功能，实现了你的某个接口。
　　2. 你的接口继承了别的接口(非空)，你的接口本身没有声明函数。这种情况一般是你不希望用户使用父接口来作为参数类型，因为他们的用途可能不同，此时就可以用空接口来实现。
　　
　　第一种情况我们不再多说，搜索一下关于Cloneable，Serializable的文章就会了解很多。
　　我们来看下面的代码:

　　public interface Text
　　{
　　String getText();
　　}
　　
　　public interface SqlText extends Text
　　{
　　}

　　可以看到，Text接口是用于返回一个字符串。而SqlText是一个空接口，它继承了Text接口。也就是说SqlText也是一种Text。但是我们可以知道，任何一个字符串不一定是Sql字符串，所以此时声明了一个SqlText接口来用于表名当前的字符串是一个Sql字符串。你的函数可以这样声明:

　　public void doQuery(SqlText aSqlText)

　　而不是这样
　　
　　public void doQuery(Text aText)

　　避免用户产生歧义的想法，一眼看去，就明白应该传入一个Sql字符串。
　　
　　【继承层次过多】
　　一般来说，继承的层次不要过多，否则使用者可能会讨厌，找一个函数会很麻烦。很多Java语言检查工具都建议你的继承层次不要超过3层。
　　
　　【Has A ，Is A，不要滥用继承】

　　"我是一个Mp3"，"我有一个Mp3"，其实很容易分辨。但是在实际应用中，往往存在把"我有一个Mp3"的情况当作"我是一个Mp3"，或者是为了偷懒方便而放松了对自己的要求，甚至还沾沾自喜，感觉找到一个捷径。(scud以前也干过这种事情)。
　　
　　以前我曾经这样干过:我的逻辑类直接继承了我的数据库访问类，这样我可以直接在逻辑类里面访问:
　　
　　public MyLogic extends MyDBA
　　
　　aLogic.getInt("click");
　　aLogic.getString("name");
　　
　　看起来是非常方便，但是你的逻辑类就牢牢绑在了DBA上，是一种非常不好的做法。现在我这样声明:

　　public MyLogic
　　
　　MyDBA adba;
　　
　　adba.getInt("click");
　　adba.getString("name");

　　其实代码改动不大，但是你的逻辑类不在牢牢绑在DBA身上了，何乐而不为。
　　
　　其实这种现象在开发人员中间可能经常见到，我们要尽量避免。下面再来看一个例子:
　　
　　//一个保存分页信息的类
　　
　　public class PageInfo
　　{
　　private int page;
　　private int pageCount;
　　private int recPerPage;
　　private int recCount;
　　
　　//get，set method list...
　　}

　　一般的情况是，在Dao中进行分页查询，计算总记录，总页数等等，所以需要把PageInfo传给Dao。而在逻辑类中，把传回来的分页信息数据推到FormBean或者是Action中。
　　也许你会这么想，如果我的Action或者FormBean继承了PageInfo，岂不是要省很多事。
　　
　　千万别这么干。并不是所有的动作都需要分页信息，你的FormBean和PageInfo没有继承的关系。也就是说FormBean Has A PageInfo，但是不是Is A PageInfo。
　　
　　【保持外观/行为一致】

　　外观一致其实很容易理解，例如你用size()表示得到一个List的大小，那么在所有的List类中你都用size()得到它的大小，这就是外观一致。
　　外观一致让用户更方便使用你的函数库，不用记住几个不同的表示同一个功能的函数名字。或者几个名字相同功能却不同的函数。那就很糟糕了。
　　
　　行为一致相对外观一致就相对比较难做到，但是优秀的设计师肯定会让他的成果行为一致，而不是出人意料的行为，也不是一套强行规定的行为。
　　
　　我们来看下面的代码:
　　
　　import java.util.HashMap;
　　import java.util.Map;

　　class UserInfo
　　{
　　private String realname;
　　
　　public UserInfo(String sName)
　　{
　　this.realname = sName;
　　}
　　
　　public void setName(String sName)
　　{
　　this.realname = sName;
　　}
　　public String getName()
　　{
　　return this.realname;
　　}
　　}
　　
　　public class MyTest
　　{
　　
　　Map userInfoMap = new HashMap();
　　
　　public void setUserInfo(String sName,UserInfo aInfo)
　　{
　　userInfoMap.put(sName,aInfo);
　　
　　userInfoMap.put(aInfo.getName(),aInfo);
　　}
　　
　　public UserInfo getUserInfo(String sName)
　　{
　　return (UserInfo)userInfoMap.get(sName);
　　}
　　
　　public static void main(String args[])
　　{
　　MyTest aTest = new MyTest();
　　
　　UserInfo aUserInfo = new UserInfo("王小二");
　　
　　aTest.setUserInfo("儿童团团长",aUserInfo);
　　aTest.setUserInfo("三班班长",aUserInfo);
　　
　　UserInfo 儿童团团长 = aTest.getUserInfo("儿童团团长");
　　
　　if(null!=儿童团团长)
　　{
　　System.out.println(儿童团团长.getName());
　　}
　　else
　　{
　　System.out.println("儿童团团长 Not Found");
　　}
　　
　　UserInfo 王小二 = aTest.getUserInfo("王小二");
　　
　　if(null!=王小二)
　　{
　　System.out.println(王小二.getName());
　　}
　　else
　　{
　　System.out.println("王小二 Not Found");
　　}
　　
　　}
　　}
　　可以看到，上面的代码运行结果是"王小二"，也就是说儿童团团长是王小二，王小二本身也是王小二，这一切正常。
　　
　　现在我们把setUserInfo里面的第一句注释掉:
　　
　　public void setUserInfo(String sName,UserInfo aInfo)
　　{
　　//userInfoMap.put(sName,aInfo);
　　
　　userInfoMap.put(aInfo.getName(),aInfo);
　　}

　　再次运行上面的代码，我们发现儿童团团长不存在了，但是王小二还在。还可以看出，如果找"三班班长"的话，肯定也找不到，也就是说只有依据王小二的真名才能找到王小二，其他方法就不行了。
　　
　　从上面的setUserInfo和getUserInfo分析，如果采用修改后的代码，我们的程序就出现了行为表现不一致，而这是令人迷惑不解的，我们set了半天，却找不到，岂不是令人恼火!
　　
　　当然上面的代码比较简单，通过简单的修改就能做到行为一致，但在实际编程中，往往因为复杂的行为操作，经常会造成行为不一致，从而给开发人员带来困惑。

　　【MVC，MVC2，WEB设计编程的分层】

　　请阅读文章 http://forum.javaeye.com/viewtopic.php?t=11712&postdays=0&postorder=asc&start=0

　　【可扩展不等于功能强大，不要夸大其辞】

　　现在的系统，因为接口或者其他方法的使用，都具有很大的扩展性。但是扩展性不等于功能强大。
　　存在一个接口，用户可以实现自己的接口，确实非常方便。但是如果你的系统本身只实现了一个接口或者根本没有实现，那么对用户来说就谈不上方便。
　　
　　例如WebWork的validators，本身是一个接口，但是实际上本身实现的具体类很少，而且功能很差，这个时候如果你说WebWork的校验器很厉害，那么就可能不太恰当了。当然扩展Webwork的Validator还是非常方便的。
　　
　　当然，可扩展性还是需要的，但是不要吹嘘，在这个浮躁的年代，让我们多干点实事。 :)

　　【20/80原则】
　　
　　在工作中，我经常想到20/80原则，也就是"巴雷多原则"。例如我们可以看到:

　　时间：我们20%的时间会产生成果的80%
　　
　　产品：产品的20%带来利润的80%
　　
　　阅读：20%的书篇幅包括了内容的80%
　　
　　工作：20%的工作给我们80%的满意
　　
　　演讲：20%的演讲产生影响的80%
　　
　　领导：20%的人作出80%的决定

　　从上面可以看出，很多时候它都很有说服力。
　　在这里我想提到几点，但是和上面的可能出发点有所不同:
　　
　　1、程序的80%都是在处理特殊情况，所以我们一定要对特殊情况重视，不要因为是特殊情况，就不很重视。80%的客户对特殊情况都很重视。
　　文档对特殊情况也要详细描述，因为开发人员80%的时候在查找这些东西，而对那些经常用到的用法却很少查阅文档。
　　
　　2、优化问题:80%的瓶颈都出在20%的代码上，所以在优化代码的时候不需要优化所有代码，只需要优化20%的关键代码就够了。当然追求完美的人我们就不多说了。
　　记得有一条优化的原则是"不要优化!不要优化"，是非常有道理的。
　　
　　3、如果你20%的事情做砸了，往往会导致80%的事情都砸了，或者是导致别人认为你把事情几乎都做砸了。
　　如果你对一些事情发表了一些很不严谨的看法，那么别人会认为你在别的事情上也很不严谨。
　　依此类推，代码质量，文档完整性等等，都会让人产生类似的推理。
　　
　　(当然一个代码写的很乱的人，往往文档也很乱。)
　　
　　【强制绑定是不受欢迎的】

　　不要在程序中强制绑定一些额外的功能。
　　
　　有的框架往往功能很多，是"大型计算机"，有很多功能，但是在我需要打字的时候，给我打字的功能即可，不要强制我使用网络功能，打印功能，负载均衡功能等等。
　　
　　一般来说，如果一个东西有很多功能，那么做好做成可配置，可插拔的，这样用户使用你的东西，没必要在不使用高级功能的时候，浪费用户的内存，磁盘。开发人员还得多copy好多lib文件，占用调试时间，岂不是很麻烦。
　　
　　不要买一送一，我不想要就别给我。 :)

　　【有时候也得考虑兼容性】

　　一般来说，一个公司的客户会有很多，用户的运行环境是各种各样的。jdk1.3，jdk1.4甚至还有jdk1.2。这样我们在编程的时候就必须做一些妥协，有些函数库就不能使用。
　　如果这些用户的jdk不能升级(一般来说都需要购买新的产品才能升级)，或者我们必须对这些情况妥协，那么我们就要在开发中考虑这些问题。
　　
　　例如以前，在Servlet 2.2的时候，因为没有setCharacterEncoding，我们必须手动对各种字符进行转换。当Servlet2.3的时候，可以使用这个函数了。但是为了客户考虑，我们只好没有升级还是使用原来的方法。(当然后来大多数用户都使用了新的App Server，我们就可以使用filter来处理编码问题了)。
　　
　　向下兼容性确实让人头疼，JDK1.5也发布好久了，不过我们现在也不能使用，只能自己没事测试测试。
　　
　　在编程的时候，一定要设置好IDE的兼容性设置，防止我们使用了不能使用的特性。Jbuilder，Eclipse都有类似的设置。
　　
　　【成本与现实，给用户以选择余地】

　　全文检索，lucene，like是三种对大文本字段检索的方法。那么你采用哪一种呢?
　　
　　也许你会毫不犹豫的说"全文检索" (我看你像TRS公司的托 :P)。
　　
　　正如"强制绑定是不受欢迎的"里面所说的一样，我还是觉得应该给用户以选择的余地。
　　
　　全文检索是要花钱的或者需要配置，而且一般来说数据库专用的全文检索都是不通用的，lucene是需要开发人员开发的，只有like最简单了，但是太简单了，而且性能也差。
　　
　　这个时候，也许我们就应该提供几种方式供用户选择了，用户如何选择那就看他们了。。。
　　
　　【结束语】

　　实际开发设计中肯定还存在很多其他的问题，本文不可能一一论述。到此为止。 :)
　　
　　希望各位在开发设计中成为高水平的设计师。 :)

作者：happy_forever     来自： http://www.javafan.net

以下文章都是经典，看不看随你的便，我只希望知识掌握在更多中国人的手里！

中国有很多小朋友，他们18,9岁或21,2岁，通过自学也写了不少代码，他们有的代码写的很漂亮，一些技术细节相当出众，也很有钻研精神，但是他们被一些错误的认识和观点左右，缺乏对系统，对程序的整体理解能力，这些人，一个网上的朋友说得很好，他们实际上只是一些Coding fans，压根没有资格称为程序员，但是据我所知，不少小网络公司的CTO就是这样的coding fans,拿着吓人的工资，做着吓人的项目，项目的结局通常也很吓人。

程序员基本素质：

作一个真正合格的程序员，或者说就是可以真正合格完成一些代码工作的程序员，应该具有的素质。

1：团队精神和协作能力
把它作为基本素质，并不是不重要，恰恰相反，这是程序员应该具备的最基本的，也是最重要的安身立命之本。把高水平程序员说成独行侠的都是在呓语，任何个人的力量都是有限的，即便如linus这样的天才，也需要通过组成强大的团队来创造奇迹，那些遍布全球的为linux写核心的高手们，没有协作精神是不可想象的。独行侠可以作一些赚钱的小软件发点小财，但是一旦进入一些大系统的研发团队，进入商业化和产品化的开发任务，缺乏这种素质的人就完全不合格了。

2：文档习惯
说高水平程序员从来不写文档的肯定是乳臭未干的毛孩子，良好的文档是正规研发流程中非常重要的环节，作为代码程序员，30％的工作时间写技术文档是很正常的，而作为高级程序员和系统分析员，这个比例还要高很多。缺乏文档，一个软件系统就缺乏生命力，在未来的查错，升级以及模块的复用时就都会遇到极大的麻烦。

3：规范化，标准化的代码编写习惯
作为一些外国知名软件公司的规矩，代码的变量命名，代码内注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。
有些coding fans叫嚣高水平程序员写的代码旁人从来看不懂，这种叫嚣只能证明他们自己压根不配自称程序员。代码具有良好的可读性，是程序员基本的素质需求。
再看看整个linux的搭建，没有规范化和标准化的代码习惯，全球的研发协作是绝对不可想象的。

4：需求理解能力
程序员需要理解一个模块的需求，很多小朋友写程序往往只关注一个功能需求，他们把性能指标全部归结到硬件，操作系统和开发环境上，而忽视了本身代码的性能考虑，有人曾经放言说写一个广告交换程序很简单，这种人从来不知道在百万甚至千万数量级的访问情况下的性能指标是如何实现的，对于这样的程序员，你给他深蓝那套系统，他也做不出太极链的并访能力。性能需求指标中，稳定性，并访支撑能力以及安全性都很重要，作为程序员需要评估该模块在系统运营中所处的环境，将要受到的负荷压力以及各种潜在的危险和恶意攻击的可能性。就这一点，一个成熟的程序员至少需要2到3年的项目研发和跟踪经验才有可能有心得。

5：复用性，模块化思维能力
经常可以听到一些程序员有这样的抱怨，写了几年程序，变成了熟练工，每天都是重复写一些没有任何新意的代码，这其实是中国软件人才最大浪费的地方，一些重复性工作变成了熟练程序员的主要工作，而这些，其实是完全可以避免的。
复用性设计，模块化思维就是要程序员在完成任何一个功能模块或函数的时候，要多想一些，不要局限在完成当前任务的简单思路上，想想看该模块是否可以脱离这个系统存在，是否可以通过简单的修改参数的方式在其他系统和应用环境下直接引用，这样就能极大避免重复性的开发工作，如果一个软件研发单位和工作组能够在每一次研发过程中都考虑到这些问题，那么程序员就不会在重复性的工作中耽误太多时间，就会有更多时间和精力投入到创新的代码工作中去。
一些好的程序模块代码，即便是70年代写成的，拿到现在放到一些系统里面作为功能模块都能适合的很好，而现在我看到的是，很多小公司软件一升级或改进就动辄全部代码重写，大部分重复性工作无谓的浪费了时间和精力。

6：测试习惯
作为一些商业化正规化的开发而言，专职的测试工程师是不可少的，但是并不是说有了专职的测试工程师程序员就可以不进行自测；软件研发作为一项工程而言，一个很重要的特点就是问题发现的越早，解决的代价就越低，程序员在每段代码，每个子模块完成后进行认真的测试，就可以尽量将一些潜在的问题最早的发现和解决，这样对整体系统建设的效率和可靠性就有了最大的保证。
测试工作实际上需要考虑两方面，一方面是正常调用的测试，也就是看程序是否能在正常调用下完成基本功能，这是最基本的测试职责，可惜在很多公司这成了唯一的测试任务，实际上还差的远那；第二方面就是异常调用的测试，比如高压力负荷下的稳定性测试，用户潜在的异常输入情况下的测试，整体系统局部故障情况下该模块受影响状况的测试，频发的异常请求阻塞资源时的模块稳定测试等等。当然并不是程序员要对自己的每段代码都需要进行这种完整测试，但是程序员必须清醒认识自己的代码任务在整体项目中的地位和各种性能需求，有针对性的进行相关测试并尽早发现和解决问题，当然这需要上面提到的需求理解能力。

7：学习和总结的能力
程序员是人才很容易被淘汰，很容易落伍的职业，因为一种技术可能仅仅在三两年内具有领先性，程序员如果想安身立命，就必须不断跟进新的技术，学习新的技能。
善于学习，对于任何职业而言，都是前进所必需的动力，对于程序员，这种要求就更加高了。但是学习也要找对目标，一些小coding fans们，他们也津津乐道于他们的学习能力，一会学会了asp，一会儿学会了php，一会儿学会了jsp，他们把这个作为炫耀的资本，盲目的追逐一些肤浅的，表面的东西和名词，做网络程序不懂通讯传输协议，做应用程序不懂中断向量处理，这样的技术人员，不管掌握了多少所谓的新语言，永远不会有质的提高。
善于总结，也是学习能力的一种体现，每次完成一个研发任务，完成一段代码，都应当有目的的跟踪该程序的应用状况和用户反馈，随时总结，找到自己的不足，这样逐步提高，一个程序员才可能成长起来。
一个不具备成长性的程序员，即便眼前看是个高手，建议也不要选用，因为他落伍的时候马上就到了。
具备以上全部素质的人，应当说是够格的程序员了，请注意以上的各种素质都不是由IQ决定的，也不是大学某些课本里可以学习到的，需要的仅仅是程序员对自己工作的认识，是一种意识上的问题。

那么作为高级程序员，以至于系统分析员，也就是对于一个程序项目的设计者而言，除了应该具备上述全部素质之外，还需要具备以下素质：

第一，需求分析能力
对于程序员而言，理解需求就可以完成合格的代码，但是对于研发项目的组织和管理者，他们不但要理解客户需求，更多时候还要自行制定一些需求，为什么这么说呢？
一般而言，进行研发任务，也许是客户提出需求，也许是市场和营销部门提出的需求，这时候对于研发部门，他们看到的不是一个完整的需求，通常而言，该需求仅仅是一些功能上的要求，或者更正规些，可能获得一个完整的用户视图；但是这都不够，因为客户由于非技术因素多一些，他们可能很难提出完整和清晰，或者说专业性的性能需求，但是对于项目组织者和规划者，他必须能够清醒认识到这些需求的存在并在完成需求分析报告的时候适当的提出，同时要完整和清晰的体现在设计说明书里面，以便于程序员编码时不会失去这些准则。
程序设计者必须正确理解用户需求所处的环境，并针对性做出需求的分析，举例而言，同样一个软件通过ASP租用方式发布和通过License方式发布，性能需求可能就是有区别的，前者强调的是更好的支撑能力和稳定性，而后者则可能更强调在各种平台下的普适性和安装使用的简捷性。

第二，项目设计方法和流程处理能力
程序设计者必须能够掌握不少于两到三种的项目设计方法（比如自顶至下的设计方法，比如快速原型法等等），并能够根据项目需求和资源搭配来选择合适的设计方法进行项目的整体设计。设计方法上选择不当，就会耽误研发周期，浪费研发资源，甚至影响研发效果。
一个程序设计者还需要把很多功夫用在流程图的设计和处理上，他需要做数据流图以确立数据词典；他需要加工逻辑流图以形成整体的系统处理流程。一个流程有问题的系统，就算代码多漂亮，每个模块多精致，也不会成为一个好的系统。当然，做好流程分析并选择好项目设计方法，都需要在需求分析能力上具有足够的把握。

第三，复用设计和模块化分解能力
这个似乎又是老调重谈，前面基本素质上不是已经说明了这个问题吗？
作为一个从事模块任务的程序员，他需要对他所面对的特定功能模块的复用性进行考虑，而作为一个系统分析人员，他要面对的问题复杂的多，需要对整体系统按照一种模块化的分析能力分解为很多可复用的功能模块和函数，并针对每一模块形成一个独立的设计需求。举个例子，好比是汽车生产，最早每辆汽车都是独立安装的，每个部件都是量身定做的，但是后来不一样了，机器化大生产了，一个汽车厂开始通过流水线来生产汽车，独立部件开始具有一定的复用性，在后来标准化成为大趋势，不同型号，品牌甚至不同厂商的汽车部件也可以进行方便的换装和升级，这时候，汽车生产的效率达到最大化。软件工程也是同样的道理，一个成熟的软件行业，在一些相关项目和系统中，不同的部件是可以随意换装的，比如微软的许多桌面软件，在很多操作模块（如打开文件，保存文件等等）都是复用的同一套功能模块，而这些接口又通过一些类库提供给了桌面应用程序开发者方便挂接，这就是复用化的模块设计明显的一个佐证。
将一个大型的，错综复杂的应用系统分解成一些相对独立的，具有高度复用性的，并能仅仅依靠几个参数完成数据联系的模块组合，是作为高级程序员和系统分析员一项最重要的工作，合适的项目设计方法，清晰的流程图，是实现这一目标的重要保证。

第四，整体项目评估能力
作为系统设计人员，必须能够从全局出发，对项目又整体的清醒认识，比如公司的资源配置是否合理和到位，比如工程进度安排是否能最大化体现效率又不至于无法按期完成。评估项目整体和各个模块的工作量，评估项目所需的资源，评估项目可能遇到的困难，都需要大量的经验积累，换言之，这是一种不断总结的累计才能达到的境界。在西方一些软件系统设计的带头人都是很年长的，比如4，50岁，甚至更老，他们在编码方面已经远远不如年轻人那样活络，但是就项目评估而言，他们几十年的经验积累就是最重要和宝贵的财富。中国缺这么一代程序员，主要还不是缺那种年纪的程序员，而是那种年纪的程序员基本上都是研究单位作出来的，都不是从专业的产品化软件研发作出来的，他们没有能积累那种产品化研发的经验，这也是没有办法的事情。

第五，团队组织管理能力
完成一个项目工程，需要团队的齐心协力，作为项目设计者或研发的主管人，就应当有能力最大化发挥团队的整体力量，技术管理由于其专业性质，不大同于一般的人事管理，因为这里面设计了一些技术性的指标和因素。
首先是工作的量化，没有量化就很难做到合适的绩效考核，而程序量化又不是简单的代码行数可以计算的，因此要求技术管理人员需要能真正评估一个模块的复杂性和工作量。
其次是对团队协作模式的调整，一般而言，程序开发的协作通常分为小组进行，小组有主程序员方式的，也有民主方式的，根据程序员之间的能力水平差距，以及根据项目研发的需求，选择合适的组队方式，并能将责权和成员的工作任务紧密结合，这样才能最大发挥组队的效率。
一个代码水平高的人，未必能成为一个合格的项目研发主管，这方面的能力欠缺往往是容易被忽视的。

综上可以看到，作为一个主管研发的负责人，一个项目设计者，所需要具备的素质和能力并不是程序代码编写的能力，当然一般情况下，一个程序员通过不断的总结提高达到了这种素质的时候，他所具有的代码编写能力也已经相当不简单了，但是请注意这里面的因果关系，一个高水平的项目设计者通常已经是代码编写相当优秀的人了，但是并不是一个代码相当优秀的程序员就可以胜任项目设计的工作，这里面存在的也不是智商和课本的问题，还是在于一个程序员在积累经验，逐步提升的时候没有意识到应当思考哪方面的东西，没有有意识的就项目的组织和复用设计进行揣摩，没有经常性的文档习惯和总结习惯，不改变这些，我们的合格的项目设计者还是非常欠缺。

另外，为防止有无聊的人和我较真，补充一点，本文针对目标是作商业化的软件项目和工程，那些科研机构的编程高手，比如算法高手，比如图象处理高手，他们的工作是研究课题而非直接完成商业软件（当然最终间接成为商业产品，比如微软研究院在作的研究课题），因此他们强调的素质可能是另外的东西，这些人（专家），并不能说是程序员，不能用程序员的标准去衡量。

最后补充一点东西，一个软件项目研发的设计流程是怎样的呢？以通常标准的设计方法为例，（不过笔者喜欢快速原型法）。

第一个步骤是市场调研，技术和市场要结合才能体现最大价值。

第二个步骤是需求分析，这个阶段需要出三样东西，用户视图，数据词典和用户操作手册。用户视图是该软件用户（包括终端用户和管理用户）所能看到的页面样式，这里面包含了很多操作方面的流程和条件。数据词典是指明数据逻辑关系并加以整理的东东，完成了数据词典，数据库的设计就完成了一半多。用户操作手册是指明了操作流程的说明书。请注意，用户操作流程和用户视图是由需求决定的，因此应该在软件设计之前完成，完成这些，就为程序研发提供了约束和准绳，很遗憾太多公司都不是这样做的，因果颠倒，顺序不分，开发工作和实际需求往往因此产生隔阂脱节的现象。
需求分析，除了以上工作，笔者以为作为项目设计者应当完整的做出项目的性能需求说明书，因为往往性能需求只有懂技术的人才可能理解，这就需要技术专家和需求方（客户或公司市场部门）能够有真正的沟通和了解。

第三个步骤是概要设计，将系统功能模块初步划分，并给出合理的研发流程和资源要求。作为快速原型设计方法，完成概要设计就可以进入编码阶段了，通常采用这种方法是因为涉及的研发任务属于新领域，技术主管人员一上来无法给出明确的详细设计说明书，但是并不是说详细设计说明书不重要，事实上快速原型法在完成原型代码后，根据评测结果和经验教训的总结，还要重新进行详细设计的步骤。

第四个步骤是详细设计，这是考验技术专家设计思维的重要关卡，详细设计说明书应当把具体的模块以最‘干净’的方式(黑箱结构）提供给编码者，使得系统整体模块化达到最大；一份好的详细设计说明书，可以使编码的复杂性减低到最低，实际上，严格的讲详细设计说明书应当把每个函数的每个参数的定义都精精细细的提供出来，从需求分析到概要设计到完成详细设计说明书，一个软件项目就应当说完成了一半了。换言之，一个大型软件系统在完成了一半的时候，其实还没有开始一行代码工作。那些把作软件的程序员简单理解为写代码的，就从根子上犯了错误了。

第五个步骤是编码，在规范化的研发流程中，编码工作在整个项目流程里最多不会超过1/2，通常在1/3的时间，所谓磨刀不误砍柴功，设计过程完成的好，编码效率就会极大提高，编码时不同模块之间的进度协调和协作是最需要小心的，也许一个小模块的问题就可能影响了整体进度，让很多程序员因此被迫停下工作等待，这种问题在很多研发过程中都出现过。编码时的相互沟通和应急的解决手段都是相当重要的，对于程序员而言，bug永远存在，你必须永远面对这个问题，大名鼎鼎的微软，可曾有连续三个月不发补丁的时候吗？从来没有！

第六个步骤是测试，测试有很多种：按照测试执行方，可以分为内部测试和外部测试；按照测试范围，可以分为模块测试和整体联调；按照测试条件，可以分为正常操作情况测试和异常情况测试；按照测试的输入范围，可以分为全覆盖测试和抽样测试。以上都很好理解，不再解释。
总之，测试同样是项目研发中一个相当重要的步骤，对于一个大型软件，3个月到1年的外部测试都是正常的，因为永远都会又不可预料的问题存在。
完成测试后，完成验收并完成最后的一些帮助文档，整体项目才算告一段落，当然日后少不了升级，修补等等工作，只要不是想通过一锤子买卖骗钱，就要不停的跟踪软件的运营状况并持续修补升级，知道这个软件被彻底淘汰为止。

写这些步骤算不上卖弄什么，因为实话讲我手边是一本《软件工程》，在大学里这是计算机专业的必修课程，但是我知道很多程序员似乎从来都只是热衷于什么《30天精通VC》之类的，他们有些和我一样游击队出身，没有正规学过这个专业，还有一些则早就在混够学分后就把这些真正有用的东西还给了老师。

网上现在也很浮躁，一些coding fans乱嚷嚷，混淆视听，实际上真正的技术专家很少在网上乱发帖子的，如笔者这样不知天高地厚的，其实实在是算不上什么高手，只不过看不惯这种对技术，对程序员的误解和胡说，只好挺身而出，做拨乱反正之言，也希望那些还沉迷于一些错误人士的coding fans们能认真想想，走到正途上，毕竟那些聪明的头脑还远远没有发挥应有的价值。