开发内部使用的软件：强调周转时间短

引言

软件开发领域非常广阔，有无数的书籍、最佳实践、流程等可供开发人员遵循和遵守。有些适合他们，有些则不适合他们的需求。但总的来说，大多数软件开发都针对“为外部‘最终用户’编写软件”的场景，并且期望这些软件能够完美无瑕地运行数月甚至数年（直到下次更新/修补）。

有一种软件开发场景常常被忽视，而我的目标是讨论这个方面并分享我的经验。我指的是为硬件工程师编写软件，以便他们测试设计或验证其在工程公司中的可靠性。硬件可以是PCBA的子系统，也可以是单个传感器。这些软件是为内部使用而设计的，永远不会提供给所谓的“最终用户”。

此类软件及其开发的主要特点是：

• 内部受众（尤其是工程师）
• 更短的交付周期
• 一次性使用/保质期短
• 数据文件比外观更重要
• 自动化以最大程度地减少长时间测试中的人为干扰

在典型情况下，您需要准备一个小型但可靠的软件来测试硬件，并尽可能少地进行人工监控或干预。不会有正式的需求规格文档（SRS）来开始实施。该软件将用于测试整体工程硬件开发中硬件的一部分。作为开发人员，您需要承担从需求收集到最终可执行文件的各种角色。这会需要更长的开发周期，但在这种环境中，时间不是奢侈品。最终，该软件将在其预期的一次性使用后被丢弃。

背景

撰写本文的驱动力之一是我从标准的SDLC（软件开发生命周期）过渡到“快速开发”周期时所遇到的困难，我想记录下我为克服这些困难所采取的步骤。这可能对在类似环境中工作的人有所帮助。

我从事了 10 年的电信和银行业桌面应用程序开发工作。在那里，我们必须遵循完整的 SDLC 流程，并得到其他部门所需文档和指示的支持。所以当我转到可靠性工程部门时，我的任务之一是编写软件来测试电子板在各种环境条件下的性能。我以为这会很容易，因为我已经在这个开发领域工作了十多年。出乎意料的是，这趟旅程充满了障碍和坎坷。我花了将近半年的时间才意识到自己的错误以及我从过去工作经验中不必要地背负的包袱。我必须调整我的工作方法，并希望与更广泛的受众分享这一点。

哪里出了问题？

因此，在换了新工作并熟悉了新技术后，我准备投入到项目中。于是有一天，我收到了一份项目启动会议的邀请。我自信满满地走进会议室并坐下。

硬件工程师：太好了，我们的新压力和温度传感器板已经准备好了。我们需要在一个月内，在各种温度下测试其可靠性和设计问题。我希望看到传感器读数随时间的变化趋势。

我：没问题。我能拿到软件的需求文档吗？

硬件工程师：为什么？我会解释电路板的功能以及功能测试的步骤。

我：嗯……好吧。GUI应该是什么样子？

硬件工程师：由你决定。只要确保没有数据丢失，并将数据以 CSV 文件形式发送给我，这样我就可以用 MATLAB 进行分析。并确保软件能在 一周内开始测试。

会议结束后，我简直要恐慌了。没有 SRS 文档，没有 GUI 布局，而我需要在 5 天内完成软件。但无论如何，我还是像传统的软件开发人员一样开始了。我花了一些时间准备完整的 SRS 文档和 GUI 布局。我对屏幕设计和 SRS 都很满意。它很全面，但花了 3 天时间。第二天，我又收到同项目另一位工程师的邀请，为他的电路板准备软件，以便进行测试，并最终与之前的电路板合并以进行完整的系统测试。情况差不多，没有正式的 SRS 和指导方针。

简而言之，我错过了截止日期，但软件质量很好。但项目团队并不满意，因为他们的上市时间因我的瓶颈而延迟。他们评论说软件很好，但没有达到目的。

与各种人和其他开发人员讨论后，我得到了一个想法，知道自己哪里出了错。其中一些原因（不分先后）是：

• 未能认识到软件的受众
• 对软件意图的误解
• 错误地侧重于错误的优先级
• 依赖于传统的“瀑布”SDLC。

所以，我不得不调整我的开发风格以适应这个环境，以便将来的项目。

“新”方法

