Moyu正在整理各位作者的修改意见（目前还剩下Hurui没有提交他负责的哪一部分），估计总的修改条目在60 条左右。和我个人的上一本书《移山之道》 相比，本书问题的数量和严重程度都是我所料不及的。 这里面虽然有各方面的原因，但是作为本书作者，负责人，我的质量意识不够强，过于相信各个审核环节的作用，没有从一开始就严格要求高质量。 我在这里向各位作者和编辑们表示道歉。  

一本有这么多硬伤的书，目前卖得还很不错，我要感谢各位编辑，特别是营销编辑的辛勤劳动。 我也对买了这本书的读者感到愧疚， 希望他们不至于因为书中的问题而对博文视点及微软公司有太坏的印象和评语。  错误已经造成，内部的道歉和“汗颜”都不能改变这一事实。  和市面上同类书籍相比，也许我们的错误率也还过得去，但是这绝对不能成为我们满足的理由。 

这本书还是有其独特价值的，会对我们的目标读者有很好的帮助，我一直相信这一点。 因此我和周老师都希望我们能尽快出一个新版本，让编程之美，美如其名。 我对这本书的期望值是一本经得起考验的“精品”。 我相信以“让精益求精成为习惯” 为宗旨的博文员工也非常希望提高本书的质量。

钢铁是如何炼成的？钢铁是在高温中不断敲打炼成的。我们大家还要再劳累一阵子，在各自的岗位上，对《编程之美》 再好好敲打一次，让编程之美，真正美如其名。

 ************

团队新来的设计总监xiaoqin在工作小结中对我说：

完善进度延误制度不光是体现在处罚方面，而是要在出现问题了以后，大家齐心共同补救、减少损失的应对机制上下功夫。对特别紧急的事情要紧急处理，该加班的要加班，一切以完成任务为目标。流程编辑要及时发现项目的进度问题，及时安排进度的补救工作，全力补救。优秀的团队并不一定是不会犯错误的团队，而在犯错之后还能够全力挽回局面的团队肯定是优秀团队。这样的队伍才能打硬战，打持久战。我相信这正是我们与其他优秀团队的距离所在。

*************

有这样的客户，这样的同事，我们定要让自己百炼成钢！

对于我们提交的修改意见，我个人认为可以分为两类：

1)      需要告知读者的严重错误： 程序的逻辑错误，语法错误，错误的公式，误导性的文字，关键文字的缺失。  (这一类错误并不是特别多)

2)      可以改进的问题： 代码中格式问题，文字中描述不精确的部分，图表的不精确，排版的问题，等等。 这些问题并不需要加到公开的勘误表中。

对于 1),   我们可以在整理之后，在网上的勘误表中公布（替换掉目前的勘误表，并且把勘误表做成   .htm 文件，不要做成  .doc  文件）。 并且在新版中确保修改正确。

对于 2),    我们可以在新版中修改，但是根据我们的时间，资源，和问题的严重程度，我们并不强求修改所有问题。 希望作者和编辑们能充分沟通，达到共识。