Testin - JSP项目有感

标签： #Share

最近被分配到Web自动化测试的项目开发任务，由于时间紧张，因此为求迅速，节约前端成本，把部分的前端开发任务挪给后端，通过JSP这种老掉牙的技术去做，但是在真正的制作当中，有很多以往没有想到，或者没有规范话的好经验值得我去深思和回顾，大致内容如下：

公共分页展示JS

真正的官网或者Web项目中，分页随处可见，且复杂的工程分页要求也比较麻烦，比如默认如何显示，比如还需要显示条数，查询窗口等等，代码非常复杂，但这往往具有通用性，回想实习时候，第一次真正做企业级开发，什么东西都自己写，根本没有意识到，这种代码是完全可以重用的，现在想来懊悔不已，给个例子如下：

// 全文请见: Testin-JSP项目有感
<c:if test="${pager.totalCount gt 0}">
    <div class="pagination-panel">
        <c:choose>
            <c:when test="${pager.startPageNo == 1}">
                <c:if test="${pager.totalCount <= pager.pageSize}">
                    <span><fmt:message key='common.page_txt1'/>1-${pager.totalCount}<fmt:message key='common.page_txt2'/><fmt:message key='common.page_txt3'/>${pager.totalCount}<fmt:message key='common.page_txt4'/></span>
                </c:if>
                <c:if test="${pager.totalCount > pager.pageSize}">
                    <span><fmt:message key='common.page_txt1'/>1-${pager.pageSize}<fmt:message key='common.page_txt2'/><fmt:message key='common.page_txt3'/>${pager.totalCount}<fmt:message key='common.page_txt4'/></span>
                </c:if>
            </c:when>
            <c:when test="${pager.startPageNo == pager.totalPageCount}">
                <span><fmt:message key='common.page_txt1'/>${(pager.startPageNo-1)*pager.pageSize + 1}-${pager.totalCount}<fmt:message key='common.page_txt2'/><fmt:message key='common.page_txt3'/>${pager.totalCount}<fmt:message key='common.page_txt4'/></span>
            </c:when>
            <c:otherwise>
                <span><fmt:message key='common.page_txt1'/>${(pager.startPageNo-1)*pager.pageSize + 1}-${pager.startPageNo*pager.pageSize}<fmt:message key='common.page_txt2'/><fmt:message key='common.page_txt3'/>${pager.totalCount}<fmt:message key='common.page_txt4'/></span>
            </c:otherwise>
        </c:choose>
        <c:if test="${sessionScope.deploy_target eq 'PRIVATE CLOUDS' and isScriptSelectPage eq 1}">
		<span style="margin-left: 5px;">
		<fmt:message key='common.page_txt5'/>

我们做过MVC开发的都知道可以给model增加属性，因此，重要属性名称一致，参数名保证一致，即可完全做到高效的重用，做后端开发的伙伴都知道工具类的重要性，但是经常会忽略，其实前端也有工具类的说法，至少我在学习期间几乎没有意识到这种问题，因为毕竟前端的需求针对性较强一些，也不复杂，但真正的面向对象的思考，是一个开发者应该一直坚持的事情。

装饰模式 - 核心界面为其装饰头，尾，菜单的效果

我们去看阿里云或者其他实用型官网项目，如果有复杂的头，尾，左侧导航等界面，难道我们都得在界面中去实现吗？在学习jsp的时候，有import这个说法，可以把界面引入到本界面来，实现上述的效果，但是总觉得每次写一堆代码怪怪的，而且头部，尾部，菜单还得分开引用，比较麻烦。那么可以考虑配置装饰的方式，通过配置给界面主动添加如头部，尾部，菜单的界面

<sitemesh>
    <!-- 指明满足“/json/”的页面，将被排除，不被装饰 -->
    <mapping path="/json/*" exclue="true"/>
    <mapping path="/ajax/*" exclue="true"/>
    <mapping path="/login*" exclue="true"/>
    <mapping path="/*/ajax/*" exclue="true"/>
    <mapping path="/*/*/ajax/*" exclue="true"/>
    ....................................
</sitemesh>

合理的界面分层

