CodeReview工具upsource—唯一一款拥有静态代码分析和代码感知导航的POLYGLOT代码审查工具 随心所欲

CodeReview工具upsource—唯一一款拥有静态代码分析和代码感知导航的POLYGLOT代码审查工具

  产品功能 1.Upsource对代码具有独特的洞察力   Upsource为多种语言提供语法高亮显示。使用Java、PHP、JavaScript和Kotlin语言的开发团队还有一个好处。Upsource中有IntelliJ IDEA 核,因此特别了解这些语言,可以提供服务器端的静态代码分析、感知代码的导航、搜索代码用途。团队查看更改的代码时,特别需要这一补充的上下文环境。 2.高效的代码审查 经过特别设计的编码审查可以提高编码质量、深化团队合作并且让团队成员之间互相学习 Upsource中没有什么严格的工作流程,你完全可以随心所欲地按照自己的节奏安排   3.资料库浏览和搜索 Upsource提供统一的友好UI,可以从一个中心位置检索和监测所有Git、GitHub、Mercurial、Perforce 、Subversion资料库。它可以保留所有文件和讨论的历史、为编写项目提供资料库。还可以快速进入资料库中的任一部分。为了更好地快速掌握更改,Upsource可以可视化提交、分支和合并的历史。 在搜索某一特定的更改、提交或审查时,Upsource具有无与伦比的功能。通过提交信息、提交ID、作者、审查者、分支等检索提交历史。通过搜索特定作者、提交信息、文件名或VCS分支过滤掉提交图以便将精力集中在最相关的部分
阅读全文
你还在使用「千行代码Bug率」来衡量开发质量吗? 随心所欲

你还在使用「千行代码Bug率」来衡量开发质量吗?

https://www.sohu.com/a/130146757_354963 作者:常柱,现58到家技术平台负责人,负责到家技术体系的规划和团队建设。58同城会员体系创建者和技术负责人,搭建了58同城核心商业产品网邻通的业务和技术架构。有十年以上的技术研发和团队管理,对后端技术,敏捷团队等十分关注。也可以关注他的订阅号「架构未来」获取更多干货。 管理学大师德鲁克说:你如果你无法度量它,就无法管理它。要想做有效的管理,就很难绕开度量的问题。 软件开发的过程或者技术团队的管理也存在着如何去合理的度量效率的问题。而度量是把双刃剑,度量具有极强的引导性。度量指标会激励团队重视并改善能够度量元素,也会导致你忽视无法度量的元素,并使得问题进一步恶化。所以,选择合适的度量指标考核技术团队成员,需要慎重考虑。例如,代码行数和千行代码Bug率指标就值得商榷。 什么是千行代码Bug率 首先我们来看一下,千行代码Bug率是怎么定义的: 千行代码Bug率 = Bug数量/ (代码行数/1000) 度量的标准:千行代码Bug率数值越小质量越好。 关于CMMI级别中和BUG率相关的信息如下: CMMI级别 BUG率 CMM1级 11.95‰ CMM2级 5.52‰ CMM3级 2.39‰ CMM4级 0.92‰ CMM5级 0.32‰ 考核千行代码Bug率的问题 从考核千行代码Bug率来看,主要存在两个方面的问题: 首先,从考核标准上来说,Bug率数值越小就说明越好,基于这个结果,会引导团队成员做出一些对长远和整体效率无益的行为,例如: 1. 增大基数,增加无意义代码 2. 把定长循环分开写,写成顺序方法 3. 把可配置信息写死到代码中 4. 大量的复制、粘贴代码 5. 重新发明各种轮子 统计“千行代码Bug率”和“每日生产代码行数”一样,都是没经过大脑思考,而直接打算把优秀员工踢出团队的懒人式管理方式。特别是对从事智力型工作工程师来说,是很不合适的考量指标。 因为优秀的程序员是通过减少代码行数来增加功能的。 千行代码Bug率,虽然没有明确鼓励增加代码行数,但是这个计算结果对于优秀的员工来说是相当的不公平。它隐含的推广了“尽量增大代码行数”这个意思。 其次,从考核阶段看,Bug率的数据主要产出在研发阶段的后期,及提交测试后产出bug数。从项目的研发阶段和效率价值金字塔来看,其对项目的整体质量方面更多的聚焦在微观层面问题,整体的质量的影响范围会较小。而前面几个阶段的缺陷,会影响整个项目的进度,甚至导致项目失败,管理者和团队更应该将风险控制和度量指标向前移。 研发阶段和效率价值金字塔 如何更合理的度量质量 如果考核千行代码Bug率不能很好的解决质量核心问题,那我们还有那些方法和方案来提高项目的整体质量呢? 个人觉得,我们还是从项目的研发阶段和效率价值金字塔出发,重整体上去把控质量,上下游一体,从源头开始: 1. 需求的评审 2. 架构设计方案评审 3. 代码模块设计,包的依赖的规划,接口的设计的review 4. 代码的review的机制 5. 测试用例评审 6. 使用代码检测工具,自动发现问题                   过程评审是最有效也是成本最低的质量和效率保证和提升的手段。另外,过程评审还是迅速提高新人能力及其成果物的规范性的一个有效手段。 但是过程评审,也存在一些问题: 1. 前期过度依赖于团队的人员素质 2. 规则的定义也比较难,产出不好量化 3. 评审耗时多 4. 团队的意识不一致 对于过程评审的实施,最核心的统一团队意识,团队意识不一致时,效果一定不好。 意识意识不一致,在资源的投入上就会缩手缩脚;只有把过程评审做到位,才能体会到评审活动的高效,避免那种走马观花式的“评审”,是浪费时间,不是真正的评审。到位地完成评审后,会有那种对系统质量“踏实了”的感觉,过程中辅以严密的变更管理和风险控制手段,系统质量出大问题可行性会很小或者近乎为零。 系统质量是要靠上游工程做出来的,而且上游的工作质量会更为重要,上游的问题的影响范围将更广,对效率和价值的影响更大,应该是我们重点关注的地方。仅仅依赖下游工程(种种测试)来把质量关,是十分低效,而且代价是非常昂贵的。 总结 想做有效的管理,就很难绕开度量的问题。在选择度量指标上,大部分管理者总是倾向于关注容易度量的指标,而忽略难以度量的指标。但是容易度量的指标不一定是重要的,难以度量的反而可能是重要的。 软件开发产出最直观的结论就是一行行代码,实际上代码行数的多少并不代表价值的多少。当考核不合理导致出现大量的复制,不合理的设计,大量的冗余,不但难以理解和维护,甚至没有实际运行起来。这样就造成大量的时间浪费,同时也造成质量的严重腐化。 而基于全过程的评审机制和持续改进方法,可以很好的改善质量。但持续改进需要一个过程,需全团队从认知达成一致,并共享问题,统一步调和规范,持续的执行和改进。 另外,从工程师自身来说,千行代码Bug率用来自我评估和改进,还是很有价值的。 运维帮「运维大咖CLUB」招募会员:如果你是甲方运维总监/运维经理,欢迎加入我们,请联系微信yunweibang555
阅读全文