Skip to content

Latest commit

 

History

History
97 lines (83 loc) · 6.07 KB

solution.md

File metadata and controls

97 lines (83 loc) · 6.07 KB

我的核心

如何用最少的代码做最多的事情，如何只专注逻辑本身

遇到的问题

  1. 设计，交互风格随着人员变化而变化，伴随而来的是琐碎，重复地返工过程，每一次的返工， 都导致代码生命的尽头。 然而更随潮流，变更是无法抗拒的过程，那么怎样才能快速，最小化地满足变更？
  2. ToB的产品形态，在固定的领域内也是相对固定的，那么不变的是什么，变化的是什么？ 如何利用这份相对做到更快地交付？(定制化的考虑？配置化？)
    领域驱动设计的思考
    定制构想
  3. 在业务支撑过程偿还了大量最早的欠考虑的债， 这样就需要考虑，同一个功能，不同平台，业务的数据流存在相同的时候，这层如何复用。
    能否用一份代码打包出不同平台。（PC，移动，PWA，各种小程序，electron） --- uniapp
  4. 开发完成后没有一套共同认知的测试方案，对自身代码如果在开发周期内没有做到极尽测试 后面的修改的成本将随时间成倍增长。对前端的自测，到底要测哪些内容，用什么方式测,以及如何回归？
  5. 维护的困难：底层工具库不统一，编程范式不统一，没有任何描述，耦合严重，没有为未来预留......
    这些让我对代码充满了恐惧，也许更改了一行代码，就会破坏一些根本不相关的东西，导致我下意识地采取更多的防御式编程，并对大的更改非常抵抗，如果没有绝对必要，不要碰任何相关的代码。
  6. 开发协作，人事变动，项目交接没有明确的基础需知，不同的经历或者习惯，必然造就一些不必要的问题。
  7. 无效总结：我犯过的错误只是我的积累，换个人重复地犯着一样的错误，如何让积累成为共同？

重构到底重构什么

对重构的持有的态度

不加思索地重写，最后只是会换另一个重写的理由，从中并不能获得‘可改进持续’的目的。
不加思索地拒绝重构，最后只是会在迭代的过程中一直偿还技术债，直至偿还不动宣告破产。 如何找到那个平衡点？

  1. 持续性

1.1)每一次废弃，应该是以修改过去的代码为主观，而不是完全抛弃。 我们更容易从错误的代码中学习，而不是从成功的经验中学习。

  1. 可维护性

2.1)我为什么想使用Typescript?

  1. 使用类型和接口等概念来描述正在使用的数据，是极好的文档
  2. 让javascript的面向对象的特性更加明显
  3. 减少运行时错误

2.2)我为什么不想使用Typescript?

  1. javascript 的开发者社区更巨大，更方便找到成熟的项目和可用资源
  2. OOP开发经验很薄弱的时候，无法真正地利大于弊
  3. 无法说服自己面对存在仅需要修改语法的工作

2.3) 见Typescript的运用

整个架构组成的思考的角度

  1. 系统级：微前端（每个模块都能成为独立的项目？lerna 包管理，可独立依赖，可独立打包)，
    监测fundebug（对方：浏览器，地理位置，带宽，自身：报错，性能 ：慢怎么个慢法，多种因素如何定位） , 日志

  2. 应用级：组件库 (改轮子进而贴近实际)

改轮子进而贴近实际，设计最多变化的为圆角，行高，颜色，字号。 组件库引用的方式不再使用npm，而是直接打包完独立到项目中
一次变更对应着一个批量修改的脚本

  1. 模块级：组件化，模块化

3.1）如何设计合理的方式管理CSS，复用，隔离变化，通用变量
3.2）组件封闭原则和粒度

  1. 代码级：规范(示例包含简单功能流程，可快速依葫芦画瓢)，原则，质量

4.1）开发流程：代码合并方式->代码提交信息（git hooks 检查）->代码规范自动化（Prettier + husky + airbnb + lint-staged）->测试驱动开发
4.2) 测试驱动开发基本步骤（交叉）

1.编写一个不通过的测试
2.运行这个测试，并保证它不能通过
3.编写应用代码，让测试通过
4.运行这个测试，保证它能通过
5.运行所有其他测试，保证程序的其他部分没有被破坏
6.重复以上步骤

4.3）质量正常没有一个重要的标准。质量代码是一种能够正常工作并易于扩展的代码。
EVAN的质量代码的原则：

  • 提取函数和模块以简化接口。
  • 通过测试验证代码行为。
  • 尽量避免非纯函数。
  • 良好的变量和函数命名。

开发的原则

  • 单一职责原则：仅存在一个需要被改变的理由 ，避免修改了一个功能导致其他的功能发生故障。
    不要做万能组件或类的封装，当一个组件或者一个类知道了太多或者做了太多事情的时候，就要考虑重新找寻更好的拆分设计。
  • 开闭原则：允许新增代码来修改系统行为，而非只能靠修改原来的代码

具体见代码实践

维护的原则

  • 从短期来看，如果能够快速地提供功能驱动业务增长，不论其设计多么丑陋，代码质量多么差，只要 不影响性能，未来就有改进空间。
  • 在业务进度不合理的情况下，只能在丑陋的，旧的代码上不断堆砌功能。
  • 如果发展到影响业务了，就愉快地选择重写，走向更好的设计，架构。

Todo List

  • 编写vscode i18n 插件
  • 编写自动化测试范例
  • 编写node命令行工具
  • 编写组件库整改方式
  • 编写生成代码组织结构图
  • 编写node自动化gulp,phantomJS
  • 编写内嵌本地化
  • web性能调优跟踪
  • 业务价值的挖掘？用户的分析
  • 静态资源包平台
  • 监控平台