如何规划我的软件以避免过度重写和相互依赖

Question

我正在编写一个具有几个接口（按钮、蓝牙、触觉旋钮）的电机控制器，这是一项正在稳步增长的任务，其规模比我想象的要大。我尝试从低级模块开始（例如编写在 I2C 总线上通信的代码），然后是上面的模块（与 I2C 上的特定设备通信的代码）巴士...），但我常常不得不回到较低的模块来处理我无法适应的怪癖。这要么需要很长时间，要么我得到的代码非常糟糕。

我的目标是 8 位 MCU，因此自下而上似乎我可以更好地利用硬件。如果我自上而下，我就没有任何可以构建或测试/调试的结构。

我尝试绘制一些总体图和特定级别/驱动程序的图，但我不确定如何构建它们，这样我就可以非常系统地了解它，并避免错过需要经过 2-3 层的奇怪信号层。

我想这就是获得 CS 学位的原因吗？我是一名电气工程师 :P

Answer 1

听起来你走在正确的轨道上。有时，再多的计划也无法阻止您日后重新设计或重构系统的某些部分。尝试以下一些技巧：

• 将代码放在由逻辑函数分隔的模块中。
• 不要重复代码，而是为共享功能设计可重用的方法。
• 尽量避免为特殊情况添加 hack 的诱惑。最终这将变得无法维护。相反，尽快调整和重构小部分。试图在最后进行大规模的重新设计将会更加困难。
• 不要试图从一开始就过度设计系统，因为当你开始实际实施时，你可能只是在浪费时间。
• 保持较低级别尽可能简单，然后在顶部构建更高级的功能。
• 记录您的函数并编写一些单元测试，尤其是在添加复杂的条件语句之后。
• 尝试捕获尽可能高的堆栈错误。例如进行输入验证和检查返回值。这将使调试更加容易。

Answer 2

在处理多层代码时，当 API 不允许您完全按照您的意愿行事时，您很容易会陷入较低层。当同时编写多层时，这尤其困难。

这里有一些建议：

• 将除您正在处理的层之外的所有其他层视为已密封的层。由另一家公司、开发人员等创建。请抵制修改另一层以解决当前层中的问题的冲动。
• 为您正在处理的层创建一个“兄弟层”。这很难从抽象意义上描述，但可以说您的较低层是业务层，较高层是 UI，为不同的应用程序创建另一个 UI 层。现在，拥有同一 API 的两个使用者可以帮助指出每一层中应该包含哪些内容。
• 尝试交替处理各层的顺序。例如，在某些应用程序中，我发现首先设计 UI，然后深入到业务层/数据库以使 UI 按设计工作更有用。其他时候，使用数据模型进行统计并处理 UI 更有意义。但重点是，在这两种情况下，您对 API 的“思考”是不同的。从两个角度查看多层代码会有所帮助。
• 经验很重要。有时，犯下过度耦合代码的错误是真正学会避免这种错误的唯一方法。不要计划你的应用程序是完美的，而是计划它是不完美的。我的意思是，首先建立一个快速的开发/测试/重构周期，这样你就可以快速适应错误，直到你犯了错误之后才发现这些错误。这也是“一次性原型设计”派上用场的领域。做一个简单的草稿，从中学习，然后扔掉。丢弃的部分很重要。即使它令人惊叹，也要从头开始构建另一个。根据您从原型中学到的知识，您将不可避免地使其变得更好（并且根据我的经验，更有条理）。

Answer 3

这实际上更多的是经验问题而不是你的学位问题。如果您仍在学习如何控制硬件，那么您的代码当然会发生变化。我不会为此烦恼。然而，由于您真正要做的是原型设计，因此您应该准备好在代码工作后重构代码。消除冗余，划分数据和功能，并组织您的界面，使其有意义。

我的经验是，设备驱动程序代码需要自上而下和自下而上的设计/实现，我称之为由外向内。您知道用户想要做什么，并且可以编写这些接口，并且您知道低级驱动程序需要做什么，并且可以编写这些接口。如果它们在中间没有很好地相遇，请重新考虑您的模块布局。

