A-A+

又一次投标

2019年07月23日 杂文, 默认 暂无评论 阅读 95 次

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

觉的不错?可以关注我的公众号↑↑↑
哼哼的泰迪熊

给我留言

Copyright © 字痕随行 保留所有权利.   Theme  Ality 京ICP备14039894号

用户登录

分享到: