提升研发效率和体验，更爽的工作

Posted 2020-11-27 tuochao

　　相信有很多人和我一样，在日常工作中会碰到各种各样让人抓狂的事，但是生活还得继续，虽然有很多事我们改变不了，比如公司规定，团队成员，工作环境等等，但幸好还有些事我们能改变，比如我们自己。一直都想写一篇关于如何改进个人和团队的工作细节，以便提高工作效率的文章，刚好最近在极客时间上听了葛俊老师的课程《研发效率破局之道》，找到了很多共鸣，也受到了很多启发，结合自己的实践一并分享出来。

　　我不会在这篇文章中聊团队管理，敏捷实践之类高深的话题，只是会聊一些简单又实用的方法和工具，但是相信我，这些方法和工具能够让研发效率和体验变得更好，让工作起来感觉更爽。我会从公司和个人两个角度分享自己的经历，再聊聊如何改进，首先是吐槽篇。

　　吐槽公司篇：

　　每个公司和团队都有自己的环境和文化，也会有相应的规定和流程，但是很多时候这些东西让工程师们很是抓狂，感觉像是戴着脚镣在跳舞。相信以下这些场景你一定不会陌生：

　　1. 公司电脑不能上外网，或者有着严格的访问限制，目的是为了防止程序员们在上网时间逛淘宝。当你想查一个Linux命令的用法或者一个Java类库时，只能在自己手机上找，然后再一行一行的把代码敲在电脑上，一不小心还有一堆的拼写错误。

　　2. 但是很不幸，公司的人事部门或者其他的什么部门会在上班时间内到处转悠，当发现你在工作时间看手机时给你的领导打了小报告，于是你被在部门内点名批评。

　　3. 代码库或者某些系统有着严格的权限控制，当想访问时被告知没有权限，申请权限需要N个boss级的人同意，走一个繁琐的流程。或者身为测试人员，想看看代码时被告知测试人员没有代码仓库的权限，理由是测试人员不需要了解代码。

　　4. 环境由专人管理，数据库不能访问，CI由专门的团队配置维护，理由是为了系统安全，怕被弄出问题。身为开发或者测试工程师需要更改配置，查询数据时却无权限去做，只能去找对应的人或团队，哪怕只是一个很简单的更改。

　　5. 公司的技术栈陈旧，又不允许团队自己选择，必须按照公司规范，例如要用maven而不是gradle，用SVN而不是Git，再比如明明环境构建和配置让团队异常痛苦，你知道Docker可以帮忙，却受限于公司约束无法使用。

　　吐槽个人篇：

　　吐槽完了公司，接下来是个人，我也遇到过一些让人很捉急的同事，每天都是忙忙碌碌，然而看TA工作总是让人忍不住想说“放着我来”，具体有以下这些表现（如有雷同纯属巧合，我真的不是在针对谁）

　　1. 习惯于用鼠标操作：我是做软件测试的，对这一点感触最深。没错，手工测试很多时候就是在界面上点点点，但是这不意味着键盘就只能用来打字。合理的使用各种快捷键可以极大的提高工作效率，而在键盘和鼠标之间频繁的换手更是极其浪费时间和体力（没错，就是体力，反正频繁的换手一天下来我的胳膊会很困）。当我看到有些人用鼠标点右键去复制粘贴，用鼠标在不同的窗口间频繁切换时，真的是无言以对。当然，如果你在需要写代码的时候还重度习惯于鼠标操作，那体验就更糟糕了，也许这也是很多测试同学不喜欢写代码的原因之一。。。

　　2. 习惯于在界面操作：这也是很多测试同学的通病，习惯了所有东西都是以可视化的形式显示，再加上软件测试中的“黑盒测试”的思想，对于命令行，日志，消息体，数据表等等不是以普通用户容易接受的形式而显示的东西，本能的有畏惧或者排斥心理，更不愿意以这些方式来工作，即使这样比从界面上操作要简单高效的多。

