早在几个月前就从网上下载到了"Working Effectively With Legacy Code"这本书的E版，之所以下这本书是因为看到了"Legacy Code"这两个单词了，说实话当时我并不知晓这本书的价值，只是想当然的认为：这本书可能会有助我改善我所从事的项目中的"Legacy Code"。早在上个月去逛书店时，就看到了书架上的这本"修改代码的艺术"，遗憾的是没有给予足够关注。在最近看到这本书译者刘未鹏的博客以及Dreamhead关于这本书的评价后，才又从电脑中找到这本书开始翻看。从与这本书几次"擦身而过"的经历来看，自己识书的能力实在是差劲。

我需要这本书，首先是因为我目前的项目中就有大量大量的"Legacy Code"，所以我已经开始迫不及待的想看完这本书了。但是翻看一些后，我觉得作为使用C的开发者独观其大略即可。为什么呢？书中代码多以面向对象的语言Java或C++作为例子代码，很多细节对使用结构化语言的开发者意义不大。毕竟结构化的思想与面向对象的思想有着较大的差别。

作者提出来的修改软件的四个起因基本上大家都是应该认同的：
(1) 添加新特性；
(2) 修正bug；
(3) 改善设计；
(4) 优化资源使用。

同时作者又给出了为了减少修改行为带来的风险而应该考虑的三个问题：
(1) 我们要进行哪些修改？
(2) 我们如何得知已经正确地完成了修改？
(3) 我们如何得知没有破坏任何(既有的)东西？

在第一部分第二章的最后作者给出了一个解决这些问题的算法：
以下算法可以用于对遗留代码基进行修改：
(1) 确定改动点；
(2) 找出测试点；
(3) 解依赖；
(4) 编写测试；
(5) 修改、重构。

看完这些我觉得就可以直接进入第二部分了，作者给出了细致的、具体的面对不同情形应该如何去做。建议：在读每一个章节之前先回顾一下自己是否遇到过类似情形，自己当时是如何做的，当时的做法是否有改善的地方，哪些是值得发扬广大的，哪些是应该摒弃的，如果是现在我还会如何去做？之后，再看看Michael Feathers是如何去做的，这样效果应该是很好的。有如下这些情形值得我们去考虑：
(1) I Don’t Have Much Time and I Have to Change It 时间紧迫，但必须修改
(2) It Takes Forever to Make a Change 漫长的修改
(3) How Do I Add a Feature? 添加特性
(4) I Can’t Get This Class into a Test Harness 无法将类放入测试用具中
(5) I Can’t Run This Method in a Test Harness 无法在测试用具中运行方法
(6) I Need to Make a Change. What Methods Should I Test? 修改时应当测试哪些方法
(7) I Need to Make Many Changes in One Area. Do I Have to Break Dependencies for All the Classes Involved? 在同一地进行多处修改，是否应该将相关的所有类都解依赖
(8) I Need to Make a Change, but I Don’t Know What Tests to Write 修改时应该怎样写测试  
(9) Dependencies on Libraries Are Killing Me 棘手的库依赖问题
(10) My Application Is All API Calls 到处都是API调用   
(11) I Don’t Understand the Code Well Enough to Change It 对代码的理解不足
(12) My Application Has No Structure 应用毫无结构可言
(13) My Test Code Is in the Way 测试代码碍手碍脚   
(14) My Project Is Not Object Oriented. How Do I Make Safe Changes? 对非面向对象的项目，如何安全地对它进行修改
(15) This Class Is Too Big and I Don’t Want It to Get Any Bigger 处理大类
(16) I’m Changing the Same Code All Over the Place 需要修改大量相同的代码
(17) I Need to Change a Monster Method and I Can’t Write Tests for It 要修改一个巨型方法，却没法为它编写测试
(18) How Do I Know That I’m Not Breaking Anything? 降低修改的风险
(19) We Feel Overwhelmed. It Isn’t Going to Get Any Better 当你感到绝望时

当你看到这些具体情形的列表，眼前是否浮现出是曾相识的经历呢？"代码修改艺术"应该说是一本实用主义的书，如果你是使用面向对象语言的程序员，那你很幸运，建议你将一本"修改代码的艺术"放在你的办工桌旁，随时翻看、思考和领悟；如果你和我一样是结构化语言的使用者，也没有关系，观其大略，品其思想，细读你兴致之所在。

以上的书中文字的中文翻译部分摘自于刘未鹏的中文译文。

昨日是十一黄金周之后的第一个工作日，也就是在昨天看到网上消息说，国家相关部门正在考虑调整所谓的黄金周休假方案。已经记不清楚黄金周这样的休假制度施行了多少个春秋了，隐约记得刚刚出台黄金周制度的时候，当时还是很兴奋的，因为毕竟是当时是学生，对于一下连休7天甚至更多感到很是兴奋，不过现在面对黄金周我实在是兴奋不起来，因为深深感到黄金周给自己和周围的人带来的’痛苦’。

中国在未改革公民休假制度之前，那时国人还是休小礼拜，后来改成大小礼拜轮休，最后改成目前的8小时工作制，每周都是大礼拜。即使这样中国人的平均工作时数在世界范围来讲还是蛮高的，人们的休息时间较少。国家最初出台黄金周政策我想一是考虑到拉动经济快速增长；二是同时给国人一段较长时间的放松时间。前者的目的达到了，黄金周的经济拉动作用不可小视，但是其弊端也许是当初决策者估计不足的。而第
二个目的真的达到了么？值得商榷。

黄金周是给大家回家探亲准备了充足的时间，但是大家回家真的是那么容易么？
现在人们一提到黄金周，想的也许不是如何休息，而是如何买车票、船票和飞机票。毕竟在拥有13亿人口的泱泱大国，国民集中一个时段迁移给交通运输业带来的压力之大可想而知。本来想做飞机的，却买不到机票，只能做长途火车；想做硬卧的，却只能买到坐票；那些买不到火车票的，只能去买高价且不舒适的汽车票，更有甚者还有那些根本买不到合适票的人。同样这样的情况助长了’黄牛党’一族的快速增长。一票难求的情况估计只要黄金周的存在就难以根治。这里还要重申的是：中国不仅仅只有一个十一黄金周，还有春节黄金周、五一黄金周。三个黄金周，三次人口大迁移。辛苦的，或者说痛苦的是老百姓啊。

黄金周是给大家出游准备了充足的时间，但是大家都玩好了么？
记得去年黄金周过后，一幅照片让我震惊，在天安门前的金水桥上满满登登的都是人，如果不是前人将金水桥造的结实，我还真是担心这座桥会被压踏。毕竟前人不会想到今天会有如此多的人站在这座桥上。今年黄金周之后大家在电视、报纸、网络媒体上看到的也是各个景区人满为患、票价上涨、服务质量急剧下降的报导，故宫游览人数超出最大接待量的2倍，八达岭长城又’下了饺子’，九寨沟更是采用了限时入景区的策
略。尽管国家加大了景点和文物的保护力度，但是你不得不承认在如此大的游览人数面前这些保护规定显得那么脆弱，这不是治本的方法。

黄金周出台有其历史原因，但随着中国经济的发展，人们发现其带来的弊端日益严重，到了急需改革的阶段了。我个人希望取消五一、十一这两个黄金周，但是要延长春节的假期，毕竟春节这个黄金周是无论如何不该取消的。还有一条就是总的休假时间是不能减少的，如果新方案不能保证这一点，那就是倒退了。