原创 Code Review 常見的5個錯誤模式

原作者:Trisha Gee Code Review 的時候,每個人都會關心最佳實踐,但最壞的實踐有時可能會更有啓示意義。 Code Review是研發團隊必不可少的,但並不總是正確的。這篇文章指出了所有開發者在Code Review時或提

原创 從團隊管理視角看重複建設問題:輪子小造怡情,大造傷身,全局出發成就更好的你

在一定規模的軟件研發團隊內,經常出現的情況是對同一個問題領域,會有多個人或多個者團隊矇頭再重複做系統或方案來解決相同問題。 甚至,在一些團隊內,技術人員爲了職位晉升,會通過重複建設相關的系統來展示其能力,併名其名曰面向晉升編程。 對於個人來

原创 軟件設計的哲學:增加複雜度的12中危險信號

軟件系統的設計和開發過程中,增加系統複雜性的12中危險信號: 危險信號1:淺層模塊 淺層模塊的接口相對於它提供的功能來說是複雜的。淺層模塊在與複雜性的鬥爭中幫助不大,因爲它們提供的好處(不需要了解它們內部如何工作)被學習和使用它們的接口的成

原创 坦誠,不要對領導說謊

引子 你是否曾經遇到過這樣的情況,當你在向你的經理或更高級的領導彙報工作時,你說了一些錯誤的事情而錯過了一些很好的機會? 在我的十幾年職場經歷中,我遇到過很多這樣的場景,在高壓下,因爲提供信息不準備,或者含糊其詞,都會給領導留下不好影響。

原创 軟件設計的哲學:第二十章 性能設計

目錄 20.1 如何考慮性能 20.2 修改前的測量 20.3 圍繞關鍵路徑進行設計 20.4 一個示例:RAMCloud緩衝區 20.5 結論 到目前爲止,軟件設計的討論都集中在複雜性上,我們的目標是使軟件儘可能的簡單和易懂。

原创 不要給領導驚喜或驚嚇

在職場中,你是否曾經遇到過這樣的情況:你負責工作出現了嚴重的錯誤,例如系統停機,你希望在問題更廣泛地傳播之前找出問題的原因或解決方案?我知道這就是我的感受,特別是如果保持這個系統正常運行是我或我的團隊的責任,不希望給領導造成麻煩,期望儘快解

原创 軟件設計的哲學:第二十一章 結論

目錄 結論 最重要的軟件設計原則 結論 這本書講的是一件事:複雜性。處理複雜性是軟件設計中最重要的挑戰。它使系統難於構建和維護,並且常常使它們變慢。在這本書中,我試圖描述導致複雜性的根本原因,比如依賴性和模糊性。我已經討論了可以

原创 軟件設計的哲學:第十八章 代碼的可見性

目錄 18.1 使代碼更簡單的東西 18.2 使代碼不那麼明顯的事情 18.3 結論 晦澀是2.3節中描述的複雜性的兩個主要原因之一。當系統的重要信息對新開發人員來說不明顯時,就會出現模糊現象。模糊問題的解決方案是用一種簡單易解

原创 軟件設計的哲學:第十七章 一致性

目錄 17.1一致性的例子 17.2 確保一致性 17.3 別做過了頭 17.4 結論 一致性是降低系統複雜性和使其行爲更加明顯的強大工具。如果一個系統是一致的,這意味着相似的事情以相似的方式完成,而不同的事情以不同的方式完成。

原创 軟件設計的哲學:第十六章 修改現有代碼

目錄 16.1 保持戰略 16.2 維護註釋:將註釋放在代碼附近 16.3 註釋屬於代碼,而不是提交日誌 16.4 保留註釋:避免重複 16.5 維護註釋:檢查差異 16.6 更高級別的註釋更容易維護 第1章描述了軟件開發是如何

原创 軟件設計的哲學: 第十五章 先寫註釋

目錄 15.1 延遲的註釋是糟糕的註釋 15.2 先寫註釋 15.3 註釋是一個設計工具 15.4 早期的註釋很有趣 15.5 早期的註釋代價高昂嗎? 15.6 結論 許多開發人員將編寫文檔的工作推遲到開發過程的末尾,即編碼和單

原创 軟件設計的哲學:第十四章 選個好名字

目錄 14.1例子:不好的名字會導致錯誤 14.2 創造一個形象 14.3 名字要準確 14.4保持一致性 14.5 不同的觀點:Go style guide 14.6 結論 爲變量、方法和其他實體選擇名稱是軟件設計中最被低估的

原创 軟件設計的哲學:第十三章 註釋應該描述代碼中隱藏的內容

目錄 13.1 選擇約定 13.2 不要重複代碼 13.3 低級註釋增加了精確性 13.4 更高層次的註釋增強直覺 13.5 接口文檔 13.6 建議:什麼和爲什麼,而不是如何 13.7 跨模塊設計決策 13.8 結論 13.9 對第

原创 軟件設計的哲學:第二十章 爲什麼要寫註釋

目錄 12.1 好代碼是自我解釋的 12.2 我沒有時間寫註釋 12.3 註釋會過時併產生誤導 12.4 我所看到的一切註釋都是毫無價值的 12.5 良好的註釋的好處 代碼內文檔在軟件設計中起着至關重要的作用。 註釋對於幫助開發

原创 軟件設計的哲學:第十一章 兩次設計

目錄 設計軟件是困難的,所以你對如何構建一個模塊或系統的最初想法不太可能產生最好的設計。如果您爲每個主要的設計決策考慮多個選項,您將得到一個更好的結果:設計兩次。 假設您正在爲GUI文本編輯器設計管理文件文本的類。第一步是定義類將呈