摘要：
QA应该找不到任何错误 QA也是团队的一部分 QA和开发人员应该紧密协作，携手保障系统的质量。 QA在团队中要扮演的便是需要规约定义者（specifier）和特性描述者（characterizer）。 需求规约定义者 QA的任务便是和业务人员一起创建自动化验收测试，作为系统真正的需求规约文档。 业务 阅读全文
摘要：
需求的沟通 开发方与业务方之间最常见的沟通是关于需求的。业务方描述他们认为自己需要的东西，程序员按照自己理解的业务方表达的需求来开发。 在现实里，关于需求的沟通是极其困难的，其中会出现各种问题。 过早精细化 做业务的人和写程序的人都容易陷入一个陷阱，即过早进行精细化。 1、不确定原则 每次向业务方展 阅读全文
摘要：
编程柔道场 卡塔：编程卡塔是一整套敲击键盘和鼠标的动作，用来模拟编程问题的解决过程。 瓦萨：两个人的卡塔。一个人负责攻，另一个人负责守。 自由练习：很像由两个参与者解决问题的瓦萨，也可以有多人参与。 自身经验的拓展 职业程序通常会受到一种限制，即所解决问题的各类比较单一。老板通常只强调一种语言、一种 阅读全文
摘要：
此事已有定论 TDD绝不仅仅是一种用于缩短编码周期的简单技巧。 每个开发人员都要适应和掌握TDD。 TDD的三项法则 1、在编好失败单元测试之前，不要编写任何产品代码。 2、只要有一个单凶测试失败了，就不要再写测试代码；无法通过编译也是一种失败情况。 3、产品代码恰好能够让当前失败的单元测试成功通过 阅读全文
摘要：
要精熟掌握每项技艺，关键都是要具备“信心”和“出错感知”能力。 做好准备 在编码时必须平衡互相牵制的多种因素 1、代码必须能够正常工作。 2、代码必须能够帮你解决客户提出的问题。 3、代码必须要能和现有系统结合得天衣无缝。 4、其他程序员必须能读懂你的代码。 凌晨3点写出的代码 疲劳的时候，千万不要 阅读全文
摘要：
承诺用语 口头上说。心里认真。付诸行动。做出承诺，包含三个步骤 1、口头上说自己将会去做。 2、心里认真对待做出的承诺。 3、真正付诸运行。 识别“缺乏承诺”的征兆 在承诺做某事时，应当留意自己的用词，因为这些用词透露了我们对待承诺的认真程度。 真正的承诺听起来是怎样的 对自己将会做某件事做了清晰的 阅读全文
摘要：
对抗角色 要做出艰难决定的时候，存在对抗角色间的冲突于此是最为有利的。 “为什么”远不如“事实”重要。事实是功能还需要两个星期才能完成。而为什么需要两个星期，则只是个细节。 高风险时刻 最要说“不”的是那些高风险的关键时刻。 要有团队神精神 有团队精神的人不会总是说“是”。 试试看 许诺“尝试”，意 阅读全文
摘要：
担当责任 “专业主义”就意味着担当责任，不但象征着荣誉与骄傲，而且明确意味着责任与义务。 不行损害之事 1、不要破坏软件功能 1）让QA找不出任何问题，发布软件时，你应该确保QA找不出任何问题。 2）要确信代码正常运行，要求进行百分百测试覆盖，可以使用测试驱动开发（TDD）。 3）自动化QA，自动化 阅读全文
摘要：
注释 C1：不恰当的信息 让注释传达本该更好地在源代码控制系统、问题追踪系统或任何其他记录系统中保存的信息，是不恰当的。注释只应该描述有关代码和设计的技术性信息。 C2：废弃的注释 过时、无关或不正确的注释就是废弃的注释。 C3：冗余注释 如果注释描述的是某种充分自我描述了的东西，那么注释就是多余的 阅读全文
摘要：
为什么要并发 并发是一种解耦策略。它帮助我们把做什么（目的）和何时（时机）做分解开。解耦目的与时机能明显地改进应用程序的吞吐量和结构。 迷思和误解 1、并发总能改进性能：并发只在多个线程或处理器之间能分享大量等待时间的时候才能改进性能。 2、编写并发程序无需修改设计：并发算法的设计有可能与单线程系统 阅读全文