开发心得

• 我要把这件事做成
• 怎样做才是更高效的
• 什么事情是关键要牢牢自己把握，才能保证事情做成
• 第一思维是什么事都敢承担才能正确评估
• 生为一个前端，体验是重点

银行账户设置
发薪前数据监控
用户授权
考勤台账、流程
膳食台账、流程、二级台账
代发台账、流程
竞业限制金、申请、提前终止
专项奖励管理台账、方案申请、向上级申请发放、下级提交发放明细、查看发放明细汇总，向上级申请发放明细汇总

关于项目开发的一些问题和心得

• 就 vue 项目而言，代码结构主要分为组件、函数、请求、路由、多语言、状态等。

关于公共组件

• 其中项目的初期框架和公共部分最为重要，在“国内薪酬”模块中就存在公共部分没有特定人员维护的问题。这导致后期组件功能臃肿、缺乏使用文档等问题，再加上参与的人员水平参差不齐，公共组件反而成为了影响开发进度的因素之一。
• 公共组件的难点在于开发经验，重构优秀前端库是快速积累这方面经验的捷径。例如：“长期激励”模块中有一个输入值保留2位小数的需求，过去的解决方案是使用 el-input 的 blur 事件来格式化数值，但是这种方法存在事件触发顺序的问题。在 input 编辑状态时直接点击表单提交会造成 submit 事件早于 blur 事件触发。参考了 element-ui 的解决方案后，新的组件采用输入短路的方式实现。当有输入时造成显示短路，显示输入值并 emit 到外部保存，当失去焦点时清空输入值去除短路，显示外部保存的数据。

关于请求

• 请求不仅是一个异步问题，还是一个缓存、节流和响应问题。
• 例如：国家地区、字典、菜单等类似的数据在一个浏览器访问周期一般是保持不变的，所以对类似这样的请求应当对返回结果进行缓存。
• 例如：在整个美的 IHR 架构中很多短语是通过字典配置管理的，在业务代码运用时需要使用这些异步获取的字典数据来进行翻译，所以就要求这些数据具备响应。
• 在“长期激励”模块中我们采用字典服务来解决以上问题。其中，通过 lodash 的 debounce 函数来实现节流功能，通过 bus 技术实现数据响应，最后结合 sessionStorage 的浏览器生命周期尽量延长了 bus 的缓存周期。
• 展望：实际上在请求方面有其他更系统的解决方案，如 HTTP 基于 ETag 和 Last-Modified 的缓存机制，基于 ServiceWorkers 和 Fetch 的前端中间层等，需求和所学有限不能够一一展开。

关于缓存和页面通信

• 缓存实际上是多页面应用的一个遗留问题，在单页面应用中已经通过 vuex、bus 完美解决。
• 在 IHR 架构中，由于各个模块由一个单页面实现，在进行页面间通信时需要借助 sessionStorage 保存交接数据。比如：业务中的流程填写和选择审批人分别属于两个模块，在从填写页跳转时需要缓存数据便于提交及返回时复现用户输入。
• 在原来的机制中由于没有设置缓存白名单，导致不同流程间缓存混乱且不能及时清除。“长期激励”模块通过提供缓存服务统一读写方法来实现统一缓存名称、设置缓存白名单和清除缓存的功能。
• 展望：浏览器的缓存机制还包括 LocalStorage、cookie和基于 IndexedDB 的 Dexie.js 前端数据库等，而页面间通信也可以使用 postMessage、SharedWorker 等方案，所学有限在此不能够一一展开。

关于路由和菜单权限控制

