《整洁架构》：软件设计原则与成功策略

需积分: 20 76 浏览量更新于2024-07-17 收藏 8.06MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

"《整洁架构：软件结构设计》是一本由知名软件开发专家Uncle Bob Martin撰写的专业书籍，它深入探讨了软件架构设计中的关键原则和实践。这本书不仅提供了一种清晰的视角，而且基于作者超过半个世纪的丰富经验，为软件架构师们提供了实际问题的解决方案，确保项目成功与否。在本书中，马丁强调了软件架构师的主要目标——实现业务需求并遵循核心设计纪律和实践。他指导读者掌握处理功能、组件分离和数据管理的基本软件设计原理，这些都是构建高质量系统的基础。他还揭示了编程范式如何通过限制开发者的行为来强制实施规范，帮助设计师理解哪些是至关重要的，哪些是细节层面的考虑。书中的内容涵盖了多种应用场景，如Web、数据库、厚客户端、控制台和嵌入式应用的高级结构设计。马丁着重于定义合理的边界和层次，以及如何组织组件和服务，使设计保持清晰和可维护。他还分析了常见的设计和架构问题，并提供了预防和修复这些问题的方法。此外，书中还特别提到了EPUB电子书格式，虽然它是行业标准，但在不同的阅读设备和应用上支持程度各异。读者可以根据自己的喜好调整字体、字号、单双列阅读模式，甚至图像大小。对于代码和配置示例，书中推荐在单列、横屏模式下查看，并保持最小字体大小以优化呈现。如果可流动文本格式影响了代码列表的清晰度，读者可以通过点击链接查看与印刷版一致的图片。《整洁架构：软件结构设计》是一本实用的指南，不仅提供了理论知识，还结合了实战经验和具体案例，帮助读者提升软件架构设计的能力，确保项目顺利进行并避免常见陷阱。无论是初学者还是经验丰富的架构师，这本书都是提升软件工程实践水平的重要参考资料。"

资源详情

资源推荐

of structures—but its variety eclipses the range of physical structure found in

buildings. You can even argue quite convincingly that there is more design activity

and focus in software than in building architecture—in this sense, it’s not

unreasonable to consider software architecture more architectural than building

architecture!

But physical scale is something humans understand and look for in the world.

Although appealing and visually obvious, the boxes on a PowerPoint diagram are not

a software system’s architecture. There’s no doubt they represent a particular view of

an architecture, but to mistake boxes for the big picture—for the architecture—is to

miss the big picture and the architecture: Software architecture doesn’t look like

anything. A particular visualization is a choice, not a given. It is a choice founded on

a further set of choices: what to include; what to exclude; what to emphasize by

shape or color; what to de-emphasize through uniformity or omission. There is

nothing natural or intrinsic about one view over another.

Although it might not make sense to talk about physics and physical scale in

software architecture, we do appreciate and care about certain physical constraints.

Processor speed and network bandwidth can deliver a harsh verdict on a system’s

performance. Memory and storage can limit the ambitions of any code base.

Software may be such stuff as dreams are made on, but it runs in the physical world.

This is the monstrosity in love, lady, that the will is infinite, and the execution confined;

that the desire is boundless, and the act a slave to limit.

—William Shakespeare

The physical world is where we and our companies and our economies live. This

gives us another calibration we can understand software architecture by, other less

physical forces and quantities through which we can talk and reason.

Architecture represents the significant design decisions that shape a system, where

significant is measured by cost of change.

—Grady Booch

Time, money, and effort give us a sense of scale to sort between the large and the

small, to distinguish the architectural stuff from the rest. This measure also tells us

how we can determine whether an architecture is good or not: Not only does a good

architecture meet the needs of its users, developers, and owners at a given point in

time, but it also meets them over time.

If you think good architecture is expensive, try bad architecture.

—Brian Foote and Joseph Yoder

The kinds of changes a system’s development typically experiences should not be

the changes that are costly, that are hard to make, that take managed projects of their

own rather than being folded into the daily and weekly flow of work.

That point leads us to a not-so-small physics-related problem: time travel. How do

we know what those typical changes will be so that we can shape those significant

decisions around them? How do we reduce future development effort and cost

without crystal balls and time machines?

Architecture is the decisions that you wish you could get right early in a project, but that

you are not necessarily more likely to get them right than any other.

—Ralph Johnson

Understanding the past is hard enough as it is; our grasp of the present is slippery at

best; predicting the future is nontrivial.

This is where the road forks many ways.

Down the darkest path comes the idea that strong and stable architecture comes from

authority and rigidity. If change is expensive, change is eliminated—its causes

subdued or headed off into a bureaucratic ditch. The architect’s mandate is total and

totalitarian, with the architecture becoming a dystopia for its developers and a

constant source of frustration for all.

Down another path comes a strong smell of speculative generality. A route filled

