程序被猫吃了 I
虽然完全不会编程，不过决心还是要看一看编程的哲学啊。这本书叫做
《THE PRAGMATIC PROGRAMMER------FROM JOURNEYMAN TO MASTER》
随手做了一点读书笔记，因为忽略了编程过程中的一些逻辑所以后面有点散乱。
书的出发点是“注重实效”，里面一些道理无论在平时做事做项目，或者之后项目管理什么的，大概都有一点点用吧。
A pragmatic philosophy
Provide options,. Don’t make lame excuse.
切实负起责任。不要说事情做不到，要说明做什么能够挽回局面。
Don’t live with broken windows.
不要留着低略的设计，错误的决策，或糟糕的代码不修。无序的力量是巨大的。
想想自己，当整齐桌面一个角落开始凌乱时，整个桌面就即将沦陷了。
Be a catalyst for change.
在有些情况下，你也许确实知道做什么，怎么做，整个系统就在你的眼前。但是当请求许可去处理这件事情的时候，遭到团队的拖延和漠然。你可以设计出合理要求的东西，默默开发它，完成（哪怕雏形）就拿给大家看。然后说“要是我们增加……就更好”
让人们参与正在发生的成功更加容易。让团队瞥见未来。
Remember the big picture.
要持续不断观察周围发生的事情，而不只是你自己在做的事情。
Invest regularly in your knowledge portfolio.
学习的过程将扩展你的思维
Critically analyze what you read and hear
不要低估商业主义的力量，确保你的知识是准确的。
It’s both what you say and the way you say it
你说什么和怎么说同样重要。
知道你想要说什么 （做出规划、列出大纲，准备几种讲得清楚重点的策略）；
了解你的听众（知道他们兴趣和擅长之处，知道对方的诉求）；
选择时机（找对你说的话有需求的人，在他心情和状态、环境合适的时机）；
选择风格（是正式还是随意，是长还是短，是详还是简，与对方提前确认）；
让文档美观；
让听众参与（让读者参与草稿的制作，获取他们的反馈，这也能建立良好的工作关系 ）；
做倾听者（创造机会让听众说话，并且学会倾听，鼓励他们来提问，或者让他们总结你告诉他们的东西，把会议变成对话）；
回复他人（及时回复邮件和消息，以示尊重）
A pragmatic approach
Don’t repeat yourself.
Make it easy to reuse.
Eliminate effects between unrelated things.
正交性思想（解耦）：提高生产率 降低风险
设计“独立，具有单一、良好定义的目的”的组件
正如如何把项目团队划分为责任得到良好定义的小组，使重叠率降到最低。
There are no final decision.
可撤销性。随着每一项关键决策的做出，可选择的余地越来越小。你应该为可能出现的意外做准备。想想薛定谔的猫，你的代码能支持多少中可能的未来。
Use tracker bullets to find the target.
曳光弹与常规弹药交错着装在弹药带上，发射时曳光弹中的P点燃，点亮燃烧轨道。如果曳光弹射中目标，那么常规子弹也会射中目标。曳光弹快速飞向目标并得到及时反馈。优势在于：
用户能够及早看到能工作的东西（进展可视化）
开发者构建了一个他们能在其中工作的结构（不断丰满、完善）1
集成平台（调试、测试）
你有了可用于演示的东西
你将更能够感觉到工作进展
Prototype to learn.
为了学习而制作原型
原型不同于曳光弹。价值在于所学到的经验教训。可以忽略一些细节，聚焦于某些具体方面。
Estimate to avoid surprise.
估算以避免意外。这一节作者讲了如何进行估算，并且认为应当习惯于估算。
你使用的单位会对结果的解读造成影响，所以根据场景选择单位
理解提问内容，思考问题域的范围
建立系统模型，指粗略、就绪的思维模型
把模型分解为组件，确定其中影响最大的参数
为这些参数赋值，用合理的方式计算这些参数
计算答案
追踪估算，承认错误，下次改进
这样说起来很抽象，但是我们的生活其实常常在估算的啊。
The basic tools
调试的思维
Fix the problem,not the blame.
调试是最最最最最最讨厌的环节了吧，记住调试的第一个准则
Don’t panic.哈哈
使你的数据及其相互关系可视化。跟踪消息。
最好的办法，向别人解释它（这就是为什么要开组会？）
Don’t assume it! Prove it!
不要我以为，而是证明它。
如果修复这个bug要花去很多时间和功夫，问问自己是否可以改进使得下一次修复变得更容易。
Pragmatic paranoia 注重实效的偏执
You can’t write perfect software.
处女座程序员会抓狂吧。
DBC 按合约设计
前条件完全满足，后条件保证会做，约定补偿措施
“对开始之前接受的东西要严格，而允诺返回的东西要尽可能少，或者不允诺交付什么”
一定不要把固定的需求、不可违反的法则与那些仅仅是政策的东西混为一谈。
死程序不说谎。所有的错误都能为你提供信息。
Finish what you start.
谁分配资源，谁释放资源。
《THE PRAGMATIC PROGRAMMER------FROM JOURNEYMAN TO MASTER》
随手做了一点读书笔记，因为忽略了编程过程中的一些逻辑所以后面有点散乱。
书的出发点是“注重实效”，里面一些道理无论在平时做事做项目，或者之后项目管理什么的，大概都有一点点用吧。
A pragmatic philosophy
Provide options,. Don’t make lame excuse.
切实负起责任。不要说事情做不到，要说明做什么能够挽回局面。
Don’t live with broken windows.
不要留着低略的设计，错误的决策，或糟糕的代码不修。无序的力量是巨大的。
想想自己，当整齐桌面一个角落开始凌乱时，整个桌面就即将沦陷了。
Be a catalyst for change.
在有些情况下，你也许确实知道做什么，怎么做，整个系统就在你的眼前。但是当请求许可去处理这件事情的时候，遭到团队的拖延和漠然。你可以设计出合理要求的东西，默默开发它，完成（哪怕雏形）就拿给大家看。然后说“要是我们增加……就更好”
让人们参与正在发生的成功更加容易。让团队瞥见未来。
Remember the big picture.
要持续不断观察周围发生的事情，而不只是你自己在做的事情。
Invest regularly in your knowledge portfolio.
学习的过程将扩展你的思维
Critically analyze what you read and hear
不要低估商业主义的力量，确保你的知识是准确的。
It’s both what you say and the way you say it
你说什么和怎么说同样重要。
知道你想要说什么 （做出规划、列出大纲，准备几种讲得清楚重点的策略）；
了解你的听众（知道他们兴趣和擅长之处，知道对方的诉求）；
选择时机（找对你说的话有需求的人，在他心情和状态、环境合适的时机）；
选择风格（是正式还是随意，是长还是短，是详还是简，与对方提前确认）；
让文档美观；
让听众参与（让读者参与草稿的制作，获取他们的反馈，这也能建立良好的工作关系 ）；
做倾听者（创造机会让听众说话，并且学会倾听，鼓励他们来提问，或者让他们总结你告诉他们的东西，把会议变成对话）；
回复他人（及时回复邮件和消息，以示尊重）
A pragmatic approach
Don’t repeat yourself.
Make it easy to reuse.
Eliminate effects between unrelated things.
正交性思想（解耦）：提高生产率 降低风险
设计“独立，具有单一、良好定义的目的”的组件
正如如何把项目团队划分为责任得到良好定义的小组，使重叠率降到最低。
There are no final decision.
可撤销性。随着每一项关键决策的做出，可选择的余地越来越小。你应该为可能出现的意外做准备。想想薛定谔的猫，你的代码能支持多少中可能的未来。
Use tracker bullets to find the target.
曳光弹与常规弹药交错着装在弹药带上，发射时曳光弹中的P点燃，点亮燃烧轨道。如果曳光弹射中目标，那么常规子弹也会射中目标。曳光弹快速飞向目标并得到及时反馈。优势在于：
用户能够及早看到能工作的东西（进展可视化）
开发者构建了一个他们能在其中工作的结构（不断丰满、完善）1
集成平台（调试、测试）
你有了可用于演示的东西
你将更能够感觉到工作进展
Prototype to learn.
为了学习而制作原型
原型不同于曳光弹。价值在于所学到的经验教训。可以忽略一些细节，聚焦于某些具体方面。
Estimate to avoid surprise.
估算以避免意外。这一节作者讲了如何进行估算，并且认为应当习惯于估算。
你使用的单位会对结果的解读造成影响，所以根据场景选择单位
理解提问内容，思考问题域的范围
建立系统模型，指粗略、就绪的思维模型
把模型分解为组件，确定其中影响最大的参数
为这些参数赋值，用合理的方式计算这些参数
计算答案
追踪估算，承认错误，下次改进
这样说起来很抽象，但是我们的生活其实常常在估算的啊。
The basic tools
调试的思维
Fix the problem,not the blame.
调试是最最最最最最讨厌的环节了吧，记住调试的第一个准则
Don’t panic.哈哈
使你的数据及其相互关系可视化。跟踪消息。
最好的办法，向别人解释它（这就是为什么要开组会？）
Don’t assume it! Prove it!
不要我以为，而是证明它。
如果修复这个bug要花去很多时间和功夫，问问自己是否可以改进使得下一次修复变得更容易。
Pragmatic paranoia 注重实效的偏执
You can’t write perfect software.
处女座程序员会抓狂吧。
DBC 按合约设计
前条件完全满足，后条件保证会做，约定补偿措施
“对开始之前接受的东西要严格，而允诺返回的东西要尽可能少，或者不允诺交付什么”
一定不要把固定的需求、不可违反的法则与那些仅仅是政策的东西混为一谈。
死程序不说谎。所有的错误都能为你提供信息。
Finish what you start.
谁分配资源，谁释放资源。
还没人转发这篇日记
