Java Web 后台开发效率提高
发布时间：2020-04-05 22:09:56
来源：网络
阅读：7314
作者：RamZheng
栏目： 软件技术
Java 后端服务开发过程中常用的技术
为开发团队选择一款优秀的 MVC 框架是件难事儿,在众多可行的方案中决择需要很高的经验和水平。你的一个决定会影响团队未来的几年。要考虑方面太多：
简单易用，以提高开发效率。使小部分的精力在框架上，大部分的精力放在业务上。
性能优秀，这是一个最能吸引眼球的话题。
尽量使用大众的框架（架构师可以自定义轻量级框架，越简单但能完成业务功能的框架最好，方便进行重构），新招聘来的开发人员技术功底不一致，要按水平最低的人员考虑，减低人员流动再适应的影响。
这是大部分项目优先选择的条件 基于这些条件 一般选择轻量级框架为主，如果架构师无法自定义架构，则优先选择 Spring（毕竟比较流行）。
但使用 Spring 开发服务应用，需要开发人员有一定的基础，至少 3 年以上经验的才能独自独挡一面，效率上肯定无法比 5 年以上工作经验的高。
揭开后端开发过程中可优化区域方向
想优化服务后端 ，首先要了解可优化的模块，以及框架优化可行性，当前主流框架 Spring、Mybatis，使用开发比较方便，但同时限制了扩展，框架非轻量级，想扩展和修改，则必须要有相当丰富经验的架构师来处理，且测试时间相当漫长，不利于普通开发人员。
普通开发人员关注的其实只是业务实现，无需考虑其他。比如开发人员无需考虑框架是如何存储数据到数据库以及权限具体实现流程等（普通开发人员只需考虑如何实现业务功能，以及业务功能实现的高效合理性），具体的模块如数据存储，权限模块主要有架构师完成设计。
架构师设计成对应的模块接口，如登录，架构师只需对外提供登录接口的详细信息，开发者只需调用该接口即可完成登录操作。
至于开发者使用何种框架对接接口，可由架构师设计，这样开发者只管调用方法，而无需关注框架。（开发者可以在不知道 Spring、Mybatis 框架的前提下完成开发任务）。
故架构师可以考虑将原有的三层架构模式设计成接口-微服务模式，每个功能为一个接口模块，这样部署服务商可以横向扩展进行 负载均衡，方便灵活的进行单个模块的更新，而无需停止整个服务，做到服务零维护，7*24 小时对外提供服务。
架构师可以分配单个模块给指定开发者，开发者只需实现单个模块，单个模块功能可以使用架构师指定的方法用于实现，只是使用架构师提供的框架进行流程设计，无需编码即可进行功能开发。
了解作者多年开发项目经验后自定义架构的高效框架
由于本人实在是懒（没办法，写了几年代码后发现写代码特别累），于是就想着能不能在不写代码的前提下把后端功能开发出来，之前一直做 ETL Kettle 开发的工作，了解到数据流插件后，发现可以将 Kettle 运行思想应用到 Web 请求开发中，下图 Kettle 开发界面：
该图可以完美展示登录判断流程，其中
INPUT：接收用户传入的参数，用户名密码等信息
判断：用于判断用户传入参数信息
登录以及用户信息：获取用户基本信息
ADMIN_CHECK：判断是否是管理员
putCache：放入缓存
通过可视化工具，这样就可以方便设计出功能流程，小到获取单记录信息，大到查询数据等功能都可以很方便完成。
测试也很方便地直接通过可视化工具传入请求参数，而无需使用开发工具（Eclipse 等），实际项目开发者无代码能力者也可以完成分配的功能任务。
流程化工具：
主要设计理念参考了 Kettle 等ETL工具，用于数据流向所处理的系统化模式，并带入 Web 理念中去。
试想下，一个 Web 请求服务端，服务端需要如何处理？处理后返回给客户端的数据又需要做什么处理等等。
分析具体步骤，并把一个个功能划分成积木那样，先考虑最小化模块。
如登陆模块：
接收传入的参数
判断用户名是否存在
判断密码是否存在
判断用户名格式，密码格式是否正确
判断验证码
查找数据库是否存在用户名
查找到用户，判断用户密码与输入密码是否一致（密码判断）
判断成功后生成 token，返回给用户，失败的话 返回错误信息
简单的登录流程简化成上述 8 个处理步骤，分析下这八个步骤，每个步骤需要的插件可以归类为：
INPUT 接收参数插件
判断过滤插件
数据格式验证插件
数据库记录查询插件
返回信息插件
常量插件
如下图：
我们看到图中主要使用了几种插件，如 INPUT（接收用户输入的参数），配置内容如下图：
增加常量：设置常量用户输出信息，配置如下图：
过滤插件：判断字段值，如下图：
数据格式验证：判断字段值的格式是否符合要求，如下图：
数据查询插件：查询数据库表记录值，如下图：
输出内容选择值：选择需要进行下一步操作的字段，如下图：
现在我们发现，原本需要进行代码编写进行用户登录验证操作的功能，现在只需要动手配置下具体实施流程即可，无需编码，是不是很方便，而且不需要有开发经验的人即可进行配置。
如何带领 Java 团队开发并效率最大化
项目架构师和管理者（最好是同一人，这样对项目了解通透）应考虑团队人员的水平情况，并以最新人开发者为基准设计框架，而不是一味的让开发者迎合架构师，架构师应站在产品经理的方向上考虑，将开发者当做产品用户 设计出合理的产品给开发者使用。
另外架构师要尽可能的”懒”（这里指通过工具就可以完成工作，而无需大量编码），只有这样才能想着如何调高效率，而不是每日加班来凸显自己，一直以来我不认可加班，没有什么事情需要一个加班就处理好，如果需要那也是线上运维出现的紧急情况，而不是开发过程中。
后台开发效率提高取决于以下方面：
1. 人员配置
理论上项目配置越多的开发人员开发效率越高，但盲目的增加人员不紧增加管理人员的负担，且软件工程配置人员有一定规则，不是开发人员越多越好。
2. 框架选型
选择合适框架的前提下能更好的提高开发效率,但是框架的选型要考虑同组开发人员的整体水平，框架要约简单越好，简而不繁最优 ，还要兼顾团队中的测试 需求等人员，如果框架选型上可以让测试和需求人员一同参与开发（一般只要求测试人员可以一同开发，如果框架选型后可以让需求人员一同参与开发则最好，毕竟开发项目时压榨人力资源是每个管理者追求的）。
3. 代码工作量
项目中编码必可不少，但如果能尽量减少开发的代码量，让人员有更多时间关注业务方向（毕竟开发项目主要还是与业务相关联紧密），既然不想写多余代码，自然而然想到通过可视化操作来实现（现在 APP 开发都可视化，几分钟就可以生成一个），架构师就主要考虑开发出可以让开发人员可视化工作的框架。
详细效率：
人员配置方面，我所在项目目前配备人员：
架构师兼开发工程师（A），开发工程师（1-2 名，B 和 C）无开发经验或从测试组以及其他部门借调（没办法，公司不给多配人），测试人员以及需求人员和其他组公用。
鉴于以上人员组合，如果选用 Spring MVC 等框架的情况下，只有A有能力快速开发且需要编写大量代码，B 和 C 需要先提前对其进行培训，培训结束后开始开发，效率肯定不如有经验的开发人员，即使 B 和 C 是同 A 一样的开发能力，三人同时开发编码量也比较大。
此时如果 A 开发一工具可以让 B 和 C 可视化编程操作，如当前所在项目使用的架构，通过工具 T_VISUAL（A 开发出来的可视化工具），B 和 C 完全可以在无基础开发能力的情况完成功能开发，如下图：
这是参考开源软件 ETL 工具 KETTLE 实现模式，开发了一条后台程序流程工具，比如界面上 VALI_LOGIN_CHECK 这个表示一个功能块，该功能可以作为一个简单判断功能块，其中 INPUT 插件表示接收 WEB REQUEST 请求的参数，如下图：
这三个参数是从页面请求传入，后续步骤分别判断用户名密码验证是否符合验证要求。
用以上工具此时 A 只需全力开发需要的功能插件，而 B 与 C 只需要规划业务功能块，比如项目中需要的登录、注册、获取用户信息、获取产品列表等功能模块，只需要创建对应的功能模块即可。B 和 C 无需编码，只需可视化设计流程即可，后续只需安排好模块功能，人员安排可以成几何倍扩展，而无需担心开发人员能力问题，借助工具，只需要基础开发人员，具有一定的逻辑能力即可。
如果架构师没有开发出对应的可视化工具，则建议架构师设计时应尽量先将各单元操作类独立成单个插件（类似于上图工具的插件步骤），这样编写代码的时候，无需编写功能块的详细内容，只需编写功能流程，即编写时。
如下图：
其中 A 只需要编写功能块的内容，B 和 C 只需要调用功能块重的模块类进行拼接。项目难点在功能块实现上，而具体模块实现功能无需考虑具体功能实现，只需考虑业务流程即可，对开发能力要求较低，这样 A 就可以带领 B 和 C 进行开发，且 A 不需要对 B 和 C 进行详细指导，只需要再他们觉得有问题的时候进行解答即可。每个人都可以更加专注，如果后续功能模块需要增加的话，只需要增加和 B、C 同等水平的即可，而无需增加 A 类工程师。大大降低人员成本，开发效率上也有高效率。
Web 框架上选用 Spring MVC 虽然符合主流，但对人员要求比较高，为了兼顾团队整体可以考虑一些轻量化框架如 JFinal（现在项目所用），对人员要求较低，且适合初级开发人员。
以上是本人总结的一些经验以及个人带领团队开发中总结的一些方法，主要兼顾下团队中的其他人员，毕竟高大上的框架看上去完美，但是确是开发人员的噩梦，尤其是要在编写代码量巨大的份上。
后续
多年的开发经验总结下来就是，程序员需要懒，因为只有懒才能开发出高效的工具以及流程，你看一个开发人员每日编程 代码量巨大，看似勤奋，但是却比不上一个使用工具的开发人员一半的工作量，有时候开发停下来要思考下如何将当前的工作流程简化，编写的代码可以尽可能的小而精，从而开发出可以复用的工具。
最后附上我的个人公众号：
