今天下午架构师带着我对我前段时间写的代码进行了重构，收获还是很多，现在与大家分享下。
PS：因为自己太菜，所以大家不要笑话。^_^
如果没有单元测试或者自动化测试，重构的首要原则就是保证不印象现有的功能：
如果对现有的类进行重构，那就重新写一个类，实现与现在类同样的功能；
如果对现有的函数进行重构，那就在原有的类中重新加一个函数，保证与要重构的函数实现同样的功能。
以上两点是我感受最深的。
另外在处理复杂问题时要抓住问题的主线。
比如：
我们修改的一个功能包括：异步访问网络，任务队列，消息中心，任务队列中的任务对象，如果实现的过程中把许多问题柔和到一起，会让我感觉脑袋很大，这时我们应该下手前将可能遇到的问题点考虑清楚比如，任务如何处理异步请求，任务队列中的对象存在依赖关系，有些任务会依赖前面的任务必须正确执行，如果将结果通过消息中心通知界面，错误的处理等等。但是在具体实现的时候我们应该简化问题，一开始只是完成一个简单的框架，完成任务队列的基本功能，但是任务队列中的任务对象为空的，然后在任务执行时，只是向消息中心发送一个简单的任务对象，测试任务队列可以正确的按顺序执行任务，任务执行过程中通过消息中心可以将任务执行的结果通知到界面。基本路径都通了后，然后再处理其它的异常情况，比如，任务队列中任务的依赖关系，异步的网络请求如何通过委托通知任务对象任务执行的结果。总之，就是不要想一下子做到十全十美，而是先搭一个框架，让基本流程可以跑通，然后再慢慢往上加东西，处理各种附件条件与异常场景。
从使用者的角度考虑接口的设计。
基于层思考问题。
简单功能可以跑通，说明这些简单功能是类的本质职责，其他功能是其他类或者派生类负责。
越简单的东西越稳定，越容易找到问题的本质、类的本质。
从上到下进行细化，从 View 开始。
回顾功能性需求。
交换的信息与代码要做到人机可读，比如：用 YES 不用 1。
程序与类的设计要达到的几个标准：简洁性、一致性、自然性。
当不清楚一个类的职责时，问他的用户。
软件需求的三个维度：功能性需求、非功能性需求、软件的架构或者分层。