今天顶着大太阳去客户那投了一次标。自从开启自由职业生涯以后，这还是第一次再次参与投标，真是个中滋味，唯有自知。

今天写这篇，不是为了唏嘘感叹，而是投标的过程中，客户提出了一个问题，让我现在仍旧有所回味。

问题其实很简单，客户问：我们这次的系统很关键，一旦有问题，可能就是比较大的生产事故，那么你们是如何保证系统安全运行的。

投标结束后，我仔细想了想这个问题，看似挺简单，但是我个人倒是觉得这个问题涵盖的倒是挺宽泛。

不如，回头看看这十几年，我是如何保证项目质量和系统安全的？

刚工作那几年，愣头青一个，只管怼功能，上线能用就好，不过自从服务器因为系统漏洞被黑之后，就开始尤为注重这块。引起重视，自然就会去搜索资料了解，了解的越多就越发现更多的空白。

之后，有一段时间，经常操作生产数据库，所以心惊胆战，对写下的每一行SQL都审视再审视，那阵子觉得每一行代码都不可靠，所以总是想各种办法进行测试后再用。

随着经验的增长，开始带团队，每次的BUG都能搞的压力山大，而且有时为了维持客户关系，还得不停的帮擦屁股，于是开始注重软件交付质量。

再后来，团队不停的增长，团队成员也良莠不齐，促使着思考如何使用规则保证系统的质量下限，再加上开始接触CMMI，渐渐的把这些概念揉到日常的工作中。

所以，到底怎么才能保证系统质量和安全呢？我个人认为，还是要抓住那么几个关键点。

第一个，从需求入手。到现在为止，我所见到过的，凡是需求混乱不清的项目或产品，质量全部堪忧。至于安全方面，我不觉得在需求混乱的情况下，会有人去主动考虑。

第二个，设计先行。没有设计，就没有骨架，没有骨架，这个项目或者产品就容易塌，容易垮塌的东西，自然谈不上任何质量。

第三个，单元测试。这块我个人的看法是，有单元测试肯定是好的，但是这块的确是最难实现的。如果真的不能实现覆盖，至少要做以下的工作：个人对关键代码的走查，关键代码的断点追踪，以及相应的边界测试和功能性测试。

第四个，控制产出物。程序员们总认为自己的代码完美无缺，恨不得写出来就赶紧上线跑出效果。但是你看看那些优秀的开源项目，无不经过了各种挑剔的审视，所以代码评审是必不可少的一步。

第五个，系统测试。如果真的因为资金紧张，没有测试人员，那只能听天由命了。如果测试人员，只会点点点，那也只能听天由命了。这里我要重申我的观点，测试一点也不比开发简单，比开发压力更大。

第六个，经验。如果缺失行业经验，会非常难以理解客户的想法，尤其对于ToB的项目。难以与客户达成一致，那就有想不到的一堆坑等着往里跳。

第七个，责任。其实上面的都是规则，如果说抛开这些规则，什么东西还能保证系统的质量和安全，那我觉得最重要的就是团队成员的敬业精神和责任心。如果一个团队的成员，全都是这样的人，他们自然而然的会规范自己和自己的产出物，会自然而然的拿出可靠的东西。

我的这些经验，其实更多的是基于ToB的领域，以上的一些可能对于某些行业领域不太适用。其实我倒是觉得，更早的形成自己的一套理论方法，并且用日常积累的经验不断的去打磨它，反倒是最好的。

最后，希望这篇总结，于己于人都有所帮助。