你可以称它们为指导方针、试探法或经验法则。无论如何，目的都是一样的：提供一个合理的近似值。这些经验法则可以帮助您了解您所使用的系统，将您的注意力集中到正确的解决方案上，并突出潜在的问题区域。
这些只是我在过去一年里收集的初步经验法则。如果您有任何其他有用的规则或启发式方法，请发送电子邮件给我或在下面留下评论。
保持一个系统正常工作要比在你破坏它之后修复它容易得多。(詹姆斯·格勒宁)。
通过消除分心和干扰，开发人员的生产效率大大提高“住在小隔间里的开发人员可能不是很有效率。检查他们是如何管理中断的。“。(杰克·甘斯勒)。
“复杂性呈指数增长；罗伯特·格拉斯(Robert Glass)计算出，问题的难度每增加25%，代码的大小就会翻一番。一个数百万行的程序可以假设许多人类无法掌握的大小状态。(杰克·甘斯勒)。
在自然界中，最佳值几乎总是在中间的某个地方。不相信最优处于极值点的断言。(阿金定律)。
过去的经验非常适合提供现实核查。然而，太多的现实可能会毁掉一个原本有价值的设计(阿金定律)。
根据经验，您在缺陷预防上花费的每一个小时将使您的修复时间从三个小时减少到十个小时。(史蒂夫·麦康奈尔)
复杂系统从工作的简单系统进化而来(约翰·加尔)“工作的复杂系统总是从工作的简单系统进化而来的。相反的命题似乎也是正确的：从头开始设计的复杂系统永远不会工作，也不能让它工作。你必须从头开始，从一个运行简单的系统开始。“。(约翰·加尔)。
如果你不能用通俗易懂的英语描述行为，你就不能用代码成功地描述它。
如果一个问题可以分解成两个或多个独立可解的问题，那么就把复杂的问题分解成更小的子问题，然后先独立解决它们！
在实施和测试解决方案之后，将各个部分合并到一个更大的操作中。
正确地设计一艘航天器需要付出无限的努力。这就是为什么将它们设计为在某些情况出错时运行是个好主意。(阿金定律)。
设计是一个迭代的过程。所需的迭代次数比您当前已完成的次数多一次。这在任何时候都是正确的。(阿金定律)。
从来没有单一的正确解决方案。然而，总是有多个错误的。(阿金定律)。
(爱迪生定律)“更好”是“好”的敌人。(阿金定律)
估计日期而不是小时保证项目延迟(杰克·甘斯勒)“当开发人员不将日历时间与工程时间分开时，日程安排灾难是不可避免的。”(杰克·甘斯勒)。
“如果进度表出现人员利用率远远超过50%的幻觉，项目将按比例落后。”(Jack Ganssle)“一些数据显示，开发者平均只有55%的人在从事新产品工作。其他例行公事，从处理文书工作到谈论幸存者十六世，几乎消耗了一周一半的工作时间。(杰克·甘斯勒)。
我们经常没有预见到开发的困难领域“我们对大多数项目的进度估计得多么糟糕，这不是很令人惊讶吗？80%的嵌入式系统交付得很晚。大多数权威人士认为，平均每个项目消耗的开发工作量是最初预算的两倍。(杰克·甘斯勒)。
5%的函数消耗了80%的调试时间(Jack Ganssle)“我观察到大多数项目都在调试周期中打滚，调试周期通常占整个计划的一半。显然，如果我们能对代表我们大部分麻烦的那几个功能做些什么，这个项目就会更快地推出。“。(杰克·甘斯勒)。
时间表的增长速度远远快于固件大小--代码行增加了一倍，并且交付日期增加了2倍以上(Barry Boehm)。
“代码的前90%占开发时间的前90%。剩下的10%的代码占用了另外90%的开发时间。“。(汤姆·嘉吉)。
当将旧代码移植到新项目时，如果修改超过25%，就不会有太大的进度提升(理查德·塞尔比)。
加载到90%处理器容量的系统需要的开发时间是加载70%或更少的系统的2倍。95%的加载是开发时间的三倍。(Jack Ganssle)“当只剩下几个字节时，即使是微不足道的功能也可能需要数周时间，因为开发人员必须重写大量代码来释放内存或CPU周期。”(杰克·甘斯勒)
你制定的时间表看起来就像是一部完整的虚构作品，直到你的客户因为你没有达到它而解雇你的时候。(阿金定律)。
有时候，到达终点的最快方法就是扔掉所有东西，然后重新开始。(阿金定律)。
(巴顿计划法则)现在猛烈执行的好计划胜过下周完美的计划。(阿金定律)。
每个传感器都是温度传感器。一些传感器还可以测量其他东西。(Elecia White)。
将令人讨厌的实时硬件功能分解成独立的CPU(Jack Ganssle)，每秒处理1000个来自设备的中断？将其分区到其自己的控制器，并将所有ISR开销卸载主处理器。
只要可以简化软件就添加硬件(Jack Ganssle)这将大大降低NRE和软件开发成本，但代价是增加BOM成本。
加载到90%处理器容量的系统需要的开发时间是加载70%或更少的系统的2倍。95%的加载是开发时间的三倍。添加额外的硬件以减少负载。(杰克·甘斯勒)。
(阿特金演示定律)当硬件工作完美时，真正重要的访客就不会出现。(阿金定律)
遵循“三个规则”：允许你复制和粘贴代码一次，但是当相同的代码复制三次时，它应该被提取到一个新的程序中(马丁·福勒)。
在一个软件包真正可重用之前，它必须至少被重用过三次(Jack Ganssle)“我们不够聪明，无法真正理解软件块可能被使用的应用程序的范围。每个领域都需要自己独特的功能和调整；除非我们在足够广泛的应用程序中实际使用了代码几次，否则我们不会对其进行足够的通用化，以使其真正可重用。“。(杰克·甘斯勒)。
重用在大段代码中效果最好-考虑重用整个驱动程序或库，而不是函数(Jack Ganssle)理查德·塞尔比发现，当将旧代码移植到新项目时，如果修改了大约25%以上，就不会有太大的进度提升。
过早的优化是浪费时间，“比起其他任何单一的原因--包括盲目的愚蠢，以效率的名义(不一定达到效率)犯下的计算错误更多。”(W.A.Wulf)。
“程序优化的第一条规则是：不要这样做。程序优化的第二条规则(仅限专家！)：先别做。“。(迈克尔·A·杰克逊)。
只有在对代码进行概要分析后才能优化代码，以确定问题区域“瓶颈出现在令人惊讶的地方，所以在证明瓶颈在那里之前，不要尝试事后猜测和提高速度。”(罗伯·派克)。
“我们应该忘记小效率，比方说97%的时间：过早优化是万恶之源。然而，我们不应该错过这关键的3%的机会。一个好的程序员不会因为这样的推理而自满，他会明智地仔细检查关键代码；但只有在代码被确定之后“(唐纳德·努斯)。
帕累托原理可以应用于资源优化：80%的资源被20%的操作使用。软件工程中有90/10定律：一个程序90%的执行时间花在执行10%的代码上
算法优化比微优化有更大的影响“真正的效率收益来自于改变算法复杂度的顺序，比如从O(N2)复杂度变为O(NlogN)复杂度。”
永远不要为了感知到的效率而牺牲清晰度，特别是在效率提高没有数据证明的情况下。
当开发人员不敢更改函数时，是时候从头开始重写代码了(杰克·甘斯勒)。
重复代码表明设计不佳或编程习惯不佳。它必须被消灭。“复制是一种糟糕的做法，因为它使代码更难维护。当在复制的代码片段中编码的规则发生更改时，维护该代码的任何人都必须在所有地方正确地更改它。此过程容易出错，并且经常会导致问题。如果代码只存在于一个地方，那么可以很容易地在那里进行更改。“。(杰克·甘斯勒)。
“这条规则甚至可以应用于少量代码，甚至是单行代码。例如，如果你想调用一个函数，然后在它失败时再次调用它，有两个调用点是可以的；但是，如果你想在放弃之前尝试五次，那么一个循环内应该只有一个调用点，而不是5个独立的调用。“。(杰克·甘斯勒)。
禁用中断往往是件坏事(Jack Ganssle)，即使在最好的情况下，它也会增加系统延迟并可能降低性能。
警惕单独启用中断(EI)命令(Jack Ganssle)“位于中断服务例程(ISR)之外的EI通常意味着危险-启动代码中的初始EI除外。”(杰克·甘斯勒)。
如果使能不是DI/EI对的一部分(这两条指令必须彼此非常接近才能保持较低的延迟和较高的可维护性)，那么代码很可能是一口错综复杂的深井；探测这些深度将使最热切的开发人员老去。(杰克·甘斯勒)
当代码中充斥着DI/EI对(Jack Ganssle)时要小心“，但是当出现系统设计问题时，这些DI/EI对会大量溜进代码中，这会产生很多易受可重入性问题影响的关键区域。您知道这是怎么回事：勇敢的开发人员追逐一个错误，发现一个被上下文切换丢弃的变量。插入快速DI/EI对。然后还有另一个。还有另一个。就像吸食海洛因的人最后一次吸毒。它永远不会结束。“。(杰克·甘斯勒)。
除了最短暂的时间和最迫切的需求之外，让中断一直存在。(杰克·甘斯勒)。
如果在代码块中禁用中断，请在同一块中重新启用它们(Jack Ganssle)。
保持ISR较小，设置一个标志，向队列添加值，然后依靠用户空间代码来处理更复杂的任务。
检查在返回前立即重新启用中断的任何ISR的设计(Jack Ganssle)“允许另一个设备中断ISR是完全可以的！或者甚至允许相同的中断这样做，只要有足够的堆栈空间。这建议我们应该创建服务例程，尽早执行所有不可重入的事情(如维护硬件)，发出EI，然后继续执行可重入活动。然后弹出寄存器并返回。“。(杰克·甘斯勒)。
避免涉及动态内存分配的操作，因为分配可能需要锁定，并且需要不确定的时间。
避免堆栈分配取决于您的体系结构和操作模型，您的中断处理程序可能会利用中断线程的堆栈或公共的“中断堆栈”。
功能点是软件一部分的功能度量，您可以在这里阅读。一个C函数点平均大约需要130行代码。
以下是Capers的经验法则，其中“FP”表示功能点。这些摘自杰克·甘斯勒的时事通讯。
项目中注入的大约错误数量：FP 1.25手动代码检查将发现大约65%的错误。对于纪律严明的团队来说，这个数字要高得多。
如果有人说你要用声音调制解调器工作，问问他们它是否会设在另一栋楼里。除非答案是肯定的，否则拒绝。(Elecia White)