区块链怎么分工，开发共识前端各归谁管才不踩坑

导读： 从事了区块链项目相关工作长达八年的时间, 期间带领过三个开发团队, 而让我感到最为苦恼的问题, 始终是关于工作分工如何进行有效的落地执行这一方面。...

从事了区块链项目相关工作长达八年的时间, 期间带领过三个开发团队, 而让我感到最为苦恼的问题, 始终是关于工作分工如何进行有效的落地执行这一方面。

其中涉及到节点开发、智能合约编程、共识机制构建以及前端交互设计等各个不同的业务环节, 对于每一条具体的线路而言, 究竟由哪位成员来承担哪部分工作任务, 都需要将其界限划分得非常清晰明了, 一旦出现任何的含糊不清的情况, 就会导致项目的整体工期产生不可预测的漂移和变动, 使得工期每天都在发生变化难以把控。

区块链怎么分工开发

我是按照技术栈的情况来对团队进行切块划分的, 智能合约组的工作人员是专门负责处理Solidity编程语言以及Rust语言编写的链上业务流程逻辑的, 他们是不去碰那个共识层的设计与开发的, 至于说共识层还有那所谓的P2P网络底层通信机制, 这些都是明确归属于底层架构组这个部门的全责范围, 而关于协议升级和分叉策略这类重要的事项, 最终都是由他们底层架构组来进行确定的, 那么站在智能合约这边的人来说, 是绝对不可以出现越权去进行修改的行为的。

把前端团队, 还有相关的工具链人员, 单独拉出来组建一组新的工作单元。让这一组新人承担起钱包接入, 以及DApp交互这些任务, 同时还要负责SDK的封装工作。

这样做带来的好处是, 每一个员工所承担的工作内容都是完整的闭环系统。他们之间涉及的交叉依赖情况非常少, 这样在程序出现bug的时候, 非常容易快速定位到具体原因。

区块链怎么分工协作

跨组的协作关系主要是依靠接口文档以及代码审查来形成强制性的锁定机制的。

具体而言, 合约方面的工作组需要在每两周的时间段内发布一份关于应用程序二进制接口变更情况的专门说明文件, 以便前端方面的工作组能够提前进行技术层面的适配与调整操作, 坚决防止因为适应不及时导致在联合调试阶段发生严重的问题或者混乱状况。

如果在修改属于公共模块范围内的代码内容时, 则必须严格遵守规定, 即要求上述两个工作组各委派一名人员共同参与代码审查环节,并且所有的相关操作都必须严格遵循合并请求的流程来进行办理, 这样做的目的就是为了避免在工作完成后出现互相推卸责任的情况。

把安全审计这个岗位单独设立起来, 不要去找开发人员让他们自己来审查, 而是去拉拢第三方机构或者组内那些不接触业务代码的人来做这件事。这样做是为了让这条独立于业务之外的线索拥有真正的权力, 让审计得出的结论直接对正式上线的时间节奏形成卡控作用。

分工如果划分得清清楚楚, 沟通成本就会自然而然地降低下来。在链上的项目中, 模块的个数很多, 耦合的地方非常密集, 一个人去做全栈开发反而会把进度给拖累掉, 各自管理一段工作, 对接口进行对齐, 这才是正确且正派的道路。