在前两天的    关于“代码规范”,“Review”和“Check list”    一文中,我给自己列出了Check list,如下: 1.代码能够工作么?它有没有实现预期的功能,逻辑是否正确等. 2.所有的代码是否简单易懂? 3.代码符合你所遵循的编程规范么?这通常包括大括号的位置,变量名和函数名,行的长度,缩进,格式和注释. 4.是否存在多余的或是重复的代码? 5.代码是否尽可能的模块化了? 6.是否有可以被替换的全局变量? 7.是否有被注释掉的代码? 8.循环是否设置了长度和正确的终止条

公司原先搭了一个代码Review的服务器,由于历史原因,装的是一个32bit的Ubuntu系统,后来由于需要,需要安装gitlab,由于gitlab需要64位系统,所以临时凑合了个vagrant,本质就是一个纯粹的虚拟机,感觉不爽,这两天终于抽出时间来重新整理了一下.基于Ubuntu 18.04 x64版本和Docker来部署,减少后面换机器换系统可能导致的重复安装工作. Docker安装 Docker安装还是比较简单的. $ sudo apt-get install apt-transport

经验丰富的程序员和一般程序员之间的最大区别,不仅体现在解决问题的能力上, 还体现在日常代码的风格上.掌握一门技术可能需要几月,甚至几周就够了. 好的习惯风格养成却需数年. 团队成员之间需要合作,代码需要日后可维护,个体的能力和习惯存在差异. 故保证代码质量及风格,就需要制定一定的规则,按项目周期(最好是在上预发之前)组织进行集体代码review. 一 目的 1 保证代码质量 自己的代码要给别人看,在开发过程中就会刻意的注意一些规范,写法及逻辑严谨性. 2 扼杀潜在的风险 程序员会去自测,即使有某

前言 对于一个程序猿来讲怎样来最直接的来衡量他的技术能力和产出呢?我想最直观的作法是看他的代码编写能力,就拿我常常接触的一些程序猿来看,他们买了非常多技术重构类书籍.可是看完后代码编写能力并没有显著提高.有人说可以用代码review工具啊,可是像市面上的这些代码review工具.仅仅能帮助我们解决表面的bug和规范点.还无法帮助我们发现更深层次的设计问题. 以下我将结合<软件设计重构>这本书谈谈在进行代码review的时候.须要关注的哪些点. 一.技术债务 何为技术债务? 技术债务是有意或无意

来新公司,给公司的SDK review了一下.发现了不少小问题,在此总结一下. (我下面说明问题可能是很简单,但是搞清楚某些问题还是花了些时间的,大家引以为戒吧) 先谈谈处理的问题: 1.某天QA说有游戏在iphone5 上测试,启动闪退. 我通过日志捕捉到,是因为用了openssl库,这个库包含了libcrypto.a, 这个库 和 老款的 iphone 处理器 架构冲突,导致crash. 我检查了openssl引入是为了做 https 的验证(为了验证服务器证书,其实是画蛇添足).但是这部分

以前我们一直都是如果要进行代码review的时候,要不我们就直接用idea来进行查看,根据不同的来查看 但是我们都是看代码的不同来进行来实现的,其实我们不需要这样,我们可以使用工具Phabricator的 工具进行提交,无奈,自己在windows的安装目前不行,所以就用公司的代码review的工具 1.我们先使用git到你自己的分支wangjing18-dev,然后到master里面,pull下来,接下来再到自己的分支wangjing-dev,接下来 git merge master,合并mas

代码review是代码质量保障的手段之一,同时开发成员之间代码review也是一种技术交流的方式,虽然会占用一些时间,但对团队而言,总体是个利大于弊的事情.如何借助现有工具在团队内部形成代码review的流程与规范,是team leader或技术管理者需要考虑的问题.本文分享一种基于Gitlab代码merge流程的code review方法,以供参考与探讨.如有更好的方法,欢迎交流. 1. 设置成员角色 首先需要对你团队的成员分配角色,在Gitlab groups里选择一个group,然后左边菜

