系统架构分析与设计参考及注意事项

系统架构分析与设计参考及注意事项

分析与设计
[容错设计][健壮性]
做好容错设计，提升鲁棒性，用好程序员的异常处理；
比如定义枚举值考虑有效值时同时考虑初始值或无效值，考虑预期结果时照顾到非预期情况以及出错后除错和自我恢复；
考虑极端情况下的异常处理，比如系统启动停止阶段的事件处理，有无必要缓存处理等；

[可扩展性][易于兼容性]
考虑可扩展性，努力做到易于扩展；
比如参数类型通用性及是否需要预留，状态机触发条件是否合理以及能否兼容异常case。
考虑冗余设计，预估可能的变化，比如参数类型，枚举变量等有无必要预留。

[可维护性]
考虑可维护性设计，关注系统运行日志和调试模块，便于开发和维护时的诊断和调试。
关键事件和主要处理流程添加必要日志；
注意日志信息与日志级别合理设置；使关键事件与运行信息有log可追踪。
使用以下技巧可以使日志更易读；
C/C++可以利用宏来返回枚举对应的string；比如 case (eID): { return #eID; }
也可以封装一个全局的map来保存errno和对应的字符串；
还可以为消息加上收发的方向指示，比如 msgtrace "ServiceName::function [ICI] --> [TBox] msg body";

[解耦]
注意分析识别稳定不变的部分和易变的部分，使机制和策略分离。集公共特性为机制，集公共机制于平台。

[考虑依赖和限制]
设计时需要熟悉业务逻辑，并考虑相关模块的能力和限制；
比如基础模块的数据转发或处理性能限制，会不会导致消息丢失或block；

代码重构或改写注意事项

重构或改写代码前，一定要先把原先的业务和代码吃透，
了解为什么需要重构，原来代码架构遇到了什么瓶颈或问题，重构的目标是什么，能cover设计的所有问题吗；
因此慎用重构，不要过早的优化，可以小规模改写或优化；

代码阅读注意事项

首先从用户角度整体认识产品；
    了解业务使用场景，核心功能以及周边交互模块，缩小问题范围；并体验一下，有个整体的感性认识；
    如 RVC 是什么？什么时候会用到？我们软件会做什么？与哪些模块有交互等；

其次从硬件架构角度了解硬件布局与交互关系；
    比如 RVC 硬件是通过什么线束或硬件连接，对应的连线用来发送什么消息或数据，数据流怎么走，控制流怎么走，我们需要关注哪些部分等；

然后从软件整体架构和模块架构角度切入，了解与系统周边模块交互关系以及模块内部如何交互；
    了解关键业务代码在哪，消息处理入口在哪，数据和消息是如何传递的，都会涉及哪些模块，业务流程是在哪里实现的；
    了解用户操作对应的消息传递流程，如某项目C1,SWC--CAN-->rawinput--IDC-->AndroidHMI;D2是SWC--DLIN-->IPC--MOST-->functionBlock;
    如果有spec和设计文档，可以先快速浏览一遍，有个整体把握，再对照代码进行一些详细研究；关注数据流(媒体)和消息流(信令)；

然后还要从维护角度入手；
    了解如何获取log，以及log存放在哪里，关注哪些关键字段，该业务哪些场景容易出问题以及涉及模块维护责任人；
    如该业务的每个交互部分分别是有谁负责的，数据流和控制流是如何传递和处理的，分别是在哪个地方和谁在处理的；
还要挑选几个典型case打开log运行一遍，反复对照日志进行代码走读研究，了解基本流程；
如有必要还要根据具体情况在关键位置和不确定位置加上log并反复研读代码和打磨代码，搞清楚为何要如此实现；
如果还需要确认消息触发细节，可以在debug环境获取实时log进行过滤和分析；

debug注意事项
[研读代码和业务]
首先要了解BUG所处的场景(业务场景，搞清楚代码的业务逻辑)，在场景中模拟正常的逻辑，搞清楚输入和输出条件，
验证一下基本case并获取log，对照log进行代码走读梳理基本业务逻辑；
然后反复阅读代码并加入必要的log进行验证，精通业务流程；
其次要根据自己的经验推测BUG可能出现在什么位置并进行代码走读确认；
再次根据预定位出来的问题进行验证，可以采用二分法，逐步缩小问题范围，定位到问题点；
确认问题后根据业务逻辑给出具体的解决方案并验证，问题解决后做相关的整理或更新对应的文档。
对于性能问题应从整体架构出发，先了解相关业务逻辑后才能确定具体方案，不要过早的优化；

[定界]
清楚自己的责任田和能力边界；
分析定位问题需要清楚问题边界，方便快速找到对应责任田；因此要准确快速地解决项目中的问题，最关键的是要熟悉业务流程；
如果简单的业务交互只有自己维护的模块，通过定位语法问题或许就能解决问题了；
但业务往往是多个模块甚至多个设备交互，因此就需要研究spec和消息交互流程是否有问题；

因此debug过程其实就是保证自己遵守spec，再确认交互模块是否也遵守了spec；另外还要注意不同业务间的仲裁处理逻辑；