刚开始做开发，没人教，或者有人教的时候，总是喜欢这么做，把所有东西堆到一个界面里去，然后传递参数到后端，后端把数据获取到，添加到model里，再展示到前端，顺便通过jquery把请求的界面节点的数据部分拿出来，再替换当前界面里的内容，以此完成一个完美的 “Ajax界面刷新的效果”，但是这么做有不好的地方

想要这么做，在ajax请求时必须对返回的界面转化为jquery对象，然后通过find或者其他方法把数据节点位置找到再替换当前的内容，这里存在两个问题，一个是低版本的jq转换H5界面时候一直报错（换成高版本就OK）另外数据节点的寻找需要进行DOM的解析，会耗时
把参数什么的刷到后台，然后又从后台转到前台来，有点多此一举

如果这么做呢？
查询条件界面（留一个数据Div填充）- 数据界面（直接被Div包含，去掉多余的样式，body，html等无用的东西）

然后通过默认函数加载数据，通过分页跳转界面再加载数据等等… 完美解决了上面的需求，同时有以下的好处：

界面分开后，代码会更加清晰。哪个部分干什么事一目了然
参数只用往后传，不用再往前传，完全解决了各种莫名其妙的回显问题
效率更高（由于不用再解析返回的界面了，直接通过jquery append到指定节点位置即可）

MVC mapping * 占位符的妙用

在MVC开发中，总有这样的需求前端三个界面不同，但是功能类似，此时映射三个mapping，到底写三个还是写一个然后把想法抽取？当然不可能写三个，但是写一个想法抽取的话，在语义上不明确，而且增加了额外的方法，让类变得更加复杂了，比较麻烦，那为何不利用 *去站位匹配呢？

// 此时匹配 list-任意内容 -> 如 list-ajax  list-jsp等等
@RequestMapping("/list-*")

这样做的好处，可以把代码减少的最少，同时语义稍微明确一点，再来看一个更加方便的用处把

在初期学习界面，写的界面比较简单，总会用到各种各样的不包含太多逻辑的index界面，或者包含非常简单的基本数据而已，但是利用MVC设计的话，需要映射mapping，怎么做可以让代码更加简洁而且通用呢？

@Controller
public class BaseController {
    @RequestMapping("/path/*")
    public String jumpPath (HttpServletRequest request) {
        String path = request.getServletPath();
        // 截取path/ 之后的具体路径  如 finalPath
        String finalPath = path.sub........
        return finalPath;
    }
}

// 前端页面
href = "/path/task-list"
href = "/path/monkey-list"
href = "/path/money-list"
此时不再需要给每一个不需要什么逻辑的界面单独写一个controller去映射界面，是不是方便了很多？

一行代码，10个BUG

真正开始工作之后才知道，什么jsp。ssm都是老掉牙的东西，整个编程的风气如今都是高并发，高可用诸如此类的，但是有天看到一句笑话，一位程序员说，天天尼玛高并发，高可用，一行代码，10个BUG，玩NM的高并发，如此粗俗的话一下子击中了我，后来我渐渐发现，原来我也是整天想着高并发高可用，完全没有意识到真正基础的重要性，最近做一个大批量文件导入的模块，涉及文件上传，用户操作配置，文件解析，文件导入等几个步骤，刷刷刷，代码写完，自测没毛病，交给测试了，后来一堆隐患问题就来了，直接掠过过程说问题：

耗时操作的部分按钮没有加上限制，即点击后仍然处于可操作状态 -> 非常致命
代码设计上，想到哪里写到哪里，功能最后都实现了，但是总的来说不完美，虽然不擅长JS。但这也不应该是借口，比如弹窗，按钮等等的重置效果，成功或者失败的响应效果，就应该封装好，统一调用等等

总结：做一个事情不难，想真正做好一件事情，难

一切都是有可能的，甚至那些不可能的也是.

实习加工作10个月了，突然回顾之前的知识，觉得太浅显，但是仍然从如此浅显的内容中提炼出了以前并没有意识到的技巧或者更好的设计方式等等，因此记录了此篇感触，用以醒悟自身，不要自傲。

2019年 8月26日 Kerwin