软件开发与项目管理易理——你该相信谁？

“永远不要相信任何人，你能相信的，只有你自己。”——屠岸贾，电影《赵氏孤儿》

 

一般情况下，程序开发流程为：

第1步：编写代码（包括程序所需的其他资源，诸如配置文件、数据库等），实现期望的功能。

第2步：编译代码，生成可执行文件。若编译不通过，返回第1步。

第3步：运行。若运行结果不正确，返回第1步。

 

我们通常的思维是，如果运行结果不正确，往往会认为是自己的代码有问题。那么看一下在VC6.0开发环境中的Debug模式下一段C程序：

 #include <stdio.h>#include <stdlib.h>#include "string.h"#include <crtdbg.h>static long crtBreakAlloc_Value = 0;static long lRequest_Value = 0;int __cdecl MyAllocHook( int nAllocType, void* pvData, size_t nSize, int nBlockUse, long lRequest, const unsigned char* szFileName, int nLine) { switch(nAllocType) { case _HOOK_ALLOC: case _HOOK_REALLOC: lRequest_Value = lRequest; crtBreakAlloc_Value = _crtBreakAlloc; break; } return 1; } int main() { _CrtSetAllocHook(MyAllocHook); char *pTest = NULL; while(1) { pTest = (char*)malloc(10); free(pTest); printf("%d %d/n",crtBreakAlloc_Value , lRequest_Value); } return 1;}   

这段程序中，每次malloc调用之后，lRequest_Value的值都加1，在VC6自带的DBGHEAP.C文件中有段代码：

lRequest = _lRequestCurr; /* break into debugger at specific memory allocation */ if (lRequest == _crtBreakAlloc) _CrtDbgBreak();

当malloc达到一定次数，会使得if条件城西，从而程序会崩掉。

尤其对于24*7运行的程序，如果程序中会不时的调用malloc函数，那么总有一天程序会崩掉。该问题的解决方法参考http://blog.csdn.net/donhao/archive/2010/05/14/5591927.aspx。在程序崩掉时，以下几种补救措施：

1. 使用看门狗

2. 使用dump工具

3. 使用日志记录

 

IDE本身是一种软件，是软件，就可能存在bug。如果我们的程序开发依赖于其他工具，那么可能存在所依赖的工具中不可预知的因素带来的风险。

 

你现在要实现嵌入式开发中双口RAM的读写操作，假设你的程序逻辑没有问题，编译器没有问题，但是运行结果不对，向双口RAM写入数据0x55，有时读出来确是0xAA。你再次确认了程序是没有问题的，你经过多次测试依然是这种现象。你找到BSP和硬件开发人员，他们给出的可能答案是“在某些特殊情况下，例如板子上有‘特殊’的静电，会导致双口RAM数据错误”。你是否怀疑过硬件本身的错误？甚至是CPU的错误？

 

所以，如果你的CPU将1加1算出3，或者是你的银行账户突然多出了100万，都不会是什么稀奇的事情！

 

[未经作者许可 不得转载]