你瞭解你和程式碼的生存環境嗎

我們編寫的程式碼執行的每一天，其實跟我們生存的每一天都差不多，我們都依賴於外部資源——CPU、記憶體、網路等。因此瞭解我們（程式碼）的生存環境是相當重要的事情，無論是程式從 Redis 獲取資料，或者是我們看到綠燈之後走過馬路，大概率上是安全的，但是依然存在風險，瞭解存在哪些風險是必要的。對於程式設計師來說，確切的說對於渴望成長的程式設計師來說，瞭解生存的空間必不可少。

這裡說的生存環境主要是三部分：技術，團隊，業務。

微觀程式碼環境 這個是最直接的，每天都在做各種業務的支援，寫各種程式碼亦或是抄各種程式碼。你有沒有在不經意間思考這麼個問題，你所產生的程式碼如果能思考，它會怎麼看那些跟他在同一個檔案中的其他程式碼？另外一個問題是這個模組中有那麼多程式碼，為什麼你改掉了別人之前寫的程式碼，而放下你的程式碼？你的程式碼可能會在什麼樣的場景下被別人修改？

來看下面一個簡單程式碼:

不知道你是否有過這個經歷，看到過這樣的程式碼，小 C 的 my_db 會不會同一年前小 A 產下的 our_db 進行溝通：喂，我說哥們兒，你爹真是個 low x 呀。當然這個程式碼比較短你可能會一眼看到問題所在，但是當你維護一個有幾百行程式碼的檔案時，你得有很好的記憶力才行。這只是 Python 的例子，JS 裡的例子還會更多。

瞭解你所編寫程式碼的環境，上下文。然後去用那些能夠複用的連線、函式、工具，而不是自己造一個。如果覺得別人的寫的有問題，gitblame 是個好工具，跟他溝通，我們一般會總想著讓自己過的舒服點，搞個好點的鍵盤，好點的椅子。但是從程式碼角度來看，也需要要整個程式碼環境更好一點，同時這也是讓人精神愉悅的方法。

有兩個理論需要知道，一個是 破窗理論，另外一個就是童子軍軍規——讓營地比你來的時候更加乾淨。另外值得不斷警醒的是不要生下程式碼猴子。參見《程式碼整潔之道》。

技術棧 先從技術說起，比較容易理解，一般我們新到一個公司，前幾天肯定是需要做的就是熟悉環境。這裡的熟悉環境一般都是指技術上的，首先需要做的就是了解新公司用到了哪些技術，比如你之前的公司都是用 SVN 管理程式碼，現在大家都用 git，那你肯定需要儘快熟悉，再比如說你之前打包都是用 grunt，但是新公司都用 glup 了，這也需要熟悉。在此之上才是業務層面的熟悉，這個業務是指跟你編寫程式碼緊密相關的業務（功能）。

這顯然就是我們新到一個環境首先需要做的事情，但是對於一部分老人（老員工）來說，對於能夠支撐業務的程式碼（技術點）足夠熟悉了，每天需要做的可能是徘徊在各種業務之間，運用熟悉的技術，不斷的構建一個又一個產品。短期來說是個好事，通過快速的提供技術支援保證產品進度，同時也能收穫其他同事的信任。但是長期來說是一種危害。有句話叫做：跳出你的舒適區。在舒適區待的太久會導致：一年經驗用十年的狀況。因此這個時候還需要再次考慮你的生存環境是什麼？你所持有的技術的生存環境是什麼？

所謂的生存環境並不是固定的，它是隨著你的認知的不斷的擴大而擴大，就像是一個圓，內部標記為已知，外部是未知，你已知的東西越多，未知的東西就越多。

因此要是時刻有更深層次的考慮，對於如何跳出舒適區的最好的辦法就是保持警惕心。在感覺一切盡在掌握之中的情況下，考慮到出現什麼情況會導致你無法把控——無論是專案進度還是問題修復。

再說到技術棧，目前我們前端用到的技術棧是：JS、CSS3、H5、Backbonejs、Zepto、Grunt、Git 等等，後端的技術棧是: Python、Django、Tornado、Redis、MySQL、Fabric，Gunicorn 等等。但這些就現在來看是穩定的，但是相對於大的環境來說，這些可能並不是穩定的。這其實就是另外的問題了，區域性環境和大的環境之間的考慮。

單純的就區域性環境來說，只是能夠熟練的運用 JS，CSS 解決問題是不行的，對於現在已經工程化的前端來說，只會這些會讓你丟掉飯碗——遲早。因此有必要精通你的技術棧。對於後端來說也是一樣，看了別人的 Tornado 程式碼，你也能寫出非同步處理器，但是你知道 Tornado 是怎麼處理的嗎，如果你不知道，你可能會在訪問 Redis 的 Handler 上加一個非同步的裝飾器，這有用嗎？另外如何改造 Redis 驅動，支援非同步請求呢？

