画了三百张区块链创新设计图，终于不踩坑，劝你别再瞎画了

导读： 在长达三年的时间里, 我专注于区块链领域的创新设计绘图工作, 在此过程中, 我目睹了数量极其庞大的团队存在一种普遍性的错误现象...

在长达三年的时间里, 我专注于区块链领域的创新设计绘图工作, 在此过程中, 我目睹了数量极其庞大的团队存在一种普遍性的错误现象, 他们往往把本该严谨的逻辑架构图绘制得如同流水账一样杂乱无章, 仅仅将节点、协议以及共识机制这些要素机械地堆砌在一起, 虽然在视觉上看起来似乎十分热闹和复杂, 但在实际运行测试中, 却发现没有任何一个具体的业务场景能够顺利跑通。

真正具备实用价值的图表, 必须能够将核心逻辑表达得非常清晰, 也就是说, 必须明确地交代清楚究竟是谁, 在什么样的具体时间点出发, 去触发了哪一条特定链路上的处理逻辑细节部分。

区块链设计图难在哪

难点肯定不是去画那个框子和箭头这么简单。我已经见过有人, 就把TPS、Gas费这些东西标上去, 就算完成任务了, 可是用户他们根本都不会去看这些。

实际上真正的难处在于把那什么链上和链下的边界给划得清清楚楚、死死地定住, 到底哪些数据要上链, 哪些数据要走那个中心库, 还有跨链调用到底会在什么地方断掉, 这几条线如果弄含糊, 那么整个方案就全部都是白搭、全都废掉。

还存在一个坑, 这个坑指的是时序的问题。在很多设计图画出来的时候, 往往只是去画那些正常的路径情况。至于像fork、revert、回滚这些异常的状态, 在图里也就被简单地带过去了没有详细说明。等到开发人员在一起对齐方案的时候, 全组人才发现图里根本没有覆盖到相关的内容, 导致整个团队都陷入了被动。

创新设计图怎么落

不要追求通过一张图就来把所有的事情都说清楚。我现在是分层来出图的, 最外面的一张图是给投资人看的, 主要是用来展示业务闭环, 中间层的图是给开发人员看的, 主要是用来展示模块之间的调用关系, 最里面的那一张图是给审计方看的, 主要是用来展示哈希锚点的信息。

每一张图只管回答一个方面的问题, 在信息充足的情况下,千万不要然后再往里面继续塞多余的内容。

落地的关键点就是需要让设计图能够直接转化为接口文档。我见过最优秀的团队, 在把图画好之后的第二天, 开发人员就可以直接对着来进行合约的书写工作, 完全不需要再去翻阅那个PPT去查找备注信息。

现在新人的同事刚要绘画第一张图像的, 我建议该人士先行暂停挥笔的动作。需要将该人士针对极端恶劣情景的设想书写在纸张上面。绘制图像的目的应当是为了应对最坏的状况而做出的准备, 而不是为了向领导汇报工作成果所使用的材料。