with hard-coded guesswork, countless parameters, tombs of dead code, and more

accidental complexity than you can shake a maintenance budget at.

The path we are most interested is the cleanest one. It recognizes the softness of

software and aims to preserve it as a first-class property of the system. It recognizes

that we operate with incomplete knowledge, but it also understands that, as humans,

operating with incomplete knowledge is something we do, something we’re good at.

It plays more to our strengths than to our weaknesses. We create things and we

discover things. We ask questions and we run experiments. A good architecture

comes from understanding it more as a journey than as a destination, more as an

ongoing process of enquiry than as a frozen artifact.

Architecture is a hypothesis, that needs to be proven by implementation and measurement.

—Tom Gilb

To walk this path requires care and attention, thought and observation, practice and

principle. This might at first sound slow, but it’s all in the way that you walk.

hardware over the same half-century. I started programming on machines the size of

kitchen refrigerators that had half-megahertz cycle times, 4K of core memory, 32K

of disk memory, and a 10 character per second teletype interface. I am writing this

preface on a bus while touring in South Africa. I am using a MacBook with four i7

cores running at 2.8 gigahertz each. It has 16 gigabytes of RAM, a terabyte of SSD,

and a 2880×1800 retina display capable of showing extremely high-definition video.

The difference in computational power is staggering. Any reasonable analysis will

show that this MacBook is at least 10

more powerful than those early computers

that I started using half a century ago.

Twenty-two orders of magnitude is a very large number. It is the number of

angstroms from Earth to Alpha-Centuri. It is the number of electrons in the change in

your pocket or purse. And yet that number—that number at least—is the

computational power increase that I have experienced in my own lifetime.

And with all that vast change in computational power, what has been the effect on

the software I write? It’s gotten bigger certainly. I used to think 2000 lines was a big

program. After all, it was a full box of cards that weighed 10 pounds. Now, however,

a program isn’t really big until it exceeds 100,000 lines.

The software has also gotten much more performant. We can do things today that we

could scarcely dream about in the 1960s. The Forbin Project, The Moon Is a Harsh

Mistress, and 2001: A Space Odyssey all tried to imagine our current future, but

missed the mark rather significantly. They all imagined huge machines that gained

sentience. What we have instead are impossibly small machines that are still … just

machines.{xx}

And there is one thing more about the software we have now, compared to the

software from back then: It’s made of the same stuff. It’s made of if statements,

assignment statements, and while loops.

Oh, you might object and say that we’ve got much better languages and superior

paradigms. After all, we program in Java, or C#, or Ruby, and we use object-oriented

design. True—and yet the code is still just an assemblage of sequence, selection, and

iteration, just as it was back in the 1960s and 1950s.

When you really look closely at the practice of programming computers, you realize

that very little has changed in 50 years. The languages have gotten a little better. The

tools have gotten fantastically better. But the basic building blocks of a computer

program have not changed.

剩余428页未读，继续阅读

dywane333

粉丝: 0
资源: 2

《整洁架构》：软件设计原则与成功策略

《架构整洁之道》读书笔记.pdf

关于软件架构的一些书籍

整洁架构和SpringMVC架构好像没什么不同啊

架构整洁之道.pdf

设计 口碑 品牌 风格 价格 售后 质量 明星代言 广告宣传 优惠活动 1 2 3 4 5 4 3 2 1 2转换为店面设计:4|汉服陈列:4|风格搭配:2|汉服价格:5|店面整洁度:3|促销活动:2

怎么用用Python把“设计 口碑 品牌 风格 价格 售后 质量 明星代言 广告宣传 优惠活动 1 2 3 4 5 4 3 2 1 2”转换为店面设计:4|汉服陈列:4|风格搭配:2|汉服价格:5|店面整洁度:3|促销活动:2

如何提升自己的架构能力

购物网站的网页总体设计

python美化软件界面设计

请阐逑AD绘制流程并说明需要注意的细节

可载入程序的设计要素与实例的分析与研究的网络参考资料

利用JavaWeb设计一个旅游宣传网页

轴系结构设计实验中的注意事项

q版聊天软件的设计mfc

基于stm32的扫地机器人设计

室内设计家装的设计流程和施工流程

linux规范目录结构的好处

环境保护html网页设计

PPT组织架构如何画

最新资源

设计口碑品牌风格价格售后质量明星代言广告宣传优惠活动 1 2 3 4 5 4 3 2 1 2转换为店面设计:4|汉服陈列:4|风格搭配:2|汉服价格:5|店面整洁度:3|促销活动:2

怎么用用Python把“设计口碑品牌风格价格售后质量明星代言广告宣传优惠活动 1 2 3 4 5 4 3 2 1 2”转换为店面设计:4|汉服陈列:4|风格搭配:2|汉服价格:5|店面整洁度:3|促销活动:2