Pet*_*ler 46 unit-testing code-analysis
我喜欢我的代码是有序的,即格式正确,可读,设计,测试,检查错误等.事实上我对它很狂热.(甚至可能比狂热更多...)但在我的经验中,帮助代码质量的行动很难实现.(通过代码质量,我的意思是您日常生成的代码的质量.软件质量与开发过程等的整个主题要广泛得多,而不是这个问题的范围.)
代码质量似乎并不受欢迎.我的经验中的一些例子包括
可能每个Java开发人员都知道JUnit,几乎所有语言都实现了xUnit框架,但在我所知道的所有公司中,只有很少的正确单元测试存在(如果有的话).我知道由于技术限制或紧迫的截止日期,并不总是可以编写单元测试,但在我看到的情况下,单元测试可能是一种选择.如果开发人员想为他/她的新代码编写一些测试,他/她可以这样做.我的结论是开发人员不想编写测试.
静态代码分析通常在小型项目中进行,但并不真正用于强制执行编码约定或在企业项目中发现可能的错误.通常甚至会忽略像潜在空指针访问这样的编译器警告.
会议发言人和杂志会谈论很多关于EJB3.1,OSGI,云和其他新技术,但几乎没有关于新的测试技术或工具,新的静态代码分析方法(例如SAT解决方案),有助于保持更高质量的开发流程,如何遗留代码的一些讨厌的野兽被测试,...(我没有参加很多会议,它可能在敏捷主题的会议上看起来不同,因为单元测试和CI等具有更高的价值.)
那么为什么代码质量如此不受欢迎/被认为无聊呢？
编辑:
谢谢你的回答.其中大多数涉及单元测试(并已在相关问题中进行了讨论).但是还有很多其他的东西可以用来保持代码质量很高(参见相关问题).即使您无法使用单元测试,也可以使用每日构建,向IDE或开发过程添加一些静态代码分析,尝试配对编程或强制执行关键代码的审核.
jal*_*alf 32
Stack Overflow部分的一个明显答案是它不是一个论坛.它是一个问答数据库,这意味着可以避免重复的问题.
您能想到多少关于代码质量的不同问题？这就是为什么没有关于"代码质量"的50,000个问题.
除此之外,任何声称会议发言人都不想谈论单元测试或代码质量的人显然需要参加更多的会议.
我也看到了关于持续集成的文章.
没有编写测试的常见借口,但它们只是借口.如果有人想为他/她的新代码编写一些测试,那么就有可能
真的吗？即使你的老板说"我不会因为你在单元测试中浪费时间而付钱"？即使您正在开发一些没有单元测试框架的嵌入式平台？即使您在紧迫的期限内工作,试图达到一些短期目标,即使以长期代码质量为代价？
不.编写单元测试并非"总是可行".它有许多常见的障碍.这并不是说我们不应该尝试编写更多更好的测试.有时候,我们没有机会.
就个人而言,我厌倦了"代码质量"的讨论,因为他们倾向于
我当然有兴趣编写高质量的代码.我倾向于被通常谈论代码质量的人关闭.
Eri*_*ric 12
代码审查不是一门精确的科学.使用的指标在某种程度上是有争议的.在该页面的某处:" 你无法控制你无法衡量的东西 "
假设您有一个具有35个参数的5000行的巨大功能.您可以对它进行单元测试,但它可能完全按照预期进行测试.无论输入是什么.所以基于单元测试,这个功能是"完美的".除了正确性之外,还有许多其他质量属性可能需要测量.性能,可扩展性,可维护性,可用性等.你有没有想过为什么软件维护是一场噩梦？
真正的软件项目质量控制不仅仅是检查代码是否正确.如果你检查软件开发的V模型,你会发现编码只是整个方程的一小部分.
软件质量控制可以达到项目总成本的60%.这是巨大的.相反,人们更愿意降低到0%并回家认为他们做出了正确的选择.我认为为什么这么少的时间专注于软件质量的真正原因是因为软件质量还不是很好理解.
很多编码器血汗工厂都没有意识到"现在减少错误"和"后来更多利润"之间的关系.相反,他们所看到的只是"浪费时间"和"现在利润减少".即使显示漂亮的图形显示相反的情况.
而且,软件质量控制和软件工程作为一个整体是一门相对较新的学科.到目前为止,很多编程空间都被网络牛仔所采用.你有多少次听说"任何人"可以编程？任何人都可以编写肯定的代码,但并不是每个人都可以成为程序员.
编辑*
我遇到过这篇论文(PDF),这篇文章来自那个说"你无法控制你无法衡量的东西"的人.基本上他说控制一切并不像他最初认为的那样令人满意.这不是一个精确的烹饪配方,你可以盲目地应用于所有项目,如软件工程学校想让你思考.他只是添加了另一个参数来控制"我想控制这个项目吗？会不会需要？"
Spe*_*ort 11
我不同意它虽然很沉闷.坚固的单元测试设计使创建测试变得轻而易举,让它们更加有趣.
Calculating vector flow control - PASSED
Assigning flux capacitor variance level - PASSED
Rerouting superconductors for faster dialing sequence - PASSED
Running Firefly hull checks - PASSED
Unit tests complete. 4/4 PASSED.
像任何事情一样,如果你做了太多的事情就会感到无聊,但是花费10或20分钟为一些复杂的功能编写一些随机测试后,几个小时的编码就不会给你带来创意生活.
为什么代码质量如此不受欢迎？
因为我们的职业不专业.
然而,是人谁做对代码质量的照顾.你可以在Software Craftsmanship运动的讨论组中找到这样的志同道合的人.但不幸的是,软件业务中的大多数人并不了解代码质量的价值,或者甚至不知道什么构成了良好的代码.
我想答案与"为什么代码质量不受欢迎？"这个问题相同.
我认为最主要的原因是:
简短的回答:这是其中一种无形的东西,只有其他人,主要是经验丰富的开发人员和工程师才会欣赏,除非出现问题.在这一点上,管理者和客户都在哗然,并要求为什么没有正式的流程.
更长的答案:这种短视的方法不仅限于软件开发.美国汽车工业(或其左翼)可能就是最好的例子.
当项目一次性或一次性开始时,也很难证明正式的工程流程是正确的.当然,在项目完成很久之后,它需要自己的生命(并且变得突出),因为不同的业务部门开始依赖于它们自己的业务流程.
此时需要设计新的解决方案; 但是,如果没有使用这些工具和良好实践的实践,这些工具就没有用处了.它们成为一个耗时的障碍.在IT团队支持业务的公司中,我经常看到这种情况,在这些公司中,开发通常是反动的而不是主动的.
编辑:当然,这些坏习惯和许多其他人是像思科工作这样的咨询公司能够继续茁壮成长的真正原因.
我没有看到提到的一个重要因素是任何流程改进(单元测试,连续集成,代码审查,等等)需要在组织内拥有致力于技术的倡导者,在组织内部具有适当的影响力,并愿意做的工作,以说服他人的价值.
例如,我已经看到了一个真正认真对待代码审查的工程组织.那家公司有一个软件副总裁,他是一个真正的信徒,他会参与代码审查,以确保他们正确完成.他们偶然拥有与我合作过的任何团队的最佳生产力和质量.
另一个例子是我在另一家公司实施了单元测试解决方案.尽管管理层坚持,但最初没有人使用它.但我们中的一些人真正努力谈论单元测试,并为想要开始单元测试的人提供尽可能多的帮助.最终,一些最受尊敬的开发者签约后,他们开始看到单元测试的优势.之后,我们的测试覆盖率大幅提升.
我只是想到了另一个因素 - 一些工具需要花费大量时间才能开始,并且启动时间很难实现.静态分析工具可能很糟糕 - 你运行该工具,并报告2,000个"问题",其中大多数都是无害的.一旦正确配置了工具,误报问题就会大大减少,但有人必须花时间,并承诺随着时间的推移维护工具配置.
可能每个Java开发人员都知道JUnit ......
虽然我相信大多数或许多开发人员都听说过JUnit/nUnit /其他测试框架,但是很少有人知道如何使用这样的框架编写测试.从那些人中,很少有人很好地理解如何使测试成为解决方案的一部分.
我已经了解了至少7年的单元测试和单元测试框架.我试图在5-6年前的一个小项目中使用它,但仅在最近几年我才学会了如何正确地做到这一点.(即找到适合我和我的团队的方式......)
对我来说,其中一些是:
所以直到找到正确的方法; 是的,它很无聊,没有回报,很难做,很费时间等等.
编辑: 在这篇博文中,我深入介绍了针对单元测试的一些原因.
| 归档时间： |
|
| 查看次数： |
6834 次 |
| 最近记录： |