工作心得 | zKing的学习乐园

摘要

自己在工作中记录到的一些成长变化心得，按年份更新

# 2021

前端设置数据模型的时候，应该是根据 UI 组件去设计数据模型，还是根据后端数据，再去设计数据模型呢？
- 无论根据哪一种进行设计，最后都可能需要用到适配器来做数据转换，从而增加一定的维护成本
- 正确的做法是，前端和后端分别设计，然后再进行沟通处理，通过沟通数据结构，来避免适配器的出现，降低维护成本，如果实在数据结构差异确实过大，才需要使用到适配器

应用混杂的原因在于，没有统一的处理
- 完善的全局方案处理
- 经典的文件上传下载
- 定制 UI 和第三方 UI 统一处理 -- 统一的弹窗，统一的 loading，统一的颜色等
- 统一的工具函数
- 统一的代码规范
- 按模块对 ts 类型进行分类，避免混合重复
- 单独的 service 层来处理复杂逻辑
善用/慎用 Vuex
每次需求需要考虑是否有必要进行阶段性的重构防止代码臃肿
慎用 delete 关键字删除对象 key 值，更多情况下建议返回一个对象，需要 delete 的字段设置为 undefined/null 来处理

如果子组件本身的数据需要频繁同步到父组件中的话，那就需要考虑不再以子组件的模式存在，而是直接在父组件中编写逻辑，或者根据情况改写成 mixins 进行处理
如果一定要写成组件的形式话，可以参考 React 函数组件，使用 hooks 钩子进行回调

摘抄：

架构是顶层设计
框架是面向编程或配置的半成品
组件是从技术维度上的复用
模块是从业务维度上职责的划分
系统是相互协同可运行的实体

简单解释”解构“和”重构“的不同

解构：一件事物本身是由多种不规则边的几何体构成，很难去分类，解构的意义就在于把多种不规则边的几何体重新处理成能被认知的正方体，长方体等
重构: 一件事物本身是由多种不规则边的几何体构成，但重构完全不管，我直接打磨成圆柱体或者圆锥，但照常能使用

可以偶尔偷懒划水，但不能敷衍了事，在其位谋其职

# 2020

在调研一项新技术，或者上手一个新项目的时候，最重要的事情不是马上实践，而是找到相关的文档进行仔细阅读，再阅读相关的代码，了解整个使用流程，才能把握风险，做出正确的决定，不为后面的开发埋坑
在开发一个新项目是，最先要做的不是功能实现，而是从架构入手，从规范入手，对整个项目构建，开发流程，文档维护等进行考虑并确认完成后，再进行功能开发。
可能没办法编写出高质量，高性能的代码，但一定要能编写出规范化，可维护的代码。
需求需要一一确认好，这不是产品和项目的事情，而是开发的事情，有疑惑需要提出并解决，不然吃亏的是自己。

自己平时是如何去开发的？

开发过程
- 开发前（要做什么？——> 怎么做？——>需要多少人做？——>做多久？——>什么时候能上线？）
  - 需求评审（进行需求分析，确认是否能够实现，并给出初步的解决方案）
  - 人天评估（根据原型和业务，落实到不同的模块进行评估，确定好关键日期节点）
  - 技术评审（该项目需要采用的技术，根据项目的紧急度去选择对应的技术，评估业务实现的可行性，另外还有日志记录，单元测试等）
  - 环境评估（是否需要配置新域名，是否需要配置 nginx 转发，是否需要多个环境，是否需要 https 或者公网开放）
  - 人员对接（UI-设计图，产品-原型，后端-接口文档，测试-用例评审，前端开发人员-小组会议功能分配）
  - 文档撰写（每个项目都需要有对应的文档进行记录，需要记录以上内容）
  - 个人排期
    - 需要根据个人的情况进行日程管理，确认是否需要添加资源
    - 根据对应的项目模块进行划分对应的开发日期，确保能够在测试时间节点前发布到测试环境
- 开发中
  - 简单搭好一个大致框架
  - 写代码前要先落实好编写规范，git 规范，代码风格等，确认好整个项目结构
  - 在实现业务逻辑前，是否还有其他逻辑需要去准备？
  - 落实具体逻辑，确认完逻辑再进行开发，而不要一味写代码
  - 不断开发，更新文档
  - 有问题需要及时沟通，最好还要做代码评审
  - 基本开发完后，如果还有时间，需要进行细节优化，甚至进行重构优化
  - 如果有用例，开发完成后需要根据用例进行冒烟，没有则根据业务逻辑跑通主流程进行冒烟
  - 发布到测试环境后，需要不断地跟进，优化
- 开发后
  - 上线交付，更新文档，注明关键点
  - 如果项目中发生一些问题，最好记录下来，进行回顾避免下次再犯同样的错
对待自己开发的产品，最好要有热爱，不然一定要有责任
- 对于需求程序员要积极提出不合理的地方，并且告知如何改变
- 让产品有更好的体验
- 让代码“赏心悦目”
- 有改善性能的意识
- 有捕获错误进行日志记录的意识
- 考虑业务逻辑下的安全性
- 在必要的地方需要写注释，注释需要有规范
- 单元测试代码
- 代码整体优化
当出现的 bug 或者不合理的需求并不是由自己造成的时候
- 不要急着甩锅，而是要先找到对应的错误方，进行沟通，找出解决方案。
- 再去回答“发现 bug 或者需求不合理”的相关人所提出的问题，并提供解决方案
- 如果相关人觉得还有问题，可以三方一起来进行一个方案的沟通解决