这周好闲啊！啊哈哈！

随便扯扯

快递到了，我滴小零食吼吼！开心！

其中很深刻的话

• 完美，不实在没有什么需要增加，而是再没有什么需要去掉时达到的。

• 不要搜集需求---挖掘它们。

• 与用户一同工作，以像用户一样思考。

• 需求不是架构，需求不是设计，也不是用户界面，需求是需要。

• 抽象比细节活的更长久。

• 使用项目词汇表。

• 不要在盒子外面思考--要找到盒子。

• 有时犹豫的人会得以保全。

• 倾听反复出现的疑虑。

• 有些事情“做”胜于“描述”。

• 不要做形式方法的奴隶。

• 昂贵的工具不一定能制作出更高的设计。

• 围绕功能，而不是工作职务进行组织。

• 文明通过增加我们不假思索就能完成的重要操作的数目而取得进步。

• 不要使用手工流程。

• 早测试，常测试，自动测试。

• 要到通过全部测试，编码才算完成。

• 测试什么？单元测试、集成校验、验证和校验、资源耗尽、错误及恢复、性能测试、可用性测试、

• 通过蓄意破坏，测试你的测试。

• 测试状态覆盖，而不是代码覆盖。

• 一个 bug 只抓一次。

• 好记性不如烂笔头。

• 把英语当做又一种编程语言。

• 把文档建在里面，不要拴在外面。

• 温和的超出用户的期望。

• 让一般用户觉得很好的特性包括：气球是帮助或工具提示帮助、快捷键、作为用户手册的补充材料的快速参考指南、彩色化、日志文件分析器、自动化安装、用于检查系统完整性的工具、运行系统的多个版本、已进行培训的能力、为他们的机构定制的 splash 屏幕。

• 你愉悦我们已经足够长久。

随便写点笔记吧

第七章 在项目开始之前

1 需求之坑

了解好需求，才能避免事倍功半。

2 解开不可能解开的迷题

有时候问题的解决需要跳出常规的思维。或者简单一点，用另外一种方法，而不是钻牛角尖。

3 等你准备好

不打无准备的仗。

4 规范陷阱

不要等万事具备才开始，因为不可能万事具备，用户总是在变。

5 圆圈与箭头

工具是拿来帮助加快开发，而不是束缚开发的。各种各样眼花缭乱的UML，其实只是为了能够清晰描述设计者的思想。

第八章 注重实效的项目

6 注重实效的团队

项目开发就脱不开团队，个人的项目除了兴趣爱好，还没听说过。团队重要性不言而喻，以往的经历告诉我一个合理的团队让人觉得有归属感，反之，就容易萌生去意。一起喝着可乐，听着破喇叭放出的音乐，并且加着班的团队在多年以后的记忆里面显得那么的美。

6 无处不在的自动化

程序的目的之一就是让原本繁琐复杂的重复劳动自动化的处理，而软件开发过程中也一样需要自动化。我一直坚信别人说过的一句话：凡是有人参与的过程，肯定会产生错误。所以，我也一直坚持能让机器去做的事情就交给机器，以减少人的参与，减少错误的发生几率。在过去，我尝试了多次为某些任务编写简单的程序来自动化处理，虽然，我的计划上，没有写一个程序这样的描述，但是，写程序自动处理更好，更有效，最重要的是，还能再次重复预设的动作。此外其他的自动化工具也是很值得推荐，比如自动化测试，代码生成器。

7 无情的测试

测试是为了保障代码的质量。所以越是仔细，全面的测试，越是有助于系统的健壮，不负责任的程序员或者测试，总是拿着可以正常运行的数据来进行着测试。有条件还是需要专职的测试，合格的测试，而不是那种连代码都看不懂的刚毕业的小姑娘。

8 全都是写

文档和注释。自认为注释方面还过得去，但是有些情况下还是会忽略注释而后期弥补，这一点需要改正。 至于文档倒是需要好好努力的，这样能显的更“专业”，能更好的记录代码的情况。

9 极大的期望

达到客户的期望，才是软件真正的成功。

10 傲慢与偏激

很cool的名字，不是吗?

其实只是指了一个小事情，在你的代码上面留下你的足迹。对于自己，对于队友，都是很重要的好习惯，当别人发现有问题时，可以马上过来问我：嘿，为什么会有这个问题。他可以节约自己的时间，我也可以有机会再一次增加自己的经验。而且留下自己的痕迹，也留下一份责任心，不负责任的人，马上就能被发现。

结束语

至此，终于把这本书看完了一遍，当然最后的附录和答案没看。

看完之后收获很多，并不是代码能力得到了多大的提高，而是提高了自己的眼见和格局，对程序员有了更清醒更清晰的认识。

说实在的，其实好多地方看的都是一知半解，甚至有的时候看不懂，或许得在工作实践中慢慢体会和理解了！