代码封装与细化及其他思考

这可能算是一个吐槽贴。

我看过2000-3000行代码,作为一个整体,没有细分业务流程,也不按照代码先后顺序,就这么洋洋洒洒两三千行代码。明明只是添加一个小小的功能,但是耦合紧的一逼,在这基础上,改动一个值,影响另外好几个值(脏值检测处理),甚至连手动触发这个值改变,连带调用其他修改的操作函数都没有,也没办法添加。

这样的代码着实比较头疼,原则上来说,代码的功能点应该是最小模块化,并不是说seaJS、requireJS,而是约定俗成的写法或者说是代码洁癖,所以才有封装的存在。

好比简单的登录注册,检测的代码可以封装为validate.js,只用于返回验证完的true和false;因为要兼容ie6/7/8 password的input,于是需要一个placeholder.js用于兼容处理;通用的错误提醒(基于validate.js)与通用的事件处理函数,可以作为登录注册业务公用的代码member_common.js;最后,登录注册的具体代码login.js/register.js实际需要的单独处理与依赖到的相关公用函数的调用只是占用了几十行。

1
// 所有验证通过 验证不通过则在其中显示错误消息
if (memberCommon.usernameHelper($iptUsername) && memberCommon.passWdHelper($iptPasswd) && 
    (!$iptCheckcode.length || memberCommon.checkcodeHelper($iptCheckcode))) { // 需要checkCode 就进行验证  不需要就跳过
    $('.J_loginForm').submit();
}
1
// usernameHelper 做的操作
memberCommon.usernameHelper = function (dom) {
    var $dom = $(dom),
        input = $dom.val(),
        result = validate.checkEmail(input) || validate.checkPhone(input);

    this.showHideSingleMsg(dom, !result ? '请输入正确的邮箱或手机号' : undefined);
    return result;
};

问题查起来,就非常简单:验证有问题,查validate.js;错误处理有问题,查member_common.js等等。

好比很久之前分享时说的一句话:因为细分,所以强大。需要哪些功能,拆分功能,把功能交给单独的功能函数/方法,尽量减少各个函数方法间的依赖而靠参数来传递,避免牵一发而动全身的情况。

好比一个公司,技术做技术,技术里面分前端、分后端、分运维……

衍生的其他内容:

  • grunt 图片压缩插件还包含了图片缓存功能,于是被gulp揪着吐槽了一世纪
  • handlebars无逻辑模版引擎的受欢迎,或许是因为可以封装逻辑处理
  • why MVC ?

嗯,以上就是我的吐槽,以及关于封装、细分的一点点sun of beach的思考。