4月19日要交的读书笔记

（我也很难分清楚这理论上应该是第几次随笔了）

40， 圆圈与箭头
第一次个人作业的时候讲过类似的方法，但是不是在对用户调查需求这一层次上
人类的交流方式相比计算机实在是充斥着误码、解析错误，人类贫乏的想象力根本不足以脑补大部分的这些差错，讲道理，有时候大白话+例图比那些严谨的调查描述能更有效的缓解“用户不懂需求”这个问题
至于别的形式方法，我们的团队用很多结构图来描述游戏里的各个部分关系
第八章 注重实效的项目
41，注重实效的团队
别当破窗者，小拖延症同学，你有摧毁你们团队维持良好的时间纪律性的“潜力”
重复的问题，在团队里你用统一表述的文档来取代一个一个去解释，效果还行，只是需要再修正一些开发实际过程中发现的可能存在歧义的部分
知道何时停止绘画：画饼同学已经不画新饼了，正在慢慢填坑，耶
42，自动化
还行，这个结对编程作业里，上个星期提到了很多关于自动配置运行的问题
在需要保持均一性和效率的时候，把人类全部当成傻子（和自动流程比起来确实是的）
就是这样
已经开始在DWCC里使用一些自动语句生成工具了，他们真的是非常非常好用！
43，无情的测试
哈，你从结对里学会写单元测试搞自动测试了！（摆脱了手工写样例的脑残体验）
集成测试是什么，学习
“体面地fail”“有意义的failure”是一个很重要的思想，程序运行哪怕真的到了无法挽救的失败地步也不能毫无动作地has stopped working（至少，日志和最后状态要发给服务器）
回归测试：新的代码会不会破坏一些本来安全的代码？
不能仅关注人工合成的测试样例，现实中的样例有其自身特点，找出这个特点，对你的软件会有极大帮助（比如说，单词统计里，要求支持1024长的单词，合成样例中可能存在大量上千长度的单词以进行测试，但是如果考虑到现实中单词普遍的长度特征进行优化（比如，默认使用32长，仅在超长的情况下申请1024长的空间）应该就能起到优化的作用）
测试工具本身也要有测试，要蓄意破坏它
测试要尽早，bug要一次解决
44，全都是写
可执行文档需要写一堆宏吗
45，极大的期望
过大地超出用户期望也会引来失败这是什么原理？
我能猜到的其中一个原因是增加使用复杂度？
46，傲慢与偏见
明确自己负责的部分，并且做好它
第九章
今天就先到这里吧