技术填补-问题
- 问题1
- 开发过程中因为时间紧迫导致的实现不合理。
- 举例:查找10000以内的质数。
- 循环的方式，筛选法
- 问题2
- 暂时没有想到更好的实现方式而妥协的版本。
- 刚开始使用if…..else实现
- 演变为使用责任链的模式
- 问题3
- 架构设计前期没有考虑到的细节。
- 交互细节-> props传递参数(交互冗余,流程较长)
- 使用全局状态管理实现参数传递
- 问题4
- 不合理的交互设计，导致技术实现复杂
问题5
修复变重构
- 小的技术债务不做偿还,最后会演变成一 场大规模的重构工作,导致产出不高。
- 影响开发速度
- 技术债务的存在导致整体开发需要兼容的点过多,影响开发效率极大影响上线速度,导致整体项目迭代缓慢,失去核心竞争力。
容易陷入维护旧功能→开发新功能→兼容旧功能→维护旧功能→开发新功能….这样的恶性循环
技术填补-解决方案
解决方案1
- 优秀的架构设计是基础
- 必须能够有效处理当前需求可预见的情况,对于未知的、可能出现的特殊情况,很小的改动就能解决问题。
- 根据当前的业务,进行合理的项目拆分,尽量的代码解耦和。
- 必须有日志模块,操作日志,错误日志,业务日志等等
- 解决方案2
- 良好的技术培训和传帮带能力。
- 让每一位开发者可以从更深一层次理解自己所需要实现的功能。
- 从最开始的代码规范、到熟悉业务、最后再到编写文档。
- 解决方案3
- 充分的技术方案可避免一部分技术债务的产生。
- 技术方案是充分理解需求之后所能产出的对需求理想的实现方式必要性不言而喻。
- 解决方案4
- 不同工程师之间可以相互review。
- CodeReview是非常重要的,同时也是对自身的一个提高。
- 解决方案5
- 提升对修复技术债务重要性的认知
- 工程师如果能预见一个债务可能导致的问题,自然愿意花时间去处理。
解决方案6
构崩溃是严重的架构设计事故,也是我们需要预防的关键所在。
- 系统崩溃的产生
- 日志记录,如:操作日志,错误日志,业务日志等
- 用户行为抓取→争取在最新时间获取到用户操作链条
- 解决存量问题→技术债务
-
崩溃预防
对脏数据进行兜底和检验
- 单元测试
- 崩溃报警
- 自动化测试
- 更广的灰度触达
- 性能优化体系
若有收获，就点个赞吧
0 人点赞
