1. 語言只是工具
我曾經是非常執著的開發人員。我有連續幾天幾夜做Coding的經歷，也曾經為了一個技術問題耗上三、四個星期而導致項目一再延遲，還曾經為了一個實現細節與項目相關的人員逐一爭論。
我也曾經像大多數開發人員一樣熱衷于爭論語言之間孰優孰劣。我在“Delphi大富翁論壇”上寫過一個簡介，其中個人特長是“擅長TPascal、Delphi、TASM系列語言，痛恨C/C++”。我至今保留這段文字，因為那的確是真實的經歷。
如今我已經不再專注于語言，正如我在第一章中寫到的一樣：成天討論這門語言好，或者那門語言不好的人，是可悲的。
然而就在我寫這段文字之前的一年，我還在寫《Delphi源代碼分析》，我還是無止盡地深入語言細節，深入操作系統細節，以及深入……開發的細節。
就在2004年3月間，我接受一個朋友的邀請，去北京做一個名為“Delphi & Delphi .NET源碼分析”的專題培訓。我用了近兩周的時間，做了50頁的幻燈，全面講述Delphi和Delphi .NET。然而在臨行前的一晚，我輾轉反側，思考著一個問題：我究竟做了些什么?或者說，我究竟想告訴學員些什么?
凌晨5點，我在幻燈的末頁后插入了一張幻燈，標題是“語言只是工具”，而幻燈的內容是一張圖。這是與培訓完全無關的一張幻燈。然而，這是自1997年我接觸到管理，以及從1998年我接觸到工程以來，第一次正視“軟件工程”這四個字。我第一次看清楚代碼、方法、過程、工程與組織的關系!
對于一個程序員，或者以程序員自命的人來說，看清楚這一切的第一步，竟是一句“語言只是工具”!
猿之于為人，“學會制作和使用工具”是最重要的標志。因而我不知道“語言只是工具”這句話，究竟是對語言的膜拜，還是漠視。然而從那一刻開始，我才真正地知道工程。
2. 程序
在我的那個圖中，在最內層的環里，是“程序=算法+結構”。這是編程的本源定義，也是原始的狀態。與代碼相關的任何工作，最終仍舊會落足于這樣的一條規則。
編程的精義于此。從有開發行為開始，它就存在。挖山不止的愚公在數千年前就在用類似的行為做編程實踐，而幾十萬年前的智人，也在循環與分支所構成的邏輯中打轉。
3. 方法
推動這種邏輯向前發展的是“方法”和“方法論”。長期編程實踐，自然的推演與總結，必須沉淀為某種(軟件開發)方法，于是“過程”出現了， “對象”出現了，相關的方法論也就出現了。
這是實踐的成果。方法不是某個人或者某個組織創造的。瓜熟而蒂落，實踐積累達到一定的程度，就算微軟不提出某個方法，IBM也會提出這個方法。即便他們都不提出，可能你自己已經在使用這個方法了。
方法并不神秘，因為它就是你今天正在做的、從事的和實現的。正如“模式”是一種方法，而模式就是你昨天書寫代碼的那個行為。只不過，GoF歸納、抽取、提升了這些行為的內在規律。你看不到你做事的行為，也就不能理解“模式”作為一種方法的價值。所以大師們眾口一詞：模式需要一定的編程經驗才能理解。
同理，理解過程也需要編程經驗，理解對象也需要編程經驗，理解MDA與SOA還是需要編程經驗。
這可能就發生在你回顧上一行精彩的代碼，或者上一個失敗的項目的一瞬息。經驗來源于回顧、理解與分析，而不是你將要寫的下一行代碼。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
