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