本网站不提供下载链接，喜欢看书的朋友请关注公众号：【lennylee的碎碎念】(lennyleede)，首页回复：授人以渔，自动获取搜索资源的方法。
内容简介:
Andrew Hunt、David Thomas所著的《程序员修炼之道》（The Pragmatic Programmer）由一系列独立的部分组成，涵盖的主题从个人责任、职业发展，到用于使代码保持灵活并且易于改编和复用的各种架构技术，利用许多富有娱乐性的奇闻轶事、具有思想性的例子及有趣的类比，全面阐释了软件开发的许多不同方面的最佳实践和重大陷阱。无论你是初学者，是有经验的程序员，还是软件项目经理，本书都适合你阅读。
《程序员修炼之道——从小工到专家(评注版)》是The Pragmatic Programmer一书的评注版，力邀国内资深专家执笔，在英文原著的基础上增加了中文点评和注释，旨在融合二者之长，既保留经典的原创文字与味道，又以先行者的学研心得与实践感悟，对读者的阅读和学习加以点拨，指明捷径。《程序员修炼之道——从小工到专家(评注版)》由周爱民、蔡学镛评注。
作者简介:
Andy Hunt是一位热切的木匠和音乐家，但奇怪的是，人们更需要作为顾问的他，他的工作领城包括电信、银行、金融服务、公共服务，以及一些更奇特的领域，比如医学成像、图形艺术、Internet服务。Andy的专长是把经过验证的技术与先进的技术混合在一起，创建各种新颖的——但也是实用的——解决方案。Andy在北卡罗莱纳州的罗利市拥有自己的顾问公司。
Dave Thonms喜欢驾驶单引擎飞机飞行，并通过这样的方式为他的习惯付账：为各种难题寻找优雅的解决方案，提供诸多领域里的咨询服务——航空、银行、金融服务、电信、交通运输及Internet。在于1994年移居美国前，Dave在英国创立了一家通过ISO9001认证的软件公司，为世界各地的客户开发成热、定制的软件项目。Dave现在是一位独立顾问，居住在德克萨斯州的达拉斯。
务实的哲学 1
CHAPTER1 A PRAGMATIC PHILOSOPHY（新增评注21条） 5
1．The Cat Ate My Source Code 6
2．Software Entropy 8
3．Stone Soup and Boiled Frogs 11
4．Good-Enough Software 14
5．Your Knowledge Portfolio 16
6．Communicate! 23
务实的方法 29
CHAPTER 2 A PRAGMATIC APPROACH（新增评注34条） 35
7．The Evils of Duplication 36
8．Orthogonality 44
9．Reversibility 54
10．Tracer Bullets 58
11．Prototypes and Post-it Notes 64
12．Domain Languages 68
13．Estimating 75
基本工具 83
CHAPTER 3 THE BASIC TOOLS（新增评注18条） 87
14．The Power of Plain Text 89
15．Shell Games 93
16．Power Editing 98
17．Source Code Control 103
18．Debugging 106
19．Text Manipulation 115
20．Code Generators 119
务实的执著 125
CHAPTER 4 PRAGMATIC PARANOIA（新增评注20条） 129
21．Design by Contract 130
22．Dead Programs Tell No Lies 142
23．Assertive Programming 144
24．When to Use Exceptions 148
25．How to Balance Resources 151
解耦合是王道 161
CHAPTER 5 BEND, OR BREAK（新增评注13条） 165
26．Decoupling and the Law of Demeter 166
27．Metaprogramming 172
28．Temporal Coupling 178
29．It’s Just a View 185
30．Blackboards 193
编码时刻 199
CHAPTER 6 WHILE YOU ARE CODING（新增评注16条） 203
31．Programming by Coincidence 204
32．Algorithm Speed 209
33．Refactoring 216
34．Code That’s Easy to Test 221
35．Evil Wizards 230
需求与问题 233
CHAPTER 7 BEFORE THE PROJECT（新增评注22条） 237
36．The Requirements Pit 238
37．Solving Impossible Puzzles 249
38．Not Until You’re Ready 252
39．The Specification Trap 254
40．Circles and Arrows 257
团队 261
CHAPTER 8 PRAGMATIC PROJECTS（新增评注13条） 265
41．PragmaticTeams 266
42．Ubiquitous Automation 272
43．Ruthless Testing 279
44．It’s All Writing 290
45．Great Expectations 298
46．Pride and Prejudice 300
APPENDIX A RESOURCES 303
Professional Soci＆not;＆not;eties 304
Building a Library 304
Internet Resources 308
Bibliography 316
APPENDIX B ANSWERS TO EXERCISES 321
INDEX 351
· · · · · · (收起)
原文摘录:
项目团队
你是否注意到，一些项目团队非常高效，每个人都知道该做什么，并做出了充分的贡献；而其他一些团队的成员却总是争吵不休，似乎无法相互谦让？
通常这就是一个正交性问题。当团队组织重复到架屋迭床时，成员会对职责感到困惑。每修改一个东西都需要整个团队开会，因为修改会影响每个人。
如何将团队组织成职责明确、重叠最少的不同小组？没有简单的答案。这一定程度上取决于具体项目，以及你对可能发生变化区域的分析；同时还取决于你能调用的人手。我们的首选做法是，先将基础设施从应用程序中分离出来，让每个主要的基础设施组件（数据库、通信接口、中间件层等）都有自己的子团队，让应用程序中特别明显的不同功能都能简单地分开。然后再查看我们拥有（或计划拥有）的人员，并相应地调整分组。
有一个通俗的方法，可以用来评估项目团队结构的正交性——只需简单看看，在讨论每个修改时，有多少人需要参与进来。人数越多，组织的正交性越差。显然，一个正交的团队更有效率。（话虽如此，我们还是鼓励子团队间保持相互沟通。） (查看原文)
云风
5 回复
35赞
2020-05-08 11:28:31
—— 引自章节：10 正交性 40
要把低级的知识放在代码中，把注释留给高级的知识。 (查看原文)
Suave
13赞
2012-02-23 22:56:13
—— 引自章节：全书笔记