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