程序员修炼之道（通俗版）—

《程序员修炼之道》这本书中的内容挺不错，里面包含了很多精华，但一些句子很拗口，所以我就根据国人的阅读习惯，在不改变原意的情况下对词句稍加修改，标题中的“通俗版”就是这么来的。

1、我们喜欢按照功能划分的团队。把你的人划分成小团队，分别负责系统特定方面的功能。让各团队按照各人的能力，在内部自行组织。每个团队都按照他们约定的承诺，对项目中的其他团队负有责任。承诺的确切内容随项目而变化，团队间的人员分配也是如此。
这样按功能组织有什么好处？使用我们用于组织代码的相同技术，去用像合约、解耦、正交性这样的技术组织我们的各种资源，有助于使团队作为整体与变化的各种效应隔离开来。如果用户突然决定变更数据库供应商，应该只有数据库团队受影响。如果市场部突然决定使用现成工具来实现日程安排功能，只有日程小组会受影响。适当地加以运用，这种分组方式能够极大地减少各个开发者之间的相互影响。缩短时间标度、提高质量、并减少缺陷的数目。这种途径还能带来更愿意付出的开发者，每个团队都知道他们要对特定的功能负责，所以他们更会觉得自己是他们的工作成果的主人。

2、人的重复性并不像计算机那么好。shell脚本或批处理文件能以相同的次序、反复执行同样的命令。它们能被置于源码控制之下，你因而也可以检查流程的修改历史（“昨天还能工作……”）
Linux中一个特别受欢迎的自动化工具是cron（或Windows NT上的“at”）。它允许我们安排无人照管的任务周期性地运行——通常是在午夜。例如下面的crrontab文件指定，每天午夜过后5分钟运行项目的nightly命令，每个工作日的凌晨3:15进行备份，每月第一天的午夜运行expense_reports

3、在“重复的危害”中，我们提倡生成代码，以根据公共来源派生知识。我们可以利用make的依赖分析机制，让这一过程变得更容易。给makefile增加规则，根据其他来源自动生成文件，是一件相当简单的事情。例如，我们想要根据一个XML文件生成一个Java文件，并编译所得结果。
.SUFFIXES: .Java .class .xml
.xml .java:
perl convert .pl $< >$@
.Java .class
$(JAVAC) $(JAVAC_FLAGS) $<

敲入make test.class，make就会自动查找名为test.xml的文件，通过运行Perl脚本构建一个.java文件，然后编译该文件，产生test.class。
这看起来不错，有机会得试一下。

4、如果程序员能够把他们的所有时间投入实际编程，那不是很好吗？遗憾的是，难得有这样的情况。有E-mail要回复，有书面工作要完成，有文档要发布到Web上，等等。你可以创建一个shell脚本来完成一些烦人的工作，但你仍然要记得在需要时运行这个脚本。
因为记忆是随着你的年龄增长而丧失的第二种东西，我们不想过分依赖它。我们可以运行脚本，让他们基于源码和文档的内容，自动为我们完成各种流程。我们的目标是维持自动、无人照管、内容驱动的工作流。

5、让计算机去做重复、庸常的事情——它会做得比我们更好。我们有更重要、更困难的事情要做。

6、寻找bug有点像是用网捕鱼。我们用纤小的网（单元测试）捕捉小鱼，用粗大的网（集成测试）捕捉吃人的鲨鱼。有时鱼会设法逃跑，所以为了抓住在我们的项目里游动地、越来越狡猾的缺陷，要补上我们发现的任何漏洞。
许多团队都会为他们的项目精心制定测试计划，但实际上，使用自动测试的团队更容易成功。

7、编码完成的标志不是你已经写完了这段代码，而是你写完的这段代码已经通过了全部测试。

8、回归测试把当前测试的输出与先前的（或已知的）值进行对比。我们可以确定我们今天对bug的修正没有破坏昨天可以工作的代码。这是一个重要的安全网，它能减少令人不快的意外。
我们到目前为止提到过的所有测试都可以作为回归测试运行，确保我们在开发新代码时没有损失任何领地。我们可以运行回归测试，对性能、合约、有效性等进行校验。

9、一旦测试人员找到了某个bug，这应该是测试人员最后一次发现这个bug。应该对自动化测试进行修改，从此每次都检查那个特定的bug，没有例外，不管多琐碎，也不管开发者怎样抱怨说：“哦，那绝不会再发生了。”
因为它会再次发生，而我们完全没必要花时间去追踪自动化测试本可以为我们找到的bug。我们必须把时间花在编写代码——以及新的bug——上。

