下降軟件複雜度

本文原創：yangyanchun

在進行軟件開發時，咱們經常會追求軟件的高可維護性，高可維護性意味着當有新需求來時，系統易擴展；當出現bug時，開發人員易定位。而當咱們說一個系統的可維護性太差時，每每指的是該系統太過複雜，致使給系統增長新功能時容易出現bug，而出現bug以後又難以定位。

什麼是複雜度

修改擴散

修改時有連鎖反應，相互依賴，耦合度高，某部分代碼不能被獨立地修改和理解，一定會牽涉到其餘代碼。

認知負擔

開發人員須要多長時間來理解功能模塊，從代碼中難以找到重要信息

不可知

開發人員在接到任務時，不知從哪裏入手，數據流向混亂。

複雜性的危害在於，它會遞增。你作錯了一個決定，致使後面的代碼都基於前面的錯誤實現，整個軟件變得愈來愈複雜。"咱們先把產品作出來，後面再改進"，這根本作不到。

如何下降複雜性

重視設計和細節的改進

拒絕戰術編程，採用戰略編程

戰術編程致力於完成任務，新增長特性或者修改Bug時，能解決問題就好。這種工做方式，會逐漸增長系統的複雜性。若是系統複雜到難以維護時，再去重構會花費大量的時間，極可能會影響新功能的迭代。

戰略編程，是指重視設計並願意投入時間，短期內可能會下降工做效率，可是長期看，會增長系統的可維護性和迭代效率。

設計兩次

爲何該方案可行？

架構圖、接口設計、時間人力估算

在已有資源限制下，爲何該方案是最優的？

在關鍵點或爭議處提供二到三種方案，並給出建議方案

水平分層，垂直分模塊

層次和抽象

複雜性下沉，儘可能讓用戶使用簡單，接口要簡單，實現能夠複雜。

深模塊：功能強大，接口簡單，是抽象的最佳實踐，經過排除模塊內部不重要的信息，讓用戶更容易理解和使用。

淺模塊：功能簡單，接口複雜，無助於解決複雜性。由於他們提供的收益（功能）被學習和使用成本抵消了。

好的 class 應該是"小接口，大功能"，糟糕的 class 是"大接口，小功能"。好的設計是，大量的功能隱藏在簡單接口之下，對用戶不可見，用戶感受不到這是一個複雜的 class。

異常處理

儘量減小須要處理異常的可能性

用戶必須面對全部的 error異常"反正我告訴你出錯了，怎麼解決是你的事。"，正確的作法是，除了那些必須告訴用戶的錯誤，其餘錯誤儘可能在軟件內部處理掉，不要拋出。

通用和專用

知足當前功能，快速實現，接口設計通用化

知足當前需求最簡單的接口是什麼？在不減小功能的前提下，減小方法的數量，意味着接口的通用性提高了。

接口的使用場景有多少？若是接口只有一個特定的場景，能夠將多個這樣的接口合併成通用接口。

知足當前需求狀況下，接口的易用性？若是接口很難使用，意味着咱們可能過分設計了，須要拆分。

註釋文檔

好比「好代碼是自注釋的」、」沒有時間「、「現有的註釋都沒有用，爲何還要浪費時間」等等。這些觀點是站不住腳的。「好代碼是自注釋的」只在某些場景下是合理的，好比爲變量和方法選擇合適的名稱，能夠不用單獨註釋。可是更多的狀況，代碼很難體現開發人員的設計思路。好的註釋能夠減小文檔工做。

使用註釋提高系統可維護性, 重視what、why，而不是how(而不是代碼是如何實現的)