易栈网-膘叔

代码重构是所有人的噩梦。怎么样重构一系列代码，是一件非常重要的事情。
在没转这篇文章之前，我的重构都是先从部分非关键代码开始重构，而且把这一部分慢慢的独立成一个模块，在采用新的架构的时候，这一块也可以被嵌入的新的架构中。
当然在其中也会遇到一系列的问题，但这样来说会轻松一点。
OK，让我们来看原文吧。
原文是来自：http://coolshell.cn/articles/5201.html

你曾去想重构一个很老的模块，但是你只看了一眼你就恶心极了。文档，奇怪的函数和类的命名，等等，整个模块就像一个带着脚镣的衣衫褴褛的人，虽然能 走，但是其已经让人感到很不舒服。面对这种情况，真正的程序员会是不会认输的，他们会接受挑战认真分析，那怕重写也在所不惜。最终那个模块会被他们重构， 就像以前和大家介绍过的那些令人销魂的编程方式中的屠宰式编程一样。下面是重构代码的几个阶段，文章来自：The 7 stages of refactoring，下面的翻译只是意译。

第一阶段 - 绝望

在你开始去查看你想要重构的模块的，你会觉得好像很简单，这里需要改一个类，那里需要改两到三个函数，重写几个 函数，看上去没什么大不了的，一两天就搞定了。于是你着手开始重构，然后当你调整重构了一些代码，比如改了一些命名，修理了一些逻辑，渐渐地，你会发现这 个怪物原来体型这么大，你会看到与代码不符甚至含糊不清的注释，完全摸不着头脑的数据结构，还有一些看似不需要方法被调了几次，你还会发现无法搞清一个函 数调用链上的逻辑。你感到这个事可能一周都搞不定，你开始绝望了。

第二阶段 – 找最简单的做

你承认你要重构的这个模块就是一个可怕的怪物，不是一两下就可以搞定的，于是你开始着干一些简单的事，比如重新命名一下几个函数，移除一些代码的阻碍，产生几个常量来消除magic number，等等，你知道这样做至少不会让代码变得更糟糕。

第三阶段 – 再次绝望

但是接下来的事会让你再次撞墙。你会发现那些代码的瑕疵是些不痛不痒的事，改正这些事完全于事无补，你应该要做 的事就是重写所有的东西。但是你却没有时间这么干，而这些代码剪不乱理还乱，耦合得太多，让你再一次绝望。所以，你只能部分重写那些不会花太多时间的部 分，这样至少可以让这些老的代码能被更多的重用。虽然不完美，但是至少可以试试。

第四阶段 – 开始乐观

在你试着部分重构这个模块几天之后，随着重构了几个单元后，虽然你发现改善代码的进度太慢了，但此时，你已知道代码应该要被改成什么样，你在痛苦之 后也锁定了那些那修改的类。是的，虽然你的时间预算已经超支，虽然要干的事比较多，但你还是充满希望，觉得那是值得的。你胸中的那团火又被点燃了。

第五阶段  - 快速了结

在这个时候，你发现你已花了太多的时间，而情况越来越复杂，你感到你所面对的情况越来越让你越到不安，你明白你自己已经陷入了困境。你原本以为只需 要一次简单的重构，然而现在你要面对的是重写所有的东西。你开始意识到原因是因为你是一个完美主义者，你想让代码变得完美。于是你开始在怠慢你文档，并想 找到一个捷径来重写老的代码，你开始采用一些简单而粗暴，快速而有点肮脏的方法。虽然不是很完美，但你就是这样去做了。然后，你开始运行测试做UT，发现 UT报告上全是红色，几乎全都失败了，你恐慌了，于是快速地fix代码，然后让UT 能工作。此时，你拍拍自己胸口，说到，没问题 ，于是就把代码提交了。

第六阶段 – 修改大量的Bug

你的重写并不完美，虽然其过了测试，但是那些UT测试对于你的新的代码有点不太合适，虽然他们都没有报错，但是他们测试得范围太小了，没有覆盖到所 有的情况和边界。所以，在这以后，你还需要几周或是更长的时间不得不来修正越来越多的bug，这使得你的设计和代码在每一次quick-fix后就变得越 来越难看。此时，代码已经不像你所期望的那样完美了，但你依然觉得他还是比一开始要好一些。这个阶段可能历经几个月。

