敏捷个人-做好一个开发者

1,267 阅读6分钟

开发者定义

研发人员:是相对公司管理人员、职能人员、销售和市场人员来定义。前端、后台、设计、产品、移动端、数据库、大数据等都可以定义研发。国外称之为开发者,英文:Developer。

前端开发者:Front End Web Developer

后端开发者:Back End Web Developer

全栈开发者:Full Stack Developer

开发者和其他使用技术和手段的人员一样,也是手艺人。只是我们借助的工具是计算机,通过设计或者开发软件或App,服务客户和使用者。

作为一个开发者,最重要技能就是写代码,写文档,而这些恰恰是很多开发者不具备的能力。如果一个团队成员不敏捷,不高效,那么很难做到一个团队的敏捷和高效,管理稍微不善,团队就陷入泥潭。

左手-代码

1.需求不明确

作为一个开发者,从产品经理和客户经理那边得到需求之后,一定是先想清楚客户需要什么内容,当然大多数客户也不知道想要什么,可能是天马行空的想法,你们研发先做做看,我看哪个好用哪个?需求不明确,导致大量返工。

这个需求是客户要想看到云主机性能数据,包括实时和历史。前端实现2个tab简单,代码逻辑也用一份,里面判断一下是哪个tab,然后决定是否显示日历控件。实时默认5分钟,历史支持用户自己选择时间段。

通过分析需求,可以看到这2个tab可以合并为1个,因为除了时间段不一样,其他都是一样。默认时间控件选择5分钟,如果用户选择了其他时间就是历史。

大多数研发只知道接需求,做开发,具体客户想要什么,如何去实现更优化考虑的少。有时经常觉得我们不是开发功能,是在堆功能。

2.代码分支管理混乱

自从互联网和软件公司,从SVN切到Git做代码管理,开发和测试都觉得,公司档次瞬间提升了一些。我们能把代码管好,防止这个那个带来的代码问题。大家都想着去遵守Git流程最佳实践,如下图所示:

大家自己仓库里面用了master分支请举手?

大家仓库里面创建了hotfix分支并使用起来了,请举手?

Q:你们每次发布上线可以用master分支代码吗?

A:不可以,我们代码还在一个release1.x.x分支上。master分支是1年前的代码。

大多数部署和升级代码都无法从master分支拉去代码,而且有很多本地代码在开发者电脑里面。或者A提交了代码,B还没有获取,就开始构建镜像,然后去部署。

然后公司可能增加一个入库和出库操作,这个操作其实就是鸡肋,所有团队用这个里面镜像代码去升级,10次升级,有9.5次失败。我们是基于项目的产品迭代式开发,环境和依赖的内容实在太多。标准互联网公司,有一整套测试环境,开发环境,除了数据的多少之外,完全是一样的。

上一家公司做广告交易平台,涉及到广告展示和计费相关,所以他们升级都非常辛苦,但是速度很快,凌晨0点开始进行,大概2点就可以结束。得益于他们的开发、测试环境和生产环境一致,升级之前已经进行了充分的测试。当然现网有问题,也还是要遵循解决问题去修改代码或者配置。

能不能在现网修改代码?

我个人觉得互联网公司操作起来相对简单一些,完整的开发、测试、预发布和发布环境。对于软件公司,可能数据和底层组件的,比如和硬件相关的产品公司就相对不是那么简单。

1.如果是明显的错误,比如js报错,文案错误,样式出错,接口不通,那么这些都是研发和测试问题,这个可以加入业绩考核;

2.依赖现网环境和底层,开发和测试没有环境,这个就应该在升级就指出,需要现网调试。如果这个要改动代码,那么也是可以接受。发布和升级的目的是提供产品质量和增加新功能。

3.代码没有防御性编程

我写前端多,就以前端举例。

userService.getUserList().success(function(response){
        if(response.success){
            ctrl.userList = response.entity.list;
            //这样写可以吗?
            ctrl.selectedUser=ctrl.userList[0];
        }else{
            messageService.error("用户获取失败" + response.message);
        }
    }).error(function(error){
        console.log(error);
    });

大家很容易写出这个代码。开发和测试的时候大家都觉得没有问题,然后一上线,Javascript报错。请求后端返回数组为空,ctrl.userList[0]报错。

防御性写法:

if(ctrl.userList.lenghth>0){
    ctrl.selectedUser=ctrl.userList[0]
}

4.单词拼写错误

method写成metohd,singal写成signal,“块存储”写成“快存储”等。

右手-文档

1.不愿写文档

程序员最喜欢干的两件事: 1.不愿意写项目和代码文档

2.不愿意接收文档少的项目和代码

2.问题描述太笼统

需求创建了一个jira,标题 如下:

晚上升级因为这个需求在最开始没有详细讨论,导致晚上后台发现要注意如下这些问题。

3.文档归类混乱

接口文档写了,修改了不进行更新。同一个开发团队,有的人用domain,有的人用domainId,实际代表名称是安全域ID;有的用host,有的用hostName,实际代表时宿主机名称。

需求当时做好了,下次新人加入或者回归测试,开发功能的小伙伴和测试这块的小伙伴不在现场,全部人员蒙住了,不知道啥逻辑,找文档找不着,要翻1年前的邮件。

笨方法是在代码加一些注释,最起码看代码能看出来。

如何改进

1.代码改进

人:招聘、培训和绩效三方面提升研发本身人员的素质

流程自动化:机器能干的,就不要用人去干。比如前端增加ESLint,单元测试,E2E测试,后端单元测试,发布之前进行集成测试。每日构建

严格的线上和线下代码审查。迭代速度要放慢,一直催着加这个功能,修复那个地方bug,能集中时间写代码的时间就很少。

2.文档改进

好好利用现有的工具。

需求等重要信息分模块写入conf上。

接口文档统一存放Github或者内部其他有历史记录的系统上。有更新记得及时更新。

作为一个研发,关注和写好以下文档:

  1. 本次迭代功能清单。Jira列表,其实可以细分到更小的子任务。需求写
  2. 本次升级方案和测试用例。测试写
  3. 本次迭代内容。比如新增了哪些功能,修复了哪些bug。开发写
  4. 本次升级记录和遗留问题反馈。开发写
  5. 看好和理清需求文档。共同
  6. 写好接口文档。前后的研发

做好敏捷个人,才有敏捷团队。最重要:执行到位