忽然发现自己很久没有写技术博文了，上一篇还是在两周前。
今天下午和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的《解析极限编程——拥抱变化》与《测试驱动开发》，愈发觉得这几本书真是相见恨晚的好友。
当时非常想实践一下这些设计思维，但是觉得语言基础还是不够深厚。于是决定先精通一门易于进行面向对象分析与设计的语言，具体来说，就是Java。为此，专门系统地学习了UML、分析与设计的基本原理等知识，还看了《Java编程思想》、《深入Java虚拟机》等书。这两本书让我印象十分深刻，这也算是我第一次拿出十倍的努力去钻研一门编程语言吧，《Java编程思想》这本书的所有可编程习题我都做了一遍。从语言的底层实现，到基本用法，再到高级特性，终于系统地走了个来回。我这么说像是在演戏吗？像，不过如果是场好戏，就必须得演下去才行。
在学完了《Effective Java》与《Java Puzzlers》（又叫《Java谜题》）之后，我又明白了一些语言的细微名堂，更加手痒了， 立刻开始着手做一个小项目，将设计模式和学到的一些原则运用于其中。那次是编写一款JavaME平台的手机麻将游戏。开始做的时候很顺利，感觉这次总算可以提取出一些可以复用的模块了，而且代码质量的管控第一次让我自己感到满意。到了中途，遇到一些问题，比如某个类到底写不写测试、GUI怎么测试、某个模块应该用什么模式、某个需求是否该做得更加灵活等等。不过经过我个人的努力探索，基本也都较为平坦地走过去了。到了2009年中，项目基本算是定格了。我很满意。尽管那个游戏赚不了几个钱，然而我在此项目的制作过程中完全体会到了设计、实现、测试这个完整的微观敏捷开发流程。为什么说是微观敏捷呢？因为敏捷是个大话题，我研究的主要是与技术相关的敏捷话题，所以加了“微观”这个定语。管理、商务、客户沟通等方面，现在的能力与阅历还不够，留待将来再与诸位讨论。这个项目虽然还有很多不完备的地方，不过这毕竟是我第一次比较系统地做完了一个自己相当满意的工程。最后的代码我一直小心地保留着，将来可以重用，必要的时候也可以与大家分享。此外，这也是我首次将软件开发的手段与目的都做得比较得体的一个项目。在这之前，为了做出成品，一味地拼代码，不择手段地使用了无数杂技，尽管心里觉得那样不好，但是当时又找不到好的办法。这一点日后我一再向好友老G提起。
做完这个项目之后，我就开始寻求一种系统化的、彻底的解决方案了。就是业内常说的“引擎”。一开始完全没有意识到这个项目的复杂性，后来在与友人的合作过程之中，才又逐渐地认识到大家对于软件开发有着各自不同的理解，尽管都要做软件，然而有些人觉得只要先做出成品就好，必要时可以牺牲一部分设计质量，有些人则对设计有着过于完美的追求。在有限的时空、资源限制下，项目的合作很难平滑地展开。再后来，我开始在Google Reader主动地订阅了一些谈论设计的网站。这其中就包括了酷壳网，在这里我看到了站长陈皓先生与诸多网友的精彩讨论。在阅读与讨论的过程中，终于发现了目前业界存在的几个大问题。
我当下最为关注的就是，太多的开发者，尤其是移动开发领域，都不甚注重软件的设计与架构，过于目的导向，容易造成我在少年时期学习编程时遇到的那两个困境。另外，有个别的开发者或者说开发方式推广者，又一味地标榜某个特定的开发方法，比如敏捷，将它无限放大为可以制作出一切优秀软件产品的万能手段。
本系列文章就是要围绕着软件开发过程与软件产品之间的关系而展开讨论。透彻地理解这两个东西，对团队的融合很重要。比如我在文章开头说的那几类程序员，如果要打造一个高效又饱含核心价值的团队，那么无论这个团队是为了工作、为了学术或者为了兴趣，都必须要对开发过程达成一些共识才行。
当然了，大家放轻松一点，我写这些文章并没有要追求一个准确的答案，只是期望多激发一些可供讨论的思维闪光点。我的朋友们经常说我这个人太过学术化了、太过艺术了、太老学究了、太严肃了，等等等等。他们说大家来工作，都是以赚钱为首要目标，只要代码写出来能用的软件就行，谁有闲功夫陪你瞎折腾这些无聊的玩意儿呢？嗯，这么说也没错，不过总得要有一些静下心来做学问的人，这个行业才有健康发展的活力与原动力呀！
各位Coder、Boder、Programmer、Brogrammer们，如果哪天觉得工作之余有点小小的心情，那不妨来看看小爱的书生傻气之见（感谢易中天的文章，让我学到了“书生傻气”这个活灵活现的词语），就算不能直接为当前的工作项目增光添彩，也好歹可以在潜移默化中加深对软件设计的感悟吧！大家如果有自己对软件设计的体会，也可以写出来互相探讨一下。以文会友，不亦乐乎？
爱飞翔
2012年7月2日至3日
欢迎转载，请标明作者与原文网址。如需商用，请与本人联系。
原文网址：http://agilemobidev.com/eastarlee/mood_note/1_aim_and_method_zh_cn/