　　3. 重复的行为：每个人工作中都会有很多需要重复去干的事，也许每天都要做，也许一天要做很多遍，例如登录系统，访问某个网页，在文件中查找某些内容再复制粘贴到某处，在命令行中执行一堆的命令等等，很多人每天就重复干着这些事，却没想过有没有什么办法能让自己解脱出来。别忘了，我们是软件工程师，擅长干重复的事的是机器，而不是人，人的时间和精力应该去干机器干不了的事，不然和面前这个金属家伙有什么区别？

　　4. 工作不停被打断，时间碎片化：相信有过类似经历的人都有这种感受，在不同的事之间频繁切换是件很累的事，并不能提高多少工作效率，而且有时候还会造成挫败感，忙了一天发现没有一件事能够完成。有时候是由于工作环境的原因，经常会有人或者事来打断，但是作为个人我们还是需要控制和计划自己的工作任务，避免不停的切换上下文，对于知识工作者这点尤为重要。

　　5. 重度依赖他人：对不起，我又忍不住想吐槽下测试同学，很多测试同学一遇到问题第一反应就是找开发。如果环境安装，数据配置，问题分析等等这些工作自己都搞不定的话，那么工作效率就不可能高，因为你要不停的依赖他人来帮忙完成这些事，即使别人都愿意提供帮助，那也需要依赖别人的工作时间和任务优先级。没错，软件项目是团队性的工作，但是每个团队是不是都有一两位大牛级别的人物，总是能独当一面，所有的问题都能搞定？即使从个人角度出发，尽量少的依赖他人也能够提高工作效率，早点下班。　　

　　个人改进篇:

　　吐槽不是目的，如何改进才是目的，工作环境和团队有很多因素我们无法改变，那么先看看作为个人我们能做些什么：

　　1. 有一个好用的机械键盘

　　这是我的第一个建议，如果你现在还没有，那么马上去网上买一个。不用太贵，但是最起码要能够自定义键位，注意别买那些敲起来五颜六色的游戏键盘。。。一个机械键盘是使用各种快捷操作的基础，良好的手感能够让你喜欢上键盘操作，有助于摆脱鼠标依赖症，同时也能有效的提升自己的专业形象：）

　　2. 尽量多的使用快捷键

　　同样的操作，用快捷键要比鼠标高效的多，流畅的多，也更加酷。刚开始可能会不习惯，需要熟悉和记忆，当熟练了以后会大幅度提升工作效率和体验。具体多少操作用快捷键去完成因人而异，看看自己平时最经常使用的有哪些操作，再去查查相关的快捷键是什么。就我自己而言，主要的场景有以下三种：

• 操作系统：常用的有复制粘贴，切换屏幕，查找文件或内容，打开或者关闭某个程序，滚动屏幕，切换焦点，更改输入法等，其实并不多，花点时间去熟悉练习一下，很快就能掌握。这一点上Mac系统要比windows系统方便，很多快捷键都能自定义修改，不过window系统也可以使用AutoHotKey这样的工具来修改。葛俊老师在研发效率破局之道》中提到，对于程序员最有帮助的改键就是把大写锁定键CapsLock改成Ctrl键，大家可以试试，效果很好；
• 浏览器：由于我工作的产品主要是Web程序，在浏览器上的工作时间占了很大的比例，即使不是做Web程序的，相信也少不了使用浏览器。我是Chrome的铁杆粉，Chrome的快捷键功能非常强大，常用的有打开/关闭页签，打开/关闭窗口，切换页签，切换窗口，刷新，滚屏，快捷输入地址，快捷跳转链接，查找关键字，打开历史纪录，前进/后退等等，在网上都可以查到。熟练了以后基本上除了click，是不用再动鼠标了。你如果还觉得不过瘾，还可以在Chrome上安装extension，为所有按钮链接生成快捷键，彻底的摆脱鼠标；
• 开发工具：目前主流的有两种，IntelliJ IDEA和Eclipse，开发工具是快捷键最重要，最有价值的场景，正如我之前说的，你能想象在用键盘写代码的同时，用鼠标去做选取内容，复制粘贴，滚屏，切换文件，查看函数定义，执行测试等等操作吗？那么你的手将会在鼠标和键盘间不停的切换。。。IntelliJ IDEA和Eclipse都有着非常强大的快捷键命令，而且可以自己定义和修改，完全可以配置出一个适合自己的开发环境。我觉得基本要求是完全放弃鼠标，用键盘完成所有的操作，如果刚开始比较难，可以强迫自己写代码时把鼠标拔掉，如果某些操作无法完成，就去查询相应的快捷键是什么。相信我，痛苦只是暂时的，带来的收益是巨大的。

