我所经历的代码重构

今天下午架构师带着我对我前段时间写的代码进行了重构,收获还是很多,现在与大家分享下。

PS:因为自己太菜,所以大家不要笑话。^_^

 

如果没有单元测试或者自动化测试,重构的首要原则就是保证不印象现有的功能:

 

    如果对现有的类进行重构,那就重新写一个类,实现与现在类同样的功能;

    如果对现有的函数进行重构,那就在原有的类中重新加一个函数,保证与要重构的函数实现同样的功能。

 

以上两点是我感受最深的。

 

另外在处理复杂问题时要抓住问题的主线。

 

比如:

     我们修改的一个功能包括:异步访问网络,任务队列,消息中心,任务队列中的任务对象,如果实现的过程中把许多问题柔和到一起,会让我感觉脑袋很大,这时我们应该下手前将可能遇到的问题点考虑清楚比如,任务如何处理异步请求,任务队列中的对象存在依赖关系,有些任务会依赖前面的任务必须正确执行,如果将结果通过消息中心通知界面,错误的处理等等。但是在具体实现的时候我们应该简化问题,一开始只是完成一个简单的框架,完成任务队列的基本功能,但是任务队列中的任务对象为空的,然后在任务执行时,只是向消息中心发送一个简单的任务对象,测试任务队列可以正确的按顺序执行任务,任务执行过程中通过消息中心可以将任务执行的结果通知到界面。基本路径都通了后,然后再处理其它的异常情况,比如,任务队列中任务的依赖关系,异步的网络请求如何通过委托通知任务对象任务执行的结果。总之,就是不要想一下子做到十全十美,而是先搭一个框架,让基本流程可以跑通,然后再慢慢往上加东西,处理各种附件条件与异常场景。

   从使用者的角度考虑接口的设计。

   基于层思考问题。

   简单功能可以跑通,说明这些简单功能是类的本质职责,其他功能是其他类或者派生类负责。

   越简单的东西越稳定,越容易找到问题的本质、类的本质。

   从上到下进行细化,从 View 开始。

   回顾功能性需求。

   交换的信息与代码要做到人机可读,比如:用 YES 不用 1。

   程序与类的设计要达到的几个标准:简洁性、一致性、自然性。

   当不清楚一个类的职责时,问他的用户。

   软件需求的三个维度:功能性需求、非功能性需求、软件的架构或者分层。

 

posted @ 2010-05-20 23:42  Proteas  阅读(246)  评论(0编辑  收藏  举报