共计 7811 个字符，预计需要花费 20 分钟才能阅读完成。
Writing computer software is one of the purest creative activities in the history of the human race. Programmers aren’t bound by practical limitations such as the laws of physics; we can create exciting virtual worlds with behaviors that could never exist in the real world. Programming doesn’t require great physical skill or coordination, like ballet or basketball. All programming requires is a creative mind and the ability to organize your thoughts. If you can visualize a system, you can probably implement it in a computer program.
编写计算器软件，是人类历史上最纯净的创造性流动之一。程序员不会被事实中的条条框框所解放（比方物理法令），咱们能够发明振奋人心的、超脱于事实的虚拟世界。编程不须要相似于芭蕾舞或者篮球运动那样非凡的身材技巧或者群体配合，只须要充斥创造力的思维和组织想法的能力。如果你能让一个零碎可视化，那大略也能用程序去实现它。
This means that the greatest limitation in writing software is our ability to understand the systems we are creating. As a program evolves and acquires more features, it becomes complicated, with subtle dependencies between its components. Over time, complexity accumulates, and it becomes harder and harder for programmers to keep all of the relevant factors in their minds as they modify the system. This slows down development and leads to bugs, which slow development even more and add to its cost. Complexity increases inevitably over the life of any program. The larger the program, and the more people that work on it, the more difficult it is to manage complexity.
这意味着，编写程序最大的限度，就是了解以后发明中的零碎的能力。当程序进化并取得更多的个性，它就变得复杂，与它的组件之间放弃着奥妙的相互依赖。随着时间推移，复杂度积攒，在须要调整零碎的时候，要让程序员记住这些相干因素就会越来越难。这样就让开发变得迟缓，并产生更多的 BUG，这些 BUG 又回减慢开发，恶性循环让开发成本减少。任何程序的开发周期中，复杂度都是逐步减少的。越大的程序，须要越多人开发，管制复杂度也就越难。
Good development tools can help us deal with complexity, and many great tools have been created over the last several decades. But there is a limit to what we can do with tools alone. If we want to make it easier to write software, so that we can build more powerful systems more cheaply, we must find ways to make software simpler. Complexity will still increase over time, in spite of our best efforts, but simpler designs allow us to build larger and more powerful systems before complexity becomes overwhelming.
好的开发工具能帮咱们管制复杂度，近十年来也诞生了不少这样的好工具。然而光靠这些工具，能做到事件也是无限的。如果想要让软件开发变得简略，从而让开发弱小的零碎变得不便，那么咱们就必须让软件开发变得简略。复杂度仍在一劳永逸，只管咱们曾经尽力去把控了。更简略的设计，能让咱们建造更大更强的零碎。
There are two general approaches to fighting complexity, both of which will be discussed in this book. The first approach is to eliminate complexity by making code simpler and more obvious. For example, complexity can be reduced by eliminating special cases or using identifiers in a consistent fashion.
反抗复杂度有两种广泛办法，书上都会介绍到。第一种，是让代码更简略更通俗，比方缩小非凡状况，或者在统一的代码格调中应用标识。
The second approach to complexity is to encapsulate it, so that programmers can work on a system without being exposed to all of its complexity at once. This approach is called modular design. In modular design, a software system is divided up into modules, such as classes in an object-oriented language. The modules are designed to be relatively independent of each other, so that a programmer can work on one module without having to understand the details of other modules.
第二种就是封装，这种形式让程序员开发时候不用一下子就看到那些简单的内容。这种办法叫做模块化设计，把软件系统分成多个模块，在面向对象的语言中能够是类的模式。模块被设计成相互之间绝对独立，这样开发一个模块就不须要去了解其余模块的细节了。
Because software is so malleable, software design is a continuous process that spans the entire lifecycle of a software system; this makes software design different from the design of physical systems such as buildings, ships, or bridges. However, software design has not always been viewed this way. For much of the history of programming, design was concentrated at the beginning of a project, as it is in other engineering disciplines. The extreme of this approach is called the waterfall model, in which a project is divided into discrete phases such as requirements definition, design, coding, testing, and maintenance. In the waterfall model, each phase completes before the next phase starts; in many cases different people are responsible for each phase. The entire system is designed at once, during the design phase. The design is frozen at the end of this phase, and the role of the subsequent phases is to flesh out and implement that design.
因为软件过于具备延展性，所以软件设计是一个持续性的过程，它跨域了软件系统的整个生命周期。这让软件开发有别于事实零碎的设计，比方大楼、船只和桥梁这一类。然而，软件设计并不是一开始就以这样的观点所意识，从编程的历史来看，设计的工作更多地是在我的项目开发的初始阶段集中进行，就像其它的工程学科那样。这种形式的极其做法，叫做瀑布流模型，它把一个我的项目划分成多个阶段，比方需要评审、设计、开发、测试和保护。瀑布流模型之下，一个阶段实现另一个阶段能力开始，很多状况下不同的人负责不同的阶段。整个零碎一次过设计成型，设计在它的阶段完结时就被固定下来了，后续的阶段就是结构并空虚设计。
Unfortunately, the waterfall model rarely works well for software. Software systems are intrinsically more complex than physical systems; it isn’t possible to visualize the design for a large software system well enough to understand all of its implications before building anything. As a result, the initial design will have many problems. The problems do not become apparent until implementation is well underway. However, the waterfall model is not structured to accommodate major design changes at this point (for example, the designers may have moved on to other projects). Thus, developers try to patch around the problems without changing the overall design. This results in an explosion of complexity.
可怜的是，瀑布模型少有好的体现。软件系统实际上比物理零碎更简单。想要让大型软件系统充沛地可视化，而后在构建之前就要充沛地了解它的含意，是不可能的。后果就是，初版设计呈现很多问题。因为直到需要被充沛实现之前，问题都不会浮现。然而，在这个节骨眼上就会发现，瀑布流模型就不是被设计成可能包容大型的整改的模式（比方设计者这时就曾经被指派到了其它我的项目中）。所以，开发者就要千方百计在不改变整体设计的状况下，对产生的问题修修补补，最终就会迎来复杂度大暴发。
Because of these issues, most software development projects today use an incremental approach such as agile development, in which the initial design focuses on a small subset of the overall functionality. This subset is designed, implemented, and then evaluated. Problems with the original design are discovered and corrected, then a few more features are designed, implemented and evaluated. Each iteration exposes problems with the existing design, which are fixed before the next set of features is designed. By spreading out the design in this way, problems with the initial design can be fixed while the system is still small; later features benefit from experience gained during the implementation of earlier features, so they have fewer problems.
基于以上种种问题，明天的大多数软件开发我的项目都是用渐进式形式，比方麻利开发，初始设计只关注于全副性能的一小部分。这部分子集会被设计、实现，而后评估，初版的问题就会被发现并整改，之后更多的小子集的性能也会被设计、实现再评估。每次迭代都能发现现有设计的问题，就能把它们在下一部分功能设计之前毁灭掉。用这种扩散式设计方案，初版问题在零碎还小的时候就被修复了。前面的性能在实现的时候，后面的修复就能成为教训，所以能比上一阶段呈现更少的问题。
The incremental approach works for software because software is malleable enough to allow significant design changes partway through implementation. In contrast, major design changes are much more challenging for physical systems: for example, it would not be practical to change the number of towers supporting a bridge in the middle of construction.
渐进式开发的无效，是因为软件变得有足够的韧性，从而能在实现的过程中对设计进行大型调整。比照之下，大型设计整改对于物理零碎来说就是困难重重的，比方说，想要在构建桥梁的过程中批改承重的柱子的数量，是不切实际的。
Incremental development means that software design is never done. Design happens continuously over the life of a system: developers should always be thinking about design issues. Incremental development also means continuous redesign. The initial design for a system or component is almost never the best one; experience inevitably shows better ways to do things. As a software developer, you should always be on the lookout for opportunities to improve the design of the system you are working on, and you should plan on spending some fraction of your time on design improvements.
渐进式开发意味着软件设计是永不平息的。在零碎的生命周期中，设计就是间断进行的：开发者须要始终思考设计问题。渐进式开发同时意味着继续的从新设计，初版设计的组件对于零碎来说永远都不是最好的一版，不可避免地，教训会通知你更好的实现形式。作为开发者，必须始终留心，一有机会就改良手头上的设计，还要打算有空就改良一下设计。
If software developers should always be thinking about design issues, and reducing complexity is the most important element of software design, then software developers should always be thinking about complexity. This book is about how to use complexity to guide the design of software throughout its lifetime.
如果软件开发者能始终思考设计问题，并认为缩小复杂度是软件开发的第一要领，那么复杂度就是他们常常要思考的因素。本书就是对于用复杂度，去指引软件设计的生命周期中，设计该当如何走向。
This book has two overall goals. The first is to describe the nature of software complexity: what does“complexity”mean, why does it matter, and how can you recognize when a program has unnecessary complexity? The book’s second, and more challenging, goal is to present techniques you can use during the software development process to minimize complexity. Unfortunately, there isn’t a simple recipe that will guarantee great software designs. Instead, I will present a collection of higher-level concepts that border on the philosophical, such as“classes should be deep”or“define errors out of existence.”These concepts may not immediately identify the best design, but you can use them to compare design alternatives and guide your exploration of the design space.
本书有两个次要目标。第一，是论述软件复杂度的性质：什么是复杂度，为什么它是要害，还有怎样才能看出程序有多余的复杂度。第二，也是更难的一点，软件开发过程中能应用并让复杂度最小化的技巧。可怜的是，没有简略易懂的配方能保障大型软件设计进去。取而代之的是，我会提供一系列靠近于哲学的高阶理念，比方“类须要深度”或者“从未存在中定义出问题”。这些理念兴许不能马上甄别出最优设计，然而如果用它们比照你的候选设计方案，能够指引你摸索对于设计的浩瀚大海。
