《Code Simplicity》：打造简洁软件的普遍原则

需积分: 10 126 浏览量更新于2024-07-20 收藏 5.86MB PDF 举报

"Code Simplicity" 是一本由 Max Kanat-Alexander 撰写的书籍，由 O'Reilly Media, Inc. 出版。这本书主要探讨了如何编写简洁、易于维护的代码，并阐述了软件开发的基本原则，适用于各种编程语言和项目。书中通过实例分析了软件随时间演变的过程，旨在帮助程序员和非技术经理理解如何制定合理的软件项目计划，以及如何做出对系统模式和结构的明智决策。在《Code Simplicity》中，作者提出了一些核心知识点： 1. **优秀程序员与普通程序员的区别**：优秀的程序员不仅能够编写出工作正常的代码，还能确保代码的简洁性和可维护性，他们理解软件设计的最终目标，能够预见未来可能的变化并为此做好准备。 2. **软件的终极目的与良好设计的目标**：软件的目的是解决特定问题，良好的设计应考虑易用性、可扩展性和可维护性，以适应未来的修改和升级。 3. **决策的价值评估**：书中教导读者如何评估当前决策对未来的影响，强调长期视角在软件开发中的重要性。 4. **系统演进的实例分析**：通过实际案例，展示了一个系统如何随着时间推移而变化，揭示了如何设计允许系统适应环境变化而自身改动最小的架构。 5. **以简化代码应对未来变化**：保持代码简洁是为了将来能更容易地进行修改和扩展，现在做的每个决定都会影响到未来的维护成本。 6. **测试的重要性**：书中强调了编写测试的原因和测试的类型，测试不仅是验证代码功能，更是保证软件质量的重要手段。此外，书中还涉及到编辑、生产编辑、封面设计、内页设计等方面的信息，这些是书籍出版过程中的关键环节。不过，这些细节与主题“Code Simplicity”关联较小，主要关注的是软件开发的核心原则和实践方法。《Code Simplicity》是一本关于软件开发哲学和实践策略的指南，对于提升代码质量、优化软件设计有着深远的指导意义。

CHAPTER 2

The Missing Science

This book is mostly about something called “software design.” Perhaps you’ve heard

this term before, and maybe you’ve even read some books about it. But let’s look at it

freshly, with new, precise definitions.

We know what software is. So what we really have to define is the word “design”:

verb

1. To make a plan for a creation. Example: The engineer will

design a bridge this

month and build it next month.

noun

1. A plan that has been made for a creation that hasn’t been built yet. Example:

The engineer came up with a design for a bridge; he will build it next month.

2. The plan that an existing creation follows. Example: That bridge over there

follows a good design.

All of those definitions apply when we talk about software design:

• When we are “designing software” (“design” as a verb), we are planning it out.

There are lots of things to plan about software—the structure of the code, what

technologies we’re going to use, etc. There are many technical decisions to make.

Often, we just make these decisions in our minds, but sometimes we also write

down our plans or draw some diagrams.

• Once we’ve done this, the result is a “software design” (“design” as the first noun

definition). This is the plan that we made. Once again, this might be a written

document, but it could also just be a bunch of decisions that we’ve made that we

are now holding in our minds.

• Code that already exists also has “a design,” (“design” as the second noun defini-

tion), which is the structure that it has or the plan that it seems to follow. Some

code may seem to have no clear structure at all—that code has “no design,” mean-

ing that there was no definite plan made by the original programmer. In between

“no design” and “a design” there are also infinite shades of gray, such as “a partial

design,” “several conflicting designs in one piece of code,” “an almost-complete

design,” etc. There can also be actively bad designs that are worse than no design.

For example, imagine coming across some code that had been intentionally made

disorganized or complex—that would be code with an actively bad design.

The science of software design is a science for making plans and decisions about soft-

ware. It helps people make decisions like:

• What should the structure of our program code be?

• Is it more important to focus on having a fast program or a program whose code

is easy to read?

• For our needs, which programming language should we use?

Software design does not cover subjects like:

• What should the structure of the company be?

• When should we have team meetings?

• What times of the day should programmers work?

• How should we measure the performance of our programmers?

Those aren’t decisions about your software, they’re decisions about you or your orga-

nization. It’s certainly important to make those decisions properly—many software

projects have failed because they had poor management. But that is not the focus of

this book. This book is about how to make the correct technical decisions about your

software.

Anything that involves the architecture of your software system or the tech-

nical decisions you make while creating the system falls under the category

of “software design.”

Every Programmer Is a Designer

Every programmer working on a software project is involved in design. The lead de-

veloper is in charge of designing the overall architecture of the entire program. The

senior programmers are in charge of designing their own large areas. And the junior

programmers are in charge of designing their parts of the program, even if they’re as

