关于 客户端流水线开发 的感触

客户端开发，需要了解业务、了解系统的当前运作方式。没有不懂业务、不熟悉现状就能开发出溜得上天的客户端。而“掌握业务”的项目要求，似乎没有开发者应当区别对待，可以幸运逃离的。

我们也是一样，即便我们把客户端的功能开发，拆分成了“切图 → 开发”的流水线，也并不意味着“掌握业务，满足业务”的要求，都应该由流水线的下游全面满足。上游的切图开发者，也具有同等责任。

如果不了解现状、不了解业务，切图成果就会与效果图源图表现出过于紧密的关联关系，成为“以效果图为导向，画什么切什么”的产出。这个产出，过于单一，只描述了静态的、单一的用例场景。而实际工作，则是“以业务为导向，系统支持什么开发什么，不合适的元素适当调整或移除”，是动态的，隐含多个用例场景的。例如：界面展示的元素是需要动态响应后台配置，或不同状态有不同字段展现需求的。

以“以效果图为导向”得出的产出为基础，进行“以业务导向”的功能开发，必然需要业务开发者进行调整，调整工作的大小，受界面展现元素的多少、界面工作需要的接口的个数、接口的功能等因素的正向影响。元素越多、接口越多越复杂，矫正工作就越大。

矫正工作，对于切图者和开发者，都是不必要的资源浪费。这个浪费是双份的，会在一定程度上制约项目的整体开展效率。而对于流水线工作，环节越多，效果衰减就越明显。如果衰减系数是0.2，两个环节就会让效果成为0.64。这和人无关，大概就像信号传输一样，是这个宇宙的客观规律吧。