48、为测试而设计
Design to Test
在你还没有编写代码时就开始思考测试问题。
49、测试你的软件，否则你用户就的测试
Test Your Software,Or Your Users Will
无情地测试。不要让你的用户为你查找bug。
50、不要使用你不理解的向导代码
Don't Use Wizard Code You Don't Understand
向导可以生成大量代码。在你把你们合并进你的项目之前，确保你理解全部这些代码。
51、不要搜集需求——挖掘它们
Don't Gather Requirements - Dig for Them
需求很少存在于表面上。
它们深深地理解埋藏在层层假定，误解和政治手段的下面。
52、与用户一同工作，以像用户一样思考
Work with a User to Think Like a User
要了解系统实际上将如何被使用，这是最好的方法。
53、抽象比细节活得更长久
Abstractions Live Longer Then Details
“投资”于抽象，而不是实现。
抽象能在来自不同的实现和新技术的变化的“攻击”之下存活下去。
54、使用项目词汇表
Use a Project Glossary
创建并维护项目中使用的专用术语和词汇的单一信息源。
55、不要在盒子外面思考——要找到盒子
Don't Think Outside the Box - Find the Box
在遇到不可能解决的问题时，要确定真正的约束。
问问你自己：“它必须以这种方式完成吗？它真的必须完成吗？”
56、等你准备好再开始
Start When You‘re Ready
你的一生都在积累经验。不要忽视反复出现的疑虑。
57、对有些事情“做”胜于“描述”
Some Things Are Better Done Than Described
不要掉进规范的螺旋——在某个时刻，你需要开始编码。
58、不要做形式方法的奴隶
Don't Be a Slave to Formal Methods
如果你没有把某项技术放进你的开发实践和能力的语境中，
不要盲目地采用它。
59、昂贵的工具不一定能制作出更好的设计
Costly Tools Don't Produce Better Designs
小心供应商的炒作，行业教条、以及价格标签的诱惑。
要根据工具的价值判断它们。
60、围绕功能组织团队
Organize Teams Around Functionality
不要把设计师与编码员分开，也不要把测试员与数据建模员分开。
按照你构建的方式构建团队。
61、不要使用手工流程
Don't Use Manual Procedures
shell 脚本或批文件会一次次地以同一顺序执行同样的指令。
62、早测试，常测试，自动测试。
Test Early，Test Often. Test Automagically
与呆在书架上的测试计划相比，每次构建时运行的测试要有效得多。
63、要到通过全部测试，编码才能算完成。
Coding Ain't Done ‘Til All The Tests Run
就是这样。
64、通过“蓄意破坏”测试你的测试
Use Saboteurs to Your Testing
在单独的软件副本上故意引入bug，以检验测试能够抓住它们。
65、测试状态覆盖，而不是代码覆盖
Test State Coverage，Not Code Coverage
确定并测试重要的程序状态。
只是测试代码行是不够的。
66、一个bug只抓一次
Find Bugs Once
一旦测试员找到bug，这应该是测试员最后一次找到它。
此后自动测试应该对其进行检查。
67、英语就是一种编程语言
English is Just a Programming Language
像你编写代码一样编写文档：
遵守DRY原则、使用元数据、MVC、自动生成等等。
68、把文档建在里面，不要拴在外面
Build Documentation In. Don't Bolt It On。
与代码分离的文档不太可能被修正和更新。
69、温和地超出用户的期望
Gently Exceed Your Users' Expectations
要理解你的用户期望，然后给他们的东西要多那么一点。
70、在你的作品上签名
Sign Your Work
过去时代的手艺人为能在他们的作品上签名而自豪，你也应该如此。
网友评论