simple as one part of one file. There is even a certain amount of design involved in

writing a single line of code.

Even when you are programming all by yourself, there is still a design process that goes

on. Sometimes you make a decision immediately before your fingers hit the keyboard,

and that’s the whole process. Sometimes you think about how you’re going to write

the program when you’re in bed at night.

6 | Chapter 2: The Missing Science

Everybody who writes software is a designer. Every single person on a software team is

responsible for making sure that their own code is well designed. Nobody who is writing

code for a software project can ignore software design, at any level.

However, this does not mean that design is a democracy. You must not design by com-

mittee—the result will be an actively bad design. Instead, all developers should have

the authority to make good design decisions in their own areas. If they make poor or

mediocre decisions, these should be overridden by a senior developer or the lead pro-

grammer, who should have veto power over the designers below them.

But otherwise,

responsibility for the design of code should rest with the people who are actually

working on it.

A designer should always be willing to listen to suggestions and feedback, because

programmers are usually smart people who have good ideas. But after considering all

the data, any given decision must be made by an individual, not by a group of people.

The Science of Software Design

Software design, as it is practiced in the world today, is not a science. What is a science?

The dictionary definition is a bit complex, but basically, in order for a subject to be a

science it has to pass certain tests:

• A science must contain knowledge that has been collected. That is, it has to be

composed of facts—not opinions—and these facts must have been put together

somewhere (like in a book).

• This knowledge must have some sort of organization. It has to be put into cate-

gories, the various pieces have to be correctly related to each other in terms of

importance, etc.

• A science must contain general truths or basic laws.

• A science must tell you how to do something in the physical universe. It must be

somehow applicable in work or in life.

• Usually, a science is discovered and proven through the scientific method, which

involves observation of the physical universe, making a theory about how the uni-

verse works, performing experiments to verify your theory, and showing that the

same experiment works everywhere to demonstrate that the theory is a general

truth and not just a coincidence or something that worked just for you.

1. If you are the one overriding a decision, attempt to educate the other programmer when you do it. Show

how or why your decision is better than hers. If you do this, over time you will have to override that

programmer less and less. Some programmers never learn, though—if after several months or years of

such education a programmer continues to make numerous bad decisions, he should be removed from

your team. However, most programmers are very clever people who pick things up rapidly, so this is

rarely a concern.

The Science of Software Design | 7

In the world of software, we have lots of knowledge; it’s been collected in books, and

it has even been somewhat organized. However, out of all the pieces required to make

a science, we are missing the most important part: clearly stated laws—unshakeable

truths that will never fail us.

Experienced software developers know what the right thing to do is, but why is that

the right thing? What makes some decisions right and some decisions wrong?

What are the fundamental laws of software design?

This book is the record of their discovery. It lays out a set of definitions, facts, rules,

and laws for software development, mostly focused on software design. What’s the

difference between a fact, a rule, a definition, and a law?

• Definitions tell you what something is and how you would use it.

• Facts are just true statements about something. Any true piece of information is a

fact.

• Rules are statements that give you true advice, cover something specific, and help

guide decisions, but do not necessarily help you predict what will happen in the

future or figure out other truths. They usually tell you whether or not to take some

action.

• Laws are facts that will always be true, and that cover a broad area of knowledge.

They help you figure out other important truths and allow you to predict what will

happen in the future.

Out of all of these, the laws are the most important. In this book, you will know that

something is a law because the text will explicitly say so. If you aren’t sure what category

some piece of information falls into, Appendix B lists every major piece of information

in the book and labels it clearly as a law, a rule, a definition, or just a plain-old fact.

When you read some of these definitions, laws, rules, or facts, you may say to yourself,

“That was obvious, I already knew that.” That’s actually quite expected—if you’ve

been around the world of software development for a long time, you’ve possibly run

into some of these ideas before. However, when you have this reaction, ask yourself:

• Did I know that particular piece of data was proveably true?

• Did I know how important it was?

• Could I have communicated it clearly to another person, so that he fully understood

it?

• Did I understand how it related to other data in the field of software development?

If you can say “yes” to some of those questions when you would previously have said

“no” or “maybe,” then you have gained a specific sort of understanding, and that un-

derstanding is a huge part of what differentiates a science from a mere collection of

ideas.

8 | Chapter 2: The Missing Science

剩余89页未读，继续阅读

vanridin

粉丝: 108
资源: 1187

《Code Simplicity》：打造简洁软件的普遍原则

grokking-simplicity-code

simplicity-backend:简单后端

simplicity studio v5 zigbee

Simplicity Studio 如何编写代码

simplicity studio v4下载

simplicity studio安装教程

simplicity studio教程

Simplicity Studio 打开别人的工程

simplicity studio v4安装教程

最新资源