昨天看完。职业生涯，自我完善，如何管理团队这几章的栏目都很精彩，不在软件这一行里的朋友也能通过阅读收获不小。而且后面的章节翻译更顺畅些，没挑什么毛病，只有这一个地方的得太多绕得头晕。

P81，L3，适当的设计产品的受欢迎的可测试性和保障性。

javaeye上有人发帖问说谁买了《代码之道》（机械工业出版社09年1月1版1印，陆其明译），看过的说说翻译的如何。

我的这本书是steedhorse送的。我慢慢看，也慢慢说。

Eric Brechner的这本书写的很出色，他以I. M. Wright为化名写的专栏确实精彩。中文版翻译不是非常糟糕，有些章节很顺畅，注解也很仔细。有些段落句子生硬些。看到难读的地方就很纠结，不太想看下去，犹犹豫豫觉得今天还没看多少内容想强迫一下自己，又实在是挠头。

好话没必要多说，直接挑毛病。

前言第一句：这是一本关于极其实操性的书。// 什么是实操性，什么是极其实操性。

P23，L16，我非常由喜欢这些开发范例提出来的很多思想和方法。

P34，L4，另一个是认为敏捷狂热归根到底是被一些无知的学者鼓吹出来的，它实际上是一种改头换面的愚昧，它让开发者免于任何责任的人。

P39，L3，这种情况下很最流行使用burn-down图。

P59，-L6，测试者没有开发者聪明。// 这句话应该使用粗体。

P60，L5，公司内的很多人都在通过像在微软准备就绪计划（Readiness At Microsoft Program，RAMP）和测试主管计划（Test Lead Program）之类的启动计划，努力纠正这种不公平。// Readiness At Microsoft Program翻译为“在微软准备就绪计划”，Test Lead Program翻译为“测试主管计划”。“启动计划”的原文不知道是什么。

P62，-L9，单元测试可以带来更好的实现设计，更可测的代码，更少的回退、建造中断和“建造验证测试”失败。

P192，L6，Watson bucket翻译为“Watson桶”。术语解释说：每个“Watson桶”代表了一个用户问题，……，微软内部和外部的工程师都可以查询到他们软件中的问题造成了哪些桶。

我不知道RAMP，Test Lead Program，Watson bucket应该怎么翻译，但是这样写，很别扭。

CSDN上看到一个帖子，说是被开会的效率不高困扰，感觉几个回帖没有瞄准发贴人的问题。

昨天看《代码之道》第三章《根除低下的效率》，《我们开会的时候》这一节很有效率的指导了如何开会。

首先，“别浪费我的时间”。如果要我去一个会议室，我会问你下面几个问题。每一个会议发起人也都要准备好回答这几个问题，你要假设每一个来参加会议的人都会问你这些问题。

1，为什么我们会在这里。

所有与会者都要清楚这个理由，否则大家可能各有所想。也许应该预先发一个议程，或者发一些将要讨论的文档，不管是什么，总得做点什么。

然后，记住要坚持这个主旨。大家现在参加这个会议，就只专注于这个会议。不管其他地方的其他会议讨论的其他议题做的其他决定。

如果有人想转移话题，告诉他先把我们的话题讨论完，再讨论他的话题。如果他坚持，他们先讨论他要这么做的理由。如果理由充分，说明你的会议时机不成熟。

2，我们正在试图做什么。

如果我们在试图做一个决定，那就让我们做个决定，其他像头脑风暴、状态检查等事情统统跳过。

如果我们在试图共享信息，比如状态汇报，那就把列表上的内容过一遍，但不要试图去做什么决定，或者解决什么问题。

如果我们在试图收集想法，那就捕捉每个人的想法，多荒诞都不要批评或论断，最后，挑最好的作为会议的成果。

记住，混合会议是低效的，常常徒劳无功。

3，为什么他们会在这里。

会议持续的时间跟参加会议的人数是直接成比例的，说不定还是线性的。只邀请那些必须出现在会议上的人。

如果是试图做一个决定，邀请可以做决定的人，其他所有人都可以在会议之后通过email了解到会议的情况。如果不是所有必要的需要做决定的人都能参加，立刻取消会议。否则，你将不得不在所有人都能参加的时候再召集一次会议。

如果是状态汇报会议，邀请那些将要汇报的人，其他所有人都可以在会议之后通过email了解到会议的情况。

如果是头脑风暴会议，邀请有创意的，思想开明的人，其他所有人都可以在会议之后通过email了解到会议的情况。

如果太多人登记要参加会议，你最好取消会议。

尽量预订一个小会议室，这样可以把一些不速之客排除在外。

4，为什么我现在才听到这个。

对于一些重要主题，不要让关键的相关人员吃惊。没人喜欢匆忙被拉去做一个重要的决定。也没人希望对关键领域发生的事情丝毫不知。

预先跟关键人物沟通，可以发现问题，协商折衷方案，预先让所有人取得一定的共识，会议开起来就比较顺畅。

5，接下去要做什么。

决定接下去要做什么，写到email中去。

把与会者名字放在地址栏，抄送所有受会议结果影响的人。要包含对会议所做决定、共享信息或收集到的想法的简短总结。然后列出接下去的安排，指明谁在什么时候做什么事情。

OK。

代码的结构。

从底向上有A，B，C三层，每层有一些模块，上层调用下层模块。不同的客户，C的差异很大，C层有很多并列的分支，A和B

与客户的合作有不同的方式，有的是不给客户源代码，任何变动的需求都由公司完成；有的是给C层的代码，部分变动的需求客户自己解决；有的是给B层和C层的源代码，几乎全由客户自己完成变更。

有一个客户，合作方式是第三种。客户拿到代码后在B层和C层做了一些改动，改动部分模块以增加功能，或者是改变部分行为方式。

一年以后，主干树上的A层和B层经过多次升级，整个工程升级到新的版本，该客户希望能同步，但是要求保持其自主改动。

矛盾是：该客户在B层做的改动不可能合并到主干树上。而另建分支增加了与主干树B层的更新保持同步的合并动作，增加测试工作量，增加错误可能性。

怎么办？

我们只能是为其另建分支，而同步代码的维护工作长期占用了一个工程师的几乎全部工作时间。

事实证明，替客户维护已经发布给他的源代码是一件非常不可取的事情。

应该告诉他们，如果希望得到源代码发布，那我们将不再对这份代码做维护。