Gitlab来做代码review 代码review是代码质量保障的手段之一,同时开发成员之间代码review也是一种技术交流的方式,虽然会占用一些时间,但对团队而言,总体是个利大于弊的事情.如何借助现有工具在团队内部形成代码review的流程与规范,是team leader或技术管理者需要考虑的问题.本文分享一种基于Gitlab代码merge流程的code review方法,以供参考与探讨.如有更好的方法,欢迎交流. 1. 设置成员角色 首先需要对你团队的成员分配角色,在Gitlab group

对于代码review个人也有些小小的看法: 1．首先我觉得我们所有开发人员要弄明白 现在Code Review 的目的 ,凡事不弄明白目的,无法做好完成一件事情,个人觉得有以下一些目的: a)可以在项目早期就能够发现代码中的BUG ,提测后可以尽快的释放开发资源:b)同时可以达到知识共享 ,避免我们所有开发人员犯一些很常见,很普通低级的错误 :c)保证项目组人员的良好沟通 ,项目的代码更容易维护 大家还有希望补充上 2．Code Review 很容易变得没有意义或是流于形式,进入 Code Re

代码审核(Code Review)是软件研发质量保障机制中非常重要的一环,但在实际项目执行过程中,却因为种种原因被Delay甚至是忽略.在实践中,给大家推荐一款免费.开放源代码的代码审查软件Gerrit. 1. Why Code Review Code Review是什么? Code Review最直观的解释即看代码.常规的做法为自己看,有时代码逻辑问题可能自己看不出来,需要找同事一起看,在大家知识体系相对平均的情况下可能需要花钱专门的公司帮助查看. Code Review需要看哪些?对于刚入职

热情高涨 代码走查作为一种流程形式,起初大家的参与热情非常高涨. 因为,自己可以学习到别人一些巧妙的思想,自己的代码和习惯都暴漏出来. 这个过程中不断地吸收和改正. 但是...... 我们一开始组织的代码走查是一个很重的会议形式. 参加的人有写这段代码的人(小菜).比较有经验的开发(大佬) 如果为了再隆重一些,请一些领导也参与其中. 但是...... 我上面提过了,会议很重,协调时间这个事情就是一个很费时间的事情. 还有就是,大家恨不得对每一句代码都发表自己的意见,往往非常低细枝末节. 导致会议

转自:http://blog.lichengwu.cn/java/2013/11/24/use-findbugs-code-review/ 介绍 Findbugs是一个代码静态分析工具,用来找出Java代码中的bug.通过分析字节码并与一组缺陷模式匹配,找出代码中的问题. 目前Findbugs支持除了java 8以外的所有版本编译的字节码文件分析. Findbugs不仅提供了可视化界面,还有Idea,Eclipse插件. Findbugs有谷歌和SUM/(Oracle)支持,在JDK源码编译中,

代码审核(Code Review)是软件研发质量保障机制中非常重要的一环,但在实际项目执行过程中,却因为种种原因被Delay甚至是忽略.在实践中,给大家推荐一款免费.开放源代码的代码审查软件Gerrit. 1.Why Code Review Code Review是什么 Code Review最直观的解释即看代码.常规的做法为自己看,有时代码逻辑问题可能自己看不出来,需要找同事一起看,在大家知识体系相对平均的情况下可能需要花钱专门的公司帮助查看. Code Review需要看哪些?对于刚入职场或

版本发布之后,外网新增了一些crash, 从mini dump看,的确是有异常的,619行crash了. 代码如下: 奔溃的地方如下 可以看到是Zip add的时候指针空了, 为什么呢? 结合代码,可以发现这个地方算便宜是有问题的,万一length 小于size呢?.. 修复方案就不另说了,其实这个问题我一开始从dump 没看出来,还是实际该代码重现才发现的. 最终找到问题了再来看,经验就是: windbg不会骗人,如果有源代码,就多review吧.不是每次都有条件重现的.