为了改进，请将您的设计和代码交给有更多经验的人来审查。把自我排除在外，了解他们对问题的看法。你还可以读一本关于面向对象分析和设计的书（我以前很喜欢Peter Coad的书，现在不知道是谁写的了）。一个好的例子将展示如何将问题划分为具有明确角色和职责的对象的示例。

一旦完成驱动程序原型设计并知道如何控制硬件，另一件事就是确保您有详细的要求。没有什么比在编写时发现需求更能扭曲代码了。在编写代码之前，您还可以尝试学习 UML 并使用图表进行设计。这并不适合所有人。另请注意，您不需要使用支持面向对象构造的语言来使用 OOD。

Answer 4

如果您的问题是如何构建正确的抽象（情况似乎如此），我认为您可以做的最重要的学习事情（除了要求设计代码审查/阅读书籍/阅读代码之外）是思考在开始编写代码之前先努力一下。

通常情况下，您首先会大致了解自己想要什么以及应该如何完成，然后继续编写代码。后来你发现你没有想清楚事情，并且有几个漏洞，现在，因为你投入了时间编写代码，所以很难修补这些漏洞，这会导致浪费时间或黑客代码。

认真思考如何创建一个可以轻松应对变化的设计。例如，封装需要在层之间传输的数据，因此，如果您后来发现错过了一个关键参数，您可以轻松地将其添加到结构中，而无需到处修改代码。

尝试多次“在头脑中运行设计”，直到您非常确定您已经考虑了最重要的细节并且您可以分辨出来（这是最重要的部分，因为您总是会错过一些事情，或者需求会发生变化）如果您错过了某些内容，您可以相对轻松地调整模块。

UML 可以帮助您构建思考设计的方式。它当然不是万能药，但它显示了创建软件设计时要考虑的不同标准。

这有点像经典的国际象棋老师的建议：“坐在你的手上”:-)

Answer 5

驱动程序适合分层方法。

您的驱动程序可以有几个“类”：

• 仅输入 仅
• 输出
• I 和 O。

它们应该具有标准化接口，例如：

GetKnobLevel()
GetNextKeyboardButton

或者，另一种方法是

syscall(DRIVERNUMBER, command)

将参数/结果放入指定的寄存器中。

这是一种简单、可用的方法。更复杂的变体可能是在硬件通信代码和软件通信代码之间使用循环队列，而不是寄存器。

这是我正在使用的心理模型：

---
Application
---
OS
---
Driver communicators
---
drivers
---
hardware

每层之间都有一个严格定义的、无差异的界面（我一直想象一个层间蛋糕，层之间有厚厚的糖霜......）。当然，您可能不存在该操作系统。

如果您的 MCU 支持软件和硬件中断（例如 x86 CPU），您可以使用它们将驱动程序与驱动程序通信器隔离。

老实说，这有点“过度设计”的解决方案。但是，在复杂性变得越来越大的情况下，采用紧密的工程比采用松散的工程更容易。

如果您在层之间进行通信，则可以为每个通信“通道”使用全局变量，并以规范的方式访问它，仅使用函数来访问它。

通常，在真正开始对项目进行编码之前，您需要在某种程度上进行纸张设计、一些探索性工作并重新设计。流程图和总线转换图在这里效果很好。

这是我在嵌入式系统工作中喜欢的方法，并且对我来说效果很好。

此外，传统的计算机科学课程并没有很好地探索这个问题空间。它比网络或现代操作系统要宽容得多。

Answer 6

在我看来，架构良好的代码最重要的方面是低耦合度和副作用与状态的分离。

另外——代码是一门手艺。不要以为从一开始就能制定出完美的解决方案。当您学习新事物时，准备好更改您的代码。事实上 - 确保您将自我改变作为工作的一部分。

Answer 7

不要太油嘴滑舌，但我想起了《人月神话》中的一句话：“计划扔掉一个；无论如何你都会扔掉。”

其必然结果是“让它发挥作用。让它正确。让它快速。”

我想这让我提倡提前进行一些设计，但不要因此而陷入瘫痪。第一次不一定是完美的。计划重构。希望您所编写的内容不会真正丢弃太多代码，而是以更令人愉快的方式重新排列内容。