　　3. 多用命令

　　这一点在葛俊老师的课程《研发效率破局之道》中也提到过，同样的操作，用命令行执行比用界面操作要快捷高效的多。类似的方法可以拓展到更大的领域，如果用一个API调用，一行SQL命令能完成的，那就尽量少用界面操作。当然，前提是你需要熟悉API的消息体格式或者是数据库的表结构。这样不仅操作更高效，而且可以更深入的了解系统，还能提升自己的技术能力，多用命令操作也是后续将重复工作自动化的基础。

　　4. 自动化重复的工作

　　类似的观点我在另一篇博客《打造高效率的软件测试》中也提到过，留意一下自己平时有哪些重复的工作，占用了多少时间，然后想办法尽可能的去优化它。可以只是很小的事情，例如打开指定的文件，访问指定的链接，集成几个常用的命令等等。

　　在实现方面，系统级别的操作可以用Shell（Linux或者Mac OS系统）或者Windows Bat脚本，浏览器上的操作当然是javascript了，Chrome浏览器上还有自动化的工具puppeteer（https://github.com/puppeteer/puppeteer）。比如我现在经常需要在不同的系统之间来回登录，每次都要输入URL，用户名和密码，非常烦人。于是我把登录信息都存在一个文件里，写脚本去根据环境信息读取登录信息，自动启动浏览器完成登录操作，每次只需要在命令行中执行脚本。再复杂一些的场景可以用python之类的脚本语言，足以满足日常工作的需要。

　　5. 合理的任务管理，专注于当前任务

　　任务管理和时间管理是个大话题，我也不是专家，在这里我只想分享几个简单易行的方法：

• 用看板来管理日常任务和优先级：即使团队没有使用看板系统，自己也应该维护一个个人的看板系统，在看板上可以清晰的看到自己有多少待办项，优先级如何，分别是什么进展，避免出现遗漏和混乱。将任务完成后拖走可以产生成就感，也方便以后进行回顾和追踪。看板的理论和使用方法有很多相关的书籍，Trello是个不错的看板工具，但是在外网，国内的网站中leangoo（https://www.leangoo.com/）用起来还不错。
• 专注于当前任务，尽量把一件事做完再任务。有心理学的理论，如果一件事没做完就做另一件事，那么之前那件事并不会彻底消失，在潜意识中仍然在分散人的精力，时不时的会对当前任务产生干扰。相信大家也有过这种体验，在一件事没有结果前切换到别的任务，有时会不自觉的想到之前的事。所以尽量把当前任务完成，或者有一个阶段性的进展后再切换上下文
• 使用番茄工作法，时间盒等方法：当然，在实际的工作中会有很多干扰和制约，例如现在正在做的事依赖于别的人或团队，需要等待。或者遇到了困难一时无法继续，同时又有优先级更高的工作。这时候可以尝试使用番茄工作法，使自己在某段时间内专注于一个任务，或者给自己设定一个time box，如果半个小时内有进展则继续，否则切换到别的任务。和看板系统配合使用，可以有效的缓解工作头绪众多，时间碎片化的问题

　　6.  DRY(don‘t repeat yourself)

　　DRY本来是代码设计中的一个术语，意思是尽可能避免重复代码，把重复的代码和逻辑进行封装。但是同样的思想可以扩展到更大的领域，尽量避免重复犯同样的错误，做重复的劳动，重复问别人同样的问题等等。如果你发现自己的工作中有些事总是要依赖别人，那么想办法自己学会掌握它，如果有些问题总是要去询问别人，那么花点时间弄懂它并记录下来，像印象笔记，博客等都是很好的知识记录工具，再不济在自己电脑上写个word文档总可以吧。且不说提升自己的能力，单从提高工作效率的角度也是很有帮助的。试想一下，你工作中需要依赖别人帮忙，如果他很忙，一个小时后才有空，那么你就得等他一个小时，也许还得和他一起加班。如果自己能搞定，是不是就可以省去这一个小时，早早下班了呢？

