使用一种工具（仅一种工具）武装自己，您可以在下一个嵌入式项目的质量和交付时间上做出巨大的改进。

该工具是：绝对承诺对开发代码的方式进行一些小而基本的更改 。

有了改变的意志，今天您应该做的是：

1. 购买并使用版本控制系统。

2. 制定固件标准手册。。

3.启动代码检查程序。。

4. 营造有利于思考的安静环境。

稍后将详细介绍这些内容。任何尝试仅建立这四种成分中的一种或两种的尝试都会失败。所有夫妇协同工作，将糟糕的代码转换为您将为之骄傲的东西。一旦您加快了步骤1” 4的速度，请添加以下内容：

5.测量您的错误率。。

6.测量代码生产率。。

7.不断学习软件工程。

这个处方听起来太难了吗？我曾与在一天之内执行步骤1至4的公司合作。当然，他们花了几个月的时间来调整过程。不过，这就是“过程”一词的真正含义，它会随着时间的推移不断发展。但是，只要您开始执行此过程，便会立即获得好处。让我们更详细地看一下每个步骤。

步骤1：购买和使用VCS。

甚至一个人的商店也需要正式的VCS（版本控制系统）。能够重建一套固件的任何版本，甚至是已经使用多年的固件，确实是神奇的。VCS提供了一种可靠的方式来回答困扰每个bug讨论的那些问题，例如“何时会出现此bug？”。

VCS是服务器上托管的数据库。它是公司所有代码，make文件以及组成项目的其他零碎资料的存储库。也没有理由不包括硬件文件，如原理图，插图等。

VCS使您的代码与开发人员隔离。它使人们免于源头的摆弄。它为您提供了跟踪每项更改的方法。它控制着在模块上工作的人数，并提供了从两个（或两个以上）人同时（错误地）修改过的模块中创建单个正确模块的机制。

当然，您可以在VCS周围溜达，但是就像欺骗您的税款一样，最终还是要进行一天的计算。也许您将不可避免地节省几分钟的时间，然后花费数小时或数天的时间来支付此快捷方式。

切勿绕过VCS。根据需要检入和检出模块。不要“积“检出”模块，以防万一。每天按计划使用系统，因此在项目结束时无需清理VCS。

VCS也是文件备份计划的关键部分。以我的经验，依靠人们的良好意愿进行宗教支持是愚蠢的。有些人全心投入；其他人关心但不一致。通常，数据比建筑物中所有设备的价值更高，甚至比建筑物本身还有价值。马虎的备份意味着最终的灾难。

我承认对备份持保留态度。烧毁所有设备的火灾将是令人难以置信的头痛，但是，保证数据销毁的业务破坏者将是令人难以置信的。但是，宣讲数据重复和实施严格的规则却完全无效。

VCS将所有项目文件保存在VCS数据库中的单个服务器上。制定一个备份计划，每晚保存每个VCS文件。有了VCS，只有一台机器可以为公司提供生死攸关的数据，因此备份问题已本地化且易于处理。尽可能使过程自动化。

检查点您的工具。 嵌入式系统的一个经常被忽视的特征是其惊人的使用寿命。发货十年或更长时间并不罕见。这意味着您必须准备好支持每种产品的旧版本。

但是，随着时间的流逝，工具供应商已淘汰了其编译器，链接器，调试器等。当您突然不得不更改最初使用编译器2.0版构建的产品（现在只有5.3版）时，您将要做什么？

新版本带来了新的风险和危险。至少它会给您的产品带来许多未知因素。是否有新错误？新的代码生成器意味着产品的实时性能肯定会有所不同。也许已编译的代码更大，并且不再适合ROM。

最好在产品的整个生命周期中仅使用原始的编译器和链接器，因此请保留工具 。在项目结束时，将所有工具检入VCS。这是便宜的保险。

当我向磁盘驱动器公司的一组工程师建议这样做时，他们为之欢呼！既然大型驱动器几乎不计成本，那么就没有理由不增加海量存储并节省一切。

许多供应商提供VCS。但是今天最受欢迎的是开源Subversion。另一个开源产品Trac为Subversion提供了一个具有更好用户界面的Wiki前端。

步骤2：制定固件标准手册。

