标签：
这段时间读完了《程序员修炼之道》这本书，现总结如下：
每一个程序员似乎都必须在其职业生涯的早期记住一段曼特罗（mantra）。它是计算技术的基本原则，是我们学着应用于需求、设计、代码、注释——也就是我们所做的每一件事情——的核心信仰。那就是：
这决不会发生……
“这些代码不会被用上30年，所以用两位数字表示日期没问题。”“这个应用决不会在国外使用，那么为什么要使其国际化？”“count不可能为负。”“这个printf不可能失败。”我们不要这样自我欺骗，特别是在编码时。
测试是为了保障代码的质量。所以越是仔细，全面的测试，越是有助于系统的健壮，不负责任的程序员或者测试，总是拿着可以正常运行的数据来进行着测试。有条件还是需要专职的测试，合格的测试，而不是那种连代码都看不懂的刚毕业的小姑娘。
书中提到两种依靠巧合编程的典型：实现的偶然与隐含的假定。实现的偶然就是在使用新技术、三方库或者其它人写的模块时，拼凑的代码碰巧工作了，那么我们就宣告胜利结束编码。当这些代码出问题时，通常会一头雾水，因为当初根本不明白它为什么会工作。隐含的假定是开发者使用自以为的前提，而实际上没有任何文档或者现实数据可以依靠。我曾经遇到过这样让人哭笑不得的经历：代码依赖了某个存在已久的bug的错误表现，当这个bug最终被修复时，原本运行良好的代码反而出现了问题。我们常说“踩坑”，这些坑可能是前人用巧合编程留下的，也可能是因为我们依靠了巧合编程而引起的。
用户的需求描述可能是：只有员工的上级和人事部门才可以查看员工的档案。经过挖掘的需求：只有指定的人员才能查看员工档案。前者把规则硬性的写入了需求，但规则经常会改变。后者的优点是需求描述为一般性陈述，规则独立描述，这样规则可以成为应用中的元数据。在实现时可以把需求理解为：只有得到授权的用户可以访问员工档案，开发者就可能会实现某种访问控制系统。规则改变时，只有系统的元数据需求更新，以这样的角度去实现需求，得到的自然就是支持元数据、得到了良好分解的系统。但也要注意避免过度设计，需求也许就是那么简单。
如果结合自己的项目经历，就会对书中提到的深有同感，可以将自己的经验和教训有意识变成自己的知识、本能，而那些自己还未接触到的方法，知识可以扩展自己视野，去吸收、利用。当然有感而发，最终是需要身体力行，才能成为一名真正的注重实效的程序员。
标签：
原文地址：http://www.cnblogs.com/xiaojin123/p/4463635.html
