开心一笑
【今天被公司开除了
好难过
事情的起因是我觉得很冤枉的：
昨天领导发通知说：
"明早8：00开会
带好你们吃饭的家伙在办公室集合。"
结果到办公室一看
懵逼了！
同事们都带着笔记本电脑
我特么拿了个碗……】
【茄子甲：大家一起照张合影吧！
众茄子：好啊，好啊！
茄子甲：我喊一二三大家一起喊：人类！
一只茄子好奇地问：为什么要喊“人类”啊？
茄子甲：他们人类照相的时候不是喊“茄子”吗！】
提出问题
项目开发中要注意的各个问题？？？
解决问题
实话说，《程序员修炼之道》真的没有《代码整洁之道》这本书好，它范围广，多少有点失望，这是最后一篇总结，希望大家能喜欢。接下来我会总结《重构-改善既有代码设计》和《并发编程》等一系列的书，希望大家喜欢.....
需求之坑
需求是对需要完成的某件事的陈述。
不要搜集需求，挖掘他们。
完美，不是在没有什么需要增加，而是在没有什么需要去掉时达到的。
找到用户为何要做特定事情的原因，而不只是他们目前做这件事情的方式，这点很重要。
用文档记载需求背后的原因将在每天进行实现决策时给你的团队带来无价的信息。
与用户一同工作，以像用户一样思考
建立需求文档
使用项目词汇表。
项目需求会有很多专有名词，维护它们
不要在盒子外面思考（找到盒子）。
注重实效的团队
不要留破窗户(发现代码问题尽早修复)。
多交流，这是成长的一个重要捷径
不要重复你自己（代码等等）
正交性
围绕功能而不是工作职务进行组织。
无处不在的自动化
一切都要自动化
开发代码，项目构建，项目编译都可以使用现在主流的自动化工具，比如git，Hudson等等开发工具，实现自动化，提高效率
不要使用手工流程
无情的测试
一个注重实效的程序员通常会对自己进行无情的测试。以免以后经常有别人找到我们的bug所带来的耻辱。
早测试，常测试，自动测试。
要到通过全部测试，编码才算完成
测试什么
单元测试，集成测试等等。
测试数据
数据只有两种：现实世界的数据和合成的数据，实际上我们两者都需要，因为这两类数据的不同性质将揭示出我们软件中的不同bug。
演练GUI系统
对测试进行测试
通过“蓄意破话”测试你的测试
彻底测试
测试状态覆盖，而不是代码覆盖
何时进行测试
很多项目往往会把测试留在最后一分钟，我们需要比这早得多的开始测试，任何产品代码一旦存在，就需要进行测试。
把网收紧
如果bug漏过了现有测试网，你需要增加新的测试，以在下一次抓住它。
一个bug只抓一次
一旦测试人员找到了某个bug，这应该是测试人员最后一次发现这个bug，应该对自动化测试进行修改。
全都是写
把英语当作又一种编程语言
为项目制作的文档基本上有两中：内部文档和外部文档。内部文档包括源码注释，设计与测试文档等等，外部文档比如用户手册，不管是什么文档，都是对代码的反映，如果有歧义，代码才最要紧。
把文档建在里面，不要栓在外面
代码中的注释
根据源码中的注释和声明产生格式化文档相当直截了当，但首先我们必须确保在代码中确实有注释，代码应该有注释，但太多的注释可能和太少一样糟。
可执行文档
模型是源码，模型的一种视图可以编译，其他视图意在用于打印或在web上查看，我们的目标是总在模型上工作，不管模型是代码自身还是某种其他文档，并且让所有视图自动更新。
打印还是编排
发布出的书面文档（需求）都有一个固有问题，它刚打印出来，可能就过时了，任何形式的文档都只是快照。
标记语言
文档和代码是同一底层模型的不同视图，不要让文档变成二等公民，对待文档要像对待代码一样用心。
不要做形式方法的奴隶
昂贵的工具不一定能制作成更好的设计
温和的超出用户的期望
在现实中,项目的成功是由它在多大程度上满足了用户的期望来衡量的.不符合用户预期的项目注定失败。
对于需求，要和用户交流期望。
交流期望
与用户进行交流，而不是试图控制用户。
额外的一英里
给他们(用户)的东西要比他们期望的多一点，生活需要惊喜，用户也一样。
傲慢与偏见
在你的作品上签名（在代码上写下你的大名，有很多好处哦！）
你的签名应该视为质量的保证
读书感悟
来自歌德《浮士德》
- 今天做不成的，明天也不会做好。一天也不能虚度，要下决心把可能的事情，一把抓住而紧紧抱住，有决心就不会任其逃去，而且必然要贯彻实行。
- 我要纵身跳入时代的奔走，我要纵身跳入时代的年轮：苦痛，欢乐，失败，成功，我都不问，男儿的事业原本要昼夜不停。
- 自由与命运只垂青每天努力的人。
- 外貌只能徒耀一时，真美方能百世不殒。
- 善良人在追求中纵然迷惘，却终将意识到有一条正途。
- 把心爱的人搂在怀里，乃是一种最好的天赐。
- 人有两只手，一只用来夺走，一只用来给予。
其他
如果有带给你一丝丝小快乐，就让快乐继续传递下去，欢迎转载，点赞，顶，欢迎留下宝贵的意见，多谢支持！
