關於園子裡討論的軟體的追求的雜談

首先抱歉，題目可能很難懂。不過不要擔心，內容會比較輕鬆。既然大家都喜歡講故事，聽故事，那我也來編一個故事來開始吧。

說是在很久很久以前，數學還沒有被發明的時候，神把發明數學的難題交給了一對兄弟。兄弟二人齊心協力終於發明了0，1到9的數字，卻為誰比誰大而爭了起來。弟弟堅持認為2比1大，哥哥堅持認為1比2大。二人爭執不休，最後到神那裡去，要神給嚇定論。

神想了想說：嗯，1可以比2大。哥哥聽了很高興；可是神又說：不過，2也可以比1大。

兩個人都很不高興，說，你是神，你怎麼還沒有主見呢？我們兩個人的觀點是完全對立的，如果我的觀點對了，他的觀點正好相反，當然就是錯，怎麼可能既這樣，又那樣呢！

神笑了笑說，其實你們的觀點是可以共存的啊！當1和2被當作基數的角度來看，2就比1大，當1和2被當作序數的角度看，1就比2大啊。

這個故事說明一個問題：很多看起來完全對立的問題，實際上可能是各種看法都是正確的。

回到正題，這幾天園子裡的高手們討論起技術是否重要的問題，捎帶著牽連上了創業團隊裡什麼重要、使用者需求是否重要、等等很多問題。如果要我來回答，我會大聲說：
技術非常重要！
使用者需求非常重要！
創業團隊裡技術以外的東西非常重要！

似乎什麼都很重要，沒重沒輕了是不是？

那換一個思維，如果我現在告訴你我的身高是1米80，請你告訴我，我高不高？

沒錯，我比1米75的高，比1米85的矮。高矮胖瘦，重要與否都是和其他參照物比較的結論。所以我們無法單純地說，技術重要，技術不重要。

就拿一個創業團隊來說吧，如果這個團隊不大重視技術，技術方面瘸腿，那麼在開拓市場開拓業務思考盈利模式的時候恐怕就是紙上談兵，那麼對於這樣的一個團隊來說，技術就很重要，不能因為技術帶來木桶短板效應。
但是反過來，如果這個團隊本身就是一群技術精英組建的，他們建立的初衷可能是看到了一種未來很好，“看上去很美”的技術前景，而相反沒怎麼考慮過這項技術的市場適應性、人們的接受能力、以及能否盈利以保證企業運作的方面，那對於他們來說先把技術放一放，好好考慮一下現實也許更好。

OK，我們現在解決了“是否”這個問題；下一個問題就是，軟體開發，到底該追求什嗎？

首先我們站在個人的角度，假設我們自己開發一個軟體，而且假設我們不愁吃穿，不需要這個軟體來賺錢，你只是憑興趣來開發它——這樣的話，你希望這個軟體被開發成什麼樣呢？我想，大多數程式員可能會想，把這個程式開發得盡善盡美：功能強大完善；體繫結構清晰明快；技術精巧細緻；介面美觀大方；……你注意到了，這裡你沒有考慮很多東西：成本，工期，客戶要求。

因為你是一個人，你在做自由開發；但是，假如你是一個企業呢？
你必須考慮到成本——在當前這個資訊社會，一個軟體沒有做好而虧損幾千萬的例子並不少見。其次，你要考慮到工期和產品品質的平衡——我們理解你把這個軟體做好的心情，但是在客戶要求的短短2個月內，你能把客戶所需要的功能做好就已經很不錯了，哪裡還有時間給它增加一些諸如換膚，使用Windows主題之類的花哨功能？此外，很多時候，你可能和客戶有不同的意見——你認為這裡應該用一個RadioButton，客戶卻堅持要一個DropDownList——沒錯，你用你從穿開襠褲小屁孩的時候就開始擁有的電腦經驗打賭，客戶代表絕對是頭不懂電腦的豬——可是，就算他真的是頭豬，這個軟體最終也不是你用，而是這頭豬用，所以沒辦法，你必須滿足一頭豬的需要，因為你不滿足他，他就會去找別的公司——這世界的競爭太激烈了，夥計。所以我堅信，能滿足一頭豬的需求的軟體公司，才是一個真正能讓客戶滿意的公司。

那麼，是不是又出現矛盾了呢？程式開發企業是由程式員組成的，而企業和程式員的追求又不同——
沒錯，企業和員工的目標不盡相同，不僅是軟體行業，所有行業都是這樣。但是，我們何嘗不去追求一種存異求同呢？舉個例子來說，你正在思考你剛剛寫的代碼是不是可以換一種Pattern——比如，Visitor Pattern^{※參看下文討論；因為這樣似乎將來擴充起來比較容易。這時你的頭可能會過來拍拍你的肩膀，Hi，Jerry，這一段代碼已經很不錯了！你趕快去把下一個模組寫好吧！}

這時你也許會抱怨——這一段代碼只是剛剛能用而已！我還想繼續整理它，讓他結構更鮮明一些，將來無論是做二次開發還是外掛程式，都會變得容易的！但是，你必須替你的Boss考慮——他的Boss可能剛剛對他說：嘿，Tom，下周五客戶就要來驗收了，你這個Team的進度卻只有40%！

那我們該怎麼做？我們不成沉浸在我們藝術家的思維裡，我們必須意識到我們不是在玩，我們是在一家企業，做一項實際的工作；我們的確要把工作完成得更漂亮，但是是在有限的時間內！程式有Bug？不夠完美？沒錯！世界上沒有完美的東西，程式也是一樣！缺一樣功能的程式和斷臂的維納斯是一樣的不朽之作！

如果你學會了這樣想，你可以更進一步——不要等到你的Boss來拍你的肩膀時才意識到這一點，而是在項目的最開始，就能站到和一個專案經理相同的高度——甚至高於他的高度思考問題；在最初設計軟體的體系時，就高度意識到工期，使用者的環境、要求和條件等等；這樣你會發現，你掌握的不僅僅是寫程式。

註：由於各位爭得面紅耳赤，本文是專門博大家一笑的，純屬戲謔，若有不同意見請勿深究，請勿見怪:)