? *有代碼的地方，就有程序員，有人的地方就有江湖。IT職場，不一樣的江湖。 * 歐陽明一直以為知道面向對象編程，就可以天下無敵了。至少，拋去自己的修煉問題，面向對象編程（OOP）應該是最好的武功了。可是，面對一個大型系統的設計，他發現無從下手。 這里面固然有經驗的問題，他也確實遇到了瓶頸。設計和編程，不是一個領域的。 俗話說，有了老大，打遍天下都不怕。有朱老大帶著，感覺沒問題。不過說起來，歐陽明真是天將降大任，正好趕上非典。而他們的工作環境是在一個小區里面封閉。每天都在屋子里，擔驚受怕。中午出去吃飯也是如此。做城鐵公交的，都會隨身帶著口罩。口罩有段時間都脫銷了，還報道有黑心棉的口罩出現。公司也給歐陽明他們發了一些，但是都沒用上。 發生非典是在春天。北京的春天，刮一下大風，更顯得非典之后的荒涼。朱老大開玩笑說，在這鳥不拉屎的地方，非典也是不會來的。不過后來朱老大還是用上了口罩，因為他感冒流鼻涕了。工作中也帶著，因為呼吸難受，所以還把口罩上面掖在鼻孔下面，方便出氣。看上去特別有意思。 設計就這樣開始了。朱老大先聽一遍需求，然后用用例圖（Use Case）理解一遍，然后再用順序圖，理解一下業務流程。到具體的業務模塊，用包進行分組管理，在每個包內，進行相對的獨立設計。 畫圖的技巧，基本上邊讀書，邊理解，很快就達成一致認可了。但是關于一些具體的設計，就不容易達成一致了。 有一次遇到一個問題，關于有匯總關系的兩個類的組織。小祝認為因為匯總關系，字段都差不多，不如直接繼承。歐陽明認為既然不一樣，還不如再抽象一個基類。朱老大來投決定性一票。但是老大就是不一樣。他先和他們討論原則問題。 “這兩種方法是不是都能解決問題?” “是的。”小祝和歐陽明都承認。 “那我們是不是應該看看，什么情況下應該是繼承，什么情況下不應該？” 于是這個問題，就換成了，上級匯總類，是不是下級類的一個子類，即“IS-A”的判斷。這一下子轉換成了一個業務問題，問題就簡單多了。 不過朱老大也不是萬能的。有一次遇到一個問題，小祝和歐陽明同樣吵得不開交，朱老大聽了之后，表示無法判斷。只能邀請在旁的土博士參與進來，進行了一個傾向性判斷。關于這件事，歐陽明還當面嘲笑了一下朱老大，沒想到朱老大給他們深深地上了一課。 “如果兩個方案，以10為總權重，一個1，一個9。權重越大表示越好。你們會選擇誰？” “當然是9。”兩個人異口同聲。 “如果是3和7呢？” “還是7。” “那么，如果是4和6呢，或者5和5呢“ “我選6，如果都一樣，就無所謂了。”歐陽明似乎有點感悟。 “但我可以選4。”朱老大卻出人意料的說出這樣一句話。 “為什么？”又是異口同聲，但這次是驚訝。 “如果６是我提的，４是對方提的，我愿意選４。對方是4，表明可以做好，而且我自己是6，很可能是有自我暗示的因素。最關鍵的是，我不是為了選誰，而爭論。” 歐陽明突然被震住了，因為他突然意識到，這不是個技巧問題，也不是單純的心態問題，這更是一個做人的層次問題，視野的高度問題。要做好設計，不光是血技巧，也得隨時修煉自己啊。他忽然感覺學到了很多，卻又感覺自己懂得很少。 設計就這樣吵吵的過去了，基本非典結束，他們也結束了。下面就進入了緊張的開發階段，項目組要從歐陽明和小祝兩人中選擇一個做開發經理，他們誰會當選呢？