評估設計時，您如何評估複雜性？

Question

我們都知道保持簡單吧？

我已經看到複雜性被測量爲系統之間交互的數量，我想這是一個非常好的開始。除了直覺之外，還可以使用哪些其他（最好是更客觀的）方法來確定特定設計或軟件的複雜程度？

你最喜歡的規則或啓發式是什麼？

Answer 1

如果您的應用程序已構建，您可以根據時間（特定任務需要執行多長時間）或計算（每次運行任務時執行多少代碼）來測量它。

如果您只是有設計，那麼您可以查看您的設計需要多少組件來運行給定的任務，或運行一項平均任務。例如，如果您使用MVC作爲您的設計模式，那麼在大多數任務中您至少會觸及3個組件，但根據您對設計的實施情況，最終可能會有數十個組件（緩存除了例如3層）。

Answer 2

這裏是我的：

1）有多難解釋的人誰明白這個問題，但一直沒有想過的解決方案嗎？如果我向大廳裏的某個人解釋問題（如果他們在大廳裏，他們可能已經瞭解了問題），並且可以解釋解決方案，那麼它不是太複雜。如果花費了一個多小時，那麼解決方案的過度工程就有可能是好的。

2）你必須去多大的嵌套功能？如果我有一個對象需要一個由另一個對象持有的對象持有的屬性，那麼我試圖做的事情很可能會離對象本身太遠。在嘗試使對象成爲線程安全的時候，這些情況會變得有問題，因爲從當前位置開始會有許多不同深度的對象被鎖定。

3）你是否試圖解決之前已經解決的問題？並非所有問題都是新的（有些人會認爲沒有任何問題）。有可用的現有模式或模式組嗎？如果你不能，爲什麼不呢？製作你自己的新解決方案是很好的，我完全贊成，但有時候人們已經回答了這個問題。我不會重寫STL（儘管我曾嘗試過），因爲解決方案已經存在並且是一個很好的解決方案。

Answer 3

當我參加新英格蘭複雜系統研究所的複雜系統建模研討會（http://necsi.org/）時，他們使用的其中一個度量是系統狀態的數量。

例如，如果你有兩個節點，它們相互作用，A和B，並且每個這些可以是0或1，你可能的狀態是：

A B 
0 0 
1 0 
0 1 
1 1 

因此，只有1二進制之間相互作用的一個系統組件實際上可能會導致4種不同的狀態。關鍵在於系統的複雜性不一定隨着交互次數的增加而線性增加。

Answer 4

複雜性可以用聯軸器和凝聚力是所有對象來估計。如果某些東西有太多的耦合或者不夠緊密，那麼設計就會變得更加複雜。

Answer 5

好的措施也可以是文件數量，配置存儲的位置數量，某些語言的編譯順序。

例子：

.-屬性文件，數據庫配置，XML文件來保存相關信息。

.-數萬個教學班，接口和數據庫映射

.-一個極其漫長而複雜的構建文件（build.xml文件，Makefile文件，其他..

Answer 6

有正式的指標。閱讀上了Cyclomatic Complexity，例如。

---

編輯。

而且，看Function Points。他們給你一個系統複雜性的非直覺量化測量。

Answer 7

最後LOC可以幫助您測量什麼？ :)

我認爲複雜性最好看作是需要互動的事物的數量。

一個複雜的設計會有n層，而一個簡單的設計只有兩層。

複雜性是需要解決簡單無法克服的問題，因此它不總是會成爲問題。

由於複雜性通常具有與其相關聯的任務，因此在定義複雜性時存在一個問題。 有些東西可能很難理解，但看起來很簡單（例如非常簡潔的代碼） 從服務器到您的計算機獲取此網頁的交互次數非常複雜，但http協議的抽象非常簡單。

因此，在選擇一個度量之前記住一項任務（例如維護）可能會使它更有用。 （即添加配置文件並記錄到應用程序會增加其客觀複雜性[是的，只有一點點確定]，但簡化了維護）。