公司里面前后端的协同开发办法

    在工作的时候，因为要考虑公司当下的人力情况，系统架构等，在进行开发的时候，经常需要考虑的是人员分配的情况，其中比较需要注意的是前端与后端的协同配合。

 

    当然，在小公司，可能因为人力资源不足，开发的系统尚处于起始状态，业务尚处于摸着石头过河的情况，可能很多时候需要一个人负责某一模块从后台服务到前端页面的开发（这里暂且不考虑是否存在DBA的情况）。这样子的开发模式，很多时候都是需求产品这样扔出原型，然后说一通业务，就交给某个编码人员进行开发，这个时候编码人员一般自己定义了接口，定义查询的语法，然后按照原型画出表单，随后接口实现之后，将页面绑定了接口，然后就开始调试了。

 

这样子涉及不少问题：

    <1>建模缺少注释，基本上模型里面的字段缺少注释，很多时候除非是自己看，否则别人接手你的接口的时候，看到的所有模型基本上不知道怎么对应页面上展示的内容，还有很多新手基本上命名字段也是有问题的，我认为，应该遵循标准的英文-小写第一个单词-大写第一个字母第二个单词...按照这样的模式进行规范的命名，英文是个好东西，基本上没有谁看不懂英文，因此这样的命名别人最起码不会看不懂。

    <2>缺少接口文档，其实自己写的接口，当然不用写接口文档，因为调用接口的人可能只有我一个人啊，那我肯定知道什么时候调用哪个接口，何必还花那么多时间去写这种没用的东西，本来进度就很紧张。现在可能是你自己在调用，但是你不会知道谁不会再去调用你的接口。接口与服务的可复用性，一直是各个公司追求的目标，不然现在流行的各种微服务架构(dubbo，spring cloud)是为了解决什么问题呢。

    很多新手在写接口的时候，在接口方法上面几乎没有一行注释，再加上糟糕的接口命名，在成熟的编码人员看来，就算你的接口写的是对的，百分之一百满足了业务，但是你写的接口在他们的眼里就是垃圾，无用的。我管你写得对还是不对，我都看不懂，对我来说就是废物，出错的代码不要紧，无法阅读的代码才是最糟糕的。

    写接口文档有好多种方法，如果是在与前端人员进行配合开发，可以写出文档类型的接口调用方法说明，文档的内容可以告诉前端，这个页面上想要得到的数据，你可以在调用哪个controller里面的哪个方法后得到，get的时候需要传递参数还是json数据，数据类型是什么，都在接口上面写清楚。当你写好了接口，顺便将这份接口文档扔给前端让他自己阅读，实际上是更加有效率的办法。

    为什么是更加有效率的方法呢。因为，起初你自己一个人搞定前后端，你认为我没必要写出接口文档，可以将时间腾出来继续往下做业务，但是当你有了前端可以进行配合的时候，如果你还是一意孤行的认为我没必要提供出接口文档，那前端拿到你的接口的时候就会认为我拿到的是垃圾，就算你是一个三年工作经验的成熟编码人员，在别人眼里你也就是个实习生。

    在不提供接口文档的情况下，你们需要付出更多的是沟通的时间成本。因为没有一个人能将一个接口写得完美无瑕，总是有出错的地方，比如获取不到数据，那可能是你们两个人的机器上的数据不同步，那这个时候前端人员会误以为是你的接口出现问题 了，过来问你这个接口是怎么回事，那你势必要放下手头的工作，去他的机器上面调试。何必呢，如果你提前写好了接口文档，告诉他在调用这个接口的时候要确保查询的id是否是指定的id，数据库是否要造伪数据进行调试，当这些都书写明白在接口文档上了。就算你的接口确实是有问题的，但是别人调用的时候也有理有序，出错也能顺利的找到问题。

    多花一点时间做多一点事情，而不是等到出问题再来解决，效率上反而是提高的。

    <3>离开现实情况去谈问题都是有问题的，但是我始终认为，在一家成熟的公司里，尽量要做到的就是完全的前后端分离。我并不是说分离是一定需要两个人分别开发后台服务与前端页面，我认为的完全分离是指架构上的完全分离。

    在刀耕火种的年代，很多程序员在jsp里面嵌套hql，在html里面处理数据，处理业务。这是完完全全没有任何架构思维，没有任何层次分明的写法。事实上，google的大牛早就看不下去了，所以搞出了angularjs，像java web一样给前端搞个分层：路由，控制器，页面都给你好好的分开，前端需要做的，是在controller里面post或者get后台接口服务，在路由里控制页面跳转。完全不需要后台的人在controller给你跳页面，跳页面的同时给前端传递数据。

    那种在controller混杂了各种页面控制，参数传递的前后端架构，是完完全全的混乱的，因为你可能用这种架构做一个业务模块，做了一段时间了，恰好公司请到了前端了，是一个资深前端，我的意思是这个人写前段很厉害，却几乎一点后台都不懂的，不管是php还是java，这个时候你给他看代码，他会完全蒙蔽的，他会说，为什么前后端不完全分离，为什么不引入angularjs(因为这个时候你可能还是在用thymeleaf配合后台开发页面)，如果前后端不分开，是否我也要跟你使用同样的开发工具eclipse，但是我从未用过eclipse，那我适应整个架构整个公司就需要更多的时间，间接造成了资源的浪费。

    一个好的架构是公司拓展业务的基石，但是架构也不是一开始就可以设计得完美，方方面面都可以考虑到的，这个时候，需要在业务前进的过程中抽出时间来稍微调整一下系统架构，就算系统架构很庞大，很难一时间调整过来，但是稍微调整目前你正在负责的模块，应该也不算很大的问题。

    这个时候，你完全可以将页面抽离出来，如果你正在使用spring mvc，是否可以考虑将关于前端的所有内容从template中完全移到public里面，将前端与后台管理完全分离，不需要spring帮我们去控制模板。我写后台接口的就是将工作推进到controller为止，剩下的，前端人员就看你的情况，结合接口文档，什么时候发一个post请求，什么时候发一个get请求，怎么跳转页面，都是你来进行控制，我后端的编码人员完全不管。

 

    总结来说，小公司很大机会让你从后台写到前端，有一些极端的公司，可能需要你从dba的角色一直将工作推进到集成测试，自动化测试，显然，确实这样的工作模式可以让你学习得不少东西，但是也是无奈之举，如果是成熟的大公司，我也不需要你多厉害，你足够听话，给你的任务你做出来，顺利交接给下一环节的人员，那就是已经很不错了。

    诚然，各个公司有自己的情况，但是情况是可以被改变的，多做出一点工作，多想想工作遇到的问题，多去解决问题，什么样的情况，什么样的难题，都可以找到解决的办法。

转载于:https://my.oschina.net/luckid/blog/880395