程序员修炼之道_程序员的修炼之道

第一章 ：注重实效的哲学

1，要提供各种选择，而不是找借口，不要说事情做不到；要说明能够做什么来挽回局面。
2，你可以训练你自己，编写足够好的软件。
3，如果你给用户某样东西，让他们及早使用，他们反馈常常会把你引向更好的最终解决方案。让你的代码凭着自己的质量站立一会儿。它也许不完美，但不用担心：它不可能完美。
4，定期为你的知识资产投资：

• a，每年至少学习一种新语言。
• b，每季度阅读一本技术书籍。
• c，也要阅读非技术书籍。
• d，了解某种新语言或其他技术。

5，让文档美观，对于不同职业的人，采用不同的语言表达，确保他们知道你要做什么。交流越有效，你的影响力才越大。

第二章 ：注重实效的途径

1，我们都是在一个时间和资源有限的世界上工作，如果你立于善于估计出事情需要多长时间完成，你就能更好地在两者都很匮乏的情况下生存下去
2，设计代码要：避免重复，提高复用，保证组件的正交性（任何组件的改变，都不会影响其它组件）
3，维持正交性：

• a，让你的代码保持解耦；
• b，避免使用全局数据；
• c，避免编写相似的函数
  4，（在这个时效就一切的时代，应快速实现主要功能，让客户看到这是否是他想要的，在这个基础上再叠加一些细节功能）
  5，（在不确定需求，用户想要什么的时候，应该先制作一个原型给用户看，原型不需要注意安全性，健壮性，正确性） 6，估算项目进度：
• a，检查需求；
• b，分析风险；
• c，设计、实现、集成；
• d，向用户确认

第三章 ：基本工具

1，Cygwin 工具： 在windows操作系统上实现了uinx的命令操作 > 2，Emacs 工具：一个好的编辑器，它需要有这几种特性：

• a，可配置（使用键盘操作）、
• b，可扩展（支持文本格式，例如：xml、html）、
• c，可编程(语法突现)

3，（调试BUG ：可以先从两端开始，然后再调试中间） 4，代码生成器 ：

• a，被动代码生成器只运行一次来生成结果，然后结果就变成了独立的—它与代码生成器分离了。（可理解为IDE工具中输入首字母后提示关键字）
• b，主动代码生成器在每次需要其结果时被使用，结果是用过就扔的-----它总是能由代码生成器重新生成。

第四章 ：注重实效的偏执

1，（合约：JAVA代码的规范。）
2，（断言：检查JAVA代码的正确性，打断点调试）
3，（异常：处理问题的一部分）
4，（配平资源：例如：数据库连接，查询完数据，要及时关闭连接）

第五章 ：弯曲或折断

1，使耦合减到最少（低耦合）
2，元数据驱动的应用：我们想要推迟大多数细节的定义，直到最的时刻，并且尽可能让细节保持“软和”—尽可能易于改动（例如bean)
3，时间解耦：

• a，（考虑并发：那些功能是同时发生的（相互影响），那些可以并行发生（互不影响）
• b，并发系统中：在被调用时，对象必须总是处在有效的状态中（避免构造器没有使对象进入已初始化状 态）

4，程序模块

• a，不要把程序写成一个大块，而应该“分而治之”，把程序划分成模块。
• b，模块（或类）一个好定义就是，它具有单一的，定义良好的责任。

5，黑板：（做好功能分类，一个功能包含一类）

第六章 ：当你编码时

1，怎样深思熟虑地编程

• a，总是意识到你在做什么
• b，不要盲目地编程（试图构建你不完全理解的应用，或是使用你不熟悉的技术）
• c，按照计划行事，
• d，依靠可靠的事物，不要依靠巧合或假定。
• e，为你的假定建立文档（有助于澄清你头脑中的假定，并且有助于把它们传达给别人）
• f，不要只测试你的代码，还要测试你的假定。
• g，为你的工作划分优先级。（把时间花在重要的方面：很可能，它们是最难部分。如果你的基本原则 或基础设施不正确，再好的代码也没有用）
• h，不要做历史的奴隶。(不要让已有的代码支配将来的代码）

2，常识估算（按阶层来–a方案->b方案->c方案……）

• a，简单循环：如果某个简单循环从1运行到n,那么算法很可能就是O(n)。
• b，嵌套循环：如果你需要在循环中嵌套另外的循环，那么你的算法就变成了O(m * n)。
• c，二分法：如果你的算法在每次循环时把事物集合一分为二，那么它很可能是对数型O(lg(n)。
• d，分而冶之：划分其输入，并独立地在两个部分上进行处理，然后再把结果组合起来的算法可能是O(nln(n))
• e，组合：只要算法考虑事物的排列，其运行时间就有可能推动控制，这是因为排列涉及到阶乘（从数字1到5有5！=54321）

3，实践中的算法速率

• a，考虑一下大量数据对运行时间或内存消耗可能带来的影响。

4，何时进行重构：

• a，重复。
• b，非正交的设计。
• c，过时的知识。
• d，性能

5，怎么进行重构

• a，不要试图重构的同时增加功能
• b，在开始重构之前确保你拥有良好的测试。尽可能经常运行这些测试。
• c，采取短小、深思熟虑的步骤：把某个字段从一个类移往另一个，把两个类似的方法融合进超类中
• d，为测试而设计：（每个模块都是一组件，对每个模块进行测试，确保它们组合后模块有问题，可能直接定位到错误的模块）
• e，单元测试 JUnit (每个模块进行测试）回归测试：修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
  f，不要使用你不理解的向导代码（那样如果有问题，你都不知道怎么处理）

第七章 ：在项目开始之前

1，需求

• a，找出用户为何要做特定事情的原因、而不只是他们目前做这件事件的方式，这很重要。到最后，你的开发必须解决他们的商业问题，而不是只满足他们陈述的需求。你要与用户建立有效沟通和信任的基础，但要记住，不要耽误他们的工作。

• b， 只要是与你的听众交流需求最好的方法，你都可以加以使用

• c， 需求不是架构，需求不是设计，也不是用户界面，需求是需要 d， 在面对棘手的问题时，列出所有在你面前的可能途径。

• d，注重实效的程序员批判地看待方法学，并从各种方法学中提取精华，融合成每个月都在变得更好的一套工作习惯。

• e，规范无法构建的东西太多了。越是把规范当作安乐毯，不让开发都进入可怕的编码世界、进入编码阶段就越困难。不要掉进这样的规范螺旋中：在某个时刻，你需要开始编码！如果发现你的团队全都包裹在暖和、舒适的规范中，把他们赶出来、考虑构建原型

第八章 ：注重实效的项目

1，项目成功取决于旁观都（项目出资人）成功的感觉

• a，质量只可能源于全体团队成员都做出自己的贡献（不要留破窗户）–破窗效应故事
• b，团队无需拒绝无法控制的需求变化，只需注意到它们正在发生和影响
• c，团队中的开发者必须相互交谈。（沉闷寡言的项目团队是最糟糕的团队）
• d，源码撰写解释性的注释
• e，如果你和用户紧密协作，分享他们的期望，并同他们交流你正在做的事情，那么当项目将会时，就不会发生多少让人吃惊的事情了。