早在几个月前就从网上下载到了"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 当你感到绝望时

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

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

中午在CSDN上看到一则新闻，说的是"中国开源社区热潮背后 缺少奉献型人才"，看完后有些感触，也就想在这里说两句。

谈到为开源项目奉献，我认为首先要具备三个条件：
1、投身开源的热情，即有奉献的意愿；
2、参与开源的技术能力，这里是指能参与到某开源项目核心或主力开发行列的能力；当然你要说参与开源的形式是多样的。如提交一个bug，辅助做一个模块测试同样也是为开源奉献，这里我也不否定，见仁见智。
3、时间与精力，无后顾之忧或者说生存之忧患。

我认为在中国绝不缺乏符合前两个条件的程序员，而且应该为数不少。中国程序员是愿意奉献的，也是有能力奉献的，但是中国程序员太累了，大多数没有足够的时间精力去奉献。

在与从美国出差回来的同事闲谈中得知了美国程序员的轻松生活。所谓"轻松"无非不愁钱，工作压力小，可自由支配时间多。而这些恰恰是中国程序员所缺少的。大家都知道目前中国软件业发展的确很快，但是不可否认的是中国软件公司多处于软件产业链的低端，技术含量不高，但劳动强度却很大。比如给日本人做外包，日本人是很矫情和苛刻的，当然日本人的质量意识值得我们学习，不过这是题外话了。给日本人做软
件的一个特点就是要写大量的文档，一个文档不到10页，却要反复的改来改去，改到中国项目经理满意，改到日本人满意。很多人没日没夜的加班其实都做了些什么呢？其实很可能就是在那不到10页的文档上改来改去。我没参与过外包项目，更没有参与过日本外包项目，但是以上都是身边同事的亲身经历，这里我是不敢妄言的。大好的青春时光就这样在没有任何激情和创造力的工作中虚度了。这不能怪我们的程序员，因为我们需要赚钱吃饭。

中国软件公司的产品中行业产品或项目居多。做过行业软件的人一定知道：做行业软件，一定要懂业务，只有成为行业专家才能有发展。可怜这些程序员了，整天忙于如何熟悉业务，如何满足客户变化多端的需求。做电信或者金融行业软件的人晚上还要配合客户搞升级，解决问题，这样的程序员能不累么。中国程序员虽然累，但是收入却不高，对比蒸蒸日上的房价，物价，利率，曾经的中高收入阶层的程序员也无语了。从学校步入社会后才知道曾经的买房、买车的梦想实现起来也不是那么容易。这样的情况下：程序员也就开始功利化了。做了2年技术羽翼丰满些后，转向管理的，转向销售的，转向行业专家的，转向技术支持的，转向客服的，考公务员以得到轻松生活的，甚至是转行的，都是大有人在的。这也不能怪我们的程序员，因为程序员的父母、老婆、孩子还得吃饭治病啊。

以上是从一个热爱技术的程序员的角度去分析的，也许这就是中国程序员的众生相。不过每个人有自己的生活方式，大家也不必为了缺少对开源的奉献而感到愧疚，用新名词说：这就是国情，不是我们一己之力可以改变的了的。

与欧美程序员相比，中国程序员还是很年轻的。在欧美你会见到年龄在40-50岁之间的程序员，而中国这样的程序员早已不写程序而成为管理者了。在公司办公室的座位上环顾四周，你会发现周围都是刚毕业的年轻人，他们有激情，有实力，这说明中国程序员还是很有潜力的。我相信在将来会有越来越多的中国程序员活跃在世界开源软件领域，为之默默奉献。

附：我知道的中国程序员发起的有影响的开源项目：XRuby, JFox。