上周没事扫扫系统原来的代码,突然发现这样一段代码: if(log.isInfoEnable()) { log.info("ID"+userID+"pwd"+userPwd); } 因为之前写的日志类都是公司内部自己的日志类,对log4j用的并不多.当时看了这段代码觉得很奇怪,代码意思我是明白的,log本身就可以根据打印权限,判断当前是否打印呀,为什么专门要加上这样一条判断呢?后来查了一下,发现是由于性能方面考虑的. 如果直接写入这样一段话 log.info(&quo

在此结构中,一个 PPC 处理器作为监管处理器,与大量的 SPE流处理器相连通,组成了一个工作流水线. 对于一个图形处理过程来说,某个 SPE 可负责提取数据,另一个 SPE 负责变换,再另一个负责存回.这样可构成一道完完整整的流水线,大大提高了处理速度. 在我们搭建框架之初一般会设计一个ViewController基类,并在基类ViewDidLoad中设置一个随机的背景颜色.并通过touch手势来进行界面的跳转,以此来设计最开始的一个界面跳转框架,并通过界面颜色的变幻来验证我们界面跳转是否有做

FrmMain.cs中存在问题 1. int i=0 设定为了全局常量且未在类顶部,出现问题时不好查找 i 属于常用临时变量,设定全局变量容易引起混乱 2.定义的全局变量但仅在一处方法中使用,定义全局变量过多 3.变量名及控件名等意义不明确又缺少注释,如顶部定义的全局变量 ; ; private string oldPath = null; ; ; private string quotaNum = null; 其他类似 timer1,timer2,l1,l2等等... 4. 存在多处重复或相似

本文整理向openstack社区提交代码的基本流程,以及社区一些介绍资料.如有转载,请注明出处! 先放张图说明一下OpenStack的code review的大体流程: 对OpenStack提交代码更改的流程主要如下: 配置Git与Gerrit环境 克隆目标项目的代码并在新branch上进行更改 commit到本地的repo后推送给远端Gerrit,然后由reviewer给出意见 根据reviewer的修改意见不断更新patch 其中OpenStack使用Gerrit作为代码review系统,使

写这篇博文的原因是因为自己写的代码经常会因为返工,delay项目的交付日期.总结了一下引起项目delay的原因,大概有如下几点: 在没有完全深熟悉需求交互细节的情况下:诸如根据不同渠道设置不同的订单状态变更--超时提醒和订单取消功能. 在没有想清楚自己代码如何实现业务逻辑的情况下:诸如对骑手排班--明天到当前周期结尾的排班及排班详情展示. 是否对业务逻辑有完整的测试用例:商家详情权限功能和可逆向加密算法的测试用例. 往往第一步和第二步是同时出现的,第二步的出现也在很大程度上源自于对需求交互细节的

这样Review代码牛逼啦! 一个对项目负责的团队代码质量检查是必不可少的,有条件的团队经常有代码review习惯,这样可以使技术团队共同进步,但是一个庞大的工程做代码review其实是很麻烦的,所以就催生了很多的工具,今天我们就来通过工具来对代码进行扫描,通过发现问题并改进问题,使我们的项目代码更简洁,修复隐藏bug. 什么是Sonarqube Sonarqube 是一个用于代码质量管理的开放平台.通过插件机制,Sonarqube 可以集成不同的测试工具,代码分析工具,以及持续集成工具. 在对

众所周知,代码审查是软件开发过程中十分重要的环节,楼主结合自己的实际工作经验,和大家分享一下在实际工作中代码审查是如何开展的, 笔者水平有限,若有错误和纰漏,还请大家指正. 代码审查的阻力 我想不通公司不同部门对代码审查这项工作的重视程度还是不一样的,对于代码审查的阻力总结了以下几点: 国内的整体环境,国内的公司,尤其是互联网公司,讲究速度致上,软件开发的迭代周期周期短,速度快,因为竞争太大,开发的产品要求快速上线,对代码审查不是很重视,先上线,出了问题再解决. 公司的规模,大公司重视流程,把代