如果我有时光机，我就会根据吸取的教训以不同的方式来做这个项目。就像所有的软件开发一样，如果最初的方法是错误的，那么很可能会导致延误。所以我的一个主要改变是不专注于 GUI。以下是我 incorporated 的一些改变。

需求优先级排序

我决定创建一个颜色编码的需求文档。任何软件要想有用，都应该始终满足基本的红色编码需求，最多实现橙色编码的自动化。如果时间允许，剩余的需求可以实现。

那么这个颜色编码系统是什么呢？我使用下面的图表作为参考。

我确保所有需求都属于特定的颜色方案，并确保与项目团队，尤其是工程师，达成某种理解。

核心功能通常源自要测试的硬件，我确保总是添加另外两个属性，因为这在工程项目中总是期望的。

• 文件写操作的冗余。
• 当文件被其他用户打开时，没有 I/O 错误。

这样做的目的是，人们希望在测试运行时看到中间数据，并且很可能保持文件打开状态，这会导致写入错误。

所以，我的需求表大致看起来是这样的：

同意，与普通的 SRS SDLC 相比，这并没有什么不同。但这里的重点是确保您已识别出“基本最低”需求，这些需求无论如何都必须实现。一个简单的文档可以提供清晰的思路，并为这类软件节省最少的精力。

GUI 的“KISS”原则（保持简单，愚蠢）。

一般来说，一次性软件的保质期非常短。在许多情况下，软件在使用一次后就被丢弃了。工程师不太关心 GUI 数据外观，而是更喜欢以某种文件形式获取数据。因此，如果没有用的话，花几天时间创建一个完美的 GUI 就没有意义了。所以对于上面的例子，你可以提出两个 GUI。

                                         基础 GUI

                 

                                         高级 GUI

 

上面的例子只是为了展示方法的不同。对于这类软件，基础 GUI 就绰绰有余了。很可能这个软件会在实验室运行，没有人会每隔几分钟就看一次屏幕。

如前所述，大多数工程师都希望看到一段时间内的数据趋势和其他影响其硬件的应力因素。因此，让您的 GUI 尽可能简单/最小化，并在其之上进行构建是有意义的。更多的工作和时间应投入到以正确的格式获取数据到文件中。基础 GUI 是核心需求的一部分，其他一切都可以是“易用性”和“锦上添花”部分。工程团队更关心书的内容而不是封面。

设计和实现。

有句名言说：

引用

  链条的强度取决于其最薄弱的环节

在复杂的工程项目中，我们微小但重要的任务不应该是最慢的环节。因此，在最短的交付周期内提供可靠的软件非常重要。我们没有奢侈的时间进行长时间的返工。所以我们必须以正确的方式开始。由于我们将分层处理需求，因此每个颜色编码的模块都必须是模块化和可扩展的。因此，它们应该是松耦合但内聚性强。

因此，如果迫不得已，“核心功能”模块应该能够作为一个独立的软件运行。所以对于项目团队来说，如果“自动化”也实现了，那么软件就应该被认为已经超额完成了。

换句话说，当“核心功能”模块实现并可用时，您的软件应该是可靠且完整的。

不妥协。

这可能看起来该文章支持摒弃经时间考验的 SDLC 并遵循“即时”编程的想法。这并不完全正确。所有流程都旨在为最终用户提供高质量的软件。但在一些时间至关重要的场景中，“质量”更等同于“有用和及时”。这并不意味着我们将质量抛诸脑后。软件的以下操作属性仍然成立，不应妥协：

• 完整性
• 稳定性
• 可靠性
• 正确性

在最小化需求范围的情况下，发生故障和出现 Bug 的几率往往较低。没有必要通过添加对硬件开发不重要的功能来增加出现 Bug 的几率。

最少的开发时间是这里的精髓。

 

几句忠告

本文并不提倡放弃典型的 SDLC，也不说软件需要“快速而粗糙”。本文只说明要根据目标受众和意图以正确的方式进行软件开发。

无论我们从事哪个行业，我们都需要对使用的技术/语言有深入的了解。知识的获取没有捷径。如果我们对基本的架构和糟糕的编程的陷阱没有 proper 的了解，软件开发将永远是一场噩梦。