我如何知道本身是否善於編程？（譯）

原文鏈接：http://www.danielslater.net/2017/07/how-do-i-know-if-im-good-at-programming.html 做者：Daniel Slater

 

我最近和一個程序員晚輩聊天，他問了我一個很好的問題。這個問題很是好，讓我停下來開始思考對學習的見解。這個問題是：

"我怎麼知道我擅長編程?"

我經常會被問道和這方面相似的問題"我是怎麼變得擅長編程的？"或者"我怎樣才能變得擅長編程".這類回答就是結合你的工程實踐，上課，看書，和優秀的程序員工做，貢獻開源項目。但若是你把問題的角度轉變爲"我怎麼知道我很擅長?"那就變成須要用工程的方式。你須要有個指標，進行優化。

除了實踐以外，最重要的改進就是良好的反饋。當咱們開啓一個新的領域，沒有一個好的導師，好的反饋就會變得很困難。課程經過考試或者工程實踐來獲得反饋。可是當你完成了課程以後，你怎樣獲得更高級別的反饋來全面提高呢？若是有一個好的反饋機制，那下面的事就變得簡單了。

所以，我怎麼知道我擅長編程？最好從詢問："什麼是好代碼"開始。若是一個程序員不能寫出好的代碼，那他就不是一個好的程序員。

什麼是好代碼？

全部的代碼都是爲了完成任務存在的。首先好的代碼要完成預期任務。任務的複雜程度可能很是高，可是代碼不能超出他的要完成的任務。單間的反饋就是，"代碼是否完成了預期目標"。代碼只須要完成預期任務，不該該有其餘沒有設定效果。寫好單元測試，能做爲一個成功的衡量。

若是你不能成功的完成任務，那你首先獲得的反饋就是，是否須要進一步的學習。肯定你知識的欠缺並查找相關資料。系統理論告訴咱們，若是你沒有優化你的短板，你就是在浪費你的能力。這就是你從你短板上學到的東西。

代碼是否可讀？

好的代碼能簡潔的表達你的思路。別的程序員很容易理解它。熟悉你的語言風格和語法糖。3行代碼可能被一行好的方式代替，但任然有高可讀性。確保你的代碼註釋，解釋好代碼爲何這樣寫。若是你沒有朋友幫你檢查代碼，你能夠把代碼發佈到https://codereview.stackexchange.com/ 或者相似的網站。你將來半年別人能很好的接替你的工做。

是否容易拓展和修改？

不少程序員喜歡抱怨："需求又改了".事實是，你沒有從產品特點和目的來考慮你的程序。需求常變是好事，若是你都作了3個月了需求尚未更改未必是一份好的工做。更多的時間應該帶來更多的信息和需求。

在面試的時候我喜歡讓面試者完成一個相對簡單的編程任務，好比一個電梯系統。當他們完成後，我會讓他們實現一個沒有想到過的瘋狂的功能。他們就會從社交和專業角度反饋出大量的技能信息。

一個好的程序員應該對這方面有規劃。若是你完成了任務x,那就看看當條件k到q沒觸發時，是否很容修改x來完成任務x和y（不論是k和m發沒發生這個時候只執行y而不執行x）.CS 101思想-就像多態性、繼承和構成之間的區別-當時看起來沒有意思，但如今感受頗有趣了。

改變代碼能讓你感覺到更多的經驗，但不要很快就添加過多的抽象層。過早的抽象就會變得跟Enterprise FizzBuzz 同樣了(https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition)。

代碼是否有效率?

效率從不一樣方面組成，完成速度和不一樣的資源組合，比方說內存使用，CPU使用狀況等。幸運的是，每種語言都有他的分析工具告訴你程序運行時間和資源使用狀況，這方面很容易追蹤。熟悉這些工具，並看看你能把這些指標下降多少。若是你要重構一個已知問題，好比你本身寫本地緩存，那就拿來和以前的對比誰更好。這樣你可能開始從一個大角度來審視你的代碼了，大致瞭解下不一樣的運行時間是頗有用的。

你能寫的很快嗎？

在早期學習的時候，速度不是重點。編程速度競賽讓人敬佩，但從編程工藝來說，那是很糟糕的學習方式。速度不是目的，更多的只是對進步的衡量。若是你已掌握了一個領域，你因該能高效的、高可讀的完成你的代碼，而且更短的時間進行擴展。

衡量任務完成時間很容易，但這個標準很難。你可能花費了大量時間在研究不少子任務上。這些是不是你須要深刻理解的地方呢？可能你花費不少時間作手動代碼測試，是否有更效率的自動化軟件代替呢？看看你如今用的工具。你的IDE有不少快捷鍵來提高速度了，把你的大腦從機械化任務中解放出來，去考慮更高級的東西吧。

結束

若是你的代碼都高標準的完成了，那麼你就擅長編寫這個任務了。若是你已經不知道該從哪方面提高了。你能夠從複雜性上考慮，或者看看你但願提高的其餘領域。

我想再加一件事來結束這篇文章。鑑於天天時間和生產時間的限制，只有一我的能作到這點。Elon Musk是一個出了名的有效率的人，但若是PayPal公司只有他一個工程師，他就不會走得這麼遠了。在必定程度上說，若是你想作一件大事，就要在團隊中工做。此刻編程就是了羣體活動。編程不只要經過手和大腦還要有你和整個團隊的配合。所以，好的程序員不只僅是你本身編程有多棒，好要看和你配合的程序員有多棒。

有不少方式得到反饋。你對同事的代碼審查以後他是否會作的更好？接下來的問題是他只改進了你檢查的代碼仍是全部的代碼？這僅僅是機械化的讓人改進而非技術上的。你能不能讓他們對這個任務充滿激情明白改進方法的重要性呢。你是否提升了周圍人的總體技能？著名的27x研究代表，最好的程序員是最差的程序員的27倍。若是你是一個7x的程序員，你幫助4我的從1x提高到7x，那麼你就比一個27x的人產出的還要多。

對我來講，這些就是一個好的程序員的本質，若是你作到了任何一點，你就能夠安慰的睡覺了，你是一個好的程序員。