前言

上一篇记录了务实的方法上部分的内容，这里接着记录下部分的内容~

曳光弹

很多人应该看过枪击电影、电视节目或者玩过枪击游戏，在这些场景里面，我们经常可以看到子弹在空中留下明亮的轨迹，这些轨迹就是来自曳光弹。

曳光弹和普通弹药间隔着一起被压入弹夹，当曳光弹发射时，上面的磷会被点着，在枪和击中物之间留下一道轨迹。如果曳光弹击中了目标，那么之后的常规子弹也会击中，士兵们通过使用曳光弹来调整他们的瞄准，这是一种务实的方法，可以在真实条件下实时获得反馈。

真实条件下获得实时反馈。这个原则同样适用于我们的开发，特别是我们接触到以前未做过的东西的时候，曳光弹式开发针对变化的目标进行实时性的反馈是很有必要的。当我们在使用不熟悉的技术，或者在推进新技术的时候，往往会面临很多未知因素，所以在项目完成的这段时间内，我们的工作环境可能会经常的变动。

曳光代码。曳光弹之所以有用，是因为其工作环境和约束跟真实环境是一致的，且能快速的到达目标，从实用性的角度来看，这也是一种低成本的解决方案。为了在开发中能获得同样的效果，我们可以找一些东西，能让我们快速、直观地从需求中得到最终系统的某个方面。开发中最初的曳光代码，就是创建一个简单的工程，加上一行我们熟悉的“hello world”并让这个工程跑起来，然后继续找出系统中不确定的部分再往上添加。我们在平时开发中使用一些demo来快速测试我们的想法是否行得通，其实也是属于曳光代码。

曳光代码并不是一次性的，而应该是持续性的，一开始它并不完整，随着我们不断地往上添加，我们就能知道我们跟目标的距离，一旦偏离了轨迹，我们就应该快速做出调整，这是一个逐步增加的过程。

原型与便签

各行各业都有使用原型来尝试特定的想法：比如汽车制造商可能会为一款新车的设计制造许多不同的原型，每个原型都是为了测试某一特定的功能。我们开发软件也是一样，可以通过构建软件原型，来分析和暴露风险。

原型被设计出来只是为了回答我们某些疑惑的地方，所以我们的原型可以忽略一些不重要的细节，比如制作UI原型，我们可以忽略数据，制作关于性能方面的，我们可以忽略界面。但是如果是任何一个细节都不能忽略的，那这种情况下，我们应该考虑的是上面的模式–曳光弹，也不是制作原型这种模式。

需要做原型的东西。我们会选择用原型来研究什么类型的东西呢？答案是任何有风险的东西，任何之前没有尝试过，或者说在系统中很关键的东西，任何我们觉得可疑的东西，甚至是某些地方让我们觉得不舒服的，都可以制作原型。制作原型的意义就在于吸取经验，减少错误的成本。

制作架构原型。有很多原型也会用于还在考虑中的整个系统建模。有时候这些原型不一定得编写代码，还可以用一些标签或者索引卡搞定，下面列出的领域，可能是我们希望在架构原型中找到相关问题的答案：

• 主要组件的定义是否清晰，职责是否恰当？
• 组件之间的协作是否定义清晰？
• 耦合度是否已经是最小化？
• 接口的定义和约束是否可以接受？
• 在执行过程中是否每个模块都有访问所需数据的途径？在我们需要数据的时候，能访问到吗？

带着这些去寻找，思考，我们往往能获得更有价值的结果。

不要把原型用于产品。我们制作的这种原型跟产品经理所做的产品原型的作用是不同的，我们的原型是不完整的且不可能做到完整，因为它是一个用来做特定方面分析的东西，所以在展示我们制作出来的原型时，应该跟其他人说明，这仅仅是一个展示效果，并不是最后的成品，避免其他人后面想要坚持部署不完善的原型。

如果使用得当，原型利于在开发的早期就识别出潜在的问题点，并给予纠正，且在这个时间点修正错误不仅廉价还容易。

关于便签。便签非常适合构建动态事务的原型，比如我们的工作流和系统逻辑。最近看了谍战片《局中人》，其中有一处的场景是男二在墙壁上粘贴关于男一各种信息、模型，再通过线条来动态确立各模型、数据之间的联系，从而辅助他做逻辑更清晰的判断。而他所做的工作，就是情报分析。

估算

估算不管是在生活中，还是程序世界里都是普遍存在的，当我们面对问题不能肯定地答复时，都是属于估算。通过学习估算，把这项技能发展成为对事物的数量级产生直觉，将会对我们的工作和生活产生魔法般的作用，并且在估算的过程中，我们也会加深对程序所处世界的理解。

多精确才够。在某种程度上，所有的答案都是估算，区别仅在于一些比另一些更精确。所以当我们需要估算的时候，我们要问自己一个问题：答案会用在什么场合，对方需要怎样的精度？

有一个关于估算有趣的事：我们使用的单位会对结果的解释产生影响。如果我们说某件事需要130个工作日完成，那么听的人往往会觉得实际的时间很接近130这个数字，然而如果我们说的是“大概4个月吧”，他们就会认为还需要4-6个月不等。两个数字代表的时间周期是差不多的，但是“130天”却暗示了更高的精度级别。因此当我们做估算时，可以挑选答案的单位来反映想要传达的精确性。

掌握问题域的范围。所有的评估工作都是建立在对于所问问题的理解。除了精确度以外，我们还需要掌握问题域的范围。范围通常是问题的隐含前提，我们要养成一个在猜测之前加以考虑的习惯，很多时候，我们选择的范围会成为给出的答案的一部分。

记录估算能力。除了从某些点出发去提高估算能力之外，我们还可以记录下我们做过的估算，这样可以看到我们做过的估算的准确程度，简单来说就是复盘。当我们时常估算准确的时候，我们应该觉得这是理所应当，是估算的魅力；如果估算不准确的时候，我们也要找出为什么偏离的原因，有可能是实际情况的问题，有可能是估算时采用的参数问题，通过复盘，让我们下次的估算能更加准确。通过长时间的复盘总结，也可以逐渐建立起属于自己的一套估算系统，这就是我们常说的经验，但这又比经验这一说法更可靠，更经得起推敲。