作为一名嵌入式行业的程序员，对这十大谎言也是深有感触，本人从事汽车电子行业，主要工作做软件开发以及集成测试。
每次在写代码的时候，无论是C代码还是脚本测试代码，注释总是写的很少，甚至不写，除非此处的代码有特殊的环境意义，才会切中写一些针对性的注释。这种做法其实是很不好的，我们组长经常给我讲，代码一定要写好注释，该有的注释一定不要少，可有可无的也尽量要写的优美一些，养成一个好的习惯。和组长聊的多了，感觉也越来越深刻，就一点，每次一定要强迫自己去写注释，久而久之，就慢慢就养成了习惯。
针对第一条的，这只是临时办法，这一点感触更加深刻，我的例子就是，在工作中需要开发一套基于CANoe的集成测试工具，需要用CAPL进行开发，开始的时候，就直接做了，也没考虑太多的扩展性以及后续的可维护性，做好后组长问了一下我的设计思路，说完后，组长说出了许多他的建议，让我最好重新设计一下，我当时说这只是临时方案，后续我会慢慢改，然后后续我并没有改，就这样一直用着，也就是在前一个月前吧，自己打开CAPL看了一下，发现自己就看不下去了，花了一上午时间，把之前做的不好的地方重构了一下，自己心里感觉也舒服多了。所以在写代码或者设计之初，一定要深思熟虑，千万不要放希望在后面改，这样做出的东西才会优秀，还是那句话，切记一定在开始做好！哪怕会花费你一些时间，但是前面做好了，后面你会发现很顺溜的！正所谓磨刀不误砍柴工，说的就是这个道理。
针对第二条，估计很多做开发的也会遇到，功能做好后，其实一般都会有几个小问题在那里留着，虽然不是很要紧，但是终究不是很完美，既做了就一鼓作气，全做好，正所谓一鼓作气，再而衰，三而竭，说的就是这个道理！
这很简单，我几天就能做好，这种现象更是比比皆是，再简单的东西，也要全面思考一下，特别是嵌入式这种对实时性要求很高的软件，一定要在自己的脑海中把状态机跑一遍，做好单元测试，所有的逻辑分支都要跑到，这样的软件才能经得住考验。
开发还需要十天，这就要聊聊对开发周期的评估了，要做到评估的准确性，首先要对自己的能力有一个充分的认识，也要对与该软件相关人的能力评估，一定要避免木桶原理的发生。当然了对工作量也要做一下准确的评估，做到实事求是的评估。
TODO。。。很可能就一直todo了，可能忘记了，也可能需求不明确，如何避免忘记，最好自己每天做个checklist,把每天要做的事情过一遍，如果是需求不明确，那么一定要找系统工程师以及需求工程师做一个深入的探讨，如果不把需求整明白的话，做出的软件会南辕北辙的！
在我机器上是好的，这种情况出现的话，先看看两台机器的运行环境有哪里不一致，如果都一致，那么就需要看看外界因素，比如说是不是电压有波动，哪些软件版本不一致等等，如果都一致，多半是这条谎言是成立的，呵呵。
这不需要测试，呵呵，是软件就会有bug，不经过测试的软件，谁也不能百分之100的保证没有问题，这句话，作为一个优秀的软件工程师，一般是不会说出来的。
以前就有这个问题，针对这条，可以通过代码管理工具，如SVN，来将这个版本和上一个版本进行代码变更点比较，就能很快定位问题。
第九，改之前，虽然只有一行代码，真的要考虑很多状况，这种情况在我们的项目中就遇到过，只改了一行代码，导致整车功耗大了30倍左右，是因为这行代码，导致了低频芯片不能进入睡眠了，导致静态电流过大，功耗高，经常亏电，后来查了很久才发现那一行代码！所以虽然仅仅是一行代码，也一定要慎之又慎！
硬件有问题，不排除这种可能性，但是多数是软件的问题，这一条在互联网行业应该会明显，在嵌入式行业，硬件的可能性确实会大一些，不过也不是绝对，在我们的项目种，出现过这种问题，是芯片级的问题，毕竟少之又少，所以一旦出现问题，软件还是要多查查的！
