关于软件或代码，其实之前我已经写过一篇写代码的四个境界。虽然说能写出什么样的代码这是需要长久的训练和琢磨的，但是今天讲的，是写代码人该有的心态以及一些可能是必须的外界规范。
这几天看到一篇文章《有着 1 万个全局变量的一大坨代码》，讲了这样一件事：
2013 年 10 月，丰田公司匆匆了结了“意外突然加速” 诉讼案。经过数小时的讨论，俄克拉荷马法庭陪审团得出结论：丰田汽车制造商贸然不顾用户的安全，裁定丰田公司赔偿原告 300 万美元。
而在审阅了 2005 版的丰田凯美瑞汽车的软件开发过程和源代码之后，两位软件专家得出一致结论：丰田公司的系统不但有缺陷，而且达到了危险的程度。因为故障保护机制里充斥着错误和不一致，这是导致事故的根源。
丰田公司汽车软件研发过程和源代码中的各种问题包括：位翻转(bit flips)，任务终止导致的故障保护机制失效，对爆栈和内存溢出的防护机制不足，单一的故障隔离区域，滥用全局变量(全局变量达上万个之多)等等。
丰田有自己的软件过程标准，并且和工业标准多少有一些重叠。即使如此，丰田的程序员还是屡屡违反自己制定的标准。他们没能有效地跟踪他们偏离标准的程度，并且会为这种偏离行为进行辩解，认为这样做是符合实际标准的。
具体的案例讨论我就不一一引用。
对此，朋友圈有朋友评论：“不仅仅是丰田，好奇其它车厂的控制软件的质量能有多少差异?各种碰撞测试，安全测试往往还是硬件的比较，在软件越来越影响安全的今天，软件的质量却被极大的忽视。大多时候，我们能依赖的只有程序猿的良心。”
很久以前，看到过一段关于工程师的英文，原文不记得了。但用中国话意译过来大概是这样的：每个工程师都应该在他已有的水平上尽全力追求完美。我们应该具有一点工匠精神 —— 为我们的工作而骄傲，不断打磨我们的工具、流程、和技术，以打造出最高品质的作品。
理想主义一点，软件质量最基本的保证应该来自于程序员的素养。比如说：
胸有 “成” 竹。即使是在面试中，也会常常遇到一些在没有把整个问题和程序的全局想清楚就开始动手写代码的人。这几乎是兵家(哦，应该是码家)第一大忌。从设计到架构到代码蓝图，前面工作做得越细致，后面省下来的功夫会是加倍的。
有效的 tracking。哪些已经做完了，哪些还需要做，一定要有个一目了然且有效的工具帮助跟踪，尤其是项目其实是多人合作写代码的情况。随时想起来什么东西需要做，一刻也别耽误，第一时间记录下来。过分相信自己的记忆力早晚会为自己的一时疏忽买单。
诚实。不管你信不信，其实程序里面可能潜在的问题，程序员自己是最清楚的。一个系统、一个模块，如何实现，里面可能会有什么坑，什么潜在的风险，稍微 有经验的程序员是不可能不清楚的。而如何对待这些，如何在必需做出权衡无法追求完美的情况下(比如 deadline)准确而清楚的将程序里的 “地雷”打上标签，不遮不藏，却也是程序员的良心了。
勤快。比如说代码里见到的 TODO。包括前面说的情况，或是一些后续完成的优化，有时我们会加一个 TODO 注释说明这个地方自己后面会解决。然而几乎所有较大的项目这样一些很重要的 TODO 在很久一段时间都还继续存在。即使早晚这里的 TODO 会被 done，但有一个很大的坏处就是后面遇到的代码重用中，这样的 TODO 可能会被扩散到另一个地方，而注释可能会丢失。所以， 永远不要把垃圾扫到地毯下面。 哪怕是加了标签。能解决的，尽快解决，不要遗留。
而另一个类似的情况，是当你在另一个已有文件里改动代码的时候。常常会遇到一个情况是：已有的老代码和风格其实是有你能看得出来的问题的。选择置之不 理自然省事。甚至为了保证一个文件的风格一致可以照着旧代码风格写，即使这样是不完美的。而按照正确的方式插入你的代码并且重新规范已有代码会增加很多的 工作量。那这个时候你是改还是不改呢?
完备的测试集。写代码的都知道，很多时候，写出可以测试所有情况的单元测试和综合测试，需要的工夫可能比写函数货程序本身要费劲的多。然而，完备的测试集是代码持续开发中保证正确性的第一道防护线，不论是后期的修改、重构、移植等，都会事半功倍的帮助发现问题。其重要性也不用我多说了。
转自
