读《程序员修炼之道》

原型与便签

小时候看电视，总是觉得电视里面一些人为了某个大项目，在白板上画了很多看不懂的图，那时觉得高大上，但同时也有疑问，这些用来干嘛呢？有必要吗？为何我自己从没有要需要这个呢？

后来长大点可能觉得自己做的事情太简单吧，还没有复杂到需要打草稿（画图）。再后来知道这个可能就是原型，但也仅限如此。

有几点认知是自己一直忽略的，包括：

• 原型不仅仅是画图，还可以是模型、虚拟物品等；
• 原型可以用来做架构、新功能、描述数据结构和内容、排查性能问题，当然可以用来做用户界面设计。

工作中经常会遇到要先画原型的时候，当开始一个新功能甚至一个新产品时，一时想不清楚，就会想到先画原型图。只有画好了原型图才有信心向大家展示自己的想法。但读完这一章才发现，我可能是错的，因为我没有明白画原型图的真正目的：为了避免风险。而我的初心是为了理清思路。

当然这两者可能存在重叠的地方，但总体上我的方向是错了。最终结果就是我可能做了很详细的包括很多细节的原型。当然无非是多花些时间，包括很多细节可能并非坏事，但实际上完全没有必要在前期花费太多精力在权衡细节上。

我相信这个应该是很多产品经理可能进入的误区，因为我也看到不少人跟我一样。其实要避免这种情况非常简单，只要记住：“原型是一次性的！”

对，原型不会用于真正的产品，所以可以忽略很多细节，书中给出了如下几点可以忽略：

• 正确性：可以在适合的地方使用替代数据；
• 完整性：原型只需要满足优先功能；
• 健壮性：错误检查可以不完整；
• 格式：原型不需要注释和文档。

本章节的标题还包含一个与“原型”并列的词：“便签”。作为一个随手可得的思维工具，便签甚至可以用来制作原型。只需要将便签写上关键部分，就可以在白板上随意组合成一个整体，从而验证系统的功能和关联。根据书中的描述，可能从原型找到这些答案：

• 主要组件的职责是否恰当，有没有清晰的定义？
• 主要组件之间的协作是否定义清晰？
• 耦合度最小化了吗？
• 你能确定重复的潜在来源吗？
• 接口的定义和约束是否能接受？
• 在执行过程中是否每个模块都有访问所需数据的途径？在需要数据的时候，能访问到吗？

书中还提到了曳光弹方法。曳光弹和原型方法当然是不同的，但实际上这两种方法确实有相同的地方，个人总结如下：

• 原型和曳光弹都可以用于快速验证一个想法是否可行；
• 原型是一次性的，不会用于真正的产品；而曳光弹是对产品的一个初步快速实现，但会在此基础上继续完善产品；
• 原型通常用于探索产品的某个特定方面，而曳光弹通常是让系统运行起来，再判断是否能达到目标。