程序员重构水管图

‘壹’ 为什么国内程序员都很少进行代码重构

说到代码的重构对于国外的程序员提到的比较多，特别是大型的开源工程，基本上一个模块或者函数的实现会反复的修改，一个文件能被修改成千上万次，曾经订阅了linux内核组的邮件，每天的收到的修改文件成千上万，有时候一个文件都能被修改上百次，对于文件修改最疯狂的是google的chrome源码，重构的次数，让你觉得每天都在重写但是功能上感觉越来越流畅。为什么我们周围的程序员绝大部分时间做的不是这样的事情。

为啥从直觉上觉得老外的写的代买质量比我们的要高，我们国内的程序员绝大部分的时间是在赶进度，准确的来讲忙着增加功能和修改bug，其实也从侧面反映出为什么国内出不了android以及Linux等影响深远的 科技 创新，从全球开源代码的占比就可以看出，差距还是很巨大的。

为什么觉得老外写的代码比我们的强？

1.国内软件发展主要阶段还在解决有没有，还远谈不上强大
中国的软件经过近几十年长足的发展，已经取得了巨大的成就，特别在互联网行业已经有几个巨头跻身世界前列了，最近炒的很热的脸书的用户数据泄密事件，作为当事人扎克伯格，也在论述中提到中国有几个很厉害的互联网公司，这说明中国在互联网领域还是取得了相当大的成就，但是在一些核心的领域，或者门槛很高的领域差别还是非常巨大。

任何事情在发展的初级阶段首要考虑的是不是有没有，所以如同创业初期的公司会选择短时间内搞出来个产品，哪怕是不成熟的产品，然后快速的投入市场，根据市场用户的反应同步追踪问题，等到产品差不多稳定，并且产品在市场上有了一席之地之后，后续的事情就要考虑优化功能，对里面的代码或者产品的性能进行全方面的提升，目前国内大部分的互联网一般比较年轻，还在解决有没有的问题，相信随着时间的推移以及国内软件的发展，也会有大量的高质量的开源框架代码出来，但这一切都需要很长的时间。

所以国内的程序员大部分时间都是在赶进度和根据需求完成功能代码。

2.软件产业的底子还很薄弱， 历史 积淀还不够
举个很典型的例子，现在很多国内的程序员到了30多岁就开始考虑后续的转型了，因为后面的轻轻人会带来很大的冲击，所以大部分的30多岁的程序员都在考虑自己后路，都要考虑转型的问题。老的有经验的程序员反而转型去做管理或者合伙创业了，哪有几个还在安心搞技术，年龄大了还在搞技术的还被人鄙视，觉得自己没有出息。

但是在国外写代码是一种很常见的职业，和别的工种没有多大的差异，40，50岁了写代码也是比比皆是，做软件是一种技术工种，经验的占比是很高的，所以老程序员写出来的代码更加有深度，稳定性更高，一切的根源还是产业的发展不够成熟，需要时间和 历史 的积淀，从这方面讲国内的软件整体产业还是比较薄弱，从业人员的整体素质和工作氛围还有待慢慢的成熟，周围都是有经验的程序员在带领着如何去重构代码，如何提升代码的质量，而国内大部分的程序要还是被产品经理鞭策着增加需求和修改代码。

3.公司的文化差异
目前很多的中国技术公司更多的追求的是短期利益的最大化，在基础软件的投入远远不够，毕竟基础的投入很难短期见成效，在一个具体的场景，有一个产品主体的功能已经实现了，也能在用户那边投入使用了，一般的公司很难拿出时间来，让你做代码的重构，毕竟这种事情很难直接产生经济效益。这与公司本身的文化差异有很大的关系，重视的技术或者懂得技术的公司对于这方面相对比较重视，反之就差很多。

小时候课本上就说着我们落后100年，所以高楼大厦不是一天建成的，所以在追赶的道路很漫长，所以承认存在差距，然后努力加倍的去追赶。

Time is money. 以目前国内互联网的情况，需求应接不暇，程序员基本上都是被需求与业务赶着走，时间非常紧张，在这种情况下，程序员很多时候唯一的选择就是赶紧实现需求的功能。所以，一个项目下来，代码基本上都变得非常非常的“垃圾”。

也有很多程序员想过在项目结尾的时候进行代码的重构，基本上每个程序员也都知道重构代码的好处，但是并不代表着真正能做起来。还是那个原因，国内互联网的速度太快，需求应接不暇，做为程序员，基本上没有时间来做这件事情。

而另外一个原因是跟团队负责人有关。若团队负责人能够意识到重构的好处，那么他可以为此单独划分一段开发时间出来，让大家分别负责一个模块进行重构，这都是可以安排做起来的。这也需要团队负责人如何在需求人员的需求与代码质量的进度上做一个平衡，进行统筹安排。

最后我想说一个可能很少意识到的原因，那就是人员流动问题。国内互联网目前人员流动非常的大，尤其是北上深这样的互联网发达的城市，基本上是平均两年就会走一大波人，在这样的情况下，也会考验从业人员的职业道德，即我到底要把代码写的多好，要把代码的可维护性做到多好，其实这都是从业人员自身需要考验的问题，因为完成一个功能很容易，但是要考虑的全面就是另外一回事了。而人员流动带来的另一个问题就是有一些代码是很难看懂的，即有些代码在人员离开后成为了“ 历史 ”，无人敢动。这也会阻碍着软件的重构工作的进行。

从我所讲的这几种情况来看，重构其实是大家都能知道的好处，但是真正实施起来却又有现实的约束，需要负责人来做这样的统筹安排与推动。

成本太大
大多数软件产品的开发都是经过了很多开发人员的付出，如果进行代码重构需要了解产品、了解框架、了解代码逻辑，这个过程会花费大量的时间和人力成本，对于企业来说，效益是第一位的，与其花费精力进行效益不大的产品重构，不如去承接更多的项目来的实在。
领导决策
由于大部分企业的老板都是非技术人员出身，他们更关注效益和客户，为了符合企业的发展，在进行产品开发时会更多的采用新技术来吸引客户，花费精力重构代码不如开发一套新产品或者开发更酷炫的效果更具有实在意义。
代码规范不足
由于国内互联网较之国外起步较晚，很多企业发展时间较短，加之人员流动比较大等多方面的因素，很难形成标准、严谨、行之有效的代码规范，所以很多技术人员在开发时都是根据个人风格习惯在开发，等其他人接手代码时，缺少相关标准和文档，很难理解代码逻辑，花时间去了解代码、重构代码不如直接推翻重做来的方便。
客户定制化需求
部分企业创业初期对企业信息化是不够重视的，只有企业发展到一定程度才会考虑信息化建设，而由于业务的限制，大多数标准化的互联网产品都很难满足企业的实际需求，需要进行大量定制化的开发，对于互联网企业来说，即使产品开发足够完善，在实际项目中也需要进行扩展，倒不如直接在项目中进行调整。
程序员的发展限定
在国内很少有终身的程序员，大部分都会逐渐转向销售、售前、项目经理、产品经理等岗位，而这些岗位则需要了解业务、了解客户，对技术的需求反而不会太高，所以与其花时间去专研技术不如将更多的精力用在业务和项目层面。

代码能够重构对底层框架要求深度掌握、且代码框架本身要足够灵活，而国内绝大部分技术人员都是停留在对框架的使用层面、少数可以完善、结合使用，极个别的在做同语言山寨或者换一种语言重写，能够对产品体系进行把握、与时俱进扩展实在是凤毛麟角。随着国家的经济提升、IT行业逐渐成熟，在我国这么多IT公司基数下，即便是凤毛麟角的概率，重视基础框架、积累萃取、不断迭代完善的一些技术公司也会慢慢崭露头角、涌现出来的。

【国内程序员很少进行代码重构】，这个现象虽然没有什么调查统计，不过我写了十多年代码，也发现身边的程序员大多数是这样的，【宁可写新的代码，也不愿意重构老代码】。下面我也谈谈自己的看法：

系统没有问题，就是最大的功劳
我见过的大部分的传统行业的软件公司或IT部门是这样的（互联网公司不太了解），“只要系统稳定，那么就是最大的功劳”，而保持系统稳定最好的方法是什么？ 就是尽可能的不要动系统！

可能很多人不能理解，但很多公司确实是这样，甚至公司对项目的考核标准中，项目有什么突破的权重很低，是否有生产事故的权重很高。所以很多“机智”的项目组成员，千方百计的不接需求，或者把需求推给别的项目组。在这种单位里面，别说重构了，新代码都写的不多。

