【翻譯】軟件設計的哲學-2-1 複雜性的定義

For the purposes of this book, I define 「complexity」 in a practical way. Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system. Complexity can take many forms. For example, it might be hard to understand how a piece of code works; it might take a lot of effort to implement a small improvement, or it might not be clear which parts of the system must be modified to make the improvement; it might be difficult to fix one bug without introducing another. If a software system is hard to understand and modify, then it is complicated; if it is easy to understand and modify, then it is simple.

就本書而言，我以特定的方式定義了「複雜性」，就是任何關於系統結構的，會讓它變得難以理解和調整的因素。複雜性能夠表現成多種形式。好比，也許是很難理解一塊代碼是怎樣工做的；也許是要大量工做才能作到一點點的改進；也許是沒法清晰地看出調整系統的哪一個部分才能改進；也許是要改一個 BUG 很難不引起其它 BUG。若是軟件系統很難理解和修改，那麼它就是複雜的；反之則是簡單的。

You can also think of complexity in terms of cost and benefit. In a complex system, it takes a lot of work to implement even small improvements. In a simple system, larger improvements can be implemented with less effort.

你也能夠把複雜性當作代價和收益。複雜系統裏，甚至要大量的工做才能實現一些小的改進。簡單系統裏，相比之下用更小的工做量，能夠得到更大的改進。

Complexity is what a developer experiences at a particular point in time when trying to achieve a particular goal. It doesn’t necessarily relate to the overall size or functionality of the system. People often use the word 「complex」 to describe large systems with sophisticated features, but if such a system is easy to work on, then, for the purposes of this book, it is not complex. Of course, almost all large and sophisticated software systems are in fact hard to work on, so they also meet my definition of complexity, but this need not necessarily be the case. It is also possible for a small and unsophisticated system to be quite complex.

複雜性是一個開發者想要達到特定目標時，在特定時間點所要經歷的事物。它不必定與系統的總體大小或者功能相關。人們經常使用「複雜」去描述帶有複雜功能的系統，可是若是這樣一個系統容易被開發，那麼就本書而言，它就不是複雜的。固然，幾乎全部的大型且複雜的軟件系統，其實是很難開發的，因此它們會體如今我對複雜性的定義上，可是也不必定是這種狀況。一個小型且功能不復雜的系統也能夠是很是複雜的。

Complexity is determined by the activities that are most common. If a system has a few parts that are very complicated, but those parts almost never need to be touched, then they don’t have much impact on the overall complexity of the system. To characterize this in a crude mathematical way:

複雜性取決於最多見的活動。若是一個系統只有一小部分構成是很是複雜的，可是這些部分幾乎歷來不用被碰到，那麼它們就不會對系統的總體複雜性有多大的影響。咱們用這個粗糙的數學公式來量化它：

The overall complexity of a system (C) is determined by the complexity of each part p (cp) weighted by the fraction of time developers spend working on that part (tp). Isolating complexity in a place where it will never be seen is almost as good as eliminating the complexity entirely.

系統的總體複雜性（C）取決於，每一個部分的複雜性（cp）加權於開發者用於開發的時間（tp）。隔離複雜性到一個不再會被看到的地方，幾乎跟消滅總體的複雜性同樣有效。

Complexity is more apparent to readers than writers. If you write a piece of code and it seems simple to you, but other people think it is complex, then it is complex. When you find yourself in situations like this, it’s worth probing the other developers to find out why the code seems complex to them; there are probably some interesting lessons to learn from the disconnect between your opinion and theirs. Your job as a developer is not just to create code that you can work with easily, but to create code that others can also work with easily.

讀者會比做者更容易看到複雜性。若是你寫的一段代碼，對你來講很簡單，可是其餘人以爲複雜，那麼它就是複雜的。若是你發現你是這種狀況，去找其餘開發者探尋一下爲何以爲你的代碼會複雜，是頗有益處的。極可能會有一些有趣的值得學習的教訓，在你和他們的意見分歧之中。做爲開發者，你的工做不只僅是寫只有本身以爲簡單使用的的代碼，還要創造讓其餘人也能簡單合做的代碼。