今天看完了《程序员修炼之道--从小工到专家》，挑些我觉得有意义的能指导我工作的小点，总结下。
首先要承认几个注重实效的哲学，类似于我们所说的公理。如果不承认这个哲学的话，后面所罗列的方法都没有意义。
注重实效哲学：
1） 我的源码让猫给吃了。敢于承担责任，不要找各种蹩脚的借口。不要说事情做不到，说明能够做什么。
2） 软件的熵。破窗理论。不要留着“破窗户”（低劣的设计，糟糕的代码，错误的决策）不修，发现一个修复一个，如果没有足够的时
间，就用注释把有问题的代码注释起来，或者加上to_do的消息，总之要采取行动防止进一步破坏。
3） 石头汤与煮青蛙。做变化的催化剂。你不能强迫人们改变。但是，你可以向他们展示未来可能会怎么样，并且帮助他们创造未来，一个
双赢的未来。
4） 足够好的软件。让你的用户来权衡，不要总想着把最完美的软件交付给客户，不存在完美的软件。
5） 知识资产。知识资产和金融资产非常相似。
a：严肃的定期投资计划-->定期投资，养成学习的习惯，不断的学习。
b：多元化是成功的关键-->了解目前所用技术的特性，向更宽广的范围涉猎。
c：投资权衡风险--> 我们要管理好风险，不要把所有的技术鸡蛋放在同一篮子里。
d：投资者低买高卖。-->养成快速学习的能力，抵抗技术学习带来的风险。
e：周期性的评估和平衡资产-->平时自己多做总结，自己哪些方面特长，如何巩固；哪些方面短板，如何补齐。
定期为自己的知识投资的方式方法：
a：每年至少学习一门新的语言，不同的语言，不同的解决问题的方式，可以拓宽自己的思维，不墨守成规。
b：每个季度阅读一本技术书籍。养成读书的习惯，一个月读一本技术相关的书籍。
c：也要读非技术的书籍，管理学，营销，心理学，经济学，掌握用户的习惯，同时也提高自己的素养能力水平。
d：上课，参加不同的学术交流组织。寻找自己感兴趣的议题，上网关注新技术的发展。
e：更上潮流，多试验不同的平台和IDE等。
f：多看报纸和杂志等，比如《程序员》，比如《IT经理世界》，要学好英语。
6） 交流。多交流，交流的越有效，你就越有影响力。
注重实效的途径
1）DRY原则。把重复抽取出来，最好能达成复用。
2）正交性原则。不相关的代码尽量减少依赖。设计自足，独立，并具有单一，良好定义的目的的组件。
3）可撤销性。没有决策时浇铸在石头上的。相反，要把每项决策都视为写在沙滩上的，并为变化做好计划。
4）曳光弹。试探性开发，如果你不知道目标的话。找到方法后，先搭个架子，一点点完善后面的事情。
5）原型与便签。原型和曳光弹不同，原型是为了学习做实验，用过了就可以扔掉。
6）领域语言。用你的用户的领域的语言进行设计和编码。
7）估算。高手应该是将估算的技能发展到对事物的数量级有直觉的程度，确定他们的可行性。
如何估算：
a：理解提问的内容，把握问题域的范围。
b：建立系统的模型。
c：把模型分解为组件，更细粒度的分解。
d：确定先后依赖关系，输入输出参数。
e：计算出估算的结果，并跟踪估算的结果，对结果负责，如果有错的话，自己多总结。
基本工具。
工具放大你的才干，工具相当于手的延伸，工具用的越好，工作越熟练，效率越高。
1）纯文本的威力。纯文本保存的东西不会过时，更易于测试，成功的例子就是Unix、Linux操作系统。
2）shell的力量。当GUI解决的步骤比较繁琐的时候，换种思路，看看shell可以解决问题不。
3）强力编辑。要熟练掌握一种文本操纵工具，比如vi，比如awk，比如sed，等等，一定精通一个。
4）源码控制。这种事情大家都知道，罗列到这里，罗嗦了。
5）调试的心理学，要发现问题，而不是职责，应该以积极的心态面对bug这种事情，早发现比上线发现好。
注重实效的偏执。
1）按照合约进行设计。客户和供应者必须就权利和责任达成共识。
2）死程序不说谎。早点崩溃，因为这样，可以尽早的发现问题，而不是把留有问题的软件交付给客户。
3）断言式编程。如果它不可能发生，用断言确保它不会发生。
4）将异常用于异常的问题。
5）注意资源的清理和回收。比如io使用后要记得关闭。
弯曲或者折断
1）低耦合高内聚。面向接口编程。
2）元程序设计。将抽象放进源代码，将细节放到元数据。要尽量把变化的东西做成可以配置。
3）时间的耦合。注意并发编程。了解客户的工作流程，合理利用并发。
4）MVC的设计模式，让视图与模型分开。
模型：表示目标对象的抽象数据模型。模型对任何视图或者控制器都没有直接了解。
视图：模型的展示方式，解释模式的方式。它订阅模式的变化和接受来自控制器的逻辑事件。
控制器：控制视图，并向模型提供新数据的途径。
5）黑板。使用黑板协调完全不同的事实和因素，同时又使各方保持隔离和独立。
当你编码时
1）不要靠交合编程。不要认为程序应该就是这样，要有计划，并作充分有计划的测试。
2）算法的效率。每个开发都应该具有开发和设计算法的能力，我们很多人都不具备这个能力。
3）重构。软件工程不像盖高楼大厦，更像是园艺工程，需要不断的维护调整更新迭代。
重构的原则：不要在重构的时候视图增加新的功能。
开始重构之前，确保你拥有良好的测试，并为此做好了准备。
采取短小，深思熟虑的步骤，然后每个小步骤完成后都进行测试。
4）易于测试的代码。针对合约进行测试用例的设计，把单元测试用例整理起来，养成测试的良好习惯。
在项目开始之前
1）需求之坑。完美，不是在没有什么需求可以增加，而是在没有什么需要去掉时达到。
不要搜集需求，发掘他们。和用户一起工作，从而能够像他们那样思考。
管理需求增长的关键是向项目出资人说明每项新特性对项目进度的影响。
2）解开谜题。有的时候加给你的约束很多，自由度很少，这就是解不开的谜题。
对付的方法：要挑战自己的先入之见，并且评估他们哪些是真正的约束，哪些是令人误解的约束，并且区分他们。
3）等你准备好。倾听反复出现的疑虑，等你准备好再开始。软件开发还不是科学，让你的直觉为你的表演加分。
4）规范的陷阱。应该把需求收集，设计，以及实现视为同一个过程的不同方面，采用无缝的方法编写规范和设计实现的代码。
5）批判的对待方法学，并从各种方法学中提取精华，融合成自己每个月都在变好的好习惯。不断提炼改善开发过程。
绝不要把方法学的呆板限制当做你的世界的边界。不要向方法的虚假权威屈服。
注重实效的项目团队
1）注重实效团队的表现。
不要留“破窗户”，一定要严把质量关，每个人都要有质量意识。
煮青蛙。即使在项目开发最火热的时候，也不要忘记观察需求等的变化。
交流。有自己项目比较容易记住的名字，还要创个logo，很可爱好笑的那种。
不要重复你自己，专人专责。
围绕功能，而不是围绕工作的职务组织团队。
自动化。技术经理可以做好自动化的培训和搭建工作，鼓励大家的开发热情。
让每个成员都以他们自己的方式闪亮，但是要注意无限制下去的诱惑。
2）无情的测试。
早测试，常测试，自动化测试。不一定要提交代码之后才可以测试。
要到全部通过测试，编码工作才算全部完成。
单元测试，集成测试，性能测试，可用性测试。
3）文档很重要。
程序员的文档中要有注释，这样更方便后来的维护，对自己也是一种鼓励，因为有这样一个让自己完美的机会。
技术文档的撰写。不一定是专门的文档撰写人员，程序员也要参与，虽然写文档的过程很痛苦。
4）和用户交流期望，温和的超出用户的期望。