当前位置：首页 > news >正文

设计模式: 关于项目架构，技术选型，技术债务问题与解决方案

news 2025/7/15 19:36:52

1 ）指标

2 ) 衡量

3 ) 架构分类

系统架构
- 从系统维度，负责整体系统的架构设计
- 基础服务和各系统间协调，着眼全局
- 比如关注负载，可靠性，伸缩，扩展，整体项目切分，缓存应用等方面的基础架构设计
- 偏向于对技术的架构设计
应用架构
- 从应用程序的维度，负责某个应用的技术架构，主要偏向业务系统
- 关注理解业务，梳理模型，设计模式，接口，数据交互等方面
- 主要思考，如何让业务更好实现，如何让数据更好的交互，什么设计更好的拓展
- 需要了解整体业务系统怎样流转，针对所有业务系统做架构设计
业务架构
- 从业务流程维度，关注某一个行业，业务领域分析，获取领域模型，最终获得系统模型
- 也可叫业务领域专家，行业专家，产品咨询师，资深顾问
- 所做事情脱离具体开发任务，比如数据分析和模型建设来推动业务发展
如何选择自己
- 特别关注技术，朝着系统架构师方向发展
- 业务与技术并存，了解技术在业务里如何应用，每个应用间的交互，朝着应用架构师方向努力
- 如何希望脱离具体开发任务，只需要关注数据系统模型，得到结论，就要朝着业务架构师方向发展

技术选型
- 社区氛围，发展规模，未来发展趋势，与当前团队的契合度，执行成本，维护和迁移成本，执行效率等内容的调研和报告
- 根据报告内容做一些取舍，选定当前技术类型，通过技术类型进行开发
- 充分调研每一项技术带来的利弊，根据利弊进行取舍，得到最优组合
- 最大程度上预测架构设计中的缺陷，防止问题的发生
- 凡是不打无准备之仗
技术优化
- 在架构发展过程中，可能会存在一些有悖于当前架构设计的实现，造成了架构发展阻塞，所以需要进行架构优化，使架构设计的适应性更高
架构优化
- 架构不是一蹴而就的，在业务发展过程中，架构也在不断演进
- 对架构设计进行实时调优，使架构优化成为常态化
- 通过不断的调整架构实现，改进初始架构中设计的不足，补足短板

开发过程中因为时间紧迫导致的实现不合理
- 举例：查找100000以内的质数
- 算法不同，效率不同，好算法和坏算法的时间
开发过程中暂时没有想到更好的实现方式而妥协的版本
- 刚开始使用if…else实现
- 使用责任链模式来进行改进：每个函数都可以独立出来，作为一个判断条件使用
- 作为整体使用不好，使用责任链使用会让复用性提高，维护性提高
架构设计前期没有考虑到的一些细节
- 交互细节 -> props传递参数 (交互冗余，流程较长)
- 使用全局状态管理实现参数传递
不合理的交互设计，导致技术实现复杂
- 交互设计的难度，正确和设计人员沟通
- 减少这类问题出现
旧功能文档缺失，无正确拓展，修改和兼容旧功能，导致上线后问题剧增
- 无技术文档，技术功能没有预留出修改和兼容的接口
- 新开发功能要预留兼容旧功能的接口
- 让旧功能逐步符合当前架构设计的内容
- 阶段性重构，将旧功能变为新功能的实现

优秀的架构设计是基础
当前架构设计，能够有效处理当前需求可预见的情况，对于未知的，可能出现的特殊情况，很小的改动就能解决问题
- 2.1 我们的架构应该是简练的，精简的，对于一些可预见的问题，不建议做一些功能处理，只需要做一些预留接口即可
根据当前的业务，进行合理的项目拆分，尽量的代码解耦合
必须有日志模块，操作日志，错误日志，业务日志等等
良好的技术培训和传帮带能力
让每一位开发者可以从更深一层次理解所需要实现的功能
从最开始的代码规范，到熟悉业务，最后再到编写文档
充分的技术方案可避免一部分技术债务的产生
技术方案是充分理解需求之后所能产出的对需求理想的实现方式，必要性不言而喻
不同工程师之间可以相互review代码，避免当局者迷出现，codeReview是非常重要的，同时也是对自身的一个提高
提升对修复技术债务重要性的认知
工程师如果能预见一个债务可能导致的问题，自然愿意花时间去处理
善于发现和定期处理一些技术债务问题
勇于发现系统中的技术债务，让自己为系统负责
让自己为系统负责