《ReleaseIt!》：打造生产级软件的实战指南

需积分: 9 177 浏览量更新于2024-07-18 1 收藏 4.59MB PDF 举报

《ReleaseIt! 设计与部署生产就绪软件》是一本由 Michael T. Nygard 所著的专业书籍，专为软件工程领域提供深入洞察。该书聚焦于敏捷开发的核心原则，特别是如何确保每次迭代都能交付真正可投入生产的代码，这对于现代关键系统来说具有重要意义。作者在书中详尽阐述了将敏捷理念应用于实际生产环境中的实践策略，强调了在快速迭代过程中如何保持软件质量、减少风险并提高可靠性。读者Tom Poppendieck高度评价这本书，认为它不仅对于采用敏捷方法的团队具有价值，还能够帮助那些面临大型项目挑战的企业节省大量资金，避免可能产生的重大损失。 Jared Richardson也对这本书赞誉有加，他指出，《ReleaseIt!》揭示了开发者可能尚未意识到的错误，并提供了改正这些问题的实用指南，使之成为任何实践者不可或缺的“Pragmatic”系列图书中的一部珍品。 Arun Batchu作为一名企业架构师，更是强调了这本书的警示作用和实用性，提醒读者它可能会揭示过去未曾察觉的问题，同时也提供了立即改善的解决方案，使得读者能够立刻提升自身的软件开发技能和项目管理水平。该书由The Pragmatic Bookshelf出版，出版社总部位于美国北卡罗来纳州的raleigh和德克萨斯州的达拉斯。值得注意的是，书中提及的一些制造商和销售商所使用的特定设计标识可能是商标，这表明作者在尊重知识产权的同时，也关注到了行业规范。《Design and Deploy Production-Ready Software》是一本深度剖析敏捷开发实践，提供实用工具和最佳实践的实战指南，对于任何追求高效、高质量软件交付的开发团队或个人来说，都是一本极具价值的参考书籍。通过阅读和学习这本书，读者可以提升软件交付的稳定性和可靠性，避免在生产环境中遇到不必要的问题，从而推动项目的成功实施。

QUALITY OF LIFE 16

(See the sidebar on page 150.) It’s a terrible irony that these very early

decisions are also the least informed. This is when your team is most

ignorant of the eventual structur e of the software in the beginning, yet

that is when some of the most irrevocable decisions must be made.

Even on “agile” projects,

decisions are best made with foresight. It

seems as if the designer must “use the force” to see the future in order

to select the most robust design. Since different alternatives often have

similar implementation costs but radically different lifecycle costs, it is

important to consider the effects of each decision on availability, capac-

ity, and ﬂexibility. I’ll show you the downstream effects of dozens of

design alternatives, with concrete examples of beneﬁcial and harmful

approaches. These examples all come from real systems I’ve worked on.

Most of them cost me sleep at one time or another.

1.3 Quality of Life

Release 1.0 is the beginning of your software’s life, not the end of the

project. Your quality of life after Release 1.0 depends on choices you

make long before that vital milestone.

Whether you wear the support pager, sell your labor by the hour, or pay

the invoices for the work, you need to know that you are dealing with a

rugged, Baja-tested, indestructible vehicle that will carry your business

forward, not a fragile shell of ﬁberglass that spends more time in the

shop than on the road.

1.4 The Scope of the Challenge

The “software crisis” is now more than thirty years old. According to These terms come from

the agile community. The

gold owner is the one

paying for the software.

The goal donor is the one

whose needs you are

trying to ﬁll. These are

seldom the same person.

the gold owners, software still costs too much. (But, see Why Does Soft-

ware Cost So Much? [DeM95] about that.) According to the goal donors,

software still takes too long—even though schedules are measured in

months rather than years. Apparently, the supposed productivity gains

from the past thirty years have been illusory.

1. I’ll reveal myself here and now as a strong proponent of agile methods. Their e mphasis

on early delivery and incremental improvements means software gets into production

quickly. Since production is the only place to learn how the software will respond to

real-world stimuli, I advocate any approach that begins the learning process as soon as

possible.

AMILLION DOLLARS HERE, A MILLION DOLLARS THERE 17

On the other hand, maybe some r eal productivity gains have gone into

attacking larger problems, rather than producing the same software

faster and cheaper. Over the past ten years, the scope of our systems

expanded by orders of magnitude.

In the easy, laid-back days of client/server systems, a system’s user

base would be measured in the tens or hundreds, with few dozen con-

current users at most. Now, sponsors glibly toss numbers at us such

as “25,000 concurrent users” and “4 million unique visitors a day.”

Uptime demands have increased, too. Whereas the famous “ﬁve nines”

(99.999%) uptime was once the province of the mainframe and its care-

takers, even garden-variety commerce sites are now expected to be

available 24 by 7 by 365.

Clearly, we’ve made tremendous strides even

to consider the scale of software we build today, but with t he increased

reach and scale of our systems come new ways to break, more hostile

environments, and less tolerance for defects.

The increasing scope of this challenge—to build software fast that’s

cheap to build, good for users, and cheap to operate—demands con-

tinually improving architecture and design techniques. Designs appro-

priate for small brochureware websites fail outrageously when applied

to thousand-user, transactional, distributed systems, and we’ll look at

