程序员如何提高开发团队的协做效率和质量?

单兵做战只能胜任分发到本身的模块,团队协做才能让产品快速而高质量上线.

有正必有反

想要提高团队协做的效率,先分析哪些事物阻碍了开发进度.

通常状况下,项目预估的时间相对的紧凑,若是发挥正常,则上线时间不会相差太远,中途有什么变化,也会根据反馈实时调整进度.

但有时候,代码可以稳定的发挥其固定的做用,人就不必定了,不一样的行为会致使差异极大的影响.

负面做用

全局干扰

最近的一个项目中,进入到提测阶段的时候,一些新版的功能都已经经过第一轮测试.

可是在代码没有改动的状况下,测试突然提出了一堆的bug,一些之前的功能部分都不能正常使用了.

请注意,一旦遇到相似的状况,几乎没有改动主要功能代码的前提下,突然发生大面积的bug,于前端而言,不是后台挂了,就是某个兼容性问题,特定手机机型或者系统版本等.

还有一种不该该发生的错误,就是团队的其余分支代码影响到整个项目的全局,从而致使你的功能异常,如css样式覆盖,js变量覆盖等操做.

如今回顾一下,当时个人操做是先排查功能异常的缘由,发现是vuex和vue-router传参parmas失效,可是为何莫名失效,google了很久,定位到怀疑人生.

因为以前已经有过协做致使错误相似的经验,加上对本身代码机制还残留一点点信心(技术的熟练度决定排查问题的思惟和方式),转而开始查看gitlab的日志记录

在查看同事的日志中,发现一段才提交不久的代码,这段代码的定义就是在全局路由作了一些操做.

在这里,我也犯了一个错误,看到对方的注释写的是仅在第一次登陆xxx,而后就没有往下看代码的做用了,而后又开始怀疑人生.

当时间耗时超过半小时后,就应该想办法解决当下没法解决的问题,和同事交流或者稍稍放松,换个思惟方式等,当排查超过一个小时,因而去问了同事.

同事说前不久是在ios上进行了全局操做,由于须要开发一个新功能,因此在ios上每次页面切换时,把vuex和vue-router传参parmas给重置了.

在这里,先不提排查和定位问题的能力,只能提醒在座的各位,若是明知道本身的代码会对全局有着影响甚至是颠覆的做用,请必定要在群里声明,或者至少和同事口头声明.

固然,尽量不要产生对全局不可控的代码,没有谁能保证本身的代码不会对之前的功能或者同事的模块形成影响,解耦是一种能力,声明是一种态度,也是协做的方式.

tips:

有一些团队会进行codeReview,一个是提交时review,一个是提交后review.

不论哪种,都是对代码的质量负责,像上述这种错误,若是进行了review,在发布测试前就会被发现和拦截,这种错误不该当出现.

团队没有review的流程,也不要紧,大多数时候不要养成别人定了规则才会去执行的习惯,必定要有本身的独立思惟,要有本身的优秀习惯,团队没有,可是不妨碍本身按期的review.

前几期讲了提高效率的方法和技巧还能够加上一条,加班时或者按期review,及时看看本身的代码和同事的代码,查漏补缺.

协做时间

前一段时间,测试在没有任何告知的状况下,周六加班冒烟测试,先后端的都不加班,也不知道要测试.

因而产生了几个严重的影响,一样也是人为的不应犯的问题.

一是因为没有邮件或者群里正式声明周六提测,致使前端没有发布最新的测试版本,周六测试的是上上个不知道何时打包的版本.

这种状况几乎能够说测试是白测了,所幸测试的版本刚好功能上都符合,只有一些样式没有跟上进度,因此没有形成极大的时间浪费,影响不大.

二是正常工做期间,先后端每次发版的时候,不多有人会主动在群里提起或者正式邮件声明(虽然有时候不须要太正式)

致使测试测着侧着就提示网络错误,或者用旧的标准在测试新的代码(如突然改一个新需求和ui,可是测试不知道),致使提出bug或者被中断测试流程(以下单)

其实在发版前群里告知一下是基本的沟通义务,也是最起码的工做态度,就效率而言,能避免不少不该该出现的问题,仅仅是一句话的事情.

其次,与人方便也是为本身方便,发版时也能够注明当前版本,发布内容(更新了哪些功能等),以及一些其余说明,让事物有据可查,有别人更容易理解.

可是在好几家公司发现,不管是刚入职的小白,仍是混久的老油条,都不会去过多的关注一些团队和沟通的细节,或者说懒得操做,宁愿过后甩锅也不肯事前留心.

tips:

国内没有倾向于使用邮件的习惯,即便是重度有工做属性的职场.

若是不强制要求,别说邮件了,连聊天软件都懒得回复,如非须要,甚至口头内容都不会有.

建议你们多使用邮件,最少也应该使用有聊天记录的群或者沟通工具.

其实说到底,首先是一个工做态度的问题,愿不肯意协做和配合,其次才是工具的使用.

其次,要注意的事,最好的工做时间是全员都在的时候,有问题必定要及时处理.

不可能等到别人下班再去解决,这样也解决不了,事情要分轻重疾缓.(很重要,思惟方式)

建议上班的时候解决要和人协做的问题,我的不太紧急和重要的问题能够留到临近下班或者加班或者解决合做问题以后.

权限问题

测试的过程经常须要反复去操做一个流程.

可是一个流程每每操做后就固定了数据状态,再次操做不可能再建立一个帐户或者每次叫后台清空数据(仅前端).

虽然假数据也能够,可是有些逻辑仍然须要真实的反馈,如登陆,短信验证,身份识别,提交订单等等等.

通常开发,有本地环境,测试环境,正式环境,至少在本地环境和测试环境,数据是能够临时操做的.

若是有管理后台建议获取操做测试环境后台面板,针对本身开发的模块作一些流程设定操做,如更改用户状态等.

若是没有管理后台,使用sql等直接操做数据库也行(前提是要会一点点数据库和对表结构了解~具体能够问后端)

前提是避免一个功能测试须要不少遍,但每次都要找别人来重置数据,别人也可能一直在忙,没有时间帮忙或者留意到你的须要.

其次是,直接操做数据库是一个很大权限的事物,哪怕只是本地环境,必定要尽量避免产生脏数据,影响其余流程.

有的时候须要去复现一个bug,必须走完一些流程,操做繁琐且很难定位,经过后台和修改数据库会快不少.

总的来讲,就是测试有的权限,你尽可能也要有,如管理后台,数据库等,没有,就只能让相关模块的人尽可能配合.

避免有时间可是流程卡住没法操做的状况,这种现象是真正的极大浪费时间,并且一废就是大半天.

tips:

固然还会有一些其余权限,如代码合并的权限,发布测试和线上的权限.

这就涉及到技术和态度意外的因素,要留心那些你有时间有技术可是你没法操做的事物.

正面做用

正面的方法能够简单归纳为

• 分工合理,责任明确,模块化
• 高效的沟通机制(聊天软件,任务面板,邮件等)
• 按期检查,及时调整(codeReview,日报,周报,大小会议)

比起正面做用,更倾向于排除负面做用,哪怕正面做用不大,但至少不会影响效率和进度.

要知道吖,大大小小的公司,其实最混乱的,最致命的,也最为核心的.

历来不是技术和能力,而是团队管理和协做,是人与人之间的沟通和行为.

tips:

正面做用下一期文章再细说.