Author：放翁（文初）
Email：fangweng@taobao.com
Blog：http://blog.csdn.net/cenwenchu79
其實想說這句話很久了,和很多同事接觸,有時候或多或少的都會發現大家會陷入在自己的一畝三分地里面.
主要表現得癥狀
1. PD的需求就是目標，踏實的實現，不懂的就猜。
2. 經驗蓋過一切，設計系統就是要夠完備夠復雜。
從開發人員角度來看，第一種人多半比較有自己的想法，同時也有不少的工作經驗，同時可能對技術比較著迷。另一種人多半是剛剛工作或者經驗不足，要么就是習慣性把工作當任務，而不是愛好，寫程序也就是一份賺錢的活。但看起來其實各自都在自己的一畝三分地上搗鼓，忘記了作為一個開發人員最基本的原則：“滿足客戶需求”。
先說1類型吧，在我們的Team有一個剛畢業一年多的同學，很勤奮，不論從學習以及工作，實實在在，踏踏實實。我們這邊來需求，通常大需求我們都會全體過一下，一些小點的需求他就自己考慮一下就作了。那天正要上線，突然說了一下設計修改的內容，發現不僅滿足不了PD原有的需求，而且給系統帶來了緩存暴增的隱患。然后找來PD一談，其實他要的功能已經在現有系統中已經實現，只是需要做部分的修改，而不需要新的去建立一套機制。這樣的情況其實在前前后后出現了不少次數了，但其實一直沒有和他細談。后來我下班時候和他一起回家的時候說：“很多時候， PD為了讓你理解，從開發的角度想要去描述一個需求，但其實最終失去了他自己想要的東西。因此對你來說第一步不是急忙的去考慮如何實現PD的想法或者和他爭論他的設計是否合理，而是需要先問他：你想要什么，想要實現的東西最終目的是什么，能滿足客戶的什么需求？當他能夠說清楚他想要什么，也知道要的東西能給客戶帶來什么價值的時候，我們再回過頭來看，究竟應該怎么做？”這其實和我每次和同學分享一些設計的時候步驟是一樣的，首先為什么要這么做，然后才是考慮如何從我的目標去尋找行動的方法方式，不然你會發現你和別人討論了許久的東西，實現出來的時候已經背離了你的目標很遠。因此在做任何需求或者設計的時候第一個問題就要問自己為什么要做，作的過程中時刻要記得我的目標是什么。這讓我想起了我在離開阿軟的那些日子和王堅博士談話以及聽他的一些對于設計的理念，很多時候還沒有到規模化的情況下，先解決客戶的需求，在解決客戶需求以后，逐步的去考慮規模化問題的設計。（當然不是說第一版設計就可以隨便作，良好的基礎能夠提升后續改進的速度）。
二類型的就比較多了，其實是很多開發人員的通病，包括有時候我自己也會陷入這樣的誤區。通常情況下有兩種場景會陷入這樣的誤區，同時當事人卻又不愿意改變。第一種情況就是覺得自己有不少的經驗，同時對技術很執著，希望設計出來的都是很完美的，一次發布就可以滿足個1，2年，但其實從這些年的設計角度來看，首先系統都是不斷迭代進化的，因此一步到位的說法基本上不靠譜（除非就是一模一樣的場景代碼重復使用），其次系統的架構要做的足夠靈活，通常情況就需要先做核心功能，預留出足夠的空間和切入點，這樣對未來擴展和需求變化有足夠的適應度。從這兩點來看，其實設計初期就是要求找到客戶最想要的，擴展可以實現客戶可能要的，防范客戶沒有估量到的。但這其實就需要和我們的產品設計師有充分的交流，好的產品設計師不會告訴你你怎么去實現，但是他會告訴你我想要的是什么，這些能給客戶帶來什么，這時候你可以告訴他我能夠通過什么方式來滿足你的需求。這樣的開發和產品設計交流的結果才是技術化的產品，大家各司其職，同時也通曉對方領域的一些情況，對對方領域的只能給出建議，不是指導，這點在TOP我很慶幸有很好的黑羽同學，我們的交流就是這樣產生良性互動。這有點撤遠了，剛才說了第一種場景，然后說說第二種場景，就是初期其實大家都沒有明確細節，但是在實施過程中開發人員會根據自己的接觸面來選擇一些技術和架構設計，最后看起來很復雜，很完美，但其實越是復雜的設計背后有越多的隱患。但是此時因為已經設計好了，就不愿意再去簡化，也不愿意聽任何人的意見，其實這是很危險的。我過去也犯過類似的錯誤，但是其實當你冷靜下來，想想那句話，我們的目標是什么：“滿足客戶需求”，這時候你就會考慮，這么復雜的系統會不會給客戶帶來更多的不穩定以及復雜度，其實客戶不關心你背后如何實現的，但是你需要滿足客戶的最基本的需求，用起來方便，高效，實實在在提供了解決問題的手段。
今天下午面試了一個外部的同學，工作年限比我長，看了簡歷也經歷了很多項目，同時在描述的時候寫了對高并發，分布式等等都很熟悉和熱衷，我開始看了簡歷就擔心，可能我這邊不一定要他，因為我怕他開口就是說一大堆如何做高并發和分布式的內容。在我看來如果你沒有搞清楚你什么時候要用牛刀，什么時候要用剪刀的人，和你談論牛刀的構造其實沒啥意思，因為在我看來，技術只要你肯花時間去學，沒什么學不到的，但是做事方式和項目設計經驗卻是長時間積累的。幸好今天和他一談，他對于技術的態度以及架構設計的思想都和我想的比較接近，不是為了技術而技術，不是為了過程而過程，了解如何從簡如繁，再從繁入簡，最終能夠找到自己的目標。當然后來還是談了很多技術細節的問題，畢竟干活還是要一個好手，作了那么多年如果沒有經驗和技術積累也是很可怕的事情。最后我問了他兩個問題：1.你學習一個新技術的過程是怎么樣的？2.你和你同事如果在設計方案上有沖突你怎么解決？他告訴我他學習新技術首先會去考慮這個技術的特點是什么，和其他技術的差別，他的擅長領域是什么，這樣才能夠用到實處。第二個問題他和我說就是開會討論，最后大家群體決定。我對他第一個問題感到很滿意，因為我就需要這樣的同事，第二個問題我給了他一個建議，其實在很多時候，將別人的架構設計的優點融入到自己的設計中，不再以方案作為邊界，那么大家最終就很容易達成一致，因為你在接受別人的思想時其實能夠看到自己的不足，同時對待別人不是用否定的態度，會讓你更容易得到認可和接受。（這點作起來需要不斷的改變程序員自身的好勝個性，我起碼還是出于變化中…）
我記得我小時候上政治課的時候，老師給我們劃分了三種人：有能力但是沒有道德的人是危險的人，沒有能力但是有道德的人是對社會無害的人（覺得像葛優說的那個對社會無害的海龜一個概念），有能力同時也有道德的人是對社會有益的人。我覺得其實程序員也就可以從兩個緯度看：
1. 有能力，有經驗，對技術有追求。
2. 對產品化和客戶沒有任何感覺。
擁有了素質1但是沒有素質2，那么最多也就只能說是試驗室的花朵，在大學搞搞研究還不錯，實際要做出產品來可能就是紙上談兵，好鋼始終用不到刀刃上，有力沒地使。
素質1有所欠缺，素質2很明晰，對自己目標不斷追求，其實這樣的人，有時候笨鳥也會飛的比聰明的鳥更高。
擁有1，2的人，當然就是最好的人，只需要學會做人那么就可以發揮自己的能量。（程序員有時候就是很難改變自己的個性，去學會如何溝通和理解）
最后一類就是自以為有1和2的人，這類人最怕就是面試的時候被考官通過，那么后續的問題就大了。
說了怎么多，其實也無非想說出一個程序員這些年的經歷，從做開發到做基礎平臺，到做業務平臺，該怎么踏實做事，該在什么時候找到自己的瓶頸，該在什么時候改變自己的狀態，都需要自己好好的讓自己冷靜下來想想。做基礎平臺需要耐得住寂寞，同時也要知道自己是有客戶的，服務不好客戶，那么基礎組件平臺就是玩具。做業務平臺需要學會去分析和溝通，需要去了解每一個層次的設計如何協作，同時在兼顧業務需求的同時滿足隱性需求（穩定性，可用性，響應速度，規模化等等）。但歸根到底，能給開發人員不斷能量的不是技術本身，而是你用技術給你的客戶帶來的價值，對你的認可是長期做事的一個最基本的動力，因為當你現在覺得純做技術能夠支持你不斷向前走的時候，其實在不遠的將來你會體會到原來過程和目標是同樣重要的。走出自己的一畝三分地，給自己多一點的空間，會讓自己看得更遠，走的更高。