是財富仍是陷阱？如何處理他人的代碼

聲明：本文大部分翻譯自How do you work with other people’s code做者：Matthew Setter。可能翻譯過程與原文略有不一樣，轉載請註明出處。

咱們在工做中經常也會遇到相似的問題。進入一個項目團隊，接手別人的項目，開始幹勁滿滿，但把別人作的東西拿來一看，瞬時傻眼，不知道從何入手，好不容易開始後又滿滿抱怨以前作項目的風格和本身如今的不一樣，而如何去化解這類的尷尬，就是這篇文章的主題內容。

處理其餘人的代碼是一個開發者的基本技能。只需一年的時間，其餘人的代碼就能夠爲你所用。

如今，我要尋找一些最有效的處理其餘人代碼的方法，怎樣去有效的閱讀遺留下來的代碼。要知道這並非一件容易的事。

爲了讓敘述過程更容易，我將把個人心得分紅如下的方式：

互動
觀察
測試
爲新人設計的錯誤修正系統
尋找可行資源
使用好的IDE
看書和blog
編寫文檔
推己及人

互動

誰是大家開發者的老大？他們在哪？在你辦公室是否能夠直接找到他們？若是ok的話，大膽去和他們交流或者Email他們。要知道他們是項目相關知識最好的來源。

你是不是遠程辦公或自由職業者？這個項目或公司的開發者用什麼來交流，他們是用的IRC、Slack，twitter，email或者其餘工具？

要確保你和項目一致。一個常常在Zend Framework 2項目受詬病的地方就是沒有什麼活動社區。若是平常能多使用IRC channel就不會出現這種狀況。因此你要確保你和開發者和其餘團隊成員保持一致。

觀察

當你開始一個項目時，不用太過於緊張。不要期望一開始就知道全部正確的事。通常項目時間估計都會各不相同，可是我有據說在真正能夠進行代碼生產以前須要3周到3個月不等的時間去了解代碼庫。

有人會有誤導的感受，認爲不論怎樣，只要你參與進去你就會能夠持續的輸出。有這種想法的人可能看了太多的好萊塢電影，好比《旗魚》。

代碼庫就是一種思想的結晶，是創造它的開發人員的想法、信念和行事方式的集合。這是須要時間去了解和學習的，對於代碼庫，你仍是一個新人，須要有背景知識的沉澱。

這裏有5種很好的方法去開始：
 花時間去一步步走一遍全部代碼
 善於提問
 配置測試機制
 嘗試使用測試機制
 讀通讀懂代碼註釋和文檔

別爲難本身，好的開頭是成功的一半，作好開頭的準備工做。以後，你會開始對那些應用如何組合爲何組合會有更好的瞭解。

在這個思想下，經過諮詢其餘的開發者和高級的開發者你能夠行動的更快。在這以前經過對代碼庫的總體瞭解，你須要列一個問題清單。

花時間向其餘的開發者搞清楚你的問題。不要害羞，問問題並獲得你須要的答案。

測試

任何好的代碼庫都有測試。若是沒有，這並非個好的兆頭。沒有必要隱瞞的事，它可能只是開發者或者開發團隊歷來都沒實施過測試。而我關心的是若是它真的沒有測試。

若是有測試的話，不用多說，運行它們。能經過麼？我遇到過不止一次這種狀況，數據庫有一套完整的測試可是沒有人能真正的運行起來。因此還有一個問題，它們是否一直保持着更新？

如今你已經嘗試着去運行了，並對它有很好的瞭解。若是是好的測試，你應該已經瞭解那些應用是如何工做，它們想達到的結果以及不一樣的組件是如何掛在一塊兒的。確保你花了時間去作這些事，這是很是有意義的。

爲新人設計的錯誤修正系統

另外一個很簡單開始的方法就是以項目的新手或者初級開發者修正bugs。有兩個典型的例子Joind.In和ownCloud，在下面的截圖中你能夠看到這兩個bug追蹤器。

經過上圖你能夠清楚的看到那些標籤。通讀他們並參與進去，雖然這些bugs並非什麼特別高技術的，可是你能夠輕鬆的應用到項目中，樹立你的自信心和知識體系。

雖然複雜的技術和榮譽能夠知足你的自我，但當他們無論用或者那你完成的只是件小事時，這些只會成爲你驕傲和熱情的絆腳石。因此別眼高手低，用最簡單的方式踏實作事，

尋找可行資源
當你接手一個代碼庫或加入一個老團隊，能作的最好的事情就是儘量的去收集各類資源，不知道怎麼去尋找？這裏有一些能夠參考的意見：
你是否有權限訪問郵件列表檔案？
項目或者公司是否有本身的wiki？
有哪些項目文檔被編制了？
你是否通讀過版本控制歷史？
那些貢獻者是否還在持續的更新有意義的操做信息？

使用好的IDE

一個好的IDE的含金量是衆所周知的。不關你是Ruby、Python、Go、Java，PHP仍是其餘語言的開發者，你須要找到一個適合你語言特點的好的IDE。