第七阶段  - 觉悟

经过了6个月，你重写的模块又出了一个比较严重的bug。这让你重构的那个模块变得更难堪。你发现出的这个问题是和当初的设计不一致，你还发现被你 重构掉的那段老的代码并不是当初看上去的那么坏，那段老的代码确实考虑到了一些你未曾考虑到的事情。这个时候，你团队里有人站出来说这个模块应该被重构或 是重写，而你却不动声色地一言不发，并希望那个站出来的人能在几个月后能觉悟起来。

——————

不知道这是不是你的经历，我经历过很多次这样的事。对于很多维护性质的项目，我犯过的错误让我成了一个实实在在的保守派，我几乎不敢动，那怕看到代 码很不合口味。当然，那些从来没有写过代码的敏捷咨询师一定会说用TDD或是UT可以让你的重构更有效也更容易，因为这样会让他们显得更我价值，但我想告 诉你，这种脱离实际的说法很不负责任，这就好比说—— 我在杀猪的时候遇到了一些麻烦，因为我对猪的生理结构不清楚，或是这本来就是一头畸形的猪，导致我杀的猪很难看，而伟大的敏捷咨询师却告诉我，要用一把更快更漂亮的刀。软件开发永远不是那么简单的事，杀猪也一样。

-----------------------
不过我想，更多的时候，安排你重构一份代码的时候，你可能想到的就是我情愿重写一份也不愿意重构，对着数据库结构和一些业务逻辑，然后就开始重写了。只是这样的写法，后面遇到的问题会非常非常多。你呢？也是这样的吗？

最近也正在做shopnc的重构，当然也就有自己的想法喽。偶尔看到这篇文章，乐死，估计所有重构过代码的人都会有类似想法吧。

原文来自：http://www.cnblogs.com/XmNotes/archive/2010/12/13/1904377.html

我在这里，就列举一下Refactorman的种种死法，以警后人：

一、一边重构，一边要完成日常任务……

1. 疲于奔命，过劳而死。

2. 吃领导给的鸭梨太大被噎死。

3. 满脑子都是代码，在上班路上不留神撞上了宝马。

4. 冷落了女友，受失恋打击跳楼而死。

5. 无暇社交，不懂人情世故，失意而死。

6. 为了说服领导和同事，心力交瘁而死。

二、重构过程中……

7. 被以前的混账代码气死。

8. 被混账代码搞得大脑程序溢出，彻底崩溃，神智错乱而死。

9. 终于醒悟，问题只是冰山一角，力有未逮，忧愤而死。

10. 泥足深陷，举步维艰，进退维谷被活活困死。

11. 自己昏天黑地，看其他同事却吊儿朗当，逍遥快活，心理不平衡致忧郁而死。

12. 重构过程中，踩中前任留下的地雷，被炸得体无完肤而死。

13. 一日偶遇以前代码的作者，怒不可遏，将其一通乱砍，再鞭尸三百，然后切腹而死。

三、经九九八十一难，大功告成……

14. 系统重构后性能提高了？漏洞消除了？对不起，领导们没兴趣，失落而死。

15. 系统重构后出现了新Bug，多半会小题大作，遭游街批斗而死。

16. 马上接到通知系统功能要大升级，吐血而死。

17. 同事依旧我行我素，继续在系统中倒垃圾代码，痛心疾首而死。

18. 重构将系统中的阴暗面曝光，被同事记恨，领导排挤，学屈原投江而死。

19. 过了不多久，发现系统又乱成了一团，比以前好不到哪儿去，悲愤下一头撞死。

20. 离职后偶遇前公司的新任维护者，被其乱刀砍死再鞭尸。

　　各种死法中，最后一种，我们比窦娥还冤枉。所以强烈推荐大家还要练一门武功以防身。什么武功，就是：“心惊肉跳、杞人忧天、无中生有、力不从 心、行尸走肉、庸人自扰、倒行逆施、废寝忘食、孤形只影、想入非非、呆若木鸡……”。这门传说中的黯然销魂掌，其中一招一式，正是我们最好的写照。

