warmhug

技术成长、工作感悟、教训反思

企业应用

这半年多一直都在做企业应用类型业务相关的开发,多少有些心得与体会。这里聊下企业应用开发,从“前后端协作”及“组件和代码”两方面说起。

前后端协作

企业应用大多是「重数据」、「重业务逻辑」、「轻交互」、「给少数专业人员使用」、「视觉设计要求低」、「交互不必太创新」的类型,这就意味着前端开发「不必兼容所有浏览器」、「不必太在意页面性能」,一般是扮演支持角色;后端开发就要包揽绝大部分工作量、当然也包含html/js/css等原本属于前端开发的工作。

所以、前后端常见的工作协作模式是:前端提供各种做好的业务组件、使用demo;后端直接拿这些组件demo套用到业务中、并写上业务相关的代码。当后端同学碰到问题:如组件用不起来了、一些组件没提供的css样式不会写了、较复杂的交互效果搞不定了,就让前端同学来支持下。

随着mvvm开发模式及AngularJs的流行,很多企业应用开发也使用了它。这就带来了新应用的两种模式:

  • 完全的SPA(单页)、前端来渲染。
    • 这种是典型的使用方式、也是很彻底的前后端分离,后端只提供封装好的数据接口,其他工作都交给前端来做。
    • 但这样前端会增加「管理页面路由」、「页面状态控制」、「页面权限控制」等不少额外的成本。
  • 非SPA、前端来渲染。
    • 表现在「页面路由、跳转、权限控制、状态管理」大多还是后端来做。
    • 但后端velocity页面上的vm语句很少,可能只是在vm变量里放置页面需要的数据,但页面渲染工作都交给html/js。

这两种模式、都面临一些同样的前后端协作问题:

  • 传统方式,前端提供组件和demo,后端拷贝修改并套用业务数据即可:

    • 后端不用拼装json,直接在vm页面上写数据变量。后端很容易独立写或修改vm。
      • 对于列表表格类型(map、枚举等),用vm的for循环生成列表htm+data
      • 对于数据验证,用Ajax方式、返回true false的结果
      • 对于表单提交,用同步方式提交、刷新页面
    • 联调阶段:前后端耦合小、开发能直接把数据填到相应坑位查看数据及展示对错即可、而不必等待前端修改
    • 不好的地方:
      • 页面能被随意修改,velocity里可能掺杂不少业务逻辑,页面很可能会越来越难维护
  • 现在,好的地方:
    • 前后端分离的更好,对于后期维护比较简单
  • 现在,增加的一些成本:

    • 几乎所有类型的数据都需要转为json格式,对不同的后端数据类型都要做转换
      • 但如提供给页面展示用的:input、table等原本就不必为json类型
    • 由于数据格式易变(业务变动比较频繁),改变之后前后端都需要修改代码(原来vm方式也同样有此问题,但开发改vm会更熟悉点)
    • 数据坑位都用特殊的前端代码表示,如ng-model="data"、``、ng-repeat="key in list"等,另外这些数据一般还需要再经过二次加工转换
      • 这会导致后端改页面更困难、对前端依赖更严重。
    • 开发同学大都对jQuery有了解,简单页面交互自己用jQuery一般能搞定;但现在可能会碰到jQuery与angular协作的冲突。
    • 项目如果是「有多个开发、只有一个前端」,因为前端工作量变大,到联调阶段、问题一多 前端就应付不过来。
  • 现在,可能遇到的angular使用问题

    • 使用时入门成本较高,需要转变思路「从操作dom」转为「操作model」,初期转变成本高、表现为:
      • 删除列表list某一项时,仍然$('li').remove(),而不是删除相应条目的数据。
      • checkbox radio等设置时,仍然$('.xx').attr("checked", "checked"),而不是直接设置数据
      • 显示隐藏页面某一部分,仍然$('.xx').hide(),而不是使用ng-hide="data"设置data
    • angular的directive指令、只用在html上做标记和配置、就能自动运行,使原本的静态html标签产生神奇的动态效果。
      • 但这增加了遇到问题时的调试及修改代码的困难、有时候甚至让人找不到该修改哪里~
        • 解决办法:在设计directive指令时、所写的配置项更集中、更清晰易懂,减少使用困难。

组件及代码

代码组织上、代码文件组织上,都该以清晰、简易为主,这样遇到问题就能够马上定位到问题所在。

directive的书写和使用,做到什么程度才好呢?

  • 让不太了解这些的人、也能很快一眼看懂
  • 使用中碰到问题时快速找到可能出问题的源码位置

有个常见的问题:我们到底该使用「功能全面丰富的集成式」组件;还是「简单专一」多个组件搭配起来使用?前者可能大而重、多数功能不一定用得上但可供备用;后者小巧玲珑但搭配使用成本可能比较大。

另外更重要的是组件常见的「细节功能」是否贴心全面、是否能与其他组件或代码能很好的共存。以下举些实例:

  • 项目有动态表格的需求,使用了angular的ng-grid组件,就发现了这个外表功能强大的组件细节上的一些不足:
    • 表格行列很多时、它在固定的容器宽高下、会出现内滚动条。但业务上有高度自适应需求、它没有提供良好解决办法。
    • 表格的「单元格高度」是固定的,不能随着内容多少改变,需要自适应高度时需要再另外设置。
    • 单元格内“只考虑了”文本类型的数据,像图片、按钮组等其他稍复杂类型的数据没考虑。
  • 写输入框的「数据合法性校验」的代码(或组件)
    • 一般只考虑“输入框的数据变化时”去验证。
    • 但其实输入数据不变、其他条件变化时也很可能需要验证。(如验证url、其他配置项等变化)
  • 不同代码协作问题:项目中使用了checklist-model组件,它主要使用checklist-model代替ng-model,能够简化单纯使用checkbox时多写的一些代码。但这个库的issue里提到一些问题How to validate等、反映了这个代码可能并不能与其他代码很好协调工作。

  • 还有其他的如:angular-strap组件库中的select组件多选或单选选中的内容过长时,在一行显示不全的问题;下拉的数据条目过多需要有内滚动条、不然会超出页面高度数据被遮挡。datepicker组件没有内置默认的清空按钮

以上说的都是出自业务中实际碰到的需求。所以、组件做的好必须要考虑许多实际细节需求。选择使用组件时也要考虑的充分、当某个组件不满足功能需求或细节点不完善时、就换个其他更完善的组件。


October 11, 2014 | by warmhug | js