没有一套一致的代码准则，您就无法编写优秀的软件。但是，绝大多数公司没有标准，也没有书面和强制执行的基准规则。一个被普遍引用的原因是在公共领域缺乏此类标准。（“嵌入式系统设计的艺术，第二版”中的附录A 包含了一种可能的标准建议。）

步骤3：使用代码检查。

测试很重要，但单独使用会导致产品中充斥bug。测试通常执行大约一半的代码。该解决方案是一个规范的代码检查程序。

每个人都喜欢开源软件，主要是因为错误率低。记住开源的口头禅：“用足够多的眼睛，所有的bug都是浅浅的。”

这就是检查的全部内容。

步骤4：创建一个安静的工作环境。

就我的金钱而言，过去20年中软件生产力方面最重要的工作是DeMarco和Lister的Peopleware（1987年，纽约州多塞特豪斯出版社）。阅读这个细长的卷，然后再次阅读，然后让老板阅读。

十年来，作者在许多不同的公司进行了编码大战，使一组标准软件问题相互对抗。结果表明，使用任何性能指标（速度，缺陷等），第一四分位数的平均值都比第四四分位数的平均值高2.6倍。

出人意料的是，您期望影响的所有因素均与最佳和最差的执行者相关。只要程序员已经工作了至少6个月，即使经验也无关紧要。

他们确实发现办公室环境与团队绩效之间存在非常密切的关联。不必要的中断会导致性能下降。最好的团队有私人（读为“安静”）办公室和带“关”开关的电话。他们的研究表明，安静的时间可以节省大量金钱。

考虑一下。根据他们的数据，获得一些安静的时间几乎可以做些微调，可以使您的生产率提高260％！这是一个惊人的结果。以您老板现在付给您的相同薪水，他将得到您几乎三个。

优胜者-那些表现几乎是失败者三倍的人-具有以下环境因素：

尽管有清晰的数据表明他们效率低下，但我们太多的人却在小隔间工作。没有门也没有隐私是非常糟糕的。更糟糕的是，当我们受到所有邻居的打扰时。

我们听到隔壁立方体里的可怜草皮与离婚搏斗时的低吟痛苦。我们尽力专注于自己的工作，但作为人性化的话，这部戏的悲情引起了我们的注意，直到我们竭力聆听最新的进展。这是对昂贵的人的时间的有效利用吗？

各种研究表明，中断之后，平均大约需要15分钟才能恢复“正常运行”状态-您将再次沉浸在眼前的问题中。因此，如果您每小时被同事或电话打扰三到四次，您将无法完成任何创造性的工作！这意味着不可能同时进行支持和开发。

但是，多维数据集警察很少会听取数据和理由。他们投资了这些立方体，并由上帝做出了决定！隔间在这里停留！

在这种情况下，我们只能采取防御行动。教育你的老板，但要屈服于失败。同时，采取一些措施以最大程度地减少环境的不利影响。这里有一些想法：

1）戴上耳机 听音乐，淹没隔壁的离婚传奇。

2）关闭手机。如果没有“关闭”开关，请拔下该死的东西。在绝望的情况下，用一对剪钳攻击电线。请记住，电话是世界上任何人都可以敲响的钟声，它可以带您跑步。在您最忙碌的时间内克服这种疯狂。

3）知道你最有生产力的时间 午饭前我工作最好。那是我安排所有创意工作，所有艰苦工作的时间。我将下午留在空闲时间低的活动中，例如会议，电话和文书工作。

4）禁用电子邮件。比电话还差 您200位最近发送笑话的朋友肯定会很高兴，但是，如果您响应电子邮件阅读器的“必应”，则只不过是NASA的一只猴子按下一个按钮即可得到一个香蕉。

5）在开口处放一个窗帘，模拟一个穷人的门。由于大多数立方体的高度都较低，因此请使用维可牢尼龙搭扣紧固件或夹子将窗帘固定在整个开口上。确保其他人了解，关闭时除非紧急情况，否则您不愿意听取任何人的意见。

理所当然，我们需要专注于思考，并且我们需要思考以创建体面的嵌入式产品。寻找一种获得一些隐私的方法，并首先保护该隐私。

第5步：测量错误率。

代码检查是减少错误的重要步骤。但是错误（某些错误）仍然存在。我们永远不会从固件工程中完全消除它们。

但是请理解，错误是软件开发的自然组成部分。没有错误的人肯定不会编写任何代码。可以预料到错误或软件工程界的缺陷。只要我们准备抓住并纠正这些错误，就可以犯错误。

