【翻译】软件设计的哲学-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.

读者会比做者更容易看到复杂性。若是你写的一段代码，对你来讲很简单，可是其余人以为复杂，那么它就是复杂的。若是你发现你是这种状况，去找其余开发者探寻一下为何以为你的代码会复杂，是颇有益处的。极可能会有一些有趣的值得学习的教训，在你和他们的意见分歧之中。做为开发者，你的工做不只仅是写只有本身以为简单使用的的代码，还要创造让其余人也能简单合做的代码。