忽然发现自己很久没有写技术文了，上一篇还是在两周前。今天下午和51CTO的博客管理员同学聊了聊，慢慢地感觉到那种大型技术博客网站是个好东西。要感谢51CTO和图灵社区这样的讨论园地，使我认识了很多对软件设计有独到见解的朋友们。
“代码质量随想录”系列更新得比较慢，原因之一，是小翔想要让随想录系列博文成为不仅能够促发思考，而且对大家的学习、工作、研究真正有用的文章。所以名虽为“随想录”，实际上不能写得太随便了。从事先读书笔记的准备，到范例的选取与修改，再到观点的提取、打磨与包装，都必须经过一番考究才行。有时候我会用私密博文的形式先写好草稿，然后分成好几部分来写，最后完整地发布上来。在随想录的写作过程中，我与很多朋友进行了交流，在交流中总结了一些很有用处的观点，但是又不太符合“代码质量”这个过于狭窄的话题，所以将这部分“软文”单独放在这个“软件设计心情笔记”系列里面来写。这样的话，方便大家按照各自的需求阅读。比如我认识的一些朋友，他们就不爱读软文，只爱看比较具体的技术文章;而我这种人则不同，很多时候在写完代码后，必须阅读一定数量的技术随笔，来整理自己的技术思路。
由于是纯软文，所以从资料的准备和观点的考究上面，就不用那么拘谨了。写出来供大家乐一下，就对了!
在将近14年的编程经历中，我渐渐把遇到的程序员分成以下四种：
1.纯粹以工作为目的，不融入任何兴趣、喜爱等因素。
2.以工作为主要目的，为了个人的兴趣爱好，适当地钻研一些技术。
3.以兴趣为主要目的，为了个人的工作，适当地学习一些实用技术。
4.纯粹以兴趣为目的，自由地享受编码的乐趣。
我是不是故意漏掉了一种呢?难道兴趣和工作就不能兼顾?可以，不过很难。当然如果哪位朋友已经做到了这一点，那么欢迎与大家分享这方面的经验，我们都很需要那种境界。
就我个人来讲，学习编程纯粹是兴趣使然，直到现在依然如此。有时候为了工作的缘故，会适当地学习一些实用技术。按照上面那个武断的分类标准，我这是不是有点“朝三暮四”了?既然是心情笔记嘛，那当然是给有心情听我讲故事朋友们分享的啦!如果是纯粹为了学习工作技能的同学，那么请去看“代码质量随想录”系列，那个系列我会为了符合大家的工作需要而选取一些实用性较强的话题来讲的。最近虽然更新得慢了一些，不过很快就会稳步续写的。
好，那我现在就来讲讲爱飞翔这个书生的小故事吧。一开始学编程时，只要是见到了程序设计方面的书，就拿来读，不管具体有用无用，也不论对自己的知识体系是否有裨益。这样经历了7、8年之后，渐渐感觉出来一个问题，那就是不管用什么编程语言，想做出来一些具体的软件并不难，然而令人纠结的却是每次开发软件之前的设计过程。当时资讯不是很发达，又没有人指点，所以不太瞭解设计、架构这些话题。只是觉得每次做软件都要从0开始，没办法复用原来的成果，而且一旦需求有变动，那么就要非常被动地去修改代码。由于没有进行质量管控，所以每次修改都是乱做一气，这样导致代码中存在的问题越积越多，为了修复某个Bug而带来成批其他的Bug。当时不太瞭解导致此状况的原因，误认为是自己的新技术学习得不够多。于是又大量学习所谓的“新”技术。软件破解、SoftICE、SysInternals……这些东西几乎每天都研究到次日凌晨快天亮才罢休。
幸好在2006年初被朋友邀请做手机游戏，才暂时跳出了这个技术战争的汪洋大海。专心做Java之后，发现上述两个问题还是没有得到彻底解决。当时的JavaME还叫J2ME呢，我们为了学习、讨论技术问题，当时一直在维护一个叫做j2megame的论坛，我以storm为名字在上面也发布了一写资料和文章。总体来说，JavaME这种上手容易的技术，降低了技术开发者的准入门槛，然而从客观上更加加剧了刚我说的那两个问题：
1.无法实行有效的代码重用。
2.由于无代码质量管控，导致工程品质低下，从而无法积极应对需求;在匆忙应付了新功能之后，代码质量又降低了一个档次，可维护性更差，在应对需求的时候更加被动，从而陷入恶性循环。
在接下来近两年的时间中，虽然在工作上做出了一些产品，个别产品还小有成绩，不过一直没有解决我所致力的那个根本问题。直到某次在本地业内聚会时，Eric先生告诉了我“设计模式”和“敏捷软件开发”这两个话题，让我好好研究。当时并没立刻去翻书，只是默默记在了心里。到了2007年底，才开始翻看Gamma等四人所著的经典教材《设计模式——可复用面向对象软件的基础》。初看时，只是觉得里面讲的思路我很是赞同，但并未立刻和工作中遇到的问题联系到一起。为什么呢?因为长久以来只关注具体代码的我，从思想上根本就没有意识到设计对于软件开发的重要性。后来读了Martin的《敏捷软件开发：原则、模式与实践》之后，才感觉到原来做代码可以有一系列的原则可以作为指导。而这些设计模式与设计原则正好可以解决我刚提出的那个两个根本问题。在读完Bob大叔这本经典教材之后，我又回过头读了一遍《设计模式》，这次对它的理解就要深入多了。此后又顺着这个思路，看了Kent Beck的《解析极限编程——拥抱变化》与《测试驱动开发》，愈发觉得这几本书真是相见恨晚的好友。