• IHR 项目由于功能众多，为了提高打包速度和迭代需求采用了微服务架构。我们把基础部分（例如：登录、首页、系统设置等）作为公共模块由一个单页面应用实现。在此基础上嵌入其他业务的单页面，实现了各个模块独立开发、独立发版的需求。
• 在“国内薪酬”模块中路由和多语言采用了集中管理，在接手了多个功能块后发现这并不理想。
• 首先路由的集中管理导致修改 bug 时，总是需要先查找对应 url 下的模块引用路径，才能找到对应的代码块。
• 其次在开发阶段一旦出现页面组织调整都需要修改公用的路由文件，容易造成不必要的提交冲突。
• 所以在“长期激励”项目中，我们把每个业务块的路由和对应的业务代码集合在一起，然后才引入到统一的注册文件中。
• 在 IHR 项目架构中菜单权限只支持到二级菜单，而“国内薪酬”模块由于没有预先处理路由结构，导致出现三级菜单能够直接通过 URL 访问的 BUG。
• 虽然这可以通过配置按钮级权限和路由守卫来实现菜单拦截，但是给使用增加了不必要的复杂度。
• 在“长期激励”模块中，我们使用路由 meta 元信息来设置当前路由对应的二级菜单、多语言和图标等信息，从而解决了普通次级菜单的权限问题，同时也便捷了菜单栏和面包屑导航的生成。

关于多语言和文件管理

• 多语言其实也存在着集中管理还是分布管理的问题，集中管理看似复用了相同的翻译节约了文件大小。但在实际操作中由于多人合作时个体并不愿意花费精力查找现有翻译，反而造成了更多的管理混乱。在“长期激励”项目中，我们采用 i18n-loader 处理多语言标签，使多语言嵌入到组件中。这样的好处是便于组件的迁移、使修改更加便捷，但是依然存在翻译重复、不够精简的毛病。
• 最后从代码管理的角度，我们给公共组件、函数提供了统一出口，并在各个业务模块中采用了统一入口。这有两个好处，1、当需要改变某个文件指向时只需要改变出入口文件即可。2、在编写业务代码时，引入将变得更加便捷。但这也埋下了隐患，统一出入口会导致潜在的引用混乱问题，并且缺少摇树时公共依赖包会包含所有组件。
• 展望：代码管理是一门综合性的学科，掌握脚手架仅仅只是应用，学习 webpack 和 yarn 也仅仅只是入门。能够准确把握项目现在及未来的需求，了解代码开发中开发人员面对麻烦的心理，然后结合 webpack、yarn、git、编辑器特性和插件等工具来提供舒适的开发环境才算真正胜任了架构工作。
• 项目管理永远都在不断发展和演变中，过去为了迭代开发而被迫把项目拆分成多个单页面应用实际牺牲了部分用户体验，新 @vue/cli 脚手架提供热打包机制给解决这一问题提供了思路。
• 最后路漫漫其修远兮吾将上下而求所。

关于 HTML 和 CSS

• HTML 主要是标签语义化，不过这点似乎越来越薄弱，甚至被刻意回避。比如，应用界面由于其对内性质没有语义化的需求，反而为了统一样式而刻意只使用 div、span 等布局标签。对于展示型网站似乎更重视语义化问题，但现在商业推广如此普遍 SEO 优化已经不如从前重要。
• HTML 存在一个内联标签换行被渲染为空格的问题，使用 font-size:0 的处理方式本人并不推荐，它违背了字体大小的初衷。在“长期激励”模块，由于对布局组件做了封装，所以能够轻松的对 slots 进行过滤，去除标签和内容都为空的 vnode 对象。
• CSS 在很多前端看来是最容易掌握的部分，实际可能是最需要统一规范的部分。例如，在“员工自助”模块需要使用到富文本框输入和展示，由于该项目采用嵌套 class 的方式组织样式，导致在内部的富文本框的默认样式被各种影响而且无法复原，最后被迫无奈使用 iframe 和 PDF 进行隔离。CSS 由于作用域的缺陷一直被诟病，vue 使用 scope 技术也不是尽善尽美，它无法很好解决在 body 下动态生成标签的样式隔离，在“长期激励”模块我们引入 emotion 来隔离样式间的影响。由于它 CSS in JS 理念，还能够实现动态切换主题的功能。
• 对于 CSS 规范由如下一些想法：
• 1、尽量使用独立类名操作不同样式，深度嵌套的选择器会导致后面的修改举步维艰。
• 2、只使用盒子模型的属性来进行布局。例如 line-height 被广泛用来设置单行垂直居中，这种方式虽然便捷但不能照顾所有情况，在 el-form-item 中如果文本内容过长出现换行就会出现行高过高的问题。
• 3、现今一个项目的开发周期可能长达2-4年，通过各个模块的迭代不断扩充。在这个过程中系统风格、样式也在不断进化，在业务代码中书写样式会导致各个模块的风格迥异，应该抽取独立的样式组件方便跟进风格的转换。

