走出来

来到大公司,告别了常一个人单打独斗的日子,有了新的规则,也遇到了新问题。比如前后端的合作方式,任务分界线到底在哪,哪种方式更高效,更重要的是怎样合作不窝火

反思自己刚做的一个小项目,暴露出了前后端配合问题。背景如下,需开发一个设计师使用的小工具,需要PC端上传设计稿,生成二维码供客户移动端访问,只提供了页面草图。然后作为前端的我和后端同事简单过了需求就开工了,悲剧开始。

用 fms.js 模拟后端返回数据,奔着草图就去了,完成简单的界面和业务逻辑。等前端完成时,后端也完成的差不多,不过后端同事的意思竟然是口述接口,口述接口!难道表达能力竟强到秒杀文档了?他考虑目前只有两三个人开发,没必要非要写文档。此时,我的内心是崩溃的,还好坚持让出文档,不然这次死的更惨。当拿到文档时,完全蒙了,这跟前端交互对不上好么,当然接口都写好了,再改肯定又是工作量。如果以牺牲用户体验来减少工作量,不能忍

好不容易,协商好改接口,又一场调试噩梦开始,提交后 404,什么情况?找了半天问题,原来是接口文档地址写错了,此事发生过两次。再提交,错误码 500,又有问题!然后又回去改接口,「再试试」。不禁怀疑接口都不用测试的吗?前端考虑用户体验和交互外,还要负责测试接口?

经过一遍遍反复,终于能够完整的跑起来,回头一看,写代码一半时间,联调一半时间。

那么究竟前后端哪种模式更高效?

拍脑袋能够想出来的,假如把开发看做是一条线,把前端和后端看做线的两端,那么中间就是接口,也是成品。 先定最终产品的交互,继而敲定基本接口,包括字段,然后大家分工从两端共同朝中间努力,完成目标,应该是目标最为明确而最少反复的流程。

开发过程

总结:

  1. 明确需求,了解清楚业务流程
  2. 敲定接口,精确到字段名称
  3. 出接口文档(前端、后端出都行)
  4. 各自完成功能
  5. 联调

总之,作为前端,更多的关注用户体验,这才是我们的核心竞争力。 而后端,对可靠性和性能要求会更高些吧。流程合理,各司其职,高效沟通,坚守底线。