网站的模板演示怎么做,网站定制分享,网站可以几个服务器,cnzz站长统计工具前天与一个大佬交流。想起自己在6年多前在团队里做的一次小小的效能提升。 改进前 在同一个产品团队#xff0c;同时有前端工程师和后端工程师。他们经常需要共同协作完成features。 前端是一个传统的多页应用。前端渲染是由后端的velocity模板引擎实现的。 打包后#xff0c… 前天与一个大佬交流。想起自己在6年多前在团队里做的一次小小的效能提升。 改进前 在同一个产品团队同时有前端工程师和后端工程师。他们经常需要共同协作完成features。 前端是一个传统的多页应用。前端渲染是由后端的velocity模板引擎实现的。 打包后最终执行就是一个jar包![[hellojar.png]] vm文件后缀名是velocity模板文件。它们内容大概是这样的 htmlbodyHello $customer.Name!table#foreach( $mud in $mudsOnSpecial )#if ( $customer.hasPurchased($mud) )trtd$flogger.getPromo( $mud )/td/tr#end#end/table/body
/html 其中一些非html代码就是Velocity Template Language。 默认情况下一个前端工程师是不懂这门模板语言的。而且这种模板语言对浏览器不友好不像Thymeleaf。同时按前端的开发习惯他们是不可能先启动你一个Java进程后再对前端页面进行调试。 总的来说这样的技术栈是不利于前端本地开发的。 所以在改进前前后端的协作的方式是 1. 前后端同时进行开发2. 后端负责在Java工程中实现后端的逻辑3. 前端负责在另一个独立的前端工程中开发HTML和CSS4. 前端完成页面的开发后他会把前端页面html文件名和页面的逻辑告诉后端5. 后端再把html页面里内容与Java工程中的vm进行对比然后将不同的部分转换到Java工程的vm模板页面中。 这样的协作方式下经常出现以下问题 1. 在将html转换到vm模板的过程中后端有时会转换漏内容2. 转换后前端调试前端问题会很麻烦。前端需要占用一个后端和他一起调试。因为前端不懂如何启动复杂的后端工程3. 命名上经常出现不一致进而导致前端bug。对于同一个概念的情况下前端命名叫item后端叫project 效能提升措施与效果 经分析以上问题均由“技术之间的转换”导致即人工的将html页面从一个前端工程转换到一个后端工程的vm模板语言。 所以解决以上问题的思路就是最好能消除html和vm的转换又或者能减少这个转换过程的失误。 思路有了以后解决方案有以下几个 1. 更换前端技术栈不再使用Javavm模板2. 让前端学习vm模板语言转换过程由前端完成3. 优化后端开发在本地启动的流程方便前端也能在本地启动4. 减小测试环境的部署难度。让任何人都可以部署方便前端进行调试。 方案1短时间无法做到而且改动巨大收益也未知。所以最终是同时做了2、3、4。 虽然当时没有进行度量但实际效果就是前文提到的所有问题都得到了减轻。 原因就是方案2、3、4减少了前端需要向后端传递的信息。很多事情前端一个人就可以解决了。 关于方案2、3可能有人会好奇前端去学习一门新的模板语言成本大吗前端在本地启动一个后端的工程去调试前端代码成本高吗 首先vm模板并不是一门难的语言只要有类C语言的基础比如Java、JavaScript、C#等都不难学。无非就是if-else判断、变量定义、循环等。 其次在后端优化本地开发环境后前端启动一个Java工程并不是一件难事。 反思 整个事件下来本质上是前端本地开发习惯与现有技术栈的冲突。这次效能的提升需要前端开发做一些工作习惯上妥协。 而这只是表面上的问题我们需要去思考更深层的问题 1. 团队成员在改进前为什么一直没有考虑如何改进呢又或者不知道该如何改进2. 对于这次效能改进感观上是提升了但是该如何度量呢 思考问题1是为了让团队的所有的人有意识和思路地提升效能。思考问题2是为了让实践有数据支撑。 答案是什么呢留给读者朋友思考。 Meta的降本增效三大招 Meta降本增效大招之自动删除数据Meta降本增效大招之自动清理死代码Meta降本增效大招之弃用产品
