前言
在最近的项目开发中发现一些上问题,针对这些不合理的地方,个人有一些建议,特此记录下.
正文
1. 模型/枚举定义一致性
在前后端分离的项目中,严格意义上讲并不需要前后端保持模型定义的完全一致,但是在开发联调中经常会发现前后台各自定义一套模型,然后埋头开发,到联调阶段的是时候发现有些属性字段不一致,导致返工或者添加映射.而前端又使用的是数据绑定的Ng,导致影响范围不好控制.
[建议]:在正式编码前,前后端定义好一套规范模型(可以由双方功能协商制定,也可由任意一方定义,另一方遵守),双方在编码过程中严格按照模型定义去写各自的对象(前端对象,后台实体,数据库表),如需改动要通知另一方.
枚举值最好也在开发之前就定义好,从而避免前后端各自定义一套枚举需要中间添加映射的情况出现.
2. 接口定义一致性
前后台接口定义主要体现名称不一致和预期值不一致.名称不一致包括接口名/参数名/参数个数等的不一致,预期值不一致主要包括参数数据类型/数据结构/接口返回值/返回值数据结构不一致.归根结底是还是因为前后端沟通不畅.
[建议]:同样是在编码前,双方约定好上面提到的接口数据.
3. 对象访问
在前后台的代码中都可以看到形如 `A.B.C` 的代码,即通过"."来访问对象属性并且还没有判空.正常情况下这种代码没问题,但是我们却无法保证中间的某个属性是有值的,如果没有值,代码直接就报错退出执行了...
[建议]:通过set/get获取对象属性,如果图方便,最好也要做为空判断
其他
以下不能算是项目中存在的问题,只能说是我认为比较重要的地方,拿出来记录下:
1. 需求文档
前端开发者一般情况下根据UI给出的图去开发,遇到问题或者不清楚的地方才去看产品的需求文档,一图胜前言,本无话可说,但是我还是觉得在开发前把需求文档一字一句的过一遍会比较好.毕竟读文档用的时间跟因文档理解不一致该需求的时间相比要少的多的多.当然,最好是在功能开发完成后,再把需求文档从头到尾看一遍,一个是检查有没有漏掉的功能,另一个也是为了避免产品直接修改需求没有通知开发的情况(当然一般情况不会出现).
2. copy代码
天下代码一大抄.严格意义上讲,我个人并不反对复制粘贴代码,我反对的是不假思索的拷贝复制.其实整个项目进行到现在,一般的需求都有在其它模块做过,将其它模块的代码拷贝过来本无可厚非,但是在拷贝代码的过程中,我觉得最基本的是要搞清楚这段代码是怎么起作用的,它的影响范围有多大,在此基础上,我们还可以思考原作者为什么这么写,这里的代码是不是还有可以优化改进的地方,最后,还可以思考下别人的编码思路和风格是不是有值得学习和采纳的地方,可以为我所用.这样下来,我们既可以用原有代码实现新的功能,避免了重复造轮子,又可以不断的从别人的代码中学习/归纳/整理,取其精髓,去其糟粕,让自己避开重复低效的复制粘贴歧路,走向不断进度提升的大神之路.
最后
程序开发是一个系统的工程,需要参与这个工程的所有人员的分工明确,协力配合,共同努力才能完美完成,愿每个人都成为神队友而不是....与各位共勉.