A Philosophy of Software Design

两个目的：

• making code simpler and more obvious
• encapsulate it. Modular design.

Complexity：Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system. If you write a piece of code and it seems simple to you, but other people think it is complex, then it is complex.

• Symptom of complexity
  1. Change amplification:One of the goals of good design is to reduce the amount of code that is affected by each design decision, so design changes don’t require very many code modifications. 封装和解耦。
  2. Cognitive load: A higher cognitive load means that developers have to spend more time learning the required information, and there is a greater risk of bugs because they have missed something important. Sometimes an approach that requires more lines of code is actually simpler, because it reduces cognitive load. 解决问题的前提是尽量避免引入新的问题。
  3. Unknown unknowns: the worst. 反向来看，能把问题表达清晰是一种能力。

• Causes of complexity
  1. dependencies
  2. obscurity：为变量命名号称第一大难题。

• Conclusion：勿以恶小而为之，勿以善小而不为。

Working code isn’t enough.Your most important job as a developer is to facilitate those future extensions. 脑中想的不是完成当前的工作，而应该是它是一个好的设计。This is strategic programming，not tactical programming.

• Strategic programming => investment mind. When you discover a design problem, don’t just ignore it or patch around it; take a little extra time to fix it.
• How much to invest: take 10-20% longer
• Conclusion: Good design doesn’t come for free. 解决问题越早越好。

Moudules Should Be Deep

• An interface: The interface consists of everything that a developer working in a different module must know in order to use the given module.
  1. The formal interface for a class consists of the signatures for all of its public methods, plus the names and types of any public variables.
  2. The informal parts of an interface includes its high-level behavior，such as the fact that a function deletes the file named by one of its arguments.

• An implementation: The implementation consists of the code that carries out the promises made by the interface.
• The more unimportant details that are omitted from an abstraction, the better.
• Module depth is a way of thinking about cost versus benefit. The benefit provided by a module is its functionality. The cost of a module is its interface.
• Conclusion: 用户看到的越少，需要理解的概念越少越好。但是开发者要了解，明白，清晰每一处设计。

Information Hiding (and Leakage)Reducing complexity in two ways.

1. It simplifies the interface to a module.
2. Information hiding makes it easier to evolve the system. Hiding variables and methods in a class by declaring them private isn’t the same thing as information hiding. 私有变量可以通过公有方法的getter和setter来进行修改读取。
3. Information leakage occurs when the same knowledge is used in multiple places, such as two different classes that both understand the format of a particular type of file.
4. Conclusion: When design modules, focus on the knowledge that’s needed to perform each task, not the order in which tasks occur.

我之前一直不理解为什么返回的数据格式是自付出而不是parse好的其他类型，比如array或者object，现在看起来可能原因是在数据处理过程中，防止将原数据改掉而做的trick，然后直接返回了。可是，仍然觉的这样的行为不友好。感觉只处理了一半。 General-Purpose Modules are DeeperOne of the most common decisions that you will face when designing a new module is whether to implement it in a general-purpose or special-purpose fashion.

1. What is the simplest interface that will cover all my current needs?
2. In how many situations will this method be used?
3. Is this API easy to use for my current needs?

Different Layer, Different Abstraction

1. Pass-through methods 不应该存在。They are bad because they contribute no new functionality.
2. When is interface duplication OK? Dispatcher
3. Global variable create other problems.

Pull Complexity DownwardsIt is more important for a module to have a simple interface than a simple implementation. 谨慎暴露配置参数，再三问自己用户真的需要知道决定这个变量么？ Better Together Or Better ApartOne of the most fundamental questions in software design is this: given two pieces of functionality, should they be implemented together in the same place, or should their implementations be separated?

1. Some complexity comes just from the number of components
2. Subdivision can result in additional code to manage the components
3. Subdivision creates separation
4. Subdivision can result in duplication
5. They share information
6. They are used together
7. They overlap conceptually
8. It is hard to understand one of the pieces of code without looking at the other.

So:

1. Bring together if information is shared
2. Bring together if it will simplify the interface
3. Bring together to eliminate duplication
4. Separate general-purpose and special-purpose code
5. 耦合性重的要在一起，可复用的要分开。Each method should do one thing and do it completely.

Define Errors Out of ExistenceA particular piece of code may encounter exceptions in several different ways. 不可逆操作之前尽量做一步挽回操作预留。Overall, the best way to reduce bugs is to make software simpler.

1. Mask exceptions
2. Exception aggregation: As a result, bugs in recovery are more likely to be discovered and fixed. One way of thinking about exception aggregation is that it replaces several special-purpose mechanisms, each tailored for a particular situation, with a single general-purpose mechanism that can handle multiple situations.
3. Just Crush 不是所有问题都要被解决。重启大法好。You must determine what is important and what is not important.

Design it TwiceNo one is good enough to get it right with their first try. Why Write Comments? The Four Excuses， Write The Comments FirstThe process of writing comments, if done correctly, will actually improve a system’s design.

1. Good code is self-documenting. Wrong.
2. I don’t have time to write comments. Wrong
3. Comments get out of date and become misleading
4. All the comments I have seen are worthless
5. Benefits of well-written comments: The overall idea behind comments is to capture information that was in the mind of the designer but couldn’t be represented in the code.

Comments Should Describe Things that Aren’t Obvious from the codeDevelopers should be able to understand the abstraction provided by a module without reading any code other than its externally visible declarations.

1. Pick conventions
2. Don’t repeat the code
3. Lower-level comments add precision
4. Higher-level comments enhance intuition
5. Interface documentation
6. Implementation comments: what and why, not how
7. Cross-module design decisions

代码不是写给自己看的，是写给别人看的。talk is cheep, show me the code. Choosing Names好的命名已经是设计成功的一半。 Modifying Existing Code Ideally, when you have finished with each change, the system will have the structure it would have finished with each change, the system will have the structure it would have had if you had designed it from the start with that change in mind. If you are not making the design better, you are probably making it worse.把注释写到代码处。 写单元测试

写单元测试

写单元测试

Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system