some of those outrageous failures.

1.5 A Million Dollar s Here, a Million Dollars There

A lot is on the line here: your project’s success, your stock options or

proﬁt sharing, your company’s survival, and even your job. Systems

built for QA often require so much ongoing expense, in the form of

operations cost, downtime, and software maintenance, that they never

reach proﬁtability, let alone net positive cash for the business, which

is reached only after the proﬁts generated by the system pay back the

costs incurred in building it. These systems exhibit low levels of avail-

ability, resulting in direct losses in missed revenue and sometimes even

larger indirect losses through damage to the brand. For many of my

clients, the direct cost of downtime exceeds $100,000 per hour.

2. That phrase has always bothered me. As an engineer, I expect it to either be “24 by

365” or be “24 by 7 by 52.”

PRAGMA TIC ARCHITECTU RE 18

In one year the difference between 98% uptime and 99.99% uptime

adds up to more than $17 million.

Imagine adding $17 million to the

bottom line just through better design!

During the hectic rush of the development project, you can easily make

decisions that optimize development cost at the expense of operational

cost. This makes sense only in the context of the project team being

measured against a ﬁxed budget and delivery date. In the context of the

organization paying for the software, it’s a bad choice. Systems spend

much more of their life in operation than in development—at least, the

ones that don’t get canceled or scrapped do. Avoiding a one-time cost

by incurring a recurring operational cost makes no sense. In fact, the

opposite decision makes much more ﬁnancial sense. If you can spend

$5,000 on an automated build and release system that avoids down-

time during releases, the company will avoid $200,000.

I think that

most CFOs would not mind authorizing an expenditure that returns

4,000% ROI.

Don’t avoid one-time

development expenses

at the cost of recurring

operational expenses.

Design and architecture decisions are also

ﬁnancial decisions. These choices must be

made with an eye toward their implementation

cost as well as their downstream costs. The

fusion of technical and ﬁnancial viewpoints is

one of the most important recurring themes in

this book.

1.6 Pragmatic Architecture

Two divergent sets of activities both fall under the term architecture.

One type of architecture strives toward higher levels of abstraction that

are more portable across platforms and less connected to the messy

details of hardware, networks, electrons, and photons. The extreme

form of this approach results in the “ivory tower”—a Kubrickesque

clean room, inhabited by aloof gurus, decorated with boxes and arrows

on every wall. Decrees emerge from the ivory tower and descend upon

the toiling coders. “Use EJB container-managed persistence!” “All UIs

shall be constructed with JSF!” “All that is, all that was, and all that

3. At an average $100,000 per hour, the cost of downtime for a tier-1 retailer.

4. This assumes $10,000 per release (labor plus cost of planned downtime), four releases

per year, and a ﬁve-year horizon. Most companies would like to do more than four releases

per year, but I’m being conservative.

PRAGMA TIC ARCHITECTU RE 19

shall ever be lives in Oracle!” If you’ve ever gritted your teeth while cod-

ing something according to the “company standards” that would be ten

times easier with some other technology, then you’ve been the victim

of an ivory-tower architect. I guarantee that an architect who doesn’t

bother to listen to the coders on the team doesn’t bother listening to the

users either. You’ve seen the result: users who cheer when the system

crashes, because at least then they can stop using it for a while.

In contrast, another breed of architect rubs shoulders with the coders

and might even be one. This kind of architect does not hesitate to

peel back the lid on an abstraction or to jettison one if it does not

ﬁt. This pragmatic architect is more likely to discuss issues such as

memory usage, CPU requirements, bandwidth needs, and the beneﬁts

and drawbacks of hyperthreading and CPU bonding.

The ivory-tower architect most enjoys an end-state vision of ringing

crystal perfection, but the pragmatic architect constantly thinks about

the dynamics of change. “How can we do a deployment without reboot-

ing the world?” “What metrics do w e need to collect, and how will we

analyze them?” “What part of the system needs improvement the most?”

When the ivory-tower architect is done, the system will not admit any

improvements; each part will be perfectly adapted to its role. Contrast

that to the pragmatic architect’s creation, in which each component is

good enough for the current stresses—and the architect knows which

ones need to be replaced depending on how the stress factors change

over time.

If you’re already a pragmatic architect, then I’ve got chapters full of

powerful ammunition for you. If you’re an ivory-tower architect—and

you haven’t already stopped r eading—then this book might entice you

to descend through a few levels of abstraction to get back in touch with

that vital intersection of software, hardware, and users: living in pro-

duction. You, your users, and your company will all be much happier

when the time comes to ﬁnally release it!

剩余349页未读，继续阅读

mengfan93

粉丝: 0
资源: 1

《ReleaseIt!》：打造生产级软件的实战指南

《软件架构师必知的97件事》——IT精英的智慧结晶

《发布它》：打造生产级Web应用的深度指南

RESTful架构中维持网络稳定的五大模式

Pragmatic Bookshelf - Release It! Design and Deploy Production Ready Software.pdf

Release It!-Design and Deploy Production-Ready Software-2007

Release It! Design and Deploy Production-Ready Software

Release It Design And Deploy Production Ready Software

REST in Practice.pdf

REST.in.Practice REST实战 PDF完整高清版

class-dump:从Mach-O文件生成Objective-C标头

最新资源