关于软件开发的一些思考

---

前言

---

一、程序设计

1. UNIX设计哲学
2. 简单最小化，简单且实现需求
3. “优秀的程序员必须对他所写的每一个字节都了如指掌”
4. 如果你不知道它的实现原理和方式，那么就很难用好它
5. 大道至简

---

现代库动辄几十万行祖传代码，使用这个库几乎不可能掌握其运行细节，只是调用接口。
现今软件设计讲究模块化，封装化。
做好模块之间的隔离，避免一个模块的错误传导到另一个模块上。做好接口设计，接口要足够简介，拒绝可能引起歧义的接口。最好遵循UNIX设计哲学。

---

软件设计原则：
SOLID原则
高内聚，低耦合
尽可能抵御外部错误和攻击，检测到内部错误时则终止程序执行。

一个完整的商业软件所必要的组件

1. 常用基础组件
   a. 日志系统 log
    不可能将log打印到前台，必须有日志持久化组件
   b. 计时器
   c. 线程间通讯、传输数据组件
   d. 进程间通讯、传输数据组件
   e. 进程功能模块分割方法

2. 软件版本以及项目适配管理方案
   软件需要维护和迭代，就会有版本管理的需求。在发版的软件中必须有有效手段追溯软件源码。如何将一套源码适配到十几甚至几十个不同的项目中也是需要思考的问题。

3. 软件架构设计方案

4. 工程结构、构建系统、测试系统

5. 性能分析工具

软件开发团队的构成

• 组内leader
  负责统筹并管理团队。负责整体软件架构的设计，技术底座搭建、实现等。
• 需求
  负责对接外部需求，输出到内部
  需求排期，内部商讨对外接不接需求等
• 发版以及项目管理
  负责软件版本管理，项目计划以及软件发版集成等
  需要明确发版计划，保证每次发版是软件的可用性，以及每次发版时的修改项
• 测试
  负责发版前的测试，保证功能的可用性。以及测试开发做的需求ok不ok
• 开发
  干活的牛马，负责具体需求的实现，俗称码农

一种较为通用的软件结构

任务生成器（根据需求生成任务）

任务（任务带有自己的属性信息）
一条任务可以包含多个子任务，任务有自己的属性信息

执行器（负责执行具体的任务）
执行器可被打断等功能，线程池、动态线程及设置限制等

通讯模型

在计算机中，建立通讯只有一种方式：必须有一方主动发起请求，另一方等待求情，其它所有通讯模型都是在此基础之上建立的。

这是很符合直接的，两个人交谈，必须有一人先发声，另一个听着。

如，tcp连接中，必须有一方先调用connect发起连接，另一方调用accept监听连接；udp通讯中也是，必须由一方调用send发送udp报文，另一方调用receive接收报文；p2p通讯也是如此，只不过双方位置是对等的，任意一方都可以connect，另一方就accept，就好像两个人谈话，任意一个人都可以先开口，另一个人听着。

请求响应
request由客户端主动发起，服务端只负责监听。是为一问一答的通讯模式，且问方总是client。

HTTP协议就是采用着用模式

发布订阅
publisher负责发送数据，subscriber负责接收数据

someip中的通讯机制

请求响应
类似HTTP，可实现rpc
请求不响应
可能会配合event使用，发送请求后通过event获取值

event, 事件触发
用于服务端主动向客户端推送数据(当发生变化时或周期性)，如车速信号应为周期性信号，使用方订阅后，周期性收到数据

field
假设远程服务中有个可被设置的字段
请求响应+event
Getter：获取远程字段的值
Setter：设置远程字段的值
订阅远程字段的值

如：挡位字段，仪表盘订阅挡位字段，当挡位发生变化时通知仪表盘，当汽车刚启动时，挡位不会发生变化，为了获取挡位的初值，仪表盘需要通过Getter获取。

ros2中的通讯机制

• 发布/订阅 (Publish/Subscribe) 模型

  机制: 这是一个由发送者（Publisher）和接收者（Subscriber）组成的异步通讯机制。Publisher 将消息发送到一个命名的 Topic 上，所有订阅了该 Topic 的 Subscriber 都会收到消息。
  特点:
  多对多: 一个 Topic 可以有多个 Publisher 和多个 Subscriber。
  异步: Publisher 发送消息后不等待回应，只管发；Subscriber 被动接收。
  持续性: 通常用于连续的数据流
  使用场景：激光雷达 (Lidar)、摄像头图像、IMU 数据、里程计

• 请求/响应 (Request/Response) 模型

  机制: 类似于传统的 C/S 架构或 RPC（远程过程调用）。Client 节点发送请求给 Server 节点，Server 处理后返回响应。
  特点:
  一对一 (通常): 一个 Service 通常有一个 Server，但可以有多个 Client。
  同步/异步: Client 发送请求后通常会等待结果（虽然在 ROS 2 SDK 中通常非阻塞实现，但逻辑上是等待回复）。
  短时性: 用于离散的、立即需要结果的操作。
  使用场景:

  逻辑开关: 启动/停止某个节点，重置里程计。
  参数查询/设置: 请求更改相机曝光度，查询当前配置。
  简单计算: 发送两个数字，请求服务器返回它们的和。

• 目标/反馈/结果 (Goal/Feedback/Result) 模型
  机制: Action 是建立在 Topic 和 Service 之上的高级通讯机制。Client 发送一个“目标”，Server 尝试达成这个目标。
  特点:
  反馈 (Feedback): 在执行过程中，Server 会周期性地向 Client 报告进度。
  中断 (Cancel): Client 可以在任务完成前随时取消任务。
  长时性: 适用于耗时较长的任务。
  使用场景:

  导航 (Navigation): 告诉机器人“去厨房”。这需要几分钟，期间机器人会不断反馈当前位置，且用户可能中途改变主意取消任务。
  机械臂控制: 告诉机械臂“抓取物体”。这是一个复杂的过程，包含路径规划和执行。
  感知任务: 执行 360 度扫描并构建地图。

---

总结