尽管我并不擅长衡量事物，但错误是嵌入式系统中的麻烦之源，我们只需记录有关它们的数据即可。进行错误测量的三个主要原因：

1）我们发现并修复它们的速度过快。在实施修补程序之前，我们需要放慢脚步并考虑更多。记录错误使我们慢下来。

2）一小部分代码将是垃圾。评估错误有助于我们识别这些功能，从而可以采取适当的措施。

3）缺陷是衡量客户感知质量的可靠指标。产品交付后，我们必须记录缺陷以了解我们的固件流程对客户的满意度如何—这是成功的最终方法。

但是首先要谈谈“测量”。取数据很容易。借助计算机的帮助，我们几乎可以测量任何东西，并尝试将数据关联到随风而变的力。

Demming指出，使用测量作为激励因素注定会失败。他意识到动机因素有两大类：第一类是“内在的”。

这包括诸如敬业精神，感觉自己像是团队的一部分以及想要做好工作。“外部”动机是指应用于个人或团队的动机，例如任意度量，反复无常的决策和威胁。外在动力驱赶了内在因素，使工人变成无所顾忌的自动机。这在工厂环境中可能会或可能不会起作用，但是对于知识型员工来说是致命的。

因此，测量是激励的无效工具。好的措施可以促进理解：超越细节并揭示隐藏但深刻的真理。这些是我们应坚持不懈地采取的措施。

但是我们大家都很忙，因此必须警惕被测量过程转移。成功的措施具有以下三个特征：

1.他们很容易做到。。

2.每个都可以深入了解产品和/或过程。。

3.该措施支持有效的变革。如果我们获取数据却不采取任何措施，那就是在浪费时间。

对于每种度量，首先考虑收集数据，然后解释它以理解原始数字。然后考虑将数据呈现给自己，老板或同事。最后，准备对新的理解采取行动。

停下来，看，听。 在大型机的糟糕年代，计算机被封装在技术住所中，由经过特殊审查的操作员担任司职。普通用户在打孔卡读取器上看不到太多东西。

在过去的那些日子里，编辑-执行周期开始于将大约数千张卡片打孔，然后将它们拖到计算机中心（请注意不要掉落卡片盒；在不止一次的情况下，我看到应届毕业生在尝试时会崩溃并哭泣（弄清楚如何订购溅到地板上的卡片），然后等待一天或更长时间，看看运行情况如何。

显然，经过如此长的周期，没人能负担得起使用机器来捕捉愚蠢的错误的能力。我们学会了“玩计算机”（可惜是一门失传的艺术），以便在机器投入使用之前深入检查代码。

事情如何改变！在您的代码中发现错误？不费吹灰之力-快速编辑，编译和重新下载只需不到几秒钟。现在，开发人员看起来像蜂鸟在疯狂地进行编辑，编译，下载之舞。

先进的技术使我们摆脱了等待工作运行的沉闷日子，这真是太好了。但是，看着开发人员的工作，我看到我们发出了一个阴险的邀请，以绕过思维。

您在代码中发现问题的频率有多少次，并想“嗯，如果我更改此错误，该错误将消失吗？” 对我来说，这肯定是灾难的迹象。如果更改未能解决问题，则您的状态良好。危险的是，经过深思熟虑的修改确实“治愈”了缺陷。真的治愈了吗？你只是掩饰吗？

除非您考虑透彻，否则对代码的任何更改都是灾难的诱因。我们出色的工具使这种功能失常的行为模式成为可能。为了打破周期，我们必须放慢一点。

传统上，EE出于工程技术保护的目的，表面上保留工程笔记本，装订页的编号页，但表面上经常用于记录便笺，想法和修正。固件人员应该做的也不少。

当您遇到问题时，请停下来几秒钟。写下来。检查您的选项并列出。记录您建议的解决方案（下面的图6.2）。

图6.2：个人错误日志

保留这样的日记有助于迫使我们更加清晰地思考问题。这也是思考的机会，如果可能的话，想出一种避免将来发生此类问题的方法。

识别错误的代码。 Barry Boehm发现，程序中的缺陷通常有80％位于模块的20％中。IBM的数字显示57％的错误在7％的模块中。温伯格的数字更引人注目：80％的缺陷在2％的模块中。

