很多时候，我们因为关注最终的结果，而总是忽略其它的情况。所以我们写的代码并不是那么的健壮。
这篇文章属于程序员内功修炼，值得一看。
写代码的时候，有几个阶段可以参考一下（鱼鹰经历并总结）：
阶段一：只要最终的结果
处于这个阶段的一般都是初学者，眼里只有一个目标，那就是程序运行成功，从不考虑其他因素。
比如一个简单的 SPI 驱动程序，最终的目标只要一个，通信成功。所以当需要延时时就会采用死等方式等待结果，而不会考虑其他可能出现的结果，比如因为某种原因导致引脚电平被持续一个电平不变，导致死循环；比如因为你的延时，导致其他人功能无法及时处理。
这个时候的思考总是过于理想化，不是因为自己太理想，太乐观，而是因为没有足够的经历告诉你，这样写是有问题的。
因为没有经历过，所以初学者也就考虑不了那么多，所以你看初学者的代码会很简单，是一条直线，逻辑很清晰，没有岔路。
阶段二：做一些常见的异常处理
随着经历越多（不管是网上看到的还是自己经历的），渐渐地，自己的代码变得多了一些，功能还是那个功能，只是这时候的你考虑的更多，更全面，你渐渐的增加了各种异常处理。
比如你不再使用死等方式延时，而是增加了一个等待时间的超时处理；又比如你写的程序不再只有if里面的内容（条件为真），还有else（条件为假）。
这个时候的你眼里不再只有最终的结果，还有在运行过程中可能出现的其他情况，并且会对这些情况做处理。
阶段三：怀疑一切
这个阶段的你不再相信任何东西了，即使它是那么的可靠。
你总是在函数开始处检查传入的参数（如果有的话），判断指针是否为空，判断数据是否在需要的范围内，等等。
总是在使用指针、数组的时候小心翼翼，深怕一不小心就越界了，而这种BUG只有经历的人才懂到底有多难查。
总是在异常的地方做出一些动作，如返回错误代号、如打印错误消息等。
不管怎样，在出现问题后，你总是能够快速的定位问题，而这，得益于你对异常的处理。
阶段四：做好善后工作
阶段三可能让你很快的定位问题，但是一旦出现问题，程序还是无法正常执行下去，比如申请的资源（内存、信号量等）没释放，又比如关闭的中断在异常后未重新打开等等。
所以异常处理代码除了能很快定位BUG外，还要做好善后处理，这样才能让程序健壮的一直运行下去。
鱼鹰曾在《代码写完了，你要花多少时间测试？》一文中介绍了一些调试方法，今天，继续更深入的探讨。
（uCOS II代码片段）
很多人其实不明白，为什么一定要在函数开头检查参数，这不是很浪费时间的吗（从上面可以看到，参数检查有时候比真正需要执行的代码还要多）？不说指针，就说一些普通变量，为什么要检查？检查的意义又在哪里？
浪费时间？
首先说说浪费时间的问题，确实，因为总是在开头检查参数，会浪费CPU的时间（鱼鹰一开始也非常不喜欢），但是当你经历了各种难查的BUG之后，你会发现，这点时间还是浪费的起。
而事实上，软件开发一般都会有两个版本，一个是Debug版本，一个是Release版本，只要通过宏进行控制，那么就可以在稳定之后，不再检查这些参数了。
但是有些重要的数据，即使稳定了，也不能放弃对它的检查，否则一旦出现问题，就是灾难。
所以在检查时，还要考虑这些检查是否在Release版本也是需要的，即按重要性分开检查。
为什么要检查？检查的意义又在哪里？
这些检查就像是函数的护城河，保证即使参数错误，也不会导致异常问题，比如数组越界，计算出错等。
那么我们要问了，参数怎么会错误，代码都是固定死的，有经验的都知道，参数是保存在栈或寄存器的，怎么会错呢？
你说内存数据保存时有问题？保存时为1，读出时为0？
别逗了，如果真是这样，那还怎么玩？程序根本没办法跑好吧（遇到强干扰可能会出现这种情况，甚至可能CPU执行流程都是乱的，最终只能重启，这个鱼鹰倒还没遇到过）。
我们可以认为存在RAM和FLASH的数据在存储和读取方面没有问题，那么又是什么导致了参数出错呢？
栈溢出
前面说过，参数有可能保存在栈里面，如果有些栈溢出了，参数被破坏也就可以理解了。（关于栈，可参考笔记《今天，你的栈溢出了吗？》）
数组越界、野指针等指针问题
一旦越界，那么产生的破坏力不可想象。
所谓越界，就是修改了不属于你的变量。比如一个数组，你操作了数组外的数据（不管是数组前面的还是数组后面的）。
而越界根据位置又可以分为三种情况。
第一种，栈（stack），比如你在栈里面申请了一个数组，越界了，那么修改的就是栈内容。
第二种：堆（Heap）。你通过malloc申请的内存，如果操作失误，那么就会修改不属于你的空间。
第三种。全局变量（data）。如果操作失误，也会出现问题。
其实，越界这种问题不一定就只会修改这些单独的区域，可能是两个区、三个区一起修改了，毕竟指针可不管修改的地址到底属于哪个区，还有一种是野指针导致的异常操作，那么它修改的位置只有鬼知道了（鬼好像不懂程序）。
比如你申请了一个数组，通过传入的参数修改数据，如果不限制参数大小，你确定它不会把你数组后所有的内存都给清零？！
如果硬要为上面三种情况划分处理难度等级，那么最容易也最快解决的就是全局变量的修改，为什么？因为地址比较固定，而ARM内核有神器处理这种情况，如果出现概率高的话，一查一个准，所以鱼鹰都不怎么苦恼这种问题。
最难解决的是堆的修改，这种问题比栈更难找。原因就在于，内存动态申请和释放，可能这次修改的是这个位置，没出现问题，下次修改另一个地址，就出现了问题，这种是最难查的。而栈的空间一般不会太大，而且他的存取都是有规律的，要稍微好查一些。
可能你会问，参数会保存在寄存器里面，那么寄存器的数据有可能被异常修改吗？
异常修改的可能性很小，因为对于C语言而言，寄存器是透明的，用户很难操作这个。
但是，虽然说参数传入之后被修改的可能性很小，但是传入前修改的可能性还是很大的，比如你传入的参数是一个全局变量，那么这个全局变量是可能被异常修改的啊！
所以，参数检查，是一个健壮程序必须要有的，这是防止产生重大问题最重要的护城河。而越早检查出问题，那么越容易定位问题。
蝴蝶效应大家都知道，千里之堤毁于蚁穴大家也知道，用在程序里面也是很合适的。
可能你会说，我对自己有信心，我的技术杠杠的，绝对不会出问题。
真的是这样吗？
第一、时间久了自己都忘了。
工作时，常常完成了一个项目，下一个项目马上来了，如果老项目需要维护，不需要一两年，只要一两个月，如果你没有参数检查、异常处理的好习惯，一旦你修改了代码，那么很可能因为某些疏忽，导致难以发现的BUG，而解决这些BUG的时间，比你写这些异常处理代码更多。
但是在你刚开始写这份代码的时候，因为思路清晰，考虑的比较多，有哪些异常很清楚，那么很容易写出那些异常处理代码。
就比如鱼鹰去年写了一份通过位绑定地址，批量配置引脚的时钟、寄存器信息的代码，那么今年再复用代码的时候，因为自己的疏忽，很可能需要大量的时间解决BUG，那我写这份代码的意义就不存在了（写这份代码就是为了在标准库中通过端口和引脚号快速配置引脚），而如果说，一旦因为疏忽导致的问题，程序会自动帮你检查，那么解决问题就很快了。
第二、维护。
不管是别人维护，还是自己维护，当项目需要更改需求时，如果因为某些疏忽，导致了BUG，那么解决起来费时费力，而且即使你这次解决了，难道下次还要重蹈覆辙吗？
第三、合作开发
一个项目可能不是一个人完成的，而是多人合作。而每个人的水平有高有低，你敢说别人不会写出有问题的代码？你敢说自己一定不会写出有问题的代码？
而且即使别人没有写出BUG，但因为某些原因，需要修改或屏蔽你的代码，如果你的代码能自动提醒出这些异常，那么定位问题也就不难了。
而鱼鹰为什么写代码的时间会比测试长，除了掌握大量的调试技巧外，就是因为在写的时候，会考虑很多，并且这些考虑，大部分会以代码的形式存在，少量的会以注释或者#warning、#error 形式存在，而其中，最好的方式是代码形式，因为它能保证程序正常运行，即使不能正常运行，也应该打印消息以提醒用户问题在何处。
所以，鱼鹰总是很庆幸自己当初花了不少时间去写异常处理代码，而这些代码，如果需要事后弥补的话，相信花的时间会更多（定位问题、回想当初自己如何思考、补充异常处理代码，这些都要时间）。
1.美商务部又将33家中国公司/机构列入“实体清单”，包括360、云从科技
2.嵌入式软件测试的10条秘诀
3.一个单片机ADC的挖坑填坑之旅
4.热了好多年，其实物联网刚刚迈过谷底~
5.如何让STM32优雅地“说”hello world?
6.常见类型ADC选型必知!
免责声明：本文系网络转载，版权归原作者所有。如涉及作品版权问题，请与我们联系，我们将根据您提供的版权证明材料确认版权并支付稿酬或者删除内容。