一些常用的库和面向的问题

• decimal.js 用于解决浮点运算的精度不准确问题
• xdate.js 用于处理时间日期问题
• ECharts 用于展现图表
• pdfobject 用于展现 PDF 文件
• Summernote 用于实现富文本输入
• vue-element-admin 适合管理系统的 UI 库

关于bug

• 就 vue 框架而言，最常见的 bug 主要由数据失去响应、this指向错误、异步混乱和基本逻辑错误4个原因造成。
• 数据响应和this指向属于单点错误，只要利用 Vue Detools 观察数据，便能轻松定位和处理。
• 异步混乱和逻辑错误往往嵌入在业务链条中，这类问题是影响开发进度的大头，修改过程中很容易造成其他次生灾害。
• 虽然异步等待在招聘面试中属于第一梯队问题，但从现在接触的项目情况来看，很多开发人员只能够回答出概念，并不能真正理解异步的处理方法。
• 逻辑混乱并不是一个纯粹的技术问题，出现的原因可能是开发人员的代码组织能力本身不足也可能是需求的不断变化导致的编码惰性。

解决之道

• 从面试开始：

  • 现今大前端时代各类库层出不穷，招聘时关注对某个库是否熟练并没有太大的意义，反而是开发人员自身的逻辑组织能力、对新事物的接受能力、对繁琐细节的耐心更为重要。
  • 基础知识的考核应该面向开发从新整理，例如：在面试的过程中经常被提及的浏览器内核问题，回答 Trident 等名词并没有意义。真正需要明白的是，不同浏览器不同版本在构建渲染树、渲染树渲染和JS解析时存在差异，具体特性在浏览器支持程度可以通过 MDN 等网站查询得到。

• 从管理优化：

  • 从个人经验来看，推行代码精简理念、重视代码评审和文档维护可以解决大部分问题
  • 推行合理的代码精简有多个好处。首先它能够加深开发人员对框架、概念的理解，其次能够提高代码组织能力，再次还能够对新语法、新对象的普及起到促进作用。
  • 而代码评审是实现上述的较佳方案。通过粗审整体、整理典型错误和解决方案、安排重构时间，来达到了解每个成员的水平、优化人员组成及后期工作安排，才能逐步提高团队整体能力和保证开发质量。
  • 从过往项目的经验来看，一个新进入的前端在文档健全的情况下只需要3-5天便可以独立进行业务开发。而缺乏文档的情况下，这个过程一般都会延长到1个月或更长。
  • 事后维护文档对于深陷逻辑的程序员是痛苦的，目前已知较为有效的方式有如下两种，1、采用 TS（未掌握）利用其强类型特点提供输入提醒，缺点是需要额外的语言学习开销；2、在传统 JS 中，我们采用为公共组件、函数提供统一出口，并在出口中维护 JSDoc 来维护项目文档。
  • 其次磨刀不误砍柴工，从过往项目来看 VSCode 在前端开发中占据统治地位，但是它的许多能够提高开发效率的特性并不为人所知，而且从 JS + vue 项目来看，还存在着部分插件相互冲突的问题。如何标准化开发工具、开发工具最佳使用指南一直是项目管理的薄弱环节（目前 VSCode 和 Chrome DevTools 是我的主要学习目标）

包含离职台账
通知发起、通知查看（员工）
模板管理，新增
人员类别管理
窗口期配置，一年中不能行权的日子
激励方案管理、新增、报表
激励方案分配台账、流程
发布授予通知台账、通知
开设证券账户台账，开户流程
限制性股票台账、缴款流程、交款成功通知
正式授予台账、正式授予通知、取消授予通知
合同管理、签订电子合同流程
注销管理、注销流程
解锁台账，解锁申请流程
通知台账，发布注销、解锁通知
缴税管理台账，限制性股票缴税流程，合并计税补缴流程
审计红线人员管理
锁定已解锁人员管理
授予及解锁明细
月末人员异动信息
异动明细信息
异动时常信息
离职人员管理