换句话说，大多数错误将出现在几个模块或函数中 。这些学术研究证实了我们的常识。您尝试过多少次函数才能提交，又一次又一次地修正错误，并确信这是最后一个？

我们所有人都还具有那种简直发臭的可怕功能。它很丑。每次打开时都会让您感到恶心的一种。体面的代码检查将检测出大多数这些制作拙劣的野兽，但是如果其中的一个通过，我们必须采取一些措施。

将识别错误代码作为优先事项。然后丢弃这些模块并重新开始。有机会两次编写每个程序肯定是件好事：第一次是对问题的深入了解；第二个做对了。现实的丑陋手意味着这不是一个选择。

但是，不良的代码（我们花费太多时间进行调试的代码）需要删除并重做。数据表明，我们只在谈论对大约5％的功能进行编码，这对于追求质量来说并不是一个不小的代价。

Boehm的研究表明，这些问题模块的平均成本是任何其他模块的四倍。因此，如果我们确定这些模块（通过跟踪错误率），则可以将它们重写两次，并且仍然领先。

Bugzilla 是一个免费的，开源的，非常流行的错误跟踪程序包。与Scmbug一起使用，可将Bug跟踪软件与Subversion或任何其他VCS集成在一起。

第6步：衡量您的代码生产率。

时间表崩溃的原因很多。在人们对电子计算机进行编程的50年中，我们首先了解到一个事实：没有明确的项目规格，任何进度表的估计都只是在黑暗中挣扎。

然而，每天都有几十个项目的定义比“好吧，构建一个像上一个类似的新仪器那样，具有更多功能，更便宜，更小”。对模糊规格所作的任何估计都是完全没有价值的。

结果是，给定了明确的规范，我们需要时间（有时是很多时间）来制定准确的时间表。将规范转换为设计，然后实际调整项目大小并不容易。您根本无法在2天之内做出公正的估计，但这通常就是我们所能得到的。

此外，管理人员必须接受其员工做出的进度估算。当然，还有很多谈判的余地：减少功能，增加资源或允许更多错误（漏洞）。然而，大多数开发人员告诉我，他们的进度估算已被管理层反复更改以反映所需的结束日期，而未对项目范围进行相应的调整。

令人反感的是，观看的结果几乎是可笑的。开发人员沉迷于项目管理软件中，来回移动里程碑三角形，以迎接管理层任意决定的日期。最终的打印输出看起来可能令人鼓舞，但通常会导致实际工作的人们完全缺乏应有的尊重。因此，时间表只不过是将不诚实行为编成政策。

我们大多数人都参与其中，这是一种阴险的不诚实的估计。很容易责怪老板造成日程安排的崩溃，但我们经常承担很多责任。我们会变得懒惰，并且不会在调试中投入相同的思想，时间和精力。

“是的，该部分有点像我以前做过的事情”，充其量只是估算的开始。您无法从这种模糊的陈述中得出时间，成本或规模，但我们当中有太多人这样做。“ Gee，看起来很容易-说一周”是该主题的一个变体。

做不到做事周到，透彻的估算工作是一种自欺欺人的形式，这种自欺欺人很快就变成了一种制度化的谎言。我们高呼“我们将于12月1日发货”，而估算人员知道这种信念的框架多么脆弱。

市场部准备有光泽的小册子，技术酒吧编写手册，生产订单部分。12月1日滚来滚去，惊喜！一月，二月和三月模糊不清。最终产品被送出门，让每个人都精疲力尽和生气。太多的原因来自项目第一周的糟糕工作，当时我们没有仔细评估其复杂性。

现在该停止疯狂了！

几乎没有开发人员似乎知道，即使代码大小是100％准确，知道代码大小也只是生成任何类型的时间表绝对需要的数据的一半。令人惊奇的是，我们设法解决了以下等式：

开发时间=（代码行中的程序大小）x（每行代码的时间）

当每行代码的时间完全未知时。

如果根据代码行（LOC）估算模块，则必须准确地知道每个LOC的成本。功能点或任何其他度量单位的同上。猜测没有用。

当我向开发人员演唱这首歌时，回答总是：“是的，可以，但是我没有LOC数据我该如何处理我今天进行的项目？” 答案只有一个：对不起，朋友-你运气不好。IBM的LOC /月数对您毫无用处，就像FAA，DOD或任何其他组织的一样。在商业世界中，我们所有人都将代码保持在不同的标准下，这在任何特定方面都会极大地影响生产率。

