码迷,mamicode.com
首页 > 其他好文 > 详细

人月神话札记:整体部分

时间:2015-05-19 10:44:57      阅读:101      评论:0      收藏:0      [点我收藏+]

标签:人月神话   札记   整体   部分   

前言:关于测试,的确太过重要,尤其是把新做成的功能加入到原来已经正常运行的系统中,先随我一起进入到Brooks的世界中看一看。

剔除bug的设计

产品的概念完整性在使他易于使用的同时,也使开发更容易进行,而且bug不容易产生。

在我所经历的项目中,我只参与了其中一部分,或者负责了较大部分,在与别人负责的代码打交道的过程中,如果我稍不留神,就会滋生很多bug在其中。除去我对整体业务掌握的不够全面以外,大部分的原因是因为我们彼此之间的差异太大。

自上而下的设计。我所经历的项目的确都是自上而下的设计,都是先搭建整体模型,再不断细化。但是很多时候,做的不好,是因为模块之间的耦合度太高,导致不够灵活。

构件单元测试

Brooks提到了本机测试和交互性测试,也许我理解的不够深刻,我认为的本机测试就是我们在个人的电脑中配置软件运行所属环境,进而对代码进行整体性测试,等本地测试通过后,我们在部署到服务器当中。这个时候,因为代码以及服务器的一些固性原因,我们需要手动去改变服务的某些状态,我们在这个时候,就会对代码多加上一些人为操作手段,进而控制程序进行交互性测试。
技术分享

系统集成调试

系统集成调试的概念,对于每个学习编程的开发人员来说,并不陌生,甚至我们经常挂在嘴边,我们都倾向于只做集成测试,而不太重视做集成测试之前先要做构件测试,也就是说保证集成到整体系统的每一部分都顺利通过。

小型团队没有代码review,也缺乏同级的代码评审,更缺少自我的代码测试,我们经常性的只要完成了代码,就认为可以放到服务器上供用户使用了,然而这个时候,我们经常吃很大亏,一些不负责任的程序员经常为我们埋雷。

我个人最近也深有体会,写完代码之后,我自己会反复检查几次, 然后对重要的部分进行单元测试,然而,等放到服务器上运行时,就出现了不应该出现的错误。

在集成测试之前,一定保证每个部分已经被测试通过了,至少确保你在集成测试时候发现问题时,能尽快的定位到为题发生的所在之地。

搭建充分的测试平台。这个非常的必要,我们项目部有两个小组,有一个小组虽然有测试服务器,但是很多时候,代码在正式环境上线后,依然出现很低级的错误,这其中一个很主要的原因就是没有保持好两者之间的同步。

伪构件、伪文件。我想很多时候,我们都经历过,并且取得了很多的成效。当我们无法真实产生所需的xml时,我们会手动构造一个;当我们的某个功能尚未完善时,我们会假装它已经完成。这些在测试的时候,都会给我们很大的帮助,让我们的整体测试顺利的进行下去,而不是阻塞,当然这是因为伪构件和伪文件足以让我们发现应该找到的bug。

控制变更。由于我们的小组成员人数只有我和另外一个人,再加上两人可以随时语言沟通,所以我们没有进行变更控制。但是如果项目人数有5人以上时,遵守Brooks的观点是应该的:
一个是供构件测试使用的最终锁定版本;一个是测试版本的拷贝,用来进行缺陷的修复;以及一个开发库,供其他人员进行各自的程序开发。虽然我知道svn有分支,但是我还是不太确定如何在SVN上执行这些操作。

一次添加一个构件。在很重要,交易平台的项目目前主要由我整体把控,所以我经常性的优化代码结构,但是有的时候会事与愿违,优化后的代码不足够保证程序正常运行,这很大一个原因就是我改动的太多,所以出现问题后,如果我反复很多很多次后,依然无法找出问题所在的原因时,我就会还原版本,再改动。再次改动的时候,我就会缩小范围,保证每一次修改都不会影响到原有的程序。这很重要。

人月神话札记:整体部分

标签:人月神话   札记   整体   部分   

原文地址:http://blog.csdn.net/qing_gee/article/details/45831799

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!