程序员必读：《开发者编码手册》实战指南

5星 · 超过95%的资源需积分: 10 103 浏览量更新于2024-07-28 收藏 2.04MB PDF 举报

"The Developer's Code"是一本面向专业开发者的实践指南，旨在为初学者提供入门指引，同时对经验丰富的开发者来说也是一份宝贵的智慧结晶。作者Kai Chueh避开了一般编程书籍中陈词滥调的传统建议，而是以一种强大且聚焦的方式探讨了软件开发的艺术和职业现实。这本书的独特之处在于它不是一本罗列过时规则的教科书，而是着重于对编程本质的理解，以及基于实际工作经验的实用建议。作者通过分享自己的亲身经历，引导读者思考软件创造的深层含义，而非仅仅局限于编程语言和技术细节。书中充满了精心提炼的教训，每个章节都像一口可口的“字节”大小的智慧，适合忙碌的现代程序员在碎片时间里学习。无论你是技术新手还是资深开发领军人物，都能从中收获到诸多有用的提示、技巧和经验，使你在快速发展的编程世界中保持竞争力。对于那些渴望提升自身编程技能并寻求职业生涯指导的人来说，"The Developer's Code"无疑是一本必读之作。它不仅提供了实用的编程策略，更深入探讨了开发人员的生活方式和价值观，是理解和提升专业素养的宝贵资源。无论你是想成为更好的开发者，还是希望对软件开发有更全面的认识，这本书都将是你知识库中的重要补充。

Essay 2

Plan Enough, Then Build

In traditional architecture, planning is essential. Certain

things unequivocally have to happen before others. Studs

go in bef ore plumbing . P lumbing is inst alle d b efore the w a l l s .

The w a l l s have to be there before the paint.

Undo

Cut

, or

R e v e r t

aren’t viable options when building a skyscraper.

The software

Undo

TRL

. The software

Cut

TRL

. The

software

R e v e r t

is a code rollback in source control.

W i t h o u t the luxury of these v e r y simple y e t powerful ges-

tures, buildings require v e r y detailed specifications. One

foot short is the difference between a profitable piece of real

estate and a catastrophic front-page headline.

Let’s pretend w e ’r e traditional architects afforded all the

shortcuts of software development. It w o u l d be a dream

w o r l d . Materials w o u l d be infinitely available. W e could

build a life-size model of a building in a few w e e k s . W e

could stress test suspension bridges over and over again. If

a bridge broke, who w o u l d care? W e could instantaneously

replicate ten new ones in a few minutes!

report erratum • discuss

Plan Enough, Then Build • 7

Of course, all of this is mere fantasy. So, writing specifica-

tions in excruciating detail makes the most sense when w e ’ v e

decided to build a skyscraper.

On the other hand, these are the luxuries of our industry.

Software components don’t need to w a i t on a shipment of

letters and numbers from the local factory. W e type, compile,

test, and repeat. W e can test code on the real product, not

some model of the real product. W e have the luxury of

w a t c h i n g our suspension bridges break hundreds of times

while in development, in all different places, under all dif-

ferent conditions, without the w o r r y of w a s t i n g materials

or putting people’s lives in jeopardy. W o r k i n g this w a y is

completely feasible. When w e finish software, the same

application can be duplicated 1,000 times with negligible

human effort.

When the developers of the W y n n Hotel in Las V e g a s built

a virtually identical twin hotel called the Encore in 2008,

they didn’t have the luxury of copying and pasting the first

v e r s i o n into the v a c a n t lot next door. They had to start with

specs and planning just to build a nearly identical structure.

Even when software meant shipping code on a disk, plan-

ning extensively still made a lot of sense. Meanwhile,

w e b - b a s e d software is a different game. Planning through

v e r y detailed specifications prior to writing a line of code

still has merits, but it doesn’t fully take advantage of the

medium. W e can release new builds daily or hourly or

whenever w e w a n t , with v e r y low overhead, from the com-

fort of our cushy Aeron chairs.

Fortunately, as an industry, w e ’r e starting to break through

the metaphor. Agile development isn’t revolutionary; it’s

just untying us from a metaphor that doesn’t make as much

sense today as it did in the past. That’s not to say that tradi-

tional w a t e r f a l l development is obsolete. It still has its merits

on larger, more complex software projects. But following

that metaphor without question might also blind us to an

approach that better fits the medium w e w o r k in.

The “plan, plan, plan” metaphor overvalues the time w e

spend trying to get everything perfect and undervalues the

time w e could be spending writing the actual code.

8 • Chapter 2. Metaphor

report erratum • discuss

The Corporate Ladder Leads to Less Code

In our industry, w e w o r k our w a y up to the role of a techni-

cal archit e c t b y ac t ually deve l oping—by do i n g t h e “p hysical”

w o r k of building applications. But in most organizations, as

w e move up the software development ladder, w e write less

code. W e immerse ourselves more with planning than with

discovering the problems on the front line. W e concern

ourselves more about an overall vision and less about the

intimate details of code. As an industry, w e ’ v e held on to

the notion that architects should plan and developers should

develop.

This creates the false perception that once w e ’ v e reached a

certain level, programming is no longer where w e ’r e most

v a l u a b l e . Just leave the dirty w o r k to the junior developers!

At the same time, it pushes lower-level programmers away

from thinking about the overall goals and direction of the

project. They’re asked to concentrate just on the implemen-

tation. The architect-developer model makes both parties

less accountable for the application as a whole.

When w e split up roles into the somewhat arbitrary hierar-

chy of those who think about the technical “big picture” and

those who think only in

statements,

for

loops, and markup,

w e fracture two disciplines that belong intimately together.

Pure technical architects can take a guess at the best architec-

ture, the best design pattern, or the best practice. It’s only

when they’re knee-deep in code that they discover where

the real challenges exist. At the same time, the developer

who isn’t given the reins to think at a high level also doesn’t

get the chance to v o i c e a second opinion. Often, it’s the guy

who’s doing the actual implementation who can see the

bumps ahead most clearly.

W e ’ v e taken the architect-developer analogy too far. The

corporate ladder in the software industry needs a better

analogy.

T o build a building, architects architect and developers

develop. T r a d i t i o n a l architects know how to create elaborate

plans and specs in fine detail. But they don’t build. It’s sim-

ply not reasonable. The separation between those who think

report erratum • discuss

The “Ivory Tower” Architect Is a Myth • 11

剩余156页未读，继续阅读

liangam

粉丝: 3
资源: 15

程序员必读：《开发者编码手册》实战指南

The Developer’s Code.pdf

Not enough information to list load addresses in the image map.

github copilot

Gradle task assembleDebug failed with exit code 1

A javaScript error occurred in the main process

E: Sub-process /usr/bin/dpkg returned an error code (1)

500 Server Error for HTTP GET "/"

rk3568 USB3.0驱动源码

Failed to resolve async component default: TypeError: Cannot read properties of undefined (reading 'documentElement')

createError.js?2d83:16 Uncaught (in promise) Error: Request failed with status code 500

最新资源