最近一直再看安全相关的话题，突然看到这马里兰大学的杰出学者Michael Hicks教授的
https://www.cs.umd.edu/event/2015/09/penetrate-and-patch-building-security
核心思想是“安全内建，应该从软件开发一开始就考虑”。
虽然我是看着Michael Hicks教授的课程入门的安全，但是对于文中的比喻不敢苟同：
他以建造大桥为例，说我们的软件应该像建造大桥一样，从一开始就充分考虑各种设计，然后开发出各种最佳实践，用最好的方法，用最好的材料后再开始构建，在我看来这显然是反敏捷的，瀑布式的思想。
为什么这么说呢？
思考一下修建一座桥需要多久？开发一个软件需要多久呢？
桥修好，会改需求吗？能改吗？显然不能，或者说很困难。软件不是啊，相对于实体的建筑，他的修改实在是太容易了。软件快速修改，甚至重构，但是桥只能重盖。这是本质差别。
其次，假如一切都考虑周到，以修桥的速度，开发出的软件可能早就过时了啊。
显然桥的质量，安全性确实好，但是他是用高的构建成本（时间，人力），换取了后期的维护成本（可以说桥承受不起缺陷修复）
所以，这引出了一个非常重要的话题，我们是否要牺牲维护性（更多的bug），而换取开发成本低廉，开发速度快？
这不是一个计算机的学术问题，而是一个经济学问题。你觉得哪一个更重要。
现代软件的中流抵柱，各大互联网产品已经充分的表明了自己的选择。
因此，个人观点：我认同质量内建，安全内建的观点，但是软件是否应该应该提升开发成本换取维护成本的下降的问题，显然不适合用建筑或是制造业来类比的。
当然也有可能有这么一天，就是软件的同行们不要这么拼，给他人一条生路，也给自己一个不用996的理由，大家都做慢一点，总是把好一面呈现出来，也把好的一面呈现给自己（手动狗头）。
