忽然發現自己很久沒有寫技術博文了，上一篇還是在兩週前。
今天下午和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/