以后，每逢周末就乱七八槽写点东西吧。精力有限，而无限制的转载其实意义也不是特别大，除了给自己做笔记外，其他的作用也真不是太大

1、来自yhustc的：微软亚洲研究院面经，因为我不知道Qzone非好友是否能够打开，如果不行，留言给我，我全文转载吧。这里转他的最后6点所谓的心得：

2、博客园的棍子上的萝卜推荐几本javascript与jquery的好书。前端用户可以看，话说那本PPK谈javascript我也有，确实感觉很简单。。然后作者在书中介绍了一个网址，有一些JS的参考手册哦：http://stephen830.javaeye.com/category/57459。

然后很奇怪的是发现这个域名居然是javaeye，然后又很奇怪的发现，它居然可以打开了，好奇怪的事情啊。。。关于它不能打开，robbin说的那句程序写的太好也是错啊，网上可以搜到这条信息的。

3、前两天，有人在博客园上批评了金山安全卫士的源码写的糟糕（金山安全卫士代码批评），其中有一段就是过多的if..else，认为用表驱动会效果和效率上都会好很多，当时文中还说了，如果不知道表驱动，那么就到google里搜索一下吧。（很多玩意儿果然只是一个名词，其实一说大家都懂）。于是这里有一篇简单的介绍和学习，可以参考一下：http://www.cnblogs.com/birdshover/archive/2010/12/02/1894703.html。

4、重构，重构，这句话，被大多数人都挂在嘴边，可是有多少人真正去做了？当晚上发现代码有问题，你第二天会去重构一下吗？一般来说，如果时间上很充分，我还是会去做这样的事情的，但你如果在一小公司，每天在不停的赶任务，你会去主动重构吗？或者会乘周末想办法重构？重构的好处是什么大家都懂，还有一本书叫《重构》，还有一个人在写《重构之美》，反正，随便折腾喽。。。

这两天一直在看Yii框架，也下载了一份API手册，却发现API手册里只有方法的介绍，却没有具体的调用方法，如果是纯方法的话，说实话，我还情愿用IDE的自动完成来查看呢。当然有个API手册在查询的时候会比较方便一点。

那么，有没有真正的manual呢？到官网的documentation分类去看了一下，NND，一堆 英文，不过，在我犀利的眼神下，还是发现了这玩意：The Definitive Guide to Yii ，点开一看，原来这才是类似于PHP手册的manual呀。可惜能够下载的只有PDF版本。更可恨的是，也只有英文版的，算了，将就点吧。。。虽然英文烂了点，一些简单的东西还是能够看得懂的。

如果初学Yii，还是建议看一下这个guide：The Definitive Guide to Yii ，它，有中文版，在：http://www.yiiframework.com/doc/guide/zh_cn/index

左边的树的目录也很清晰，值得一观，不过更建议的是多看一下：http://www.yiiframework.com/doc/guide/zh_cn/basics.application，我最初就是没看这个，一下子不知道如何调用Cache，都想在代码 new Cache之类的了。

--EOF--

后记：感谢烂桔推荐的：http://dreamneverfall.cn/yiidoc/index.htm，烂桔的网站为：http://iorange.cc

Yii的用户登录，如果不算上权限的话，恐怕真的是很简单的登录。
简单的判断，简单的处理一下就完事了。
但我今天还真的被简单的折腾了一下。
User登录，需要写几个地方
1、components目录下的UserIdentity.php中，需要加一个判断用户的方法，返回errorCode，当然没有错的话就返回0,这是常用ERROR_NONE
2、model目录下的loginForm，里面有简单的判断处理，如果登录成功，调用CWebUser中的login方法。起初的时候，我一直没找到Yii::app()->user是哪个类。。
3、由于Yii::app()->user->login方法的特殊性，因此，必须要在UserIdentity.php中设定好getId,getName,和states变量。当然最简单的就是判断是否取到用户数据，如果取到的话，直接$this->setPersistentStates($usermodel->getAttributes());如果没有id,name的变量，那么即使你登录了，还是会显示没有登录的。我就是在这里被折腾了好久。

over。。。