软件设计心情笔记（一）目的与手段都很重要

　　忽然发现自己很久没有写技术博文了，上一篇还是在两周前。

　　今天下午和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/

軟件設計心情筆記（一）目的與手段都很重要

　　忽然發現自己很久沒有寫技術博文了，上一篇還是在兩週前。

　　今天下午和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_tw/