山西住房与城乡建设厅定额网站,简约网站建设,项目经理网站开发流程,黄石市下陆区建设管理局网站对于开发人员来说#xff0c;工作都是从评估一个需求开始。我们第一个要解决的问题就是看待需求的视角。视角的不同#xff0c;得到的设计方案可能是完全不同的。作为一个程序员#xff0c;不能单单从个人视角来看待问题。而是要尝试从不同角色出发#xff0c;不停思考。上…对于开发人员来说工作都是从评估一个需求开始。我们第一个要解决的问题就是看待需求的视角。视角的不同得到的设计方案可能是完全不同的。作为一个程序员不能单单从个人视角来看待问题。而是要尝试从不同角色出发不停思考。上图是出自一个数据平台7日留存功能。在该原型图中计算了每天的留存率并以趋势图的形式呈现出来。常规服务端数据结构定义可能如下class RetainRatio {/*** 日期*/private String day;/*** 留存比例*/private double ratio;
}RetainRatio代表了留存的数据结构其中day为日期ratio为留存率。服务端将数据封装为ListRetainRatio结构传递给客户端由客户端进行展现。乍看起来没有问题但是对于数据平台可能存在着大量的其他图形分析的需求如下图是一个行为按日期统计次数的趋势图。class EventCount {/*** 日期*/private String day;/***次数*/private Integer count;
}很明显当整个系统中存在着大量画像分析时将会出现非常多的数据结构定义。我们再来考虑一下如此多的定义带来的程序复杂度。对于服务端开发人员定义大量数据结构来承载不同的趋势图结构。对于客户端开发人员需要理解不同数据结构并使用不同的代码来渲染和展现UI效果。程序设计者往往站在数据结构的角度来看待问题那么我们从客户端开发人员的角度进行思考。他们根本不想关注数据结构中的day、ratio、count等。而只关注如何将趋势图展现出来。他们唯一需要的就是横坐标和纵坐标。而具体字段的含义于客户端代码的编写并没有太大关系。本着解决一类问题而不是解决一个问题的思路。我们试着将数据结构定义为如下形式public class TrendLine {/*** 名称*/private String name;/*** 曲线上的所有点*/private ListTrendPoint pointList;
}
class TrendPoint {/*** 纵坐标的值*/private double verticalVal;/*** 横坐标的值*/private String horizontalVal;
}
TreadLine代表了一条趋势线趋势线上有若干个点ListTrendPoint而每个TrendPoint中含有横坐标horizontalVal和纵坐标verticalVal。如此一来暴露给客户端的数据含义就变为了线——点——横纵坐标三个概念。那么整个系统中所有类似趋势图的图表均可利用这一结构进行封装。我们再来看程序的复杂度服务端多中数据结构定义统一为一种在计算时均向该结构统一。客户端不再理解具体的业务意义天、行为、留存率等等仅仅理解线——点——坐标三个概念。UI展示时的代码也只会有一份。我们可以将这一思路提升为“视角”这一概念。系统设计者在设计时需要综合考量各个角色视角所关注的东西。服务端关注数据计算。客户端关注展示而并不想关注具体业务是什么——例如本例中的天次数留存率行为等等。测试端只关注计算和展示的结果是否正确更加不会关注具体数据结构如何封装。换句话说上游向下游暴露什么数据直接决定了下游理解的复杂度。上游向下游暴露的信息在保证足够的情况下应该是尽量收敛而非无限扩散的。
