编程五年心得体会

大纲  

忘了哪个大牛说过：我只是一个拥有良好编程习惯的普通程序员。

这句话对我的触动很大，下面说一下日常编码的一些习惯：

1） 简单明了的邮件确认需求

如果是需求任务，与需求人员，设计人员沟通后，最后总结发邮件给相关人员，需要主要的负责人确认。需求任务，当然要需求人员确认。 在总结发邮件时，因为我们的表达能力有限，而邮件就是要给人看的，所以不必太正式，举些小例子，某种情况下，怎么样处理才是正确的。。。这个也以备来日需求确认使用。

（通用过滤模块有一个很好的例子）

2） 30%的测试时间。

      当我开发一个任务时完成编码需要7天，那么你就应估10天上去。其实跑通主流程只是完成工作的30%到50%之间。我们都是凡人，编的代码都可能出错，未经开发人员的DEV测试就直接递交上去，少不了测试人员的牢骚与抱怨，同时，你可能就多了一个“极品程序员”雅号了。

3） 如果你是开发补丁，或者在原来的系统上开发新的功能。如果测试人员给你提一个BUG，而该BUG在该补丁前就已经存在，那么应该再提一个单，另外解决。

这样的好处有两个：

第一，这个补丁不是万能钥匙，别想着发了这个补丁什么问题都解决了。只做这个补丁该做的事。

第二，这个问题之前已经存在，那么你分析修复这个问题是需要时间的，让你的项目经理知道这个问题，安排时间。因为仓促的修改可能会导致你意想不到的问题。如果实在是很简单，也应该提一个单，再包含进该补丁，便于以后的跟踪。

4） 解决问题时，时刻保持思路的清淅。

解决问题一开始就要想好，

如果任务周期很长，编写到一半，连自己都蒙了，建议备份已作的修改，重新写，重用已完成的方法。你前面的工作不会白费，比糊里糊涂地继续要快速很多。

5） 读代码时做一些笔记，画一些时序图。了解各个模块，各个类的作用，这样对以后分析问题有帮助，对问题各种的解决方案有一个很好的价值观判断，进行做出较为明智的选择。（通用过滤模块有例子，当时林提出的方案）

SVN的问题：

1 写注释。 没有人喜欢去比对代码，看你究竟做了什么。而且大部分时间，比对的人是你自己，因为过了一段时间之后，你就忘了你当时做过什么。善待自己，给自己省一些时间，在提交时写上你这个版本所做的修改。

2 绝对不提交不能运行的代码，写了一半的代码！

   这是绝对禁止的！因为往往一个工作量大一点的任务，都会有涉及到修改好几个类，好几个方法，如果这时，只提交一部分，那么想还原回来很麻烦，并且，这个过程中，导致其它人更新的代码模块后不可用。

编程习惯：

1 命名很重要！！！！

      以刘总为例，40%思考如何命名。因为一个名字决定了这个类，这个方法该做些什么事情。每个类，每个方法应该只关心他自己。比如一个方法，只要你传进来的对了，我返回的对了，那其它事情我就不管了。

2 方法要名付其实。

     根据你的名字，只做你该做的事情，不要偷偷摸摸在里边做了你不该做的事情。比如说，曾经见到这样的方法：

getA(){

   if(A == null){

       .....

   }

   b=A+343;

}

然后我刚接手的时候，一个类是几千行的代码，好几个类就几万行的代码，找半天都没找到b到底在哪初始化的。

3 统一你的命名规范。参数以a,an开头。全局变量用小写开头，本地变量以类型开头等，使人在方法体一看就能简单明了的知道哪个是全局变量，哪些是本地变量，哪些是参数。便于理解。

4 一个方法不要超过50行（即一屏幕，超过就重构抽取相应的方法）

面向对象的设计原则：

1 最少知识原则（Least Knowledge）：只和你的密友谈话。即减少对象之间交互。那就尽量少发布接口，因为你写了public后，就不能保证其它人不调用了。所谓，覆水难收。

2 一个类应该只有一个引起它变化的原因。（印像最深刻的是 重构例子中的Rental,Movie的 getCharge()方法归属问题）

3 解决问题，通常有很多种做法，怎么选择，这就是一个有关价值观取向的问题

举例子，什么时候该抛异常的问题

4 减少模块与模块之间的耦合。

  比如应用框架与通用过滤这两个模块。在未打开通用过滤框时，应用框架也要通过默认的方案进行过滤，但没有通用过滤框的话。。。。。。

还有一堆的原则，如开闭原则，

针对接口编程，多用组合，少用继承

好莱坞原则：别调用我们，我们会调用你。用来防止"依赖腐败"等等

即高层组件控制如何when 和 how 让低层组件参与。

比如模板方法中例子：“饮料”分“咖啡”和“茶”

“饮料”的方法：烧水，泡，倒入杯子，加调料。 子类咖啡，茶分别实现“泡”，“加调料”等方法即可，不要试图去控制饮料何时烧水，何时加调料等.

有关重构：

1 不要相信自己

   如果没有单元测试，可能代码很乱，很烂，你自己想重写。可是，你难道能写出没有BUG的程序吗？不可能。我们唯一能做的是重构，可重构也是有前提的。那就是以稳定的单元测试为基础。那是不是就不重构了？

不是。那你能保证没有单元测试的情况下，重构后的代码能正常运行吗？我想，即使照着martin fowler所说的步骤一小步一小步的来，我们也还是可能会出错。毕竟我们是凡人，不是神，martin fowler也一样，谁能保证重命名的地方所有都改了，没有其它地方调用？你能保证你抽取的方法完全正确？老虎都有打盹的时候，何况我们。但我们还是有办法重构的，比如我们万能的 eclipse，:D 

它本身就提供了重构的一些小工具，比如我最常用的抽取方法，重命名等，非常的好用。

2 正如martin fowler 所说，重构是一小步一小步来的（？？？？原话忘了，有空再找）。一次只重构一小部份，然后跳出来。重构好比一个人在地面上查看地底下的建筑，这里不对，你想改，然后挖一下进去，然后挖一半，发现旁边的结构也不对，也挖一下旁边，结果，你自己就陷进去了，最后爬不出来了。

3 只重构一些很小的方法，每一个方法都职责分明了，一目了然，这时，是否需要分解继承层次，提取继承类型等也就非常清淅了。（当然，在BOS这样的平台下，大型的重构风险相当大，不建议使用。）

4 同一时间段，只做一件事情。

通常我们想重构它，一般是有新需求过来，需要加功能，发现代码难以理解，所以需要重构。这时，需要说明的是，我不是周伯通，也不是小龙女，不会双手互搏，所以，只同一时间段，只做一件事。有kent Beck原话为证：

When you add function,you shouldn't be changing existing code; you are just adding new capabilities,you can measure your progress by adding tests and getting the tests to work. When you refactor, you make a point of not adding function; you only restructure
the code.

当然，两者之间可以经常转换....

tips：

回家睡觉前想问题是最有帮助的。一天静下来后，能让你发现你白天头脑发热想起来的解决方案哪里还有问题，是否行得通。