工作模式公司目前采用前后端分离的模式进行项目开发。本人处于后端组的Java开发职位。前后端的沟通桥梁前后端分离开发项目，前端组主要负责页面的设计与交互，后端组主要负责数据的存储与服务。前后端组工作协作靠接口文档。目前本人公司的接口文档由前端工程师主要填写，后端人员进行后期的调整。发现的问题在前后端两个小组协作开发项目的过程中，逐渐了发现了些许协作问题，以本人目前的眼界，认为最为突出的问题会发生在接口文档上。结论缘由为什么本人会认为最大的问题出现在接口文档，并在此请教改善之法呢？有以下几点原因。前后端人员的思维差异接口文档，表明了前端请求后端数据时的格式。本人公司采用json的数据格式进行数据交互，后端采用Java开发，自然是将model中的数据转为json格式“跪送”给前端。但由于每个人的思维不用，对接口中的字段命名习惯等也大不相同。例如后端User类中有name和age两个属性，但前端人员写接口文档时偏偏是{“username”:“xxx”,“sex”:“xxx”}。为了应对这种情况，最开始开发项目时，后端再返回数据之前采用Map的方式将model中的数据进行重组和封装，达到前端要求的接口内容。但Java代码就泛滥出大量的put操作，甚是繁琐。个人认为这种情况可以在开发前期两组就要办法做统一规范。前端人员填写接口的“随意性”为了避免Map方式所带来的繁琐操作和put代码泛滥，随后的项目开发中，引入了DTO类，并借助Dozer工具进行实体类DTO类之间的映射转换。DTO类中的属性名符合前端人员在接口文档中所写的字段名称。例如为了传输User类的数据，对应的有UserDTO类，有username和sex属性。同时DTO也可以应对传输实体类部分属性的情况。OK，这种模式进行了一段时间后发现，由于前端人员写接口太过随意，导致后端会产生大量碎片化的DTO类。举个详细的例子：publicclassCourse{//课程实体类privateLongid;privateStringnumber;privateStringname;privateTeacherteacher;//课程教师}前端通过接口请求课程相关的数据时，可能是{"number":"xxx","name":"xxxxx"}，可能是{"id":xxx,"name":"xxxx"}，亦或是{"id":xx,"name":"xxx","teacherName":"xxx"}。这种“随意性”导致后端要么创建应对各式各样情况的DTO类，要么就是在实体类和DTO类中追加冗余的、没有意义的属性。例如又可能为了显示，需要在Course类添加一个studentScore的属性。当然“随意性”我用了引号，表示这只是我个人的观点，并不能说明前端人员有错，人家在写文档时自然更偏向于自己认为舒服的结构，这很正常，本人表示充分理解。3.过于过程化的接口结构第三点是我近期所察觉到的最可怕的一点。诸如上述问题的存在，当遇到复杂的项目时，文档结构就会失控。假如前端人员对后端的技术并不清楚的话，以及他们更偏向于过程化的编码思维，直接导致接口结构呈现过程化的趋势，可悲的是由于交互功能的复杂度，后端为了实现前端期望的接口结构，在编码时已然潜移默化地在进行面向过程的开发，而不是面向对象，个人认为这是灾难的征兆。说到这儿，我依旧不认为前端在写接口有错或是有问题，这是人家的正常思维习惯。以上是本人在自己工作经历中所感悟的痛楚，在此请教各路有经验人士的改善观点。
慕容森
杨__羊羊
相关分类