　　团队改进篇：

　　我知道想改变一个团队的规则和文化很难，尤其是当不是管理职位时。但是如果运气好，碰到了一个开放的领导或者团队环境，或者自己做到了管理者，那么以下这些建议一定会有帮助的：

　　1. 相信并尊重工程师们

　　不要限制他们的权限，比如禁止上外网，更不要搞什么上班时间是否有人不务正业玩手机之类幼稚可笑的检查。我们是知识工作者，不是小学生，这些东西对于提高工作效率和产出没有任何帮助，只会让工程师们反感厌烦，扼杀他们的创造力，破坏团队氛围。软件研发是一项高度复杂的脑力劳动，不是靠工作时间和强度堆出来的。只要能高质量完成了工作任务，在网上闲逛又有什么关系，只要他没有影响别人的工作。管理者应该考虑的是给他的工作是不是太没有挑战了，配不上他的能力。如果他没有完成工作任务，那是这个员工缺乏基本的职业素养，让他走人就好了，同时应该反思为什么会招聘来这种员工。而且限制访问外网会极大影响工程师们对于信息的获取，就像我之前举的例子，当要查询一个命令都做不到时，如何能高效率的工作。我曾经工作过的一个公司，对于网络访问没有任何限制，任何网站都可以访问，但是丝毫没有因为这个影响工作，相反，在这个公司的工作效率是我待过的公司里最高的。

　　2. 给予工程师们信息和权限

　　在葛俊老师的课程中也提到了这一点，类似的还有“不要阻塞开发”。和第一点类似，但主要是针对公司内部的系统和访问权限。当然，对于生产环境的数据库，服务器等相关系统限制权限是必要的，但是事实上很多限制是没有必要的，例如代码库，CI，文档，测试环境等等。这样只会让工程师们感觉处处被束缚，很简单的事情都要花费很多不必要的时间和精力。

　　3. 让团队自己选择技术栈

　　没有最好的技术栈，只有最合适的，这就像争论php是不是世界上最好的编程语言一样。而什么样的技术栈最合适，从事研发工作的团队最有发言权。每个公司会有自己的偏好，或者从代码安全，知识产权等角度做一些限制，但是在允许的范围内，应该尽可能的把决定权交给团队，交给那些整天写代码的工程师们。用行政手段，统一规范之类研发之外的因素来影响团队的技术方案选型毫无必要，也很不科学。

　　4. 不要搞一些奇奇怪怪的度量指标，并以此评判团队和个人的绩效

　　这一点在葛俊老师的课程中有详细的阐述，在我的工作经历中也深有感触。相信大家都对单元测试覆盖率，测试用例执行率，自动化测试比率，bug数量等度量指标深恶痛绝。我并不是说这些度量指标没用，而是它们都有自己的适用范围和适用条件，在不了解其真正含义和当前项目具体情况下生搬硬套的使用，只会适得其反，而且它们只能反映软件开发工作中很少的一部分情况。比如一个产品测试阶段bug很少，它是质量好呢还是不好呢？也许是真的质量好，也许是测试团队能力不够，没发现bug，等到上线以后一堆的bug。即使它真的质量好，没有功能bug，但是上线以后和用户群体的需求不符，用户不买账，使用人数很少，那这个产品的质量是好还是不好呢？

　　软件开发是一项高度复杂的系统化工程，有些没有技术背景的管理者仅仅凭借简单的几项指标，就想获得整个项目的工作状态，那是不可能的，甚至是荒谬的。如果再以这些指标为依据来评判团队或者个人的表现和绩效，那一定会弄得怨声载道，接下来就是员工离职。而且说真的，这些指标很容易造假，我们都懂的，毕竟像

　　Assert.assertTrue(true);

这样的代码我们都写过的，对吧？如果想了解如何科学有效的使用度量指标，可以去极客时间上听听葛俊老师的课程。

　　本来想尽可能的简单一些，但是一不小心就写了这么多，感谢你还能有耐心看到这。希望聊到的这些内容能有帮助，我们都能持续提升，向10X程序员努力。