作者：梧忌
“心流”是人在做一件事情时投入到忘我的一种精神状态，常见于运动员、艺术家和科研人员身上。
“心流”如何影响工作？我们可否解决“心流”带来的相关问题？
我在学生时代是个狂热的 NBA 球迷，家里总是堆满了篮球报，工作后我对篮球热情开始退去，直到斯蒂芬·库里的出现。
斯蒂芬·库里改变了篮球比赛的打法。他身高1.91米，在 NBA 中属于矮个子球员，但只要他进入比赛状态，他几乎可以毫不费力地在对方半场上的任何位置命中三分球。他打球的方式让人赏心悦目。
他不仅带领金州勇士队夺得了 NBA 的总冠军，而且还颠覆了所有 NBA 球员和球队的比赛风格 —— 他证明了不需要成为中锋的那样的大个子也能赢得比赛。斯蒂芬·库里之后，越来越多的球员和球队开始练习和多投三分球。
每个运动员都可以通过刻意地训练来找到自己的比赛状态，然后主宰比赛。
我们可以从斯蒂芬·库里身上学习到什么？“比赛状态”到底指的又是什么？
高效编码的秘诀：“心流”
20 世纪 70 年代，积极心理学领域的权威 Mihaly Csikszentmihalyi 定义了一种名为“心流”的状态，这在运动员、艺术家和科研人员身上可以经常看到。
Csikszentmihalyi 研究了是什么让人们感到快乐，他发现，人们在“心流”状态下最快乐。
大多数人都有过这样的经历：忽然抬起头，发现时间已经过去了很久，自己已经完成了一系列的工作。那种轻松富有成效的时间流逝和挥之不去的成就感，令人愉悦。
“心流”是高效编码的秘诀。但是要达到“心流”的状态并不容易，来看看阻碍我们进入“心流”状态的几个问题。
影响编码心流的问题
▐ 外界的干扰
| 图片来源：截取自《社交网络》电影
这是一个重大而又经常出现的情况：突然的外界干扰，会破坏我在编码时的思绪，打乱我正在大脑中加载的逻辑。例如，我会被钉钉或其他应用程序的消息干扰，又或者是到身边来问问题的同事干扰。相信每个开发者都曾经遇到过这样的场景：
| 图片来源：THIS IS WHY YOU SHOULDN'T INTERRUPT A PROGRAMMER
▐ 外界的干扰
会议是影响“心流”的另一个明显的问题，但可能大家没有注意到的是它们在会议时间之外的其他影响，如图所示：
| 图片来源："Anyone who ever schedules meetings with developers, please burn this image into your brain, thanks"
通常在开会之前，我知道很快就要进入到会议当中，因此会中断掉编码，然后准备会议的头脑状态。会议结束后，还需要时间来消化内容、让自己恢复到正常的脑力状态。
因此，Facebook 的 “周三不开会” 倡议受到工程师们的普遍欢迎，大家都认为这将有助于提升开发人员的生产力。
但是我们是只关心一周中一天的编码时间吗？有没有想过，在标准工作时间，会议频繁的时候，我们真正输出了多少代码？
▐ 人的思维惯性
技术正在飞速发展，总有很多的东西需要研究和学习。我经常思考如何平衡花在学习和编码上的时间。
保持专注并不容易，需要克服种种的思维惯性。我经常陷入到这种拖延的惯性当中：看会儿某乎再开始吧，还可以顺便检查一下邮件......午饭后再开始写吧，毕竟还有半小时就到午饭时间了……
有时候“心流”的敌人就是自己。
需要意志力和纪律才能将全部工作分解为小的、可操作的工作单元，然后才可以开始编码。
解决这些问题的对策
▐ 设定编码时间
理解“心流”之后，关键是找到自己的「心流时刻」。可以借助在编辑器上的行为来捕获和分析编程活动的轨迹得出来。
如果去跟踪我们的编码活动，例如键盘输入、添加的字符和删除的字符，然后就可以在几天或几周后得出一定的规律。有了足够的数据，就可以构建一个热图来查看开发者通常在何时高频输出。这个可能就是你的「编码心流时刻」。
| 图上的蓝色点颜色越深，代表在此时刻早键盘的输入越多。
然后，你就可以开始通过工作日历来设定自己的编码时间。开会、写代码、阅读，它们需要的状态和脑力是完全不同的，可以自己的情况来计划哪个时间段来执行这些任务。
将这些时间规划设置到你的工作软件（钉钉）上，让它们在这些时间段进入到免打扰模式，不再有应用程序的消息提示窗口，同时它还在提醒你的同事避免在这些时间段约你开会等等。
▐ 持续完善文档
会议往往是异步沟通无效的体现。另外，根据 Stack Overflow 的调研报告，几乎一半的开发者表示他们在遇到问题时会打电话给同事。为了减少会议和答疑，一个建议是持续地更新和完善文档：更好的文档可以帮助你更快地回答同事的问题，并减少被打扰的可能性。
你知道自己在写文档上的投入如何吗？或许看看你在编辑器上对文本文件的编辑时间投入可以得出一些结论。
▐ 高效会议并回顾
更有效的会议可以避免更多的会议。
明确会议主持，制定会议议程，做好会议记录，产出会议结论 —— 这些都是高效会议的一些措施。
另外，有必要考虑一下你是否真的需要参加这个会议。斯坦福大学的研究表明，当会议的参与者只有 5 ~ 8 人时，效率最高。还有 Atlassian 的一篇文章说，近 40% 的员工会在会议期间昏昏欲睡。。。
最后，结合工作日历和编码热图，可以构建会议与编码时间的关系图。可以看看你到底是花了更多时间在开会还是在编码？会议时间的增加是怎么影响编码时间的？
▐ 克服思维惯性
每个人都需要一些动力来克服行为和思维惯性。可以问一下你自己：每天在八卦群上闲聊的花费了多少时间？是不是经常走神拿起手机刷朋友圈、短视频？如果可以记录并绘制你的编程活动图，那么：
-
你可以很快地看到你最近一天或一周的编码投入是否高于或低于自己的平均值。
-
你可以看到你每个时刻的编码输出情况，想想那些数据断层是因为你在思考还是走神了？
与自己对比来找到最好的自己，关注你的编码数据和设定目标可以提高自己的纪律性和产出。
Time Master
这就是为什么 AppWorks 打造 Time Master 的原因。软件正在改变世界，数字化正在影响着我们生活的方方面面，关于我们如何开发软件的数据也很重要。
Time Master 记录和可视化开发者的编程数据，帮助开发者发现并找到“心流”状态，实现高效编码。
这一切，完全是自动的。你只需要在你的 VS Code 上安装该插件即可：
然后你在编辑器端，就可以看到你的编程活动统计数据：
在阿里内网的线上站点，可以看到编程活动的趋势和分析：
| 仅为功能示意，部分图表仍在设计或开发中。
除了帮助开发者进入“心流”状态，Time Master 还有更多的想象空间和其他意义。
▐ 越早编码越好？
Joel Spolsky，Trello 和 Stack Overflow 的创始人在他的博客中说道：
Sometimes I just can't get anything done.
Sure, I come into the office, putter around, check my email every ten seconds, read the web, even do a few brainless tasks like paying the American Express bill. But getting back into the flow of writing code just doesn't happen.
Spolsky 分享了一个简单的见解：“「立刻开始做」也许是提升生产力的关键”。
数据可以为生产力的提升提供强大的推动力。为了克服早上的惯性，我们可以做的，最简单的事情之一就是跟踪我们每天开始编码的时间：
| Time Master 可以从开发者的编辑器中自动地跟踪编码开始时间。
-
为什么要跟踪编码开始时间？
开始编码的时间越早，当天编码的时间可能就越多；）越晚开始，查看电子邮件或社交媒体的次数越多，需要克服的惯性就越大。
你上班的第一件事是编码，还是浪费在查看社交媒体和电子邮件上？一个建议是：应该将工作的第一个小时花在高价值的事情上。
-
Code First
Code First 是开发人员或团队用来提高生产力的一种工作指导原则。
-
Code First 意味着要快速原型制作以了解其工作模式而不是进行宽泛的研究和计划。
-
Code First 意味着尽可能地进行编码以进入”心流时刻“，意味着将编码时间置于会议和其他时间之前，优先满足对编码时间的要求。
-
Code First 与代码质量并不矛盾，可以与对单元测试和严格的代码审查相结合。
一旦可以查看多天和一周中特定某天的编码开始时间，开发者就可以设定目标以提高其一致性并践行 Code First。
▐ 代码重构率
开发者编写代码，然后重构一些代码，然后再重构一些代码。
就好像我写的这篇文章，我会先写一个版本，然后再次阅读，优化一些语句，添加或删除一些段落；最后我再检查一遍，修正一些错别字。最终我将产出一个经过审核的、质量更高的版本。
代码重构的情况与之类似。首先必须了解：代码重构是很正常的，或者说在研发过程中是健康的，这里讲的“重构”并不是推翻过去的一切。
问题是我们可以从跟踪代码重构中学到什么吗？—— 分析代码重构的过程或许可以帮助我们更好地进行编码。
-
代码重构率的定义
代码重构率是指在编写的代码总量（总代码）中被重写的代码量的占有率。
总代码可以分为三类：添加的字符、删除的字符和粘贴的字符。总代码可以通过按键和字符，数据的最小原子单位来计算，也可以使用代码行数来计算，这因编码风格、文本编辑器而异。
-
代码重构的原因
代码重构有被动的原因，例如：市场发生了变化，导致产品需要更新；产品经理更新了需求；我们发现架构或设计中存在严重缺陷；又或者我们在代码中发现需要修复的错误。
当然也有主动的原因。优秀的开发者通常会快速产出原型，以了解正在创作的软件的知识范畴以便学习，这也是践行 Code First 工作原则的一种体现。
在开源技术被广泛应用的今天，丰富的示例可以帮助开发者快速开始某项编码工作，开发者经常需要集成和粘贴代码，然后在集成的过程中删除一些代码 —— 这也是代码重构的一种原因。
此外当我们改进代码时，例如消除冗余、提升性能或提高可读性，也会进行代码重构。
总结一下：
-
好的代码重构原因：学习、集成、优化；
-
差的代码重构原因：市场变化、需求变化、架构或设计问题、代码缺陷；
代码重构的成本随着时间的推移而变化。在修复缺陷时，随着软件开发生命周期的进展，成本会急剧上升。在生产阶段修复错误的成本可能比在设计中修复它的成本高 100 倍。
| 图片来源：IBM 系统科学研究所
最早且修复成本最低的代码重构分析是在提交到 Git 仓库之前，即在 IDE 中进行的代码重构。这就是为什么我们需要追踪编程活动的原因之一。
-
在代码重构中学习
查看代码重构相关的数据可以挖掘程序或产品的大量信息。例如，软件开发生命周期后期的高代码重构率可能表明存在质量和生产力问题。此外，如果将代码库中所有文件的代码变动可视化，还可以了解开发工作都花在了哪里。
了解自己代码重构率，与团队成员对比，可以让你看看自己的工作方式是否有改进的空间。
▐ 工作与生活的平衡
工作与生活的平衡一种健康的身心状态，两者的平衡可能跟我们在其中投入的时间有关。改善工作与生活的平衡可以提高幸福感和生产力，同时防止过度疲劳。
Time Master 采集了我们的编码数据，因此可以了解到我们在工作时间和工作时间之外的编码时间，帮助我们了解工作与生活的平衡情况。将编码热图和工作日历结合，还可以查看会议时间和变是如何影响编码时间的，从而合理安排你的日程来改善工作与生活的平衡。
例如可以通过几个维度来看工作生活的平衡：在工作时间段内进行的编码时间的百分比、工作时间段内的编码时间变化趋势、又或者跟自己过往的数据或者同事的数据进行对比。上面的示例图表是按照按星期几来显示的，跟同期数据对比会更有意义，还可以深入了解开发者在周末编码投入。
