关于软件或代码，其实之前我已经写过一篇写代码的四个境界。虽然说能写出什么样的代码这是需要长久的训练和琢磨的，但是今天讲的，是写代码人该有的心态以及一些可能是必须的外界规范。 2013 年 10 月，丰田公司匆匆了结了"意外突然加速" 诉讼案。经过数小时的讨论，俄克拉荷马法庭陪审团得出结论：丰田汽车制造商贸然不顾用户的安全，裁定丰田公司赔偿原告 300 万美元。 而在审阅了 2005 版的丰田凯美瑞汽车的软件开发过程和源代码之后，两位软件专家得出一致结论：丰田公司的系统不但有缺陷，而且达到了危险的程度。因为故障保护机制里充斥着错误和不一致，这是导致事故的根源。 丰田公司汽车软件研发过程和源代码中的各种问题包括：位翻转（bit flips），任务终止导致的故障保护机制失效，对爆栈和内存溢出的防护机制不足，单一的故障隔离区域，滥用全局变量（全局变量达上万个之多）等等。 丰田有自己的软件过程标准，并且和工业标准多少有一些重叠。即使如此，丰田的程序员还是屡屡违反自己制定的标准。他们没能有效地跟踪他们偏离标准的程度，并且会为这种偏离行为进行辩解，认为这样做是符合实际标准的。 具体的案例讨论我就不一一引用，感兴趣的可以点击文末阅读原文阅读。 很久以前，看到过一段关于工程师的英文，原文不记得了。但用中国话意译过来大概是这样的：每个工程师都应该在他已有的水平上尽全力追求完美。我们应该具有一点工匠精神 —— 为我们的工作而骄傲，不断打磨我们的工具、流程、和技术，以打造出最高品质的作品。 理想主义一点，软件质量最基本的保证应该来自于程序员的素养。比如说： 有效的 tracking。哪些已经做完了，哪些还需要做，一定要有个一目了然且有效的工具帮助跟踪，尤其是项目其实是多人合作写代码的情况。随时想起来什么东西需要做，一刻也别耽误，第一时间记录下来。过分相信自己的记忆力早晚会为自己的一时疏忽买单。 诚实。不管你信不信，其实程序里面可能潜在的问题，程序员自己是最清楚的。一个系统、一个模块，如何实现，里面可能会有什么坑，什么潜在的风险，稍微有经验的程序员是不可能不清楚的。而如何对待这些，如何在必需做出权衡无法追求完美的情况下（比如 deadline）准确而清楚的将程序里的 "地雷" 打上标签，不遮不藏，却也是程序员的良心了。 勤快。比如说代码里见到的 TODO。包括前面说的情况，或是一些后续完成的
Read full article from 关于软件质量-程序员头条
No comments:
Post a Comment