测试覆盖度太低，重构代码没办法保证质量
代码重构，很重要的一个问题：“重构后的代码谁来保证？如果影响到原有的功能怎么办？”

这时候很有效的一个方法，是使用各种自动化的测试来保证重构代码的质量。

但是，大部分公司，不管是单元测试还是其他的自动化测试，都是不健全的，甚至是没有的。所以只要不是被逼不得已，程序员宁可重新写一个方法，也不愿意重构之前的代码。

其他

进行代码重构不是一件容易的事情，务必需要对需求熟悉；对代码 历史 变更熟悉；对代码框架，模块熟悉；对产品更新迭代做好风险把控，时间成本把控……

进行代码重构需要能力非常高，责任心非常强的人进行，甚至需要一个优秀的团队完成。

为什么要代码重构？理由一大堆，我认为主要有两条，一是原代码已不适合扩展新需求，二是原代码已拥肿不堪，乱七八糟。

为什么很少重构？除了上述分析外，还有其他因素，如人员流动快，原团队原作者早已不知何去何从了。又如需求和业务繁多，完成工作开发都累得半死不活，日理万机似的，哪有时间和心情重构？

谢谢大家。

1.国内程序员技术能力不足以进行代码重构

大量的软件从业人员连编程规范都不熟悉，怎么可能做代码重构？更多的人只会写写hello world，只会拷贝粘贴小段代码，连if else这种语句都写不清楚甚至漏掉逻辑，连面向对象的编程思想都没有，谈何重构？

2.国内程序员的沟通能力说服能力一般。

进行软件重构，必须说服经理，让经理相信重构会带来软件质量的提高和故障率的逐步降低，这样经理才会安排人力进行重构。

3.国内软件开发更注重bug的及时解决

国内软件开发大量的人力被分配到解决短期的某个bug，没人抽时间思考如何长久的彻底的解决软件缺陷，其实解决bug不重要，找到软件的缺陷或者性能低下的地方才重要，这些才是重构的点。国内加班加点疲于奔命式的开发，没人考虑bug率是否长期内能够收敛，总是先解决眼前的问题再说，处于一个永远解决bug的死循环里。

这种工作模式是愚蠢的，不是smart的。

软件开发，一定要动脑子，不要蛮干，这不是耕地，力气大就耕的多。

重构代码的目的说白了，就是让软件开发人员更自由。

谢谢楼主的问题，这是一个我特别想回答的问题？