我很欣賞一些人是純粹主義者，偏向於VIM或Emacs，這是極好的。但我是一個IDE的愛好者，個人選擇是PhpStorm。固然還有其餘不少的IDE，好比Eclipse、TextMate、SublimeText和VisualStudio。

一旦你選擇好了你的IDE，你要開始去了解和使用它提供的功能。我這裏將以個人偏好PhpStorm爲例，但你能夠把這些原則上的東西運用到你選擇的IDE上。

開始輸入代碼，看是否符合標準。並不須要像PHP PSRs這樣一個正式的標準。可是你要知道開發者是否都遵循着一致的風格，而不是各執本身的路數。學會使用Mess detector和圈複雜度測試儀去衡量代碼的質量。

是否有任何的代碼文檔？若是有，當你檢查你的代碼時，IDE應該要能使用它。接下來，使用單步調式程序，如xhprof，Xdebug或Zend調試器，運行應用程序看那看看它是如何運做的。

它作了什麼？它建立和使用的數據結構是什麼？它有沒必要要的重複代碼模塊嗎？真正要了解的遠比我在這裏列舉的要多，但使用IDE給你提供的功能去完成代碼會使你的程序員生活更輕鬆。

閱讀與學習

這只是我我的的想法。咱們學習的越多，成長的就越多。咱們並非第一個吃螃蟹的人，在咱們以前已經有不少的人犯了不少相同的錯誤。

給本身留點時間，去評判一些前人們的經驗並從中學習，吸收經驗教訓。要知道許多好的開發者也兼職編輯和博主。

我最欣賞的是Martin Fowler，他寫一部關於重構的偉大的書。也有其餘優秀的書籍，例如《Design Patterns》和相關的網站SourceMaking.com。

幫你本身一個忙接着繼續投資與這些資源。這並非一件容易的事，可是是真真切切有益的事。

編寫文檔

這也是我作的不夠的地方。作一個評論家很容易，坐在場邊而後去評判一個代碼庫或框架的好壞，或者其餘類型的軟件項目。別作評論家，你要參與進去。

文檔不是爲失敗的程序員、設計師或者非技術人員準備的。一些超級大項目會積極的建議文檔是項目最好的開始。

從文檔開始的最大的項目之一就是Linux Kernel。有什麼比記錄文檔更好的方法去學習東西呢？畢竟，只有你能記錄它，你才能真正的知道它。

所以，若是是個開源的項目，參與進去，通讀代碼，作筆記，而後編輯文檔。若是這是一個內部的應用，第一件事就是記錄文檔，就算只爲了你一我的。

也許最可怕的是徹底就沒有文檔能夠用，可是每一個項目都要有開始的地方。當你用源代碼工做時，寫下你所知道的。

據我所知一些最好的開發者，例如the lovely Lorna Jane，開始使用博客的方式。他在博客中記錄她所學到的東西，而後她的博客成爲了最有名的PHP博客之一。

推己及人

最後一點：要體諒你正在審查和構建的開發人員的工做。你不知道他們的職業生涯和教育，或者他們寫你如今加速工做的代碼時所面對的限制。

更多的是，你是在什麼技能水平的人？那可能對咱們來講很容易，當咱們年輕時候，仍是新手沒多少經驗的時候，也會有人這麼評價咱們。

咱們認爲知己無所不知，咱們的指望、概念和方法都是正確的。但事實真是如此嗎？我寧願相信，當咱們變得成熟，咱們也會更加的明智，變得更加可以去接受軟件開發的普遍方法的存在。

咱們也許不須要去贊同他們，但他們不必定是錯誤的。他們也能夠教會咱們不少，幫助咱們成長。因此嘗試多去體諒他人，站在他們的角度去想一想。不要成爲使人討厭的新人，只會指責和埋怨。畢竟這沒有任何的卵用。

我的體會：

我以前在一個遊戲公司作數據分析，雖然和代碼沾不上太大的邊，但對這方面的苦惱也深有體會。
因爲我要作數據分析，就免不了要從數據庫中調用數據，常常須要把最近今天的數據和以前的數據作比較分析。這時候問題就出現了，纔開始作的時候我就常常查詢不到以前的數據，我問管這塊的同事是否是以前就沒有記錄這個類別的數據或者是刪掉了，但他說是有記錄的並且不會刪掉重要的數據。以後我就一張張的翻數據表才發現以前的數據表的類名和如今的徹底不同，甚至有的相同數據有3個不一樣類名。還有的活動數據表的命名也毫無規則，這就給個人工做增長了很大的負擔。
因此有時候也許你的方法和命名更加科學，但儘可能與以前的工做保持一致，不只方便本身也會給後來人帶來很大的便利之處。若是實在堅持你的風格，至少要留下說明文檔，不只對本身的工做負責，也是爲他人負責。

目前有不少的開源項目和代碼，也有更好的開發環境，但慢慢你會發現使用他人的開源項目或代碼並不僅是一個捷徑，更多的是一種學習和自我提高的過程。
我如今所在的公司雲巴就是這樣一個公司，我相信不少成功的公司也是同樣，站在巨人肩膀上時也要去尊重它。