提出问题

项目开发过程中，注重实效的途径？？？

解决问题

下面是来自《程序员修炼之道》中，自己的一些总结：

重复的危害

系统中的每一项知识都必须具有单一，无歧视，权威的表示。

不要重复你自己

重复是怎样发生的

强加的重复：代码为什么要注释（糟糕的代码才需要注释），而不可信任的注释，比糟糕的注释还可怕。
无意的重复
无耐性的重复：很多时候是由于开发者，懒惰造成的。开发者经受不住诱惑，喜欢去copy别人代码。
开发者之间的重复：由于开发者之间缺少交流，造成某些方法，或者接口的重复开发，这种情况就需要开发者之间多进行交流。
让复用变得更容易

正交性

正交性：从几何学中借来的术语，如果两条直线相交成直角，他们就是正交的。两个事物中一个发生变化，对其他无影响，这两个事物就是具有正交性

在设计良好的系统中，数据库代码一用户界面是正交的，你可以改动界面而不影响数据库。更换数据库而不改动界面。说白了：就是不相依赖性和解耦性。

正交的好处：

• 消除无关事物之间的影响。
• 提高生产率：
• 正交性使问题局部化，一个模块的问题不会扩散到其它模块;
• 促进复用，便于与其它组件组合在一起；
• 使系统更健壮；更利于测试。
• 降低风险
• 正交的途径能降低任何开发中固有的风险
• 有问题的代码区域被隔离开
• 使系统更健壮
• 正交系统很可能得到更好的测试
• 不会与特定的供应商、产品、平台紧绑在一起

项目团队:团队的设置也有正交性的问题，尽量不要让2个团队的责任重叠。如果团队的组织有很多重叠，各个成员就会对责任感感到困惑。

分层：分成降低了模块间依赖关系失控的风险；一旦设计好组件，如果我显著地改变某个特定功能背后的需求，有多少模块会受到影响？在正交系统中，答案只有一个。

工具箱与库：在你引入第三方工具箱和库时，要注意保持系统的正交性。

编码：每次你编写代码，都有降低应用正交性的风险

让你的代码保持解耦。编写害羞的代码。如果你需要改变对象的状态，让这个对象替你去做。
避免使用全局数据。在项目开发过程中，全局数据会引发多线程问题。
避免编写相似的函数。养成不断地批判对待自己的代码的习惯。寻找任何重新进行组织，以改善其结构和正交性的机会，这个过程叫重构。
测试：正交的设计和实现的系统也更易于测试。

文档：正交性也适用于文档。其坐标轴是内容和表现形式。

可撤消性

如果某个想法是你唯一的想法，再没有什么比这更危险的事情了。

不存在最终的决策。要把决策视为是写在沙滩上的，而不要把他们刻在石头上，大浪随时可能到来把它们抹去。

灵活的架构:

曳光弹

在黑暗中发光的代码：

用曳光弹寻找目标

曳光开发和项目永不结束的理念是一致的：总有改动需要完成，总有功能需要增加，这是一个渐进的过程！

就是敏捷开发的理念，要即时反馈。

曳光代码与原型系统不是一回事，曳光弹是一个可以运转的整体，虽然功能不全；而原型通常只是一个界面，原型代码通常要丢弃。

原型与便笺

原型制作是一种学习经验，其价值并不在于所产生的代码，而在于学到的经验教训，那才是原型制作的要点所在。

为了学习而制作原型。

领域语言

靠近问题领域编程。

不同语言有不同的优势，关键在于扬长避短，合理运用，有时候组合起来事半功倍。

估算

估算以避免发生意外。

关于估算一件有趣的事情是：您使用的单位会对结果的解读造成影响。

我们应该这样估算:1~15天，3~8周等等，让估算的时间有弹性。

一个基本的估算诀窍,就是去问一个已经做过这件事的人。

估算的步骤:

建立系统的模型
把模型分解成组件
每个组件都有参数
给每个参数指定值
计算答案
追踪你的估算能力。如果结果证明估算错了，不要只是耸耸肩走开，而需要找出问题的所在，如果这样做你的下一次估算就会更好。
我们发现为项目确定进度表的唯一途径，常常是在相同的项目上获取经验。

通过代码对进度表进行迭代。

在被要求进行估算时，要学会说:”我等会儿再回答你。”，要学会放慢估算速度。