您只需要测量生成嵌入式代码的速度即可。每一天，终生难忘。这就像节食一样—即使一切都完美无缺，您又减掉了20磅，您将永远监视自己的体重以保持在所需的范围内。

从今天开始收集数据，永远做下去，随着时间的流逝，您会发现一个可以大大提高估算准确性的生产率模型。不要这样做，您所做的每一个估计实际上都会是一个谎言，一个疯狂的，毫无意义的猜测。

步骤7：不断学习软件工程。

最后一步是最重要的。不断学习。自ENIAC以来的50年来，我们已经了解了有关构建软件的正确与错误方法的很多知识。几乎所有的课程都直接适用于固件开发。

一位接近退休的老年医生如何执业？就像他在第二次世界大战前，青霉素之前一样？几乎不。医生终生学习。他们知道午餐时间总是花在一堆日记上。

像医生一样，我们也在不断变化的环境中进行练习。除非我们掌握更好的代码生成方式，否则我们将比喻成16世纪的医学家，而不是实践现代脑外科手术。

学习新技术。尝试一下。任何白痴都可以编写代码；天才是那些发现更好的编写代码方法的人。

（创建软件工程学科的一种比较有趣的方法是“个人软件过程”，这是由Watts Humphrey创建的一种方法。Humphrey是CMMI的原始架构师，他意识到开发人员需要一种可以立即使用的方法，而无需等待CMMI革命在他们的公司中扎根，他的愿景并不轻松，但是收益却是深远的，请查看他的《软件工程学科》，Watts S. Humphrey，1995年，Addison-Wesley。

摘要。

随着年龄的增长，回头看看，看看我们大多数人是如何在人的早期阶段就形成人格的，这是有意思的，有长处和短处的人在过去的几十年中都保持完整。

嵌入式社区由大多数聪明，受过良好教育的人组成，其中许多人相信自己会有所进步。但是，我们成功了吗？我们中有多少人不辜负新年的决心？

浏览任何书店。架子在自助书下吟。有多少人实际上得到了帮助，或者至少得到了解决某个特定问题的帮助？转到饮食部分-我认为出售的饮食比全国多余磅的总和还多。人们本着最好的意图购买这些书，但美国每年都变得更重。

在家里或办公室，我们自我完善的愿望和计划是人类最崇高的特征。现实是我们失败了很多。似乎最常见的补偿方法是对自己做出“更努力”或“做得更好”的承诺。它很少有效。

当我们改变做事方式时，改变最有效。忘记模糊的诺言-发明实现目标的新方法。计划减少饮酒？要定期运动吗？制定确保您达到目标的过程。

提高您作为开发人员的能力也是一样。忘记含糊其辞的“读更多书”的承诺。发明一种更有可能成功的解决方案。甚至更好-窃取可从其他人那里获得解决方案的解决方案。

犬儒主义在这个领域比比皆是。尽管有太多失败的项目的明显证据，但我们都是自称为开发专家。

我与许多公司进行了交谈，这些公司坚信变革是不可能的，我所拥护的方法无效（尽管数据显示相反），或者管理层将永远不会让他们采取必要的措施来实现变革。

这就是“七个步骤”背后的想法。如果需要，可以秘密进行；如果您确信他们不愿意使用定义的软件过程来更快地创建更好的嵌入式项目，则可以让管理人员处于黑暗中。

如果管理水平足够高，可以理解固件危机需要进行更改（其中包括很多内容！），那么请在进行自我教育时对其进行教育。

也许是个类比。工业革命是由许多力量催生的，但最重要的革命之一是资本的集中。工业家在铸造厂，钢铁厂和其他生产方式上花费了大量资金。

尽管可以手工制造汽车，但将大型卡车倾倒在装配线和设备中却降低了价格，并最终收回了黑桃的投资。

智力资本也是如此。投资随着时间的流逝将产生大量红利的系统和流程。如果我们不愿意这样做，我们将被甩在后面，而其他适应能力更强的人则屈居前列，并赢得了软件大战。

最后的想法：如果您是一个过程愤世嫉俗的人，如果您不相信我在这里所说的一切，请问自己一个问题：我是否始终如一地按预算交付产品？如果答案是否定的，那么您在做什么？