10、一般而言，注释应该讨论为何要做某事、它的目的和目标。代码已经说明了它是怎样完成的，所以再为此加上注释是多余的——而且违反了DRY原则。
注释可以让你把项目的那些难以描述、容易忘记，却又不能记载到其他地方的东西记载下来：工程上的权衡、为何要做出某些决策、放弃了哪些替代方案，等等。

11、在源文件里应该出现的最重要的信息之一是作者的姓名——不一定是最后编辑文件的人，可以是文件的所有者。使责任和义务与源码联系起来，能够奇迹般地使人保持诚实。

12、以一种类似的方式使用像JavaDoc和DOC++这样的工具，我们可以根据源码生成API级的文档。模型是源码：模型的一种视图可以编译；其他视图可用于打印或在Web上查看。我们的目标是总在模型上工作——不管模型是代码自身还是某种其他文档，并且让所有视图自动更新。突然间，文档没那么糟糕了。
这听起来很不错，值得我们玩一下。

13、在抽象意义上，应用如果能正确实现其规范，就是成功的。遗憾的是，这种事只活在梦里。
在现实中，项目的成功是由它在多大程度上满足了用户的期望来衡量的。不符合用户预期的项目注定是失败的，不管你认为交付的产品有多好。

程序员修炼之道（通俗版）——第八章相关推荐

程序员修炼之道（通俗版）——第一章
<程序员修炼之道>这本书中的内容挺不错,里面包含了很多精华,但一些句子很拗口,所以我就根据国人的阅读习惯,在不改变原意的情况下对词句稍加修改,标题中的"通俗版"就是这么 ...
《Ruby程序员修炼之道》（第2版）目录—导读
版权 Ruby程序员修炼之道(第2版) • 著 [美] David A. Black 译钟凤鸣陈雪静责任编辑杨海玲 • 人民邮电出版社出版发行北京市丰台区成寿寺路11号邮编 100164 ...
《程序员修炼之道（第2版）》！屹立20年王者归来！
推荐语:收到博文视点的新书<程序员修炼之道(第2版),反复拜读,确实非常全面,涵盖编程,并发,架构,程序员个人修炼,团队,项目等方面标题已经完全代表博文菌想说的话了! <程序员修炼之道( ...
《Ruby程序员修炼之道》（第2版）—第1章1.1节进入Ruby的世界
本节书摘来自异步社区<Ruby程序员修炼之道>一书中的第1章,第1.1节进入Ruby的世界,作者[美]David A. Black(戴维 A. 布莱克),更多章节内容可以访问云栖社区&qu ...
好教程推荐系列：《程序员的自我修养》和《程序员修炼之道：通向务实的最高境界（第2版）》
1.<程序员的自我修养-链接.装载与库> <程序员的自我修养:链接.装载与库>网易云风力荐:莫到用时再读书!主要介绍系统软件的运行机制和原理,涉及在Windows和Linux两 ...
《Ruby程序员修炼之道》（第2版）—第1章1.2节剖析Ruby的安装
本节书摘来自异步社区<Ruby程序员修炼之道>一书中的第1章,第1.2节剖析Ruby的安装,作者[美]David A. Black(戴维 A. 布莱克),更多章节内容可以访问云栖社区&qu ...
《Ruby程序员修炼之道》（第2版）—第1章1.4节易用的Ruby工具和应用程序
本节书摘来自异步社区<Ruby程序员修炼之道>一书中的第1章,第1.4节易用的Ruby工具和应用程序,作者[美]David A. Black(戴维 A. 布莱克),更多章节内容可以访问云栖 ...
不可能解开的谜题 (程序员修炼之道,评注者序)
我打算不点评任何东西.我打算在整个过程中只提问题,不做解答.可能讲述一个场景或者围绕书中的场景或观点来提问题.不解释,不回答,不评点. --与编辑就评注版风格进行的讨论,代引言一有本书名叫< ...
java程序员修炼之道 pdf_?活动丨和大咖云风来场1对1交流，分享《程序员修炼之道》心得...
曾经获得无数赞誉,畅销20年经久不衰的IT领域经典著作--<程序员修炼之道>,多年来频繁出现在众多行业大咖和广大读者的推荐书单中.如今,这本广受推崇.好评无数的经典之作出新版啦! ▊< ...
知识资产投资——《程序员修炼之道》的建议
<程序员修炼之道:从小工到专家>曾经获得第14届JOLT大奖,很多程序员可能都知道甚至看过.我还没看完,初步给我留下三个印象: 书上的例子还比较有趣,仔细品位又是觉得很有哲理,比如那个&q ...

程序员修炼之道（通俗版）——第八章

程序员修炼之道（通俗版）——第八章相关推荐

最新文章

热门文章