设计文档里的圆圈和箭头用来解释他们指代的作用，但这还有可能是推翻我们原先设定的证据。感觉这个是承接上一节的内容，不要被以前的假设和设计所限制，留有一定的弹性空间。
我们相信，盲目地采用任何技术，而不把他们放进你的开发实践和能力的语境中，这样的处理日后可能会让你后悔。
不要迷信工具以及各种方法学，注重实效的程序员会批判地看待他们，并从中提取精华，融合成每个月都在变得更好的一套工作习惯。
解开不可能的问题：对于问题的约束有真正的约束，也有一些是表面上的约束。要找到那些真正意义上的约束并给予尊重，对表面上的约束可以适当予以摒弃。
解决“不可能的问题”时，可以问自己这些问题：有更容易的方法吗？我是在解决实际问题还是被技术细节转移了注意力？这件事情为什么是一个问题？什么使它难以解决？它必须以这种方式完成吗？它真的必须完成吗？
等你准备好：有时候要依靠直觉，直觉觉得仍有疑虑时不该开始。为了将疑虑与单纯的拖延区分，可以通过开始构建原型检查自己的疑虑在什么地方，或者自己只是单纯懒于工作。
规范陷阱：规范重要，但不应归于细致流于琐碎。自然语言本身十分晦涩，过于琐碎的规范往往不能精确地描述意图描述的细节，而且会限制程序员的发挥空间。
圆圈与箭头：通过形式方法描述项目很流行，但有一些缺点：1. 形式化的表达需要由人来阐释含义，不如原型的展示清楚明白。2. 形式方法似乎鼓励专门化，但专门化会带来人力的浪费和不好的编码体验。一个小组应该分工，但不应该被分裂成几个不必要的部分。每个人都应该了解项目系统的大体。3. 形式方法往往无法描述系统的动态性。
形式方法只是一个工具，可以使用，但不要被限制。……事实上这个原则似乎适用于所有工具，包括ide、语言、框架等。
书籍的前几章讲了几条如何成为注重实效的开发者的建议，当然他们也对团队有所帮助，如果个体都是注重实效的，那他对整体起的作用更大。
不要留破窗户：作为整体的团队更不应该容忍代码质量的问题，不规范的不在乎质量的团队，很有可能把那些注重实效的开发者带偏。
煮青蛙：整体中的个人更难觉察到作为团队所存在的问题，可以指定一个“检测员”，让他去检查团队整体进度，依赖项的准备情况，各个环节的配合等内容。
交流：杰出的项目团队往往有着截然不同的个性，更能与其他团队进行配合。有一个简单的帮助团队凝聚力的方法：创立团队品牌，以品牌代指整个团队。
不要重复你自己（DRY）：由于个人理解程度的不同或者新成员的加入，团队总会面临重复的内容，适当的指派一名管理员，让他专门维护这些资料，所有对此有疑问的人都不必自我寻找，只要去找管理员就行了。
正交性：对于较大的团队，更应该通过功能进行组织划分，而不是工作职务。比如开发多个项目，会有多名开发，多名测试，多名设计，他们之间更应该按照具体项目进行划分，一个项目的开发，测试和设计为一个小团体。
自动化：确保一致性和准确的一种很好的方式是使团队所做的每件事情都能自动化，如果还没有做到那就尝试去做。
知道如何停止绘画：团队是由个体组成的，给每个成员足够的空间，并支持他们，而不是一直给他们具化各种需求。
注重实效的程序员会受到找到自己 bug 的驱使，以免以后经受由别人找到我们 bug 带来的羞耻。
早测试，常测试，自动化测试。要通过全部测试，编码才算完成。
测试主要围绕三个方面进行：测试什么、怎样测试、何时测试。
测试什么。测试类型有以下这些：
- 单元测试：单元测试是函数级，有时也算做模块级的测试，要保证他们都正常通过。
- 集成测试：组成项目的子系统能工作，且它们之间能很好的协同。
- 验证和校验：这个类似AB测，是产品层面的测试。
- 异常测试，资源耗尽，错误情况，如何恢复等。
- 性能测试，压力测试，负载测试：这些情况通常是服务器相关的测试流程。
- 可用性测试：也是产品项的测试，需要分析和调研，需求是否是有用的。
怎样测试。主要介绍有哪些测试方法：
- 回归测试：回归测试通常是测试的后面阶段，新旧功能一起测试，新功能不应该影响旧功能。
- 测试数据：对于一些特殊场景，测试数据能起到很大帮助，比如需要大量数据，强调边界条件的数据，能展现特定字段的数据等。
- GUI系统：UI通常不好测试，所以应该做好解耦，将逻辑和视图拆分开进行测试。
- 对测试进行测试：故意制造一些bug，观察你的测试系统能否发现。
- 彻底测试：这里需要强调的是测试覆盖率，这其中需要强调的是测试状态的覆盖，而不是代码覆盖。要对不同状态都覆盖到。
何时进行测试。尽早测试，而且测试应该是自动完成的，我们在提交代码时就应该保证测试已经全部通过。
标签：应该,第一篇,小工,注重实效,程序员,测试,团队,bug From： https://www.cnblogs.com/Arkiya/p/16996517.html