3 設計，方法爲指導
3.1 階段釋義
老李：老張，你負責的這個模塊，要有分佈式事務處理能力，還要能與客戶的OA系統通信，從OA中獲取客戶資料的數據。
老張：好的。我將用EJB來實現分佈式事務處理，然後開發一個專門的接口，用來與OA通信。
老張畢業五年，是項目組的開發經理，負責完成子系統的設計，並指導其他成員完成編碼。老張從老李處獲得關於所開發的產品的需求情況，然後進行設計和分析，用UML建出模型，並生成框架代碼，由小王等去實現。
老張屬於第二階段中人，通常工作了三年以上。此階段中人，已經完成了一定程度的技術積累。對《設計模式》、《J2EE核心模式》、《UML》等爛熟於胸，張口就是IOC（控制反轉），有事沒事也要說說AOP，最差也得是Factory、Delegate吧，你要是說不知道什麼是Facade，都不好意思跟人打招呼……
與第一階段“我能——I can do it”不同，本階段的人，特點是“我知道它能——I know It can do”，對，就是“知道它能”，至於如何去“能”，就不需要關心了。例如老張，他只需要把EJB接口定義清楚，知道有了這個接口就能完成相應的功能，至於小王如何去實現這個接口，是寫了三個類還是五個類，就不關心了。
從技術角度，追求的不再是純粹的技巧，而是方法這個層次，努力尋求正確的做事方法。即關心“怎樣才能蓋出好房子”，而不是“如何把石頭從貨車裏搬運到工地上”。用流行的話說，就是“只要方法正確，結果就會正確”。
當然，達到這個階段的人，技巧本身，通常也是很厲害的。舉個例子吧，小王要用一個開源的XML文件比較工具，並編了個測試程序，比較a.xml和b.xml的區別，卻怎麼着都得不到正確的結果。後來老張來了，牛人根本不看JavaDoc，而是拿着XOP提供的命令行比較了a.xml和b.xml，發現結果是正確的，然後直接打開與命令行對應的main()，檢查與options對應的API，發現小王少調用了一個API，加上這個API後測試程序就通過了。在這件事中，老張根本不熟悉XOP的API，但他掌握了查找API的方法，那就是：組件或工具，都有其外在特性，通過組件或工具提供的命令行能做到的事，也一定能通過它提供的API來完成。如果不知道如何去調用API，對於開源軟件，看它的source code或samples中的main()即可；對於非開源軟件，看StackTrace；如果都看不出來，就放棄該軟件，選擇別家的吧。
此階段中人，也需要編寫程序，但編寫的是與業務和框架相關的核心類。所用的語句通常樸實無華，用最簡單的語句完成最複雜的功能是他們的習慣。例如，求b和c中的較大值，通常不會寫成
result=(b>c)?b:c
而是寫成
if (b>c)
result=b;
else
result=c;
因
爲後者更容易懂，而前者，相對生僻一些。開發經理的工作，是把產品的需求，轉變爲編碼人員能理解的接口或類，並保證團隊的所有成員在理解上的一致性、無二
義性，在這個前題下，簡單而又精確的語句是必然的首選。所以，如果你的經理編寫的程序，在你看來很“幼稚可笑”時，千萬不要洋洋得意。
舍小巧而用大巧，捨棄繁花似錦的編程細節，換取簡單穩定的框架結構，換取無二義性的交流效果……獨孤劍聖四十歲前，以玄鐵重劍縱橫天下，劍法古拙，大巧不工，就是此境界（孤獨大俠也走過彎路，30歲時用紫薇軟劍，可能是追求劍招的繁複和劍法的華麗，失去控制，最終誤傷義士）
3.2 應該做的事
該階段的人，該做可做的事非常多。須知一個完整的軟件產品的開發過程，編碼僅僅是其中的一個環節而已。作爲開發經理，老張的典型工作如下：
首
先充分理解需求，挑選其中20%左右的功能，結合非功能性需求，設計出系統的結構（Architecture
Design）。通過邊界類、控制類、實體類的應用，分析清楚Use
Case中的交互流程，然後用一系列接口來表達這個流程，最後運行各種設計模式或技巧，實現這些接口，建出UML模型，並生成代碼框架。
除了開發經理外，你還有可能是項目經理，在中國公司，項目經理和開發經理可能都是你。學習先進的開發方法是你的必修課，什麼用例驅動開發、測試驅動開發，不管用不用，你都得知道個大概；選擇正確的開發模型也很重要，何時選用瀑布模型，何時選用迭代模型，一定不能含糊。
遵守公司的開發流程，爲SQA（Software Quality Assurance）提供必需的文檔和數據也是你的本職工作。如果你所在的公司尚無規範的開發流程，那麼，你要幫助公司來建立。完整的開發流程貫穿整個產品生命週期，你有可能只與其中幾個階段有關。但只要與你有關，那就要盡力去配合。
該階段的人，通常在公司中是中層幹部，執行能力是一個最主要的考覈指標。你的領導，可能根本不懂編程，而項目組裏的小夥子們，可能無法領會領導的意圖，這時，你就是中間人，好比足球場上的中場，你的溝通能力和執行能力，將決定產品開發階段的成敗。
3.3 不應該做的事
1、儘量少編程。除了“核心接口、類和算法”，不要與其它代碼糾纏，那會使你忽視宏觀上的問題。而且，你也不一定比小夥子們編得快。只有當小夥子們遇上困難時，你纔去協助他們解決問題。
2、不輕言放棄。該階段的人，工作壓力巨大，即使他看上去什麼事也沒幹，他承受的壓力也不是編碼人員所能體會的。在壓力面前，容易失去理智，如果不注意控制自己的情緒，可能會發生一些不愉快的事。
現
在的你，可以說是“到哪都能找到工作”了。當與公司、同事發生一些摩擦時，可能會“一怒而去”，這是最要不得的。因爲你現在追求的，已不是“能找到工作”
了，而是“能找到體現自己價值的工作”，千里馬尚且需要伯樂來發現，換家公司就一定能受重用了？而且，不管你是否意識到，你已經學習了許多行業相關的知
識，這些知識，在更換公司後，未必能用上，到新公司後，還得從頭學習——人生有幾次重來的機會？
3、戒驕戒躁。你現在已經是“有本事”的人了，加上工作壓力，難免有點脾氣。但是切記，你還沒有功行圓滿，還要“多長本事，少長脾氣”。因爲你的侷限性，與你的優點一樣明顯。技術等級的提升，應該是讓你眼界更開闊，並看到了更大的差距，而不是固步自封。
4、不要迷信新技術。新技術的採用是有一定的風險的。因爲技術本身，可能還不成熟。追捧新的框架可能是你的愛好。沒關係，作爲愛好，是可以的，但不一定要把愛好帶到工作中來。老闆關心的是你開發出來的東西能否買個好價錢，不是看你用了多少新的Framework。你的用戶關心的，是產品的易用性、穩定性，用起來是否順手，用戶同樣不會關心你用了Tomcat還是Jetty，甚至連J2EE和.Net都不關心——如果他不需要爲此購買新的硬件或者重新培訓操作員。
5、多看人文方面的書和文章。此時的你，在技術方面已經有一定的造詣了。但是不是就大功告成了呢？回答當然是“不”，你還需要補充人文方面的知識，即進行感性思維訓練。爲什麼？往下看。
3.4 侷限性
你的侷限性，與優點一樣明顯。如果讓你列舉自己的優點，你可能會說：
n 我精通設計模式，能做出重用性很好的軟件
n 我對軟件工程很有經驗，能做一個好的項目經理
n 我熟悉建模工具、開發環境等，能提高開發效率
n ……
是的，這些都是了不起的能力，但是：
1、 你們公司不是研究所，不賣設計模式，也不是諮詢公司，不賣軟件工程經驗，更不是培訓機構，不對外提供“建模工具、開發環境”培訓
2、 你知道軟件是如何被開發出來的，但很少考慮是否應該開發這個產品；
3、 你不知道用戶會怎樣使用你開發的產品，你不知道用戶喜歡什麼、抱怨什麼；
4、 你不知道這個產品爲公司贏得了多少利潤；
5、 ……
一句話，你懂技術，但客戶要的，並不是技術。摩托羅拉有世界上最好的射頻工程師，但爲什麼手機就是賣不過諾基亞呢？因爲諾基亞喜歡聽客戶的意見，而摩托羅拉喜歡聽工程師的意見。
你說：“我熱愛技術，喜歡鑽研技術，至於客戶在想啥，那不是我要考慮的問題——我甚至不知道客戶是誰”。是的，達到你今天的這個境界非常不容易，許多人工作十年也未必能象你這樣優秀，你是公司的骨幹，是同事的偶像，但是……但是……《武狀元蘇乞兒》中有一段經典對白：
洪日慶：先別走！行行出狀元！如果我沒看錯，你會是乞丐中的霸主！
蘇 燦：乞丐中的霸主？！那是什麼？
洪日慶：嗯……還是乞丐！
沒錯，乞丐中的霸主也是乞丐。你再優秀，也只是公司的中層幹部，是幹活的人中的霸主——還是個幹活的：
n 客戶給老闆發工資
n 老闆給你發工資
n 你不認識客戶，客戶同樣也不認識你
n 既然你不認識客戶，那就不知道客戶喜歡什麼、討厭什麼
n 如果有一天，你的產品讓客戶不滿意（這個概率還是很大的）
n 客戶很生氣，後果很嚴重
n 老闆請你喝咖啡，並建議你去度假，順便提醒你從外面把門關好
再來看看圈子裏：
n 沒有技術，但手裏有一堆客戶的公司，比比皆是，他們活得很滋潤。
n 沒有客戶，但手裏有一堆技術牛人的公司，很少見——都倒閉了。
現在，你知道侷限性在哪裏了吧？
“正因爲你技術太強了，所以只能當乞丐中的霸主，技術恰好就是你的枷鎖”
說件真實的事吧。
某天，我奉命與一個合作伙伴交流我們的平臺產品，目的是讓對方瞭解我們的平臺並在平臺上做二次開發。交流進行得很順利，對方也跟我們籤合同了。後來，市場人員去合作伙伴處瞭解反饋意見，對方說：“你們那個xxxx太厲害了，問什麼都難不倒”。回來後，領導就不允許我參加交流了。原因是：“你可能泄密了”。
作爲技術人員，我希望充分介紹自己產品的優勢，並能應付合作伙伴提出來的各種應用場景和問題。但是，從領導的角度來看，“如何滿足應用場景、如何解決問題”本身，就是商業機密，是不能亂說的。舉這個例子的目的，就是說明技術人員看問題的侷限性。
想要達到更高的層次，就要跳出技術看問題，多瞭解市場，瞭解客戶。假設孤獨劍聖陶醉於玄鐵重劍的威力，天天帶着到處亂跑，那麼他就不是劍聖，而是搬運工了。搬運工最多隻能當個中層經理，當不了高層領導。
如果想進入領導班子，與老闆一起玩遊戲，那就趕快升級吧。
3.5 進階指南
1、 跳出技術看技術
達到這個階段的人，在技術上已經“很深入”，眼中所見，盡是技術。但你們公司不是賣技術的，你們賣的是產品，是服務。所以，把你的目光從技術中解脫出來，去思考一下產品和市場層面的問題。例如：
n 市場上有同類競爭的產品嗎？
n 當前已有的產品，客戶有什麼不滿意的？
n 我做的產品應該具有什麼樣的特色？有什麼賣點？
所謂“一招鮮，吃遍天”。只要你知道客戶想要啥，並能有針對性地開發產品，客戶一定會情不自禁地給你錢。客戶都給你錢了，老闆還好意思不給你個CTO的頭銜玩玩？
2、 瞭解業務
計算機技術必須爲具體的行業服務，每個行業都有自己的特定背景和業務知識。技術人員應抓住機會，瞭解這些知識。我曾在某個電信軟件公司任職三年，號稱是項目經理，開發電信網管產品。那時我整天的工作就是研究各種框架，討論各種設計模式，我眼中所見心中所想，盡是WEB、Struts、HTML等一大堆計算機名詞。如果你問我“爲什麼這玩意是個網管軟件，而不是淘寶易趣阿里巴巴？”我一定回答不出來。
一個公司裏面，真正值錢的東西，不是技術，而是業務知識，技術是實現業務的一種手段，是爲業務服務的，主從關係，不可搞錯。
3、 加強非技術性的功夫
學書法時，老師曾說過“三分書內功夫，七分書外功夫”。這句話我一直不理解（事實上，到今天依然不理解），但把這句話用於計算機技術，卻是明白的。三分書內功夫，是計算機技術，七分書外功夫，就是非技術性的產品和市場了。
可以通過看些“不務正業”的書，來提高自己的感性思維能力，可以多看看市面上流行的《比爾蓋茨傳奇》《數字化生活》《把信寄給加西亞》等，象《誰動了我的奶酪》這種只會抱怨不會解決問題的書，就不用看了。
3.6 階段小結
適用人羣：工作三年以上，上限不封頂
輸 入：軟件需求（請注意用詞的區別：軟件需求，而不是客戶需求，你所得到到軟件需求，是由別人收集來的，並不一定能代表客戶，如果“別人”的水平一般，錯誤理解了客戶的意圖，那麼你就等着跟他一塊倒黴吧）
輸 出：設計好的類、接口和算法
階段目標：我知道它能——I know it can work
技術特點：注重方法，不關注編程語言細節
勝任職位：高級軟件工程師、開發經理、系統架構師等
升級祕笈：換位思維，跳出技術看問題
參考薪水：￥6000以上，￥15000以下（僅供參考）