当程序不能正常工作时,程序员的常用借口

来源:互联网 发布:js将图片转化为base64 编辑:程序博客网 时间:2024/03/28 23:48

我总是觉得,开发者需要一个开发的态度,我在另一篇博文里细说了这个问题。普遍来说,一旦开发出现了问题,开发人员都会编造借口。只要这些理由是真的,这并不是什么问题。但是,一旦这真的只是个借口,这就会成为整个团队的的问题所在。我自己也会对自己做过的那些借口偶尔感到羞愧,在改正的同时并思考着如果在未来避免同样的问题。下文列举了一些常见。

 

0. 在我机器上是可以运行的

拜托,这可是开发人员最常用的借口,《程序员给测试人员的20条高频回复》中的第一条就是它了。我们总是觉得测试或者用户有着某种神奇的电脑,能在我们的代码里填充着原本不存在的程序错误。这,完全不是真的。

唯一可以避免这种借口的方法是意识到开发,测试和产品运行环境。想要做到这点,第一你需要问的就是,这是什么样的产品运行环境,得到更详细的问题咨询,并进一步查看这是不是一个合理的问题。另一种方法是,建立一个持续集成的环境,同样的代码,在同一个环境内的某些机器上开发,另一些机器上测试。

weeklyrant_developersexcuses

 

1.你用最新的版本了嘛?

这是另一个借口。没有使用最新的版本,或者测试了错误的版本是一个颇为常用的借口。这也并不是不可以避免的事情。

去避免这个借口的唯一方法,就是建立一个过程,验证测试使用的是最新的版本。在一个持续集成的环境里,代码自动归档,生成新的版本并在同时部署在测试的机器上。另一个方法去验证正在测试的版本和开发的版本相同。

 

2.一定是配置问题

如果你告诉我这个,我一定会说,“对啊,可能是个配置问题。所以,你能告诉我是哪里的配置出了问题了嘛?”如果你遇到相似的情况,你也很有可能问类似的问题。正如你所预料到的,人家在这个问题是寻找一个确切的答案,而不是泛泛之词。

避免这个借口的最佳方法,是把所有配置相关的参数都定义在分开的配置文档里,并把动态值写进日志中,所以一旦出现混淆,总是可以参考配置文档里的说明,来避免分歧。在运行的过程中使用文档规定的格式,可以使错误率降到最小。到时候,即使问题真的是由配置产生的,我们也可以轻松发现并找到解决方案。

 

3.请建立一个错误报告,我等下去查这个错误

从我的角度看,在确定是否是错误前就直接建立错误报告,是个蛮大的问题。这个问题,既可能是在过程中被追踪着,也可能在测试人员和开发人员中间的协调问题。一般来说,测试人员和开发人员可以联合作业,以防测试并不能真的追查到是否是开发错误。

避免这个问题的方法是,建立良好的测试人员和开发人员之间的关系。这样子,开发和测试之间会沟通,讨论并积极的寻找解决方案。

 

4. 试试重启机器

杀手级的借口。我也做过同样的事情。确实,这真的能解决不少微软相关的技术产品上(比如说,.NET),而且在某些特殊的情况下,重启还是很起作用的。科学有效解决了相当多的微软相关的开发软件的某些错误。当然,更多的情况下,这样子是没啥结果了。

避免这个借口的方法和上面列举过的某个方法很类似: 我们需要注意开发环境、功能性、架构和代码设计。通过这些,我们可以确定这是否是一个真的软件开发错误。

 

5. 我不确定这是否能运行,让我看看

我个人非常讨厌这个借口。作为开发人员,如果你不确定某个特定功能是否能运行,这表示,要么你根本没有准确的明白这个开发的功能,要么你没有明白这个程序的设计。

解决方案:建立模块在心中的映射,一旦被告知问题,开发人员能立刻去分析问题,并找到问题的根源。如果不能确定问题根源,要么是没有设计好的代码,要么就是对功能或模块没有完全理解。

 

6. 五分钟前它还能正常运行

多可爱的回复。我猜你刚刚放下了一个定时炸弹在那里,确保了这软件5分钟以后一定不能正常运行。

解决方案: 意识到时间并不能改变程序,除非这是段专门处理时间的程序。因此任何其他的功能都不能应该受到时间的影响。

 

7. 我觉得我的程序没有任何问题

我一般不会给出这个答案。我相信在一个团队中,没有一个东西可以被称为是我的东西。我宁愿说哪个模块也许错了。这个借口是在尝试着去找个人背黑锅,绝对不利于团队的最大士气。

解决方案: 建立团队文化,并轮换开发人员的开发模块,确保没有一个开发人员只负责某一个特定的模块,保证每个团队成员都对整个项目有了解认识。


http://blog.jobbole.com/53705/

0 0
原创粉丝点击