大部分情況你只熟悉了外圍的技術點，不妨礙你做一些 Normal 或者是 Easy 模式的業務。但是如果始終停留在這個模式，那你也只能留在這個模式。一般我們派活給同事時，都會考慮他的技術能力在什麼水平，不會上來就給一個 Hard 模式的業務，這必然會導致一個問題，只能解決 Easy 模式問題的人，一般來說不會得到重視，如果能夠及時自省，自己奮發的好還好。就怕覺得自己能幹活，但是待遇不如人。

團隊 相對於上面兩個比較直觀 / 具象的內容，團隊這個概念有點虛。不過反過來說，相對於好壞程式碼的感知，對團隊，對於同事關係、能力的感知反而會比較直觀。

對於團隊來說，我一直的看法就是，任何一個新人到新團隊第一件要做的事就是儘快讓大家都認識你，同時你也要儘快的熟悉每個成員。這句話的意思不僅僅是交個新的朋友那麼簡單。需要做的是有一個具體的評判。一般面試的時候不會所有的人都跟你聊過，另外面試也是單純的被問。因此進入團隊之後，首要做的事情，除了跟大家搞好關係之外，要做的就是了解每個人的技術點，技術偏好（或者到底對技術有沒有熱愛），然後看他們目前所處的層級。

上面說過，瞭解你的程式碼所處的環境很重要，瞭解你所掌握的技術在你所處的技術棧中很重要。這裡需要了解的是，瞭解你所掌握的技術在這個團隊中能夠到怎麼樣的層級，任何地方都是會有階梯的。團隊成員都是大牛的情況可能並不多見。

瞭解在團隊中所處的層級並不是要有階級感，也不是要找一個大牛進行膜拜，找個小白進行蹂躪。而是再進一步的瞭解那些處於團隊頂部的人他們掌握的哪些東西是你欠缺的？那些處於你下面的人，他們確實是因為工作年限比你少還是因為別的原因。總之還是那句老話——取長補短，向上懼下。(後面那個成語是我編的）

另外從團隊中能夠了解到的一個重要的狀況是你離目前團隊的天花板還有多遠，你需要花多少時間才能到達。現有團隊是否有成長氛圍，技術氛圍如何。

業務 這個是技術人員最不關注的，技術人的一貫思路就是，老子有技術傍身，只要技術夠牛，哪裡不是爺的天地。

但是首先要認識的一點是，所有技術的存在都是為了業務服務。如果你覺得自己技術夠牛，為啥不會對業務產生好的影響？尤其是當你進入一個不錯的公司，覺得可以施展才華，首先要做的可能是瞭解業務特點，有哪些是除了現有技術支援之外，需要改進的地方。比方說，m.sohu.com，常規的維護支援已經能夠讓他為使用者提供服務了，似乎不需要做什麼了。但跳出常規，除了讓網站可瀏覽，能不能讓網站更快速的達到使用者眼前。能不能讓使用者開啟頁面時使用更少的流量，尤其對於非 wifi 網路訪問。這些都是業務相關的。

可能有技術大牛會這麼想，我們這個平臺已經停穩定了，我們們花點時間搞個其他的專案吧，提高下大家技術。理論上來說這沒什麼問題，技術人員要做的就是儘可能多的做實踐。但是這個業餘的實踐是沒什麼含金量的，就好像 the5fire 經常會看到有工作幾年的前端同學，簡歷上寫，工作中沒用過 grunt，但是我自己搞過一個專案，用過 grunt 打包；或者是，之前工作沒用過 tornado，但是我部落格是 tornado 搭的。相對於既不會又不學的人來說可能會有些優勢。但是你瞭解的這個東西沒上過生產環境，這個對你來說除了是知識之外，沒什麼用處（知識和經驗是有很大差別的）。

技術是支援業務的脊樑，業務是滋養技術的環境。貼合業務的技術不僅僅能讓你在技術上更為精進，也會讓你在業務有所貢獻。哪個公司不需要這樣的人，升職加薪迎娶白富美的日子不就慢慢到來了嗎。

除了從技術角度看業務，還要從行業角度看業務。《我程式設計，我快樂》是一本很好的書，雖然名字有點俗。裡面的一些觀點確實挺好的，你必須瞭解你公司的成長情況，收益情況，行業地位。據此不停的調整自己的方向。讓自己無論是在上升還是下降的公司中都能夠往上成長。

瞭解行業狀況之後，需要的是正確的認識。更適應環境，因此不能覺得，現在屬於快速發展期，我們要快速的搞 MVP，程式碼審查、重構等我們行業第一再說。也不能因為一看，我靠，我覺得我們快散夥了，程式碼隨便寫寫吧，反正早晚得關機。

其實再回到上面的微觀的程式碼環境，不要生下一個程式碼猴子，因為人們看到它會跟看到你一樣。

瞭解自己所處的環境，不斷的改進自己，改善環境。