为什么？因为，第一，我是一个对代码有洁癖的人，受不了一坨，一坨那样的代码。第二，我是一个践行Clean Code 的人，给大家我主要负责的一个项目的一组数据（java），总代码量20万行,UT coverage(单元测试代码覆盖率）82%，代码重复率0.5%，代码规则(sonar）违反（Code issue）0,甚至连最低的违反都没有。

也正是因为我的项目在实践Clean Code上的数据，我经常去给不同的团队做分享，也对团队对这个重构不太上心有一些理解。

大致以下几个原因。

第一，也是最多的，交付压力，大部分人都会抱怨，你看我们有这么多新功能，还有那么多bug,根本忙不过来，哪有时间重构？

第二，重构意识不足，老板，管理人员总是希望这个我们要有，那个我们也要实现？为什么？因为别人有，别人有我们没有可能会造成用户流逝。即使有一些有见识的程序员和老板反应这个重构问题，但是重构从来不是高优先级的。毕竟，现在的软件的生命周期可能很短。

第三，人员流动性大，这个是我听过最奇葩的一个理由，我问一个来听培训的哥们，说你代码写成这样，以后怎么维护？这个哥们说，我也知道难维护，但我明年就跳槽了。

第四，设计上就不需要重构，曾经给一个保险公司做分享，我本人也是做金融相关产品后台的，我就问你们这样写代码，可能三四年以后就非常难维护了，还是要尽快重构。他们的回答是，我们不重构，我们只重写。什么意思那？就是一个系统，三四年以后在写一遍。

第五，程序员本身的问题，可能第一写单元测试，修改命名，修改代码结构，是一件很没有成就感的事情，也是一个没有多少附加值的事情。毕竟现在你去找工作，这个代码质量方面的问题会问得很少。

第六，我见过的我不能反驳的一个回答，我的英文太差，不能很好的命名，而我也不想学英文。

第七，反正我已经实现了功能。

最后，用一句话来提醒程序员们，重构是多么重要。

出来混迟早要还的，挖了坑迟早要填的。

在国内，【重构】这件事是程序员最喜欢做的事，而不是公司喜欢做的事。

但程序员喜欢并不能影响公司的决策，所以，国内的现象就是软件系统很少有重构。

其根本的原因在于，国内的公司所推出的系统大多没有重构的价值。

1、国内的互联网公司存在这样一种快节奏，那就是发现一个有价值的创意，就马上进入开发，开发完成立即上线，并立马推广使用。这是一种快速试错的模式，一旦发现系统在 社会 中没有引起反响，那就马上把系统再下线。这种情况下的系统哪来的重构价值呢？

2、即使一个系统上线成功了，也积累了大量的用户，貌似为了系统的稳定性和性能，可以有重构的机会。但事实上不是，国内公司仍旧不会选择重构，因为重构带不来新的价值。所以，公司多数都会在系统上添加新的功能来吸引新的客户，而不会考虑重构现有系统。

总得来说，引起重构的原因在于能够有持续的价值。没有价值的事，企业当然不会做，仅是程序员的一厢情愿而已。

你只是见到了你所在的公司现象，不代表所有，也不能代表大部分的。

代码重构还是存在的现象

代码设计烂，经常出问题、扩展麻烦、维护心累、数据混乱、结果不清醒、模块划分混乱

就可能要考虑到重构了

呵呵，

老大说：

你赶紧去修复一下这个bug，

还有几个功能没有实现，加班搞一下，

pm 说：

这个功能改一下，

还有这个，界面重新调整一下，

这个业务流，现在不一样了，

客户需求需要多几个功能，

老板说：

这东西下周能出来吗？

‘贰’ 程序员的七种武器是什么

根据本人的多年开发经验，向那些刚刚踏入IT行业的新程序员们或正在迷茫的程序员们整理出了程序员必须掌握 的七种武器以及相关的视频教程。 第一种武器：开发工具 基于C++、VC++开发平台工具快速入门： 第一部份： VS2008 IDE开发环境的基本使用方法 第二部份：VS2008调试环境的使用 第三部份：VS2008性能分析工具 基于MyEclipse平台的Java程序快捷开发： 第一部份：JAVA开发环境的搭建 第二部份：MyEclipse工具常用开发操作和技巧 第三部份：MyEclipse高级使用技艺 - 重构与快速实现 基于Linux操作系统平台下的Java语言开发： 第一部份： 安装虚拟机以及Linux操作系统 第二部份： Linux桌面系统 第三部份： Linux文件和目录管理 第四部份： VIM的使用（上） 第五部份： VIM的使用（下） 第六部份： Linux终端常用命令第七部份： Java开发环境的搭建 第二种武器：数据库 SQL Server 2008 数据库基础及应用： 第一讲：SQL Server的安装与配置 第二讲：SQL Server中的库、表、数据完整性 第三讲：SQL Server中的CRUD语法 第四讲：SQL Server中的查询语句 第五讲：SQL Server中的高级查询 第六讲：SQL Server高级查询综合示例（一） 第七讲：SQL Server高级查询综合示例（二） 第八讲：SQL Server高级查询综合示例（三） ORACLE系列之SQL从入门到精通： 第一讲：数据库基础知识 第二讲：创建数据库 第三讲：管理和控制Oracle数据库 第四讲：Oracle数据库表管理 第五讲：基本SQL语句 第六讲：对数据进行限定和排序 第七讲：处理单行的函数 第八讲：从多个表中获取数据 第九讲：数据查询的综合案例(一) 第十讲：使用分组函数来对数据进行聚集 第十一讲：子查询及高级应用 第三种武器：操作系统 Linux系统编程(文件篇、进程篇、信号与管道篇、时间篇、实战篇)： 第一部分：Linux系统编程之文件篇 第二部分：Linux系统编程之进程篇 第三部分：Linux系统编程之信号与管道篇 第四部分：Linux系统编程之时间篇 第五部分：Linux系统编程之实战篇（minishell实现） 第四种武器：网络协议TCP.IP Windows服务器与网络编程实战课程(VC++系列之网络编程、WinSock超基础)： 第一部份：计算机网络和网际协议（TCPIP） 第二部份：标准套接字SOCKET原理及编程 第三部份：WinSock工作模式和编程模型 第四部份：WinSock2.0API和SOCKET池 剖析.NET网络通信、音频、移动平台IM及服务器端编程： 第一部份：.NET网络通信了解基本的.NET网络通信基础 第二部份：UDP点对点网络通信 第三部份：UDP服务器/客户端通信 第四部份：UDP网络文件传输 基于TCPIP协议的java多线程高并发服务器实战： 第1课：TCPIP协议，多线程，高并发网络编程概述 第2课：基于TCPIP协议的自定义网络通信协议实现（一） 第3课：基于TCPIP协议的自定义网络通信协议实现（二） 第4课：多线程精讲（一） 第5课：多线程精讲（二） 第6课：网络基础编程（一） 第7课：网络基础编程（二） 第8课：网络基础编程（三） 第9课：java NIO（一） 第10课：java NIO（二） 第11课：java NIO（三） 第五种武器：DCOM.CORBA.XML.WEB Services .NET下面的WebService开发： 1.掌握 Web Service 的基本工作原理 2.理解 Web Service 的优势 3.掌握 Web Service 的开发和使用 4.ASP.net中如何通过代理类调用WebServic 5.ASP.net中如何手工调用WebService(Get/Post两种方式) 6.JavaScript如何同步调用WebService 7.JavaScript如何异步调用WebService 8.ExtJs中如何调用WS 9.通过SOAP头来增强WebService安全性 10.Web Service开发中需要注意的问题 Java平台下的WebService框架Xfire深入解析： 第一部分、WebService 概念与xFire入门 第二部分、xFire开发起步 第三部分、Web服务客户端及Web服务安全性 第四部分、xFire与Spring集成 第五部分、xFire使用综合示例 第六种武器：软件工程与CMM IT人必备实用项目管理系列订餐系统实例化教学—Java版,10年IT经验总结,涉及测试、风险、负载等： 1. 课程综述：我们目前项目管理中遇到的困惑和我们所处的现状。 2. 团队组建和项目计划。 3. 需求管理：任何人都为之头疼的东西。 4. 实战订餐系统需求管理：，体验一把从头构建需求的快乐和痛。 5. 软件配置管理：只是技术，纯粹解决项目开发问题。 6. 软件设计：该怎么去设计一个软件。 7. 进度控制：进度是大部分项目组头疼的事情。 8. 风险管理：我们能做到的到底有多少。 9. 成本管理：不是说如何报价，而是说如何做能合理些。 10.软件测试：确保软件质量的关键点。 11. 单元测试：如何使用junit实施单元测试。 12. 负载测试：看看这辆车到底能拉多少货？ 13. 验收交付：客户满意，公司满意，我们的追求。 14. 过程改进：下个项目我们还需要这么费力吗？ IT项目管理实战ASP.NET版(负载均衡+Web测试+VSTS单元测试+VSS+订餐系统,10年经验总结)： 1. 课程综述：我们目前项目管理中遇到的困惑和我们所处的现状。 2. 团队组建和项目计划。 3. 需求管理：任何人都为之头疼的东西。 4. 实战订餐系统需求管理：，一起体验一把从头构建需求的快乐和痛。 5. 软件配置管理：只是技术，纯粹解决项目开发问题。 6. 软件设计：该怎么去设计一个软件。 7. 进度控制：进度是大部分项目组头疼的事情。 8. 风险管理：我们能做到的到底有多少。 9. 成本管理：不是说如何报价，而是说如何做能合理些。 10.软件测试：确保软件质量的关键点。 11. 单元测试：如何使用junit实施单元测试。 12. 负载测试：看看这辆车到底能拉多少货？ 13. 验收交付：客户满意，公司满意，我们的追求。 14. 过程改进：下个项目我们还需要这么费力吗？ 第七种武器：算法与数据结构 C#版数据结构与算法高级教程(深入探讨)--附各种算法实例： 一、算法的评价指标 （1） 二、线性表：（3） 三、栈和队列 （3） 四、串（3节） 五、树（5） 六、排序（4） 实战应用Java算法分析与设计(链表、二叉树、哈夫曼树、图、动态规划、HashTable算法)： 第一讲、算法基本概述、抽象数据类型 第二讲、算法的设计目标、时间复杂度和空间复杂度 第三讲、线性结构与顺序表的实现与应用 第四讲、单向链表以及单向链表的应用 第五讲、循环链表仿真链表以及循环链表应用 第六讲、栈的基本概念以及顺序栈的应用 第七讲、链式堆栈以及栈的应用 第八讲、中缀表达式转换后缀表达式算法 第九讲、队列以及顺序循环队列的应用 第十讲、链式队列以及优先级队列应用

记得采纳啊

‘叁’ 为什么中国的程序员总被称为“码农”

对于一些贬义的说法，个人认为作为一个程序员应该保持“诚意开张圣听，不要妄自菲薄”的态度。程序员一直以来看哪个是别名最多的一个职业，我姑且不分褒贬的称之为你才吧！就像小学的时候一样，相互之间往往喜欢区别名叫昵称之类的，而又往往外号叫的最响小名最多的就是最受关注的哪一个，程序员在当今网络上的处境大抵如此。码农这个词米偶遇仔细研究过来源。参考其他人的回答知中文中的码农大体相当于英文中的code monkey。程序员码农说法的由来大概来自于程序员圈内自嘲的说法。这里程序员对码农的更多理解可能更接近coder这个词，就是说我是一个写代码的。可能会有人以此来明志，表面自己很热爱写代码，或我很精通以此，再或者言外之意我只是一个写代码的，别来找我给你装系统修电脑什么的，我最烦这个了(ノ｀Д)ノ。
程序员这个行业知名度虽然高，但是正在了解程序员是做渗坦什么的人并不多，大多数人直观臆想出来的感受可能是一个座在电脑前，后背前倾，颈脖前伸，面容憔悴，形容枯槁，两眼无关紧盯着电脑，两只鸡爪子似的双手快速的在键盘上敲击，屏幕快速出现一行行一块块英文字符的形象。这其实只是程序员的表面，完全米有展现出大多数程序员的内在。
程序员真正的工作是解决问题，代码只是解决问题的途径，或曰实现方案。程序员究竟解决什么问题呢，又是从哪里来的问题呢？首先要提到产品经理，产品经理给成员一个需求，程序员要思考如何实现这个需求。比如产品说这个登录过程应该这样这样，用户是否有通过手机或者邮箱验证。程序员要做的就是想方案来实现这个需求。
在比如产品说我们这个网站要同时支持多少人访问不会出现卡，或者页面刷不出的情况。程序员接到这个需要就要思考如何设计这样一个高性能，高并发的服务端，最终通过代码来实现设计。
好，现在代码写完啦，产品发布上线了。什么购物网站啊，大家可以随意挑选自己喜欢的产品，什么交友网站啊，大家可以写好自己的介绍发布出去让别人看到。但是还米有完，可能这个网站还要加点新功能，或者程序员自己也想，这个代码有没有什么地方实现的不好，换一个方法会不会更优雅。然后又是思考解决<=实现方案<=线下测试。自己测试发现可以，这个方法很好，发布到线上，就是用户最终使用的形态。不断提出新需求，完善新的功能我们称之为迭代。改善现有设计我们称之为重构。这些都是非常有艺术感的事！
事物发展就会演缺念变出各种变体，有一些公司会把问题和解决问题的方法都做好，然后再交给其他公司或者个人去做实现（写代码）。由于在这里解决问题的过程被剥离出来（最有技术和艺术感的部分）剩下的就是实现，就是敲代码。
好比建一栋房子，房子的设计和施工方案都已经做好了，就剩下施工了，这时候只要找个施工队就可以了。在这些做设计的公司，他们是有能力来实现这些方案（敲代码）。
但伏喊困由于欧美日等国家人力成本高，将这些技术含量低敲代码的苦活儿剥离出来交给相对落后地区的人去实现可以帮助他们节省人力成本。以上这个现象就称之为软件外包。
另一方面，在美国主导的全球生产分工下，美帝也希望将中印这样的发展中国家固定在低端制造，劳动秘籍型的行业。
既然程序员是解决问题的，那么是否所有电脑相关的问题程序员都能解决呢？纵向来看，计算机系统可以简单的分为三层，应用程序<=操作系统<=计算机硬件。计算机硬件的设计研发基本和程序员无关。硬件往上就是程序员的职责范围了。这是可以简分为应用软件程序员和系统软件程序员。系统程序员的责任是实现高效的硬件管理，应用程序员则是为用户提供高效的服务。
下面说说在这两方面和国外的差距，手机端应用软件（有服务端的包括服务端）差别不大，大家从自己手机中软件就能感觉到。PC端有差距，比如人家有PS这样的图片处理软件，而我们则没有。在这方面人家发展了几十年我们年数不够，有差距还是可以理解的。但我辈当发奋努力，以追他人之先。
另外应用程序web化应该是趋势，这方面我们还是有优势的，对于普通用户来说最直观的体验就是不用装很多软件了，只要有一个浏览器就行。
在操作系统层面，PC如Windows，服务器如Linux。Windows微软独家拥有的闭源系统，不说。Linux内核开发来讲国内正在迎头追赶，内核的邮件中中文拼音的人名越来越常见，越来越多的国人加入到Linux内核的开发中。

‘肆’ 要成为一名专业的程序员，从零开始需要怎么一步步来比较好，要把最底层的先学精通吗(个人认为)求学长

前言
你是否觉得自己从学校毕业的时候只做过小玩具一样的程序？走入职场后哪怕没有什么经验也可以把以下这些课外练习走一遍（朋友的抱怨：学校课程总是从理论出发，作业项目都看不出有什么实际作用，不如从工作中的需求出发）
建议：
不要乱买书，不要乱追新技术新名词，基础的东西经过很长时间积累而且还会在未来至少10年通用。
回顾一下历史，看看历史上时间线上技术的发展，你才能明白明天会是什么样。
一定要动手，例子不管多么简单，建议至少自己手敲一遍看看是否理解了里头的细枝末节。
一定要学会思考，思考为什么要这样，而不是那样。还要举一反三地思考。
注：你也许会很奇怪为什么下面的东西很偏Unix/Linux，这是因为我觉得Windows下的编程可能会在未来很没有前途，原因如下：
现在的用户界面几乎被两个东西主宰了，1）Web，2）移动设备iOS或Android。Windows的图形界面不吃香了。
越来越多的企业在用成本低性能高的Linux和各种开源技术来构架其系统，Windows的成本太高了。
微软的东西变得太快了，很不持久，他们完全是在玩弄程序员。详情参见《Windows编程革命史》
所以，我个人认为以后的趋势是前端是Web+移动，后端是Linux+开源。开发这边基本上没Windows什么事。
启蒙入门
1、 学习一门脚本语言，例如python/Ruby
可以让你摆脱对底层语言的恐惧感，脚本语言可以让你很快开发出能用得上的小程序。实践项目:
处理文本文件，或者csv (关键词 python csv, python open, python sys) 读一个本地文件，逐行处理（例如 word count，或者处理log）
遍历本地文件系统 (sys, os, path)，例如写一个程序统计一个目录下所有文件大小并按各种条件排序并保存结果
跟数据库打交道 (python sqlite)，写一个小脚本统计数据库里条目数量
学会用各种print之类简单粗暴的方式进行调试
学会用Google (phrase, domain, use reader to follow tech blogs)
为什么要学脚本语言，因为他们实在是太方便了，很多时候我们需要写点小工具或是脚本来帮我们解决问题，你就会发现正规的编程语言太难用了。
2、 用熟一种程序员的编辑器(不是IDE) 和一些基本工具
Vim / Emacs / Notepad++，学会如何配置代码补全，外观，外部命令等。
Source Insight (或 ctag)
使用这些东西不是为了Cool，而是这些编辑器在查看、修改代码/配置文章/日志会更快更有效率。
3、 熟悉Unix/Linux Shell和常见的命令行
如果你用windows，至少学会用虚拟机里的linux， vmware player是免费的，装个Ubuntu吧
一定要少用少用图形界面。
学会使用man来查看帮助
文件系统结构和基本操作 ls/chmod/chown/rm/find/ln/cat/mount/mkdir/tar/gzip …
学会使用一些文本操作命令 sed/awk/grep/tail/less/more …
学会使用一些管理命令 ps/top/lsof/netstat/kill/tcpmp/iptables/dd…
了解/etc目录下的各种配置文章，学会查看/var/log下的系统日志，以及/proc下的系统运行信息
了解正则表达式，使用正则表达式来查找文件。
对于程序员来说Unix/Linux比Windows简单多了。（参看我四年前CSDN的博文《其实Unix很简单》）学会使用Unix/Linux你会发现图形界面在某些时候实在是太难用了，相当地相当地降低工作效率。
4、 学习Web基础（HTML/CSS/JS) + 服务器端技术 (LAMP)
未来必然是Web的世界，学习WEB基础的最佳网站是W3School。
学习HTML基本语法
学习CSS如何选中HTML元素并应用一些基本样式（关键词：box model）
学会用 Firefox + Firebug 或 chrome 查看你觉得很炫的网页结构，并动态修改。
学习使用Javascript操纵HTML元件。理解DOM和动态网页（Dynamic HTML: The Definitive Reference, 3rd Edition - O'Reilly Media) 网上有免费的章节，足够用了。或参看 DOM 。
学会用 Firefox + Firebug 或 chrome 调试Javascript代码（设置断点，查看变量，性能，控制台等）
在一台机器上配置Apache 或 Nginx
学习php，让后台PHP和前台HTML进行数据交互，对服务器相应浏览器请求形成初步认识。实现一个表单提交和反显的功能。
把PHP连接本地或者远程数据库 MySQL（MySQL 和 SQL现学现用够了）
跟完一个名校的网络编程课程（例如：http://www.stanford.e/~ouster/cgi-bin/cs142-fall10/index.php ) 不要觉得需要多于一学期时间，大学生是全职一学期选3-5门课，你业余时间一定可以跟上
学习一个javascript库（例如jQuery 或 ExtJS）+ Ajax (异步读入一个服务器端图片或者数据库内容）+JSON数据格式。
HTTP: The Definitive Guide 读完前4章你就明白你每天上网用浏览器的时候发生的事情了(proxy, gateway, browsers)
做个小网站（例如：一个小的留言板，支持用户登录，Cookie/Session，增、删、改、查，上传图片附件，分页显示）
买个域名，租个空间，做个自己的网站。
进阶加深
1、 C语言和操作系统调用
重新学C语言，理解指针和内存模型，用C语言实现一下各种经典的算法和数据结构。推荐《计算机程序设计艺术》、《算法导论》和《编程珠玑》。
学习（麻省理工免费课程）计算机科学和编程导论
学习（麻省理工免费课程）C语言内存管理
学习Unix/Linux系统调用（Unix高级环境编程），，了解系统层面的东西。
用这些系统知识操作一下文件系统，用户（实现一个可以拷贝目录树的小程序）
用fork/wait/waitpid写一个多进程的程序，用pthread写一个多线程带同步或互斥的程序。多进程多进程购票的程序。
用signal/kill/raise/alarm/pause/sigprocmask实现一个多进程间的信号量通信的程序。
学会使用gcc和gdb来编程和调试程序（参看我的《用gdb调试程序》）
学会使用makefile来编译程序。（参看我的《跟我一起写makefile》）
IPC和Socket的东西可以放到高级中来实践。
学习Windows SDK编程（Windows 程序设计 ，MFC程序设计）
写一个窗口，了解WinMain/WinProcere，以及Windows的消息机制。
写一些程序来操作Windows SDK中的资源文件或是各种图形控件，以及作图的编程。
学习如何使用MSDN查看相关的SDK函数，各种WM_消息以及一些例程。
这本书中有很多例程，在实践中请不要照抄，试着自己写一个自己的例程。
不用太多于精通这些东西，因为GUI正在被Web取代，主要是了解一下Windows 图形界面的编程。@virushuo 说：“ 我觉得GUI确实不那么热门了，但充分理解GUI工作原理是很重要的。包括移动设备开发，如果没有基础知识仍然很吃力。或者说移动设备开发必须理解GUI工作，或者在win那边学，或者在mac/iOS上学”。
2、学习Java
Java 的学习主要是看经典的Core Java 《Java 核心技术编程》和《Java编程思想》（有两卷，我仅链了第一卷，足够了，因为Java的图形界面了解就可以了）
学习JDK，学会查阅Java API Doc Java Platform SE 6
了解一下Java这种虚拟机语言和C和Python语言在编译和执行上的差别。从C、Java、Python思考一下“跨平台”这种技术。
学会使用IDE Eclipse，使用Eclipse 编译，调试和开发Java程序。
建一个Tomcat的网站，尝试一下JSP/Servlet/JDBC/MySQL的Web开发。把前面所说的那个PHP的小项目试着用JSP和Servlet实现一下。
3、Web的安全与架构

学习HTML5，网上有很多很多教程，以前酷壳也介绍过很多，我在这里就不罗列了。
学习Web开发的安全问题（参考新浪微博被攻击的这个事，以及Ruby的这篇文章）
学习HTTP Server的rewrite机制，Nginx的反向代理机制，fast-cgi（如：PHP-FPM）
学习Web的静态页面缓存技术。
学习Web的异步工作流处理，数据Cache，数据分区，负载均衡，水平扩展的构架。
实践任务：
使用HTML5的canvas 制作一些Web动画。
尝试在前面开发过的那个Web应用中进行SQL注入，JS注入，以及XSS攻击。
把前面开发过的那个Web应用改成构造在Nginx + PHP-FPM + 静态页面缓存的网站
4、学习关系型数据库
你可以安装MSSQLServer或MySQL来学习数据库。
学习教科书里数据库设计的那几个范式，1NF，2NF，3NF，……
学习数据库的存过，触发器，视图，建索引，游标等。
学习SQL语句，明白表连接的各种概念（参看《SQL Join的图示》）
学习如何优化数据库查询（参看《MySQL的优化》）
实践任务：设计一个论坛的数据库，至少满足3NF，使用SQL语句查询本周，本月的最新文章，评论最多的文章，最活跃用户。
5、一些开发工具
学会使用SVN或Git来管理程序版本。
学会使用JUnit来对Java进行单元测试。
学习C语言和Java语言的coding standard 或 coding guideline。（我N年前写过一篇关C语言非常简单的文章——《编程修养》，这样的东西你可以上网查一下，一大堆）。
推荐阅读《代码大全》《重构》《代码整洁之道》
高级深入
1、C++ / Java 和面向对象
我个人以为学好C++，Java也就是举手之劳。但是C++的学习曲线相当的陡。不过，我觉得C++是最需要学好的语言了。参看两篇趣文“C++学习信心图” 和“21天学好C++”
学习（麻省理工免费课程）C++面向对象编程
读我的 “如何学好C++”中所推荐的那些书至少两遍以上（如果你对C++的理解能够深入到像我所写的《C++虚函数表解析》或是《C++对象内存存局（上）（下）》，或是《C/C++返回内部静态成员的陷阱》那就非常不错了）
然后反思为什么C++要干成这样，Java则不是？你一定要学会对比C++和Java的不同。比如，Java中的初始化，垃圾回收，接口，异常，虚函数，等等。
实践任务：
用C++实现一个BigInt，支持128位的整形的加减乘除的操作。
用C++封装一个数据结构的容量，比如hash table。
用C++封装并实现一个智能指针（一定要使用模板）。
《设计模式》必需一读，两遍以上，思考一下，这23个模式的应用场景。主要是两点：1）钟爱组合而不是继承，2）钟爱接口而不是实现。（也推荐《深入浅出设计模式》）
实践任务：
使用工厂模式实现一个内存池。
使用策略模式制做一个类其可以把文本文件进行左对齐，右对齐和中对齐。
使用命令模式实现一个命令行计算器，并支持undo和redo。
使用修饰模式实现一个酒店的房间价格订价策略——旺季，服务，VIP、旅行团、等影响价格的因素。
学习STL的用法和其设计概念 - 容器，算法，迭代器，函数子。如果可能，请读一下其源码。
实践任务：尝试使用面向对象、STL，设计模式、和WindowsSDK图形编程的各种技能
做一个贪吃蛇或是俄罗斯方块的游戏。支持不同的级别和难度。
做一个文件浏览器，可以浏览目录下的文件，并可以对不同的文件有不同的操作，文本文件可以打开编辑，执行文件则执行之，mp3或avi文件可以播放，图片文件可以展示图片。
学习C++的一些类库的设计，如： MFC（看看候捷老师的《深入浅出MFC》） ，Boost, ACE, CPPUnit，STL （STL可能会太难了，但是如果你能了解其中的设计模式和设计那就太好了，如果你能深入到我写的《STL string类的写时拷贝技术》那就非常不错了，ACE需要很强在的系统知识，参见后面的“加强对系统的了解”）
Java是真正的面向对象的语言，Java的设计模式多得不能再多，也是用来学习面向对象的设计模式的最佳语言了（参看Java中的设计模式）。
推荐阅读《Effective Java》 and 《Java解惑》
学习Java的框架，Java的框架也是多，如Spring, Hibernate，Struts 等等，主要是学习Java的设计，如IoC等。
Java的技术也是烂多，重点学习J2EE架构以及JMS， RMI, 等消息传递和远程调用的技术。
学习使用Java做Web Service （官方教程在这里）
实践任务： 尝试在Spring或Hibernate框架下构建一个有网络的Web Service的远程调用程序，并可以在两个Service中通过JMS传递消息。
C++和Java都不是能在短时间内能学好的，C++玩是的深，Java玩的是广，我建议两者选一个。我个人的学习经历是：
深究C++（我深究C/C++了十来年了）
学习Java的各种设计模式。
2、加强系统了解
重要阅读下面的几本书：
《Unix编程艺术》了解Unix系统领域中的设计和开发哲学、思想文化体系、原则与经验。你一定会有一种醍醐灌顶的感觉。
《Unix网络编程卷1，套接字》这是一本看完你就明白网络编程的书。重要注意TCP、UDP，以及多路复用的系统调用select/poll/epoll的差别。
《TCP/IP详解 卷1:协议》- 这是一本看完后你就可以当网络黑客的书。了解以太网的的运作原理，了解TCP/IP的协议，运作原理以及如何TCP的调优。
实践任务：
理解什么是阻塞（同步IO），非阻塞（异步IO），多路复用（select, poll, epoll）的IO技术。
写一个网络聊天程序，有聊天服务器和多个聊天客户端（服务端用UDP对部分或所有的的聊天客户端进Multicast或Broadcast）。
写一个简易的HTTP服务器。
《Unix网络编程卷2，进程间通信》信号量，管道，共享内存，消息等各种IPC…… 这些技术好像有点老掉牙了，不过还是值得了解。
实践任务：
主要实践各种IPC进程序通信的方法。
尝试写一个管道程序，父子进程通过管道交换数据。
尝试写一个共享内存的程序，两个进程通过共享内存交换一个C的结构体数组。
学习《Windows核心编程》一书。把CreateProcess，Windows线程、线程调度、线程同步（Event, 信号量，互斥量）、异步I/O，内存管理，DLL，这几大块搞精通。
实践任务：使用CreateProcess启动一个记事本或IE，并监控该程序的运行。把前面写过的那个简易的HTTP服务用线程池实现一下。写一个DLL的钩子程序监控指定窗口的关闭事件，或是记录某个窗口的按键。
有了多线程、多进程通信，TCP/IP，套接字，C++和设计模式的基本，你可以研究一下ACE了。使用ACE重写上述的聊天程序和HTTP服务器（带线程池）
实践任务：通过以上的所有知识，尝试
写一个服务端给客户端传大文件，要求把100M的带宽用到80%以上。（注意，磁盘I/O和网络I/O可能会很有问题，想一想怎么解决，另外，请注意网络传输最大单元MTU）
了解BT下载的工作原理，用多进程的方式模拟BT下载的原理。
3、系统架构
负载均衡。HASH式的，纯动态式的。（可以到Google学术里搜一些关于负载均衡的文章读读）
多层分布式系统 – 客户端服务结点层、计算结点层、数据cache层，数据层。J2EE是经典的多层结构。
CDN系统 – 就近访问，内容边缘化。
P2P式系统，研究一下BT和电驴的算法。比如：DHT算法。
服务器备份，双机备份系统（Live-Standby和Live-Live系统），两台机器如何通过心跳监测对方？集群主结点备份。
虚拟化技术，使用这个技术，可以把操作系统当应用程序一下切换或重新配置和部署。
学习Thrift，二进制的高性能的通讯中间件，支持数据(对象)序列化和多种类型的RPC服务。
学习Hadoop。Hadoop框架中最核心的设计就是：MapRece和HDFS。MapRece的思想是由Google的一篇论文所提及而被广为流传的，简单的一句话解释MapRece就是“任务的分解与结果的汇总”。HDFS是Hadoop分布式文件系统（Hadoop Distributed File System）的缩写，为分布式计算存储提供了底层支持。
了解NoSQL数据库（有人说可能是一个过渡炒作的技术），不过因为超大规模以及高并发的纯动态型网站日渐成为主流，而SNS类网站在数据存取过程中有着实时性等刚性需求，这使得目前NoSQL数据库慢慢成了人们所关注的焦点，并大有成为取代关系型数据库而成为未来主流数据存储模式的趋势。当前NoSQL数据库很多，大部分都是开源的，其中比较知名的有：MemcacheDB、Redis、Tokyo Cabinet(升级版为Kyoto Cabinet)、Flare、MongoDB、CouchDB、Cassandra、Voldemort等。

‘伍’ 代码重构的概述

重构（），通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。也许有人会问，为什么不在项目开始时多花些时间把设计做好，而要以后花时间来重构呢？要知道一个完美得可以预见未来任何变化的设计，或一个灵活得可以容纳任何扩展的设计是不存在的。系统设计人员对即将着手的项目往往只能从大方向予以把控，而无法知道每个细枝末节，其次永远不变的就是变化，提出需求的用户往往要在软件成型后，才开始品头论足，系统设计人员毕竟不是先知先觉的神仙，功能的变化导致设计的调整再所难免。所以测试为先，持续重构作为良好开发习惯被越来越多的人所采纳，测试和重构像黄河的护堤，成为保证软件质量的法宝。 在不改变系统功能的情况下，改变系统的实现方式。为什么要这么做？投入精力不用来满足客户关心的需求，而是仅仅改变了软件的实现方式，这是否是在浪费客户的投资呢？
重构的重要性要从软件的生命周期说起。软件不同与普通的产品，他是一种智力产品，没有具体的物理形态。一个软件不可能发生物理损耗，界面上的按钮永远不会因为按动次数太多而发生接触不良。那么为什么一个软件制造出来以后，却不能永远使用下去呢？
对软件的生命造成威胁的因素只有一个：需求的变更。一个软件总是为解决某种特定的需求而产生，时代在发展，客户的业务也在发生变化。有的需求相对稳定一些，有的需求变化的比较剧烈，还有的需求已经消失了，或者转化成了别的需求。在这种情况下，软件必须相应的改变。
考虑到成本和时间等因素，当然不是所有的需求变化都要在软件系统中实现。但是总的说来，软件要适应需求的变化，以保持自己的生命力。
这就产生了一种糟糕的现象：软件产品最初制造出来，是经过精心的设计，具有良好架构的。但是随着时间的发展、需求的变化，必须不断的修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改。为了实现变更，不可避免的要违反最初的设计构架。经过一段时间以后，软件的架构就千疮百孔了。bug越来越多，越来越难维护，新的需求越来越难实现，软件的构架对新的需求渐渐的失去支持能力，而是成为一种制约。最后新需求的开发成本会超过开发一个新的软件的成本，这就是这个软件系统的生命走到尽头的时候。
重构就能够最大限度的避免这样一种现象。系统发展到一定阶段后，使用重构的方式，不改变系统的外部功能，只对内部的结构进行重新的整理。通过重构，不断的调整系统的结构，使系统对于需求的变更始终具有较强的适应能力。
通过重构可以达到以下的目标：
·持续纠偏和改进软件设计
重构和设计是相辅相成的，它和设计彼此互补。有了重构，你仍然必须做预先的设计，但是不必是最优的设计，只需要一个合理的解决方案就够了，如果没有重构、程序设计会逐渐腐败变质，愈来愈像断线的风筝，脱缰的野马无法控制。重构其实就是整理代码，让所有带着发散倾向的代码回归本位。
·
Martin Flower在《重构》中有一句经典的话：任何一个傻瓜都能写出计算机可以理解的程序，只有写出人类容易理解的程序才是优秀的程序员。对此，笔者感触很深，有些程序员总是能够快速编写出可运行的代码，但代码中晦涩的命名使人晕眩得需要紧握坐椅扶手，试想一个新兵到来接手这样的代码他会不会想当逃兵呢？
软件的生命周期往往需要多批程序员来维护，我们往往忽略了这些后来人。为了使代码容易被他人理解，需要在实现软件功能时做许多额外的事件，如清晰的排版布局，简明扼要的注释，其中命名也是一个重要的方面。一个很好的办法就是采用暗喻命名，即以对象实现的功能的依据，用形象化或拟人化的手法进行命名，一个很好的态度就是将每个代码元素像新生儿一样命名，也许笔者有点命名偏执狂的倾向，如能荣此雅号，将深以此为幸。
对于那些让人充满迷茫感甚至误导性的命名，需要果决地、大刀阔斧地整容，永远不要手下留情！
·帮助发现隐藏的代码缺陷
孔子说过：温故而知新。重构代码时逼迫你加深理解原先所写的代码。笔者常有写下程序后，却发生对自己的程序逻辑不甚理解的情景，曾为此惊悚过，后来发现这种症状居然是许多程序员常患的感冒。当你也发生这样的情形时，通过重构代码可以加深对原设计的理解，发现其中的问题和隐患，构建出更好的代码。
·从长远来看，有助于提高编程效率
当你发现解决一个问题变得异常复杂时，往往不是问题本身造成的，而是你用错了方法，拙劣的设计往往导致臃肿的编码。
改善设计、提高可读性、减少缺陷都是为了稳住阵脚。良好的设计是成功的一半，停下来通过重构改进设计，或许会在当前减缓速度，但它带来的后发优势却是不可低估的。 新官上任三把火，开始一个全新??、脚不停蹄、加班加点，一支声势浩大的千军万码夹裹着程序员激情和扣击键盘的鸣金奋力前行，势如破竹，攻城掠地，直指黄龙府。
开发经理是这支浩浩汤汤代码队伍的统帅，他负责这支队伍的命运，当齐桓公站在山顶上看到管仲训练的队伍整齐划一地前进时，他感叹说我有这样一支军队哪里还怕没有胜利呢？。但很遗憾，你手中的这支队伍原本只是散兵游勇，在前进中招兵买马，不断壮大，所以队伍变形在所难免。当开发经理发觉队伍变形时，也许就是克制住攻克前方山头的诱惑，停下脚步整顿队伍的时候了。
Kent Beck提出了代码坏味道的说法，和我们所提出的队伍变形是同样的意思，队伍变形的信号是什么呢？以下列述的代码症状就是队伍变形的强烈信号：
·代码中存在重复的代码
中国有118 家整车生产企业，数量几乎等于美、日、欧所有汽车厂家数之和，但是全国的年产量却不及一个外国大汽车公司的产量。重复建设只会导致效率的低效和资源的浪费。
程序代码更是不能搞重复建设，如果同一个类中有相同的代码块，请把它提炼成类的一个独立方法，如果不同类中具有相同的代码，请把它提炼成一个新类，永远不要重复代码。
·过大的类和过长的方法
过大的类往往是类抽象不合理的结果，类抽象不合理将降低了代码的复用率。方法是类王国中的诸侯国，诸侯国太大势必动摇中央集权。过长的方法由于包含的逻辑过于复杂，错误机率将直线上升，而可读性则直线下降，类的健壮性很容易被打破。当看到一个过长的方法时，需要想办法将其划分为多个小方法，以便于分而治之。
·牵一毛而需要动全身的修改
当你发现修改一个小功能，或增加一个小功能时，就引发一次代码地震，也许是你的设计抽象度不够理想，功能代码太过分散所引起的。
·类之间需要过多的通讯
A类需要调用B类的过多方法访问B的内部数据，在关系上这两个类显得有点狎昵，可能这两个类本应该在一起，而不应该分家。
·过度耦合的信息链
计算机是这样一门科学，它相信可以通过添加一个中间层解决任何问题，所以往往中间层会被过多地追加到程序中。如果你在代码中看到需要获取一个信息，需要一个类的方法调用另一个类的方法，层层挂接，就象输油管一样节节相连。这往往是因为衔接层太多造成的，需要查看就否有可移除的中间层，或是否可以提供更直接的调用方法。
·各立山头干革命
如果你发现有两个类或两个方法虽然命名不同但却拥有相似或相同的功能，你会发现往往是因为开发团队协调不够造成的。笔者曾经写了一个颇好用的字符串处理类，但因为没有及时通告团队其他人员，后来发现项目中居然有三个字符串处理类。革命资源是珍贵的，我们不应各立山头干革命。
·不完美的设计
在笔者刚完成的一个比对报警项目中，曾安排阿朱开发报警模块，即通过Socket向指定的短信平台、语音平台及客户端报警器插件发送报警报文信息，阿朱出色地完成了这项任务。后来用户又提出了实时比对的需求，即要求第三方系统以报文形式向比对报警系统发送请求，比对报警系统接收并响应这个请求。这又需要用到Socket报文通讯，由于原来的设计没有将报文通讯模块独立出来，所以无法复用阿朱开发的代码。后来我及时调整了这个设计，新增了一个报文收发模块，使系统所有的对外通讯都复用这个模块，系统的整体设计也显得更加合理。
每个系统都或多或少存在不完美的设计，刚开始可能注意不到，到后来才会慢慢凸显出来，此时唯有勇于更改才是最好的出路。
·缺少必要的注释
虽然许多软件工程的书籍常提醒程序员需要防止过多注释，但这个担心好象并没有什么必要。往往程序员更感兴趣的是功能实现而非代码注释，因为前者更能带来成就感，所以代码注释往往不是过多而是过少，过于简单。人的记忆曲线下降的坡度是陡得吓人的，当过了一段时间后再回头补注释时，很容易发生提笔忘字，愈言且止的情形。
曾在网上看到过微软的代码注释，其详尽程度让人叹为观止，也从中体悟到了微软成功的一个经验。 学习一种可以大幅提高生产力的新技术时，你总是难以察觉其不适用的场合。通常你在一个特定场景中学习它，这个场景往往是个项目。这种情况下你很难看出什么会造成这种新技术成效不彰或甚至形成危害。十年前，对象技术（object tech.）的情况也是如此。那时如果有人问我“何时不要使用对象”，我很难回答。并非我认为对象十全十美、没有局限性 — 我最反对这种盲目态度，而是尽管我知道它的好处，但确实不知道其局限性在哪儿。
现在，重构的处境也是如此。我们知道重构的好处，我们知道重构可以给我们的工作带来垂手可得的改变。但是我们还没有获得足够的经验，我们还看不到它的局限性。
这一小节比我希望的要短。暂且如此吧。随着更多人学会重构技巧，我们也将对??你应该尝试一下重构，获得它所提供的利益，但在此同时，你也应该时时监控其过程，注意寻找重构可能引入的问题。请让我们知道你所遭遇的问题。随着对重构的了解日益增多，我们将找出更多解决办法，并清楚知道哪些问题是真正难以解决的。
·数据库（Databases）
“重构”经常出问题的一个领域就是数据库。绝大多数商用程序都与它们背后的database schema（数据库表格结构）紧密耦合（coupled）在一起，这也是database schema如此难以修改的原因之一。另一个原因是数据迁移（migration）。就算你非常小心地将系统分层（layered），将database schema和对象模型（object model）间的依赖降至最低，但database schema的改变还是让你不得不迁移所有数据，这可能是件漫长而烦琐的工作。
在“非对象数据库”（nonobject databases）中，解决这个问题的办法之一就是：在对象模型（object model）和数据库模型（database model）之间插入一个分隔层（separate layer），这就可以隔离两个模型各自的变化。升级某一模型时无需同时升级另一模型，只需升级上述的分隔层即可。这样的分隔层会增加系统复杂度，但可以给你很大的灵活度。如果你同时拥有多个数据库，或如果数据库模型较为复杂使你难以控制，那么即使不进行重构，这分隔层也是很重要的。
你无需一开始就插入分隔层，可以在发现对象模型变得不稳定时再产生它。这样你就可以为你的改变找到最好的杠杆效应。
对开发者而言，对象数据库既有帮助也有妨碍。某些面向对象数据库提供不同版本的对象之间的自动迁移功能，这减少了数据迁移时的工作量，但还是会损失一定时间。如果各数据库之间的数据迁移并非自动进行，你就必须自行完成迁移工作，这个工作量可是很大的。这种情况下你必须更加留神classes内的数据结构变化。你仍然可以放心将classes的行为转移过去，但转移值域（field）时就必须格外小心。数据尚未被转移前你就得先运用访问函数（accessors）造成“数据已经转移”的假象。一旦你确定知道“数据应该在何处”时，就可以一次性地将数据迁移过去。这时惟一需要修改的只有访问函数（accessors），这也降低了错误风险。
·修改接口（Changing Interfaces）
关于对象，另一件重要事情是：它们允许你分开修改软件模块的实现（implementation）和接口（interface）。你可以安全地修改某对象内部而不影响他人，但对于接口要特别谨慎 — 如果接口被修改了，任何事情都有可能发生。
一直对重构带来困扰的一件事就是：许多重构手法的确会修改接口。像Rename Method（273）这么简单的重构手法所做的一切就是修改接口。这对极为珍贵的封装概念会带来什么影响呢？
如果某个函数的所有调用动作都在你的控制之下，那么即使修改函数名称也不会有任何问题。哪怕面对一个public函数，只要能取得并修改其所有调用者，你也可以安心地将这个函数易名。只有当需要修改的接口系被那些“找不到，即使找到也不能修改”的代码使用时，接口的修改才会成为问题。如果情况真是如此，我就会说：这个接口是个“已发布接口”（published interface）— 比公开接口（public interface）更进一步。接口一旦发行，你就再也无法仅仅修改调用者而能够安全地修改接口了。你需要一个略为复杂的程序。
这个想法改变了我们的问题。如今的问题是：该如何面对那些必须修改“已发布接口”的重构手法？
简言之，如果重构手法改变了已发布接口（published interface），你必须同时维护新旧两个接口，直到你的所有用户都有时间对这个变化做出反应。幸运的是这不太困难。你通常都有办法把事情组织好，让旧接口继续工作。请尽量这么做：让旧接口调用新接口。当你要修改某个函数名称时，请留下旧函数，让它调用新函数。千万不要拷贝函数实现码，那会让你陷入“重复代码”（plicated code）的泥淖中难以自拔。你还应该使用Java提供的 deprecation（反对）设施，将旧接口标记为 deprecated。这么一来你的调用者就会注意到它了。
这个过程的一个好例子就是Java容器类（collection classes）。Java 2的新容器取代了原先一些容器。当Java 2容器发布时，JavaSoft花了很大力气来为开发者提供一条顺利迁徙之路。
“保留旧接口”的办法通常可行，但很烦人。起码在一段时间里你必须建造（build）并维护一些额外的函数。它们会使接口变得复杂，使接口难以使用。还好我们有另一个选择：不要发布（publish）接口。当然我不是说要完全禁止，因为很明显你必得发布一些接口。如果你正在建造供外部使用的APIs，像Sun所做的那样，肯定你必得发布接口。我之所以说尽量不要发布，是因为我常常看到一些开发团队公开了太多接口。我曾经看到一支三人团队这么工作：每个人都向另外两人公开发布接口。这使他们不得不经常来回维护接口，而其实他们原本可以直接进入程序库，径行修改自己管理的那一部分，那会轻松许多。过度强调“代码拥有权”的团队常常会犯这种错误。发布接口很有用，但也有代价。所以除非真有必要，别发布接口。这可能意味需要改变你的代码拥有权观念，让每个人都可以修改别人的代码，以运应接口的改动。以搭档（成对）编程（Pair Programming）完成这一切通常是个好主意。
不要过早发布（published）接口。请修改你的代码拥有权政策，使重构更顺畅。
Java之中还有一个特别关于“修改接口”的问题：在throws子句中增加一个异常。这并不是对签名式（signature）的修改，所以你无法以delegation（委托手法）隐藏它。但如果用户代码不作出相应修改，编译器不会让它通过。这个问题很难解决。你可以为这个函数选择一个新名tion（可控式异常）转换成一个unchecked exception（不可控异常）。你也可以抛出一个unchecked异常，不过这样你就会失去检验能力。如果你那么做，你可以警告调用者：这个unchecked异常日后会变成一个checked异常。这样他们就有时间在自己的代码中加上对此异常的处理。出于这个原因，我总是喜欢为整个package定义一个superclass异常（就像java.sql的SQLException），并确保所有public函数只在自己的throws子句中声明这个异常。这样我就可以随心所欲地定义subclass异常，不会影响调用者，因为调用者永远只知道那个更具一般性的superclass异常。
·难以通过重构手法完成的设计改动
通过重构，可以排除所有设计错误吗？是否存在某些核心设计决策，无法以重构手法修改？在这个领域里，我们的统计数据尚不完整。当然某些情况下我们可以很有效地重构，这常常令我们倍感惊讶，但的确也有难以重构的地方。比如说在一个项目中，我们很难（但还是有可能）将“无安全需求（no security requirements）情况下构造起来的系统”重构为“安全性良好的（good security）系统”。
这种情况下我的办法就是“先想象重构的情况”。考虑候选设计方案时，我会问自己：将某个设计重构为另一个设计的难度有多大？如果看上去很简单，我就不必太担心选择是否得当，于是我就会选最简单的设计，哪怕它不能覆盖所有潜在需求也没关系。但如果预先看不到简单的重构办法，我就会在设计上投入更多力气。不过我发现，这种情况很少出现。
·何时不该重构？
有时候你根本不应该重构 — 例如当你应该重新编写所有代码的时候。有时候既有代码实在太混乱，重构它还不如从新写一个来得简单。作出这种决定很困难，我承认我也没有什么好准则可以判断何时应该放弃重构。
重写（而非重构）的一个清楚讯号就是：现有代码根本不能正常运作。你可能只是试着做点测试，然后就发现代码中满是错误，根本无法稳定运作。记住，重构之前，代码必须起码能够在大部分情况下正常运作。
一个折衷办法就是：将“大块头软件”重构为“封装良好的小型组件”。然后你就可以逐一对组件作出“重构或重建”的决定。这是一个颇具希望的办法，但我还没有足够数据，所以也无法写出优秀的指导原则。对于一个重要的古老系统，这肯定会是一个很好的方向。
另外，如果项目已近最后期限，你也应该避免重构。在此时机，从重构过程赢得的生产力只有在最后期限过后才能体现出来，而那个时候已经时不我予。Ward Cunningham对此有一个很好的看法。他把未完成的重构工作形容为“债务”。很多公司都需要借债来使自己更有效地运转。但是借债就得付利息，过于复杂的代码所造成的“维护和扩展的额外开销”就是利息。你可以承受一定程度的利息，但如果利息太高你就会被压垮。把债务管理好是很重要的，你应该随时通过重构来偿还一部分债务。
如果项目已经非常接近最后期限，你不应该再分心于重构，因为已经没有时间了。不过多个项目经验显示：重构的确能够提高生产力。如果最后你没有足够时间，通常就表示你其实早该进行重构。 “重构”肩负一项特别任务：它和设计彼此互补。初学编程的时候，我埋头就写程序，浑浑噩噩地进行开发。然而很快我便发现，“事先设计”（upfront design）可以助我节省回头工的高昂成本。于是我很快加强这种“预先设计”风格。许多人都把设计看作软件开发的关键环节，而把编程（programming）看作只是机械式的低级劳动。他们认为设计就像画工程图而编码就像施工。但是你要知道，软件和真实器械有着很大的差异。软件的可塑性更强，而且完全是思想产品。正如Alistair Cockburn所说：‘有了设计，我可以思考更快，但是其中充满小漏洞。’
有一种观点认为：重构可以成为“预先设计”的替代品。这意思是你根本不必做任何设计，只管按照最初想法开始编码，让代码有效运作，然后再将它重构成型。事实上这种办法真的可行。我的确看过有人这么做，最后获得设计良好的软件。极限编程（Extreme Programming）【Beck, XP】 的支持者极力提倡这种办法。
尽管如上所言，只运用重构也能收到效果，但这并不是最有效的途径。是的，即使极限编程（Extreme Programming）爱好者也会进行预先设计。他们会使用CRC卡或类似的东西来检验各种不同想法，然后才得到第一个可被接受的解决方案，然后才能开始编码，然后才能重构。关键在于：重构改变了“预先设计”的角色。如果没有重构，你就必须保证“预先设计”正确无误，这个压力太大了。这意味如果将来需要对原始设计做任何修改，代价都将非常高昂。因此你需要把更多时间和精力放在预先设计上，以避免日后修改。
如果你选择重构，问题的重点就转变了。你仍然做预先设计，但是不必一定找出正确的解决方案。此刻的你只需要得到一个足够合理的解决方案就够了。你很肯定地知道，在实现这个初始解决方案的时候，你对问题的理解也会逐渐加深，你可能会察觉最佳解决方案和你当初设想的有些不同。只要有重构这项武器在手，就不成问题，因为重构让日后的修改成本不再高昂。
这种转变导致一个重要结果：软件设计朝向简化前进了一大步。过去未曾运用重构时，我总是力求得到灵活的解决方案。任何一个需求都让我提心吊胆地猜疑：在系统寿命期间，这个需求会导致怎样的变化？由于变更设计的代价非常高昂，所以我希望建造一个足够灵活、足够强固的解决方案，希望它能承受我所能预见的所有需求变化。问题在于：要建造一个灵活的解决方案，所需的成本难以估算。灵活的解决方案比简单的解决方案复杂许多，所以最终得到的软件通常也会更难维护 — 虽然它在我预先设想的??方向上，你也必须理解如何修改设计。如果变化只出现在一两个地方，那不算大问题。然而变化其实可能出现在系统各处。如果在所有可能的变化出现地点都建立起灵活性，整个系统的复杂度和维护难度都会大大提高。当然，如果最后发现所有这些灵活性都毫无必要，这才是最大的失败。你知道，这其中肯定有些灵活性的确派不上用场，但你却无法预测到底是哪些派不上用场。为了获得自己想要的灵活性，你不得不加入比实际需要更多的灵活性。
有了重构，你就可以通过一条不同的途径来应付变化带来的风险。你仍旧需要思考潜在的变化，仍旧需要考虑灵活的解决方案。但是你不必再逐一实现这些解决方案，而是应该问问自己：‘把一个简单的解决方案重构成这个灵活的方案有多大难度？’如果答案是“相当容易”（大多数时候都如此），那么你就只需实现目前的简单方案就行了。
重构可以带来更简单的设计，同时又不损失灵活性，这也降低了设计过程的难度，减轻了设计压力。一旦对重构带来的简单性有更多感受，你甚至可以不必再预先思考前述所谓的灵活方案 — 一旦需要它，你总有足够的信心去重构。是的，当下只管建造可运行的最简化系统，至于灵活而复杂的设计，唔，多数时候你都不会需要它。
劳而无获— Ron Jeffries
Chrysler Comprehensive Compensation（克莱斯勒综合薪资系统）的支付过程太慢了。虽然我们的开发还没结束，这个问题却已经开始困扰我们，因为它已经拖累了测试速度。
Kent Beck、Martin Fowler和我决定解决这个问题。等待大伙儿会合的时间里，凭着我对这个系统的全盘了解，我开始推测：到底是什么让系统变慢了？我想到数种可能，然后和伙伴们谈了几种可能的修改方案。最后，关于“如何让这个系统运行更快”，我们提出了一些真正的好点子。
然后，我们拿Kent的量测工具度量了系统性能。我一开始所想的可能性竟然全都不是问题肇因。我们发现：系统把一半时间用来创建“日期”实体（instance）。更有趣的是，所有这些实体都有相同的值。
于是我们观察日期的创建逻辑，发现有机会将它优化。日期原本是由字符串转换而生，即使无外部输入也是如此。之所以使用字符串转换方式，完全是为了方便键盘输入。好，也许我们可以将它优化。
于是我们观察日期怎样被这个程序运用。我们发现，很多日期对象都被用来产生“日期区间”实体（instance）。“日期区间”是个对象，由一个起始日期和一个结束日期组成。仔细追踪下去，我们发现绝大多数日期区间是空的！
处理日期区间时我们遵循这样一个规则：如果结束日期在起始日期之前，这个日期区间就该是空的。这是一条很好的规则，完全符合这个class的需要。采用此一规则后不久，我们意识到，创建一个“起始日期在结束日期之后”的日期区间，仍然不算是清晰的代码，于是我们把这个行为提炼到一个factory method（译注：一个着名的设计模式，见《Design Patterns》），由它专门创建“空的日期区间”。
我们做了上述修改，使代码更加清晰，却意外得到了一个惊喜。我们创建一个固定不变的“空日期区间”对象，并让上述调整后的factory method每次都返回该对象，而不再每次都创建新对象。这一修改把系统速度提升了几乎一倍，足以让测试速度达到可接受程度。这只花了我们大约五分钟。
我和团队成员（Kent和Martin谢绝参加）认真推测过：我们了若指掌的这个程序中可能有什么错误？我们甚至凭空做了些改进设计，却没有先对系统的真实情况进行量测。
我们完全错了。除了一场很有趣的交谈，我们什么好事都没做。
教训：哪怕你完全了解系统，也请实际量测它的性能，不要臆测。臆测会让你学到一些东西，但十有八九你是错的。