代碼高質量等級的階梯
社區諸君也許都聽說過，「要寫高質量的代碼」，那麼到底什麼是高質量的代碼？
我在專業環境下開發軟體有著比較長的時間。我先後在微軟，Google，Sumo Logic，以及現在的Leap.ai工作過。
我現在來總結一下代碼質量的階梯增長。可以把代碼質量階梯視作是一個簡單的框架，用它來確定一段代碼是不是高質量代碼。
希望「代碼質量階梯」能夠幫助剛剛工作的軟體工程師儘快到達職業遊戲的頂峰。
代碼質量等級I：正確性
編寫正確的代碼是軟體工程師最基本的要求。 聽起來很似乎挺淺白，但說時容易做起來難，在現實生活中很難達成。
我用一個我最喜歡的面試題作為例子：許多常用的電子表格產品的列是從A到Z，然後是AA，AB等。 編寫一個函數將列名轉換為相應的列號。 即，A變成1，B變成2，C變成3，等等。
幾乎每位看到這個問題的人很快就會想到，這是一個26位的轉換。接下來他們就開始編碼。 但是，能夠正確編碼的人的比例卻驚人地低。
我們來看下面用C ++語言編寫的實現。
你能找出這個代碼中的任何錯誤嗎？ 如果不能，那就更加努力吧。 
這段代碼存在以下幾個問題：
· const char*是一個C風格的字元串。 在C ++代碼中使用C風格的字元串可能是危險的，因為C風格的字元串被假定為NULL終止，但C ++字元串不一定如此。 需要用std::string來代替。
· 指針/引用可能是NULL，並且當傳入一個NULL指針時，這段代碼將會崩潰。如果調試伺服器崩潰在凌晨3點出現NULL指針，那麼用戶將無法訪問你的網站。
你可能會說，「但我會驗證輸入，以確保我不用NULL指針調用它」。對不起，你不能在現實生活中。 一旦你的代碼被寫入，你將不知道是誰在調用它，在什麼條件下調用。
· 如果輸入是小寫字元串，這個代碼是否正常工作？
· 那麼輸入中包含非英文字元呢？
· 如果輸入是一個Unicode字元串會發生什麼？
· 如果輸入字元串有七個As就會發生什麼？ 是的，整數溢出。我們的代碼也需要處理...
說到代碼，記住墨菲定律是很重要的：任何可能出錯的東西都會出錯 。 這意味著編寫可以處理任何輸入的代碼是非常必要的，不管它是什麼。 如果你能做到這一點，你將避免給你的代碼的調用者任何意外的驚喜。
為了達到這種編碼「正確性」的水平，你需要對代碼可測試性有一個很好的理解。 還必須為您的代碼做大量的單元測試。
代碼質量等級II：效率
恭喜你，現在你已經完成了Level I，假設你的代碼大部分是正確的。 順便說一句，沒有無錯代碼這樣的東西，所以「大多數正確」已經是一個非常高的比率。
想像一下，你把你的代碼投入到生產環境中。這個時候ta-da一聲， 你的網站出現故障。我們在驚慌和冒汗的狀態下，對大量伺服器日誌追蹤。最終把問題縮小到一個被請求所淹沒的函數調用，是它無法完成處理，導致了超時。
歡迎來到效率的土地！
你問什麼是「效率」？ 「效率和Big-O符號一樣嗎？」
答案是：效率和Big-O很接近，但不一樣。
下面是一個例子來說明我在說什麼：什麼是最快的排序演算法？ 您可能會說快速排序是最快的排序演算法，平均為O(n*log n) 。
在我們深入研究之前，讓我們快速回顧一下。 「大O符號」描述了演算法完成某個功能所需的最長時間。 所以如果一個演算法是O(n*log n) ，就意味著對於某個常數k ，運行時間是
但實際上，演算法速度有兩個條件需要考慮：
· 大小n是重要的。 例如，如果我們排序一個6維數組， O(n^2)氣泡排序可能比O(n*log n)快排序快得多。
· 常數k也非常重要。 在計算機科學課程中，我們總是忽略k在演算法複雜性分析，但在現實生活中， k是超級關鍵。 k=1的O(n^2)解將比任何n
到目前為止，我們只涉及與時間有關的效率。 但是還有其他類型的效率需要考慮。 如空間效率，功效，演算法收斂速度，用戶交互效率等。 我不能在所有這些方面詳細討論，但代碼效率是非常依賴於上下文的。 編寫任何代碼時的目標是在給定的約束條件下儘可能高效。
關於效率的最後一個注意事項：做得太過也不好。
這些被稱為「不成熟的優化」，應該避免，而應只優化需要優化的東西。 如果不確定，請首先使用最簡單的解決方案，然後進行性能測試，再確定是否需要進一步改進代碼。
代碼質量等級III：可讀性
現在你知道如何編寫既正確又高效的代碼。 下一個挑戰是要確保代碼也要讓其他人容易閱讀和理解。
現代軟體工程總是關於團隊合作的。 你寫的代碼並不是你的，它屬於你的團隊（甚至其它團隊） 。 讓我們沉浸其中......那麼，為了成功，讓你的隊友們也有興趣來維護你的代碼。 你不想在度假時打個電話，告訴你上網並修改代碼。因為團隊中沒有其他人能夠理解它，對嗎？ 這發生在很多工程師身上。 有一家公司曾經要求我幫忙，想了解一年前我寫的一段代碼 - 在我離開公司之後！ 相信我，這絕不是一個好的體驗。
用於將團隊放在同一頁面上的常見行業慣例稱為編碼風格指南。 在編碼風格指南中，一組商定的編碼風格由整個團隊或組織共享。 我推薦Google代碼風格指南 ， Google代碼風格指南 （整個Google公司是緊隨其後的）。 現在也被許多組織公開接受。 它是徹底的，涵蓋了許多常見的編碼語言。
谷歌編碼風格指南編寫得很好，所以我不再重複這裡的內容。 有一件事我想強調。 始終遵循你的團隊現有的約定。 即使與其他普遍接受的慣例略有不同，也要這樣做。 最重要的是你的團隊的代碼是一致的。
堅持編碼風格是一個好的開始，但是也需要其他實踐來使代碼可讀。 例如，注釋不應該簡單地複製寫入的代碼。 他們應該解釋代碼背後的想法，並給出代碼的上下文。 通過描述性的，具體的來使它們更有用 。
在這裡，我選擇了一個非常簡單的例子來說明這個哲學。 比較以下兩種備註方式：
int index= -1; // init to -1; useless comment
與
int index = -1;// init to invalid value; useful comment
（更新：這只是一個例子來說明備註，但不是一個寫代碼的最好例子。正如在一個響應中指出的，寫這段代碼的更好方法是int index = INVALID_VALUE; // no comment needed ）
如果你還是覺得這個例子太微不足道了，想要一個更有趣的例子，請您看Google開源的LevelDB頭文件。 這是一個很好的關於備註的例子，最初由Jeff Dean和Sanjay Ghemawat（Google的兩位高級研究員）編寫。
因此，關於可讀性的關鍵是： 你的隊友將是你的代碼可讀性的重要判斷 。您的目標是讓您的同事輕鬆理解您的代碼。 在假期里你有其它更好的事情要做！
代碼質量等級IV：可擴展性
如果您編寫的代碼是正確，高效和可讀的，那麼你就可以在任何組織的編程人員中排名前10％。
下一個挑戰 - 可擴展性，我來說說我們如何登頂。
問題改變與代碼演變。 一個好的程序員可以預見將要發生的變化，並將其考慮在內，編寫與未來兼容的代碼—— 這是「可擴展性」的魔力。
我們以MapReduce為例。 MapReduce來自Google搜索小組，大量工程師正在通過類似的任務來分析數據。 Jeff Dean和Sanjay Ghemawat認為需要對框架進行標準化，以使工程師的生活更輕鬆。
說實話，標準化框架有很多種方法。 還有批評說Map and Reduce的概念並不新鮮。 然而，MapReduce的強大之處在於它將標準化到了正確的層面 ，使得使用它變得容易。 這意味著Google Search工程師可以使用它，也適用於Google搜索之外的其他用例。 眾所周知，MapReduce在Google內外都得到了廣泛的應用，其創造成為Web大數據時代的基石。
這是可擴展性的關鍵：知道什麼級別是正確的級別。 回答這個問題奇怪的是比科學更多的藝術。 如果您的代碼太具體，那麼用例將會受到限制，每當需求發生變化時，代碼都需要修改。 如果你的代碼太泛化了，那麼你的客戶需要做很多工作來為你的特定需求構建代碼，然後使用起來就太困難了。
掌握可擴展性需要大量的經驗和智能。 對於大多數人來說，提高可擴展性的方法就是從我們的錯誤中學習 - 嘗試，失敗，沖洗和重複。 即使在Google，在MapReduce之上至少也有四五個框架構建，以使得MapReduce更容易。即使在Jeff和Sanjay身邊，Google也不止一次嘗試做到這一點。
小結
代碼的正確性，效率，可讀性和可擴展性不是彼此獨立的。 可讀的代碼更可能是正確的，但低效率的代碼很難延伸。 對於每個軟體工程師來說，最終的目標是在這些方面都要做好。
但是在一些時候，大部分人都處於一般的水平。 我的建議是評估你自己的專業水平，比如考慮一下你花費大部分時間和精力在哪裡，然後把注意力集中在那個領域，然後再進入下一個階段。
在你準備好之前，避免攻擊一個非常難的關卡。 記住這一點，在你未能建立出色的技能，或者在基礎薄弱的情況下，解決更具挑戰性的問題將會出現停頓。
祝大家都能成功攀登代碼質量高峰。
謝謝閱讀。 如果你有任何想法，請留下你的寶貴評論 。
作者：Yuankai Zhou。Leap.ai Co-founder&CTO。原Google公司技術工程師。
編譯：21CTO社區
原文：https://medium.freecodecamp.org/climbing-the-code-quality-ladder-babd3198e6e2
TAG:21CTO |