区块链神吐槽这篇文章会介绍一些远程工作相关的经验，希望能够让你更快适应远程工作的节奏。
个人篇，工作状态。
定好下班闹钟
这是多年前我刚开始远程工作的时候，得到的第一个建议。一开始还是很莫名其妙的，因为当时担心更多的是自己的积极性会不如在办公室里面时高，所以对上班闹钟的关注度要远高于下班的闹钟。但是多年远程工作之后我明白了这个建议的原因，其实也并不是需要一个字面意义上的闹钟，而是在远程工作的情况下，需要让你的生活和工作分开。
如果工作和生活没办法很好分开的话，会带来一个问题就是会把正常属于生活的时间都给放到工作里面，然后平时正常工作时又不在乎高效去利用时间。远程工作的状态保持，更多是通过自己利用定下来的目标掌握自己的工作状态。
很多时候可能会有个误区，就是远程工作意味着自己可以完全随意地安排时间和地点，想工作就工作，不想就算了，但是事实远非如此。
最大的问题在于，如果时间是随意的话，很多时候定下来的目标是完成不了的，于是通常会变成到deadline 之前再赶进度。想象这样一个场景，白天有个任务要完成，然后由于没有分开工作和生活，你会觉得晚上还有很多时间可以来完成这个任务；
然后等到晚上真的集中精神在解决问题的时候，又发现问题没那么简单需要多花一些时间，然后就开始熬夜解决问题；再到第二天就会由于前一天熬夜太晚了于是起不来（或者起来了也精神不好），长此以往不但工作质量得不到保证，而且连自己的正常生活也被干扰了。
本来晚上和周末应该或是和家人朋友聚会，或者自己消遣放松的时间，一个人不可能长时间保持高强度的工作状态，合适的安排好工作和生活的平衡，会让你的工作更有效率。
所以，如果不想正常生活被工作弄得一团糟的话，给自己定下一个 schedule，然后基本照着这个schedule 来进行工作，是非常有必要的。
再者，由于现代的社会分工，一个人的工作肯定也会涉及和团队其他人的沟通，如果没有大致的schedule，在线的时间变得捉摸不定，那么同事都不知道什么时候能找到你，也会影响其他人的效率。
Schedule 可以有一定弹性，而且也不要求所有人的时间都保持一致，但是至少是需要留一些和其他人 overlap 的空间方便沟通。
和在办公室一样
远程工作有很多好处，最直接的好处是通勤时间的减少，让你可以节省到办公室的这段时间，无论这点时间你是用来工作还是其他，对比大城市来说，都能让你每天赚多至少一个小时的自我安排的时间。另外你还可以不在乎自己的着装和形象（比如有段时间我就想给自己理光头）。
但是除此之外，其他方面的工作状态，应该是基本上和在办公室里面一样的。也就是说，你其实应该会和像坐在一间虚拟的办公室里一样，排除大部分外在的干扰因素。如果前面一段说的是时间上的固定，那么这一段说的应该算是空间上的固定。
所以，请在你家里安排出一个固定的地方作为办公场所，至少保证在你工作的时间以内，这个地方能够让你排除外界的干扰高效的完成任务。
如果工作累了中途想休息，那么和在办公室里一样，你应该离开你的工作位置，去喝个水/茶/咖啡适当地休息一下，或者去适合休息的地方发发呆。而不是每天都随意地找个地方，拿起电脑工作，放下电脑就休息，同样的，这样做也不利于你有效的分开工作和生活。
有些人可能一开始并不能够太适应家里的环境，因为能使你分心的东西会有点多。那么有个建议是你可以穿戴整齐，给自己点仪式感，走到自己的工位上开始一天的工作，当一天工作结束之后，换上休闲的服装告诉自己今天的工作已完成，是休息的时候了。
当然远程工作也没有要求你一定得呆在家里，你可以去花园、公园、咖啡厅、茶馆、海边，或者任何一个能够保证有良好网络连接的地点（但不建议经常改变，因为可能不好保证精神的集中）。但是总的宗旨是不变的，给自己找一个相对固定的空间，让自己在那个空间里可以高效进行工作，避免自己进入一个散漫的状态，尤其应该避免上面说到的太过随意的情况。
弹性休息
虽然上面说了一些规矩，也给了一些关于工作时间和空间的建议。但是需要记得的是，时间和空间的安排都不是死的，也没有必要死跟自己定下来的节奏一点偏差都不能有。时间和空间的安排是一个大体的框架，目的是为了让你可以很好的分开工作和生活，于是能在工作的时候把自己的状态都投入进去达到高效的目的。
在跟从以及检讨自己的安排的时候，不应该以和安排贴合的程度来评估，而应该以工作是否达到高效的目的来评估。在整体工作能够高效完成的情况下，不会有人在乎你今天多睡了半小时，或者多花了一个小时外出办理了一件什么事情。这也应该是远程工作想要达到的目的，让你有更高效的工作，也让你有更好的生活。
目标管理
远程工作的目标管理，除了像正常情况下用来检讨工作进度和状态之外，它还有另外一个用途，就是可以成为你工作的驱动，更像一个起点，而不只是一个总结。很多时候你是靠着目标安排来决定你今天/本周要做什么以及要花多少时间的，所以一个好的目标管理习惯也是很重要的。
不要高估
不要高估自己一天能够做多少事情，所以不要在 stand-up 会议的时候把自己的计划安排得满满当当，然后一整天都赶着做事情（我通常认为赶时间意味着质量上做出让步）。大致把自己的任务计划一下，分个类：
- 要解决的小问题，一些比较 trivial 的小问题，有现成的解决办法，稍微花些时间就可以完成；
- 高优先级的问题，可能问题不大，但是需要优先解决；
- 会花较多时间的问题，问题细节比较多，需要花一段时间来处理；
- 没有头绪，还需要深入研究的问题。
分完类之后，那就可以大概安排一下一天要做什么以及分别在什么时间做。像第一类的小问题，因为占时间不多，完全可以在碎片的时间就完成（比如改个字符串之类的），所以一天可以完成多个。
第二类的由于是高优先级，那么显然如果有的话，每天你应该是先解决这些，但是由于问题的复杂性可能不同，不一定要求你是处于最好的状态的时候才来解决这些问题，只保证每天计划里高优先级的任务都能完成即可。
像第三类，因为需要的时间较长，那么就应该要放在你能够集中精神工作的时间来完成，这样可以保证你的思路一直专注着，也利于问题的解决，但是你一天的时间肯定有限，所以肯定不会解决太多这类问题，一至两个已经到顶了。
最后一类，由于完全无法确认时间，就不建议每天做太多这种任务，而且由于问题可能很疑难，应该让自己有好状态的时候再来挑战这些问题，在没有好精神状态的情况下挑战困难的问题，通常找不到好的解决办法，除了浪费时间和精力之外没有太多的好处，应该把你宝贵的时间安排在其他问题身上。
总而言之，基本的目标就是让你能够高效利用自己的工作时间，避免资源错配造成浪费。所以每天给自己总结的时候，记得多问下自己，今天的目标是否和计划一致，是否高效，有没有发生浪费的情况，需要如何改善等等。
不要低估
不要低估自己一年能做多少事情，所以应该总是保持自己有个接下来一段时间的工作计划。每周，每两周，每月给自己大概安排短期的一些计划和小目标，然后经常性的做一些总结。
如果每天的计划都很好的完成的话，那么统计下来每周和每个月的情况都会有相当乐观的进展的。保证你的工作计划有看得见的稳步的推进，大概给自己设定一个时间然后将任务分解开来到每天完成一部分，会比你到 deadline 之前赶时间要好很多。
协作篇
日常沟通
Don't ask to ask
线上沟通有个很重要的原则，是不给别人添麻烦，由于你在别人眼里也是别人，所以其实也是避免给自己添麻烦。讲个老段子：
A: 我要给你讲一个关于 TCP 的故事
B: 你要给我讲一个关于 TCP 的故事
A: 我开始给你讲一个关于 TCP 的故事
(开始讲故事)
如果看懂这个段子在吐槽 TCP 三次握手的低效率（吐槽归吐槽，不要在意他这么设计的深层原因以及是否有必要，能替代 TCP 的东西现在还没有出来），那你就应该知道类似「在吗」，「我遇到了一个问题」这类的话语同样是很低效率的。
远程工作由于情况特别，你需要保证工作时间尽量都在电脑前让你的同事找到你，同时你也没法保证你沟通的对象时时刻刻都在电脑前让你能够找到。沟通很多时候都是异步的，于是要求的是提升沟通的效率，让它更清晰明朗。
遇到问题从来都应该是直接了当的提出，尽可能详细说明你的状况，追求的是让对方不需要再多问问题就可以给出有效的反馈（否则对方上线了你又下线了，那这个问题就可能拖到明天了）。
另外，由于沟通基本上是异步的，千万避免发生等着对方的回复你才能继续进行工作的情况。你一天会给自己安排了好几项任务，这个任务如果暂时卡住了，你应该切换自己的进程到另外的任务上去，不应该浪费时间空等。
保持开放
保持开放有两层意思，一个是要让大家知道你在做什么，另一个是，你要知道大家都在做什么。
所以日常关于工作的沟通，除了密码的传输，或者其他和工作无关的私聊，其他的都应该尽量保证在公开的频道进行。这样子的好处是让大家都能知道你在做什么，同时你也要关注其他人交流的内容，知道大家都在做什么。
如果你们之间有直接的协作关系，那么知道对方的进展总是好的，如果没有，那么知道整个项目的进展，以及你在其中的状态，也总是好的。
另外，在公开的频道进行讨论，还能避免对其他感兴趣的人需要额外重复说明情况。同时，如果你对其他人正在讨论的内容有兴趣，也可以随时就加入，多个人多个思路多些意见建议总是好事。
总结下来就是应该让我们的公开频道成为一个信息检索的资料库，而不应该把这些可以公开的信息保持在多个一对一的私聊中。
工具集成
Slack 的礼仪
我们日常基本上用的都是slack来进行沟通。为了保证沟通高效，除了上面说到的提升沟通效率，以及不私聊保证公开可以公开的信息之外，还有一些日常的习惯，这里只做补充。
第一个就是不刷屏。刷屏有两种，一种是大段内容直接就往上贴，另一种是直接在频道中回复没意义的回复。如果你的内容超过5行，那你应该考虑直接先说问题主要的点，然后再在 thread 里面开启你的长篇内容，这样子需要关注的人可以去线索里关注，另外的人不会受到太大干扰。
如果你想回复「收到」、「了解」这类表示得知相关信息的内容，你可以在线索里面回复，也可以简单的用表情回复，这两者都不会太大干扰到频道本身的简洁，对其他关注着频道的人会更友好。
记得上面讲过的宗旨吗，不要给别人添麻烦，不是每个人都有很大的竖屏可以容纳很多行的信息，你简单敲两个字自己是方便了，但是对别人，太多无意义的内容出现在频道的主屏幕中，无论是检索还是查看都是很不方便的。
另一个点是，尽量避免发送截图和视频，如果要发，则至少需要额外提供对应的文字版本。其实这是个连求职的大学生都知道的东西，对工作多年的人来说更应该知道，比如说正式发送简历的时候，提供一份纯文本的简历写在邮件正文里面。
对发的人来说，发个截图很是方便，对看的人就不一定了。远程工作的情况下，对方的网络状态你是不知道的，他可能在山里用着 3G，图片 load 完的时候太阳可能下山了。
直接发送图片有两个弊端，第一不能重复检索，第二不能复制内容。这两个很显然都是高效工作的阻碍。截图和视频不是说完全不能用，它们自有该用到的时候，比如说想表达操作过程和说明的内容完全一致的时候用视频，想表达特指的某个按钮的位置或者内容的时候用截图，这种情况下都是可以的。
但是考虑到对方接收的情况，也至少是需要额外提供对应的文字版本的，这样子可以比较快的了解情况和给出反馈。像直接扔个截图什么都不加说明的情况，是应该避免的。
Github
github 的 issue 提出，以及 issue 中的 comment，也是团队沟通的一部分，因此上面提到的原则，基本上也都能应用到上面去。
一个良好的 bug report，至少需要以下几个要素，才符合高效沟通的要求：
前提条件，类似版本信息，准备操作等
复现的过程
结果的详细描述（比如说「报错」和「报了一个（详细内容说明）的错」这种的区别）
复现的概率
如果一个 bug report 需要让解决 bug 的人额外问更多问题才能了解基本情况的话，那肯定是有问题的。
同样的，如果 issue 对应的是新 feature 的需求，至少是需要描述清楚需求的内容并确认的，避免后面浪费时间和精力。
工具篇
这里其实主要写 git ，也包括一些代码习惯。
善用git
git是沟通工具
git 是一个非常好的工具，但它远不止是一个版本管理工具，它还可以是一个很好的沟通工具。通过git 的 commit message 和代码，你可以和其他进行编码的同事完成高效的沟通。因此，上面讲到的团队协作原则，同样适用于 git 的 commit。
一个 commit 只做一件事情
想象一下，有个人发了一大段内容给你，里面杂乱的讲了好几件事情，你在看这段内容的时候会不会觉得很不舒服，找不到重点，并且需要花费很大精力才能从中理出各个事情的头绪来。如果会的话，那你也应该明白，如果你一个 commit 做了好几件事情的话，别人看 commit 的时候，一样会觉得不舒服需要花大精力才能理出思路来。记得我们的沟通宗旨吗，不要给别人添麻烦。
所以一个 commit 只应该完成一件事情，可能是修一个 bug，可能是完成某个逻辑单元，不应该把太多的内容都杂糅到一个 commit 里面，给看代码的人制造问题。
如果一个 commit 修复了两个 bug，那么要反思一下，要么 commit 要拆开了，要么两个bug重复了。
commit message要符合高效沟通的原则
同样的场景，有个人跟你说遇到了一个问题，然后剩下的都不说了让你猜是什么问题，会觉得不舒服吗？那么，如果 commit message 里面只写「fix bug」又不告诉你 fix 了什么 bug 呢？是不是一样的感觉？
要保证沟通高效，让阅读代码的人更轻松，commit message 至少要写明白改了什么内容，如果原因不直观，还需要说明改动的原因，以及给出对应修复的bug的链接。
无用的代码不是注释
没用的代码应该被删除，而不是被注释掉。注释只是注释，是用来提供需要额外说明的内容的。不能完成这个功能的，除了版权信息有时候有要求每个源文件都要包含，其他的都不应该作为代码注释存在，包括但不限于作者信息、源文件改动日期、过期的无用代码、调试用的代码。
记住，你在用git作为版本管理工具，不是直接使用记事本。删掉的代码有需要的时候可以从历史里面随时找到，作者信息和源文件改动信息在 commit 信息里就有，调试代码应该在本地缓存，不应该存到远程仓库中。
现在是2020年，上个世纪遗留下来不适合现代工具的代码习惯早应该抛弃掉了。
还是再想想，你会希望其他人发给你的信息不简洁而包含很多与主题无关的内容吗？代码同样如此。
git 的使用
以下几个阶段，可以大概评估一下自己对git的掌握程度，每一个阶段对应的技能都会让你在远程工作和团队协作中更加省心省力。
只会使用 git add .和 git commit -a 是负分。
如果你不是第一天接触git在学习基本使用，你不应该使用以上两个命令。
事实上，好的教程也不会让你去使用这两个命令。这两个命令容易误添加文件，也让你在每次添加的文件这件事情上养成一个马虎的习惯而不是精细地控制和了解改动了哪些，需要添加哪些文件。
问题在于，你对自己改动的代码真的了解吗？如果代码的结构和逻辑你都很清晰，那么添加文件的时候你应该至少是指定特定的文件或者目录来添加，而不是不加区分全部添加并提交就算了。
如果你日常使用上述两个命令，那么应该反思一下。这两个命令对你多线程的工作（在远程的情况下你和其他人是异步的，于是多线程变得很重要）只会有阻碍。
单独添加文件并 commit
你应该至少对你改的代码的结构和逻辑都有一定的了解，知道每次添加哪些文件就能完成一个最小的逻辑或者修复一个 bug（还记得上面说到的一个 commit 只做一件事吗）。然后通过多次添加并多次 commit 的方式来保持 git 历史的简洁。
当然，如果你不是初学者，只会这么使用 git 还是远远不够的。
自由在分支中进行切换
这里包括会使用 git checkout 和 git stash
两个，前者用来切换不同分支，后者用来缓存你本地的代码。
如果你能熟练使用这两个命令，那么对于你多线程进行工作会很有帮助。因为如果一个地方由于外部原因卡住了，那就暂停一下，切换到另外的分支里面完成另外的任务。
熟练使用 git push，至少要会 push 上一/两个 commit 到远程。
上面说过调试的代码要放在本地。那么本地不存起来也很不好，容易丢，那么怎么办呢？
很简单的做法是，把调试的代码放到最后一个 commit 里面，整个本地调试完成之后，把上一个commit 的历史提交到远程，这样子提交的代码就不包含你本地的调试代码，你本地的调试代码也没那么容易丢了。
会使用 git mergetool 解决代码冲突
这个其实和 git 没什么关系，主要是解决代码冲突，用任何你顺手的工具能够解决即可。包括分支间的冲突，包括其他同事代码和本地代码的冲突，等等，主要是为后面几个阶段服务的。
熟练使用 git rebase（普通版）
万一我加了调试代码之后，调试过程中发现问题，于是又改动了代码，这个时候我应该怎么 push 才能既保证修改的代码完全提交，又不包含我本地的调试代码呢？
答案是使用 git rebase，你可以使用它的 -i 参数来完成 commit 顺序的调整。
熟练使用 git rebase（进阶版）
对 git rebase -i 中操作不同的命令熟练使用。至少需要掌握 fixup 和 edit 的用途。
原因也是上面说过的，一个 commit 只做一件事情，如果这件事情到后面发现还没有做完（比如说引入了其他问题之类的），那你可以继续写一个 commit 将它解决完整，然后用 rebase->fixup 来将两个 commit 合并起来。
这样子，你不会有两个各做了半件事的 commit，而是一个只做一件事的commit。
熟练使用 git add
git add 几乎每天都在使用，但是是否用过 git add -i 或者 git add -p？
因为你添加代码的时候可能一次性加了比较多内容，为了保证每个 commit 的纯粹，有时候会需要添加一个文件的一部分改动而不是整个文件的改动都添加。
你对改动的代码掌握程度越高，你越可能需要使用上述这两个参数，能够精确控制每个 commit 的逻辑，从而将大量的内容依照代码逻辑分开添加。
更多
git 是个宝藏，还有更多能让你提高效率的用法等你去发现。
其他
关于安全
以下是一些简单的关于安全的建议：
- 不要公开传输密码，通过其他人处获取的密码，要立即更改；
- 在任何服务器和服务上保证密码强度，尽可能开启二步验证；
- 任何服务尽可能使用 https；
- 永远不要将敏感信息存储在代码仓库中，即使是私有仓库。甚至本地仓库也不建议这么做；
- 如果你使用服务器，服务器上记得要打开防火墙，避免安装不必要的东西开放不必要的端口。
结尾
以上就是一些关于远程工作的建议。如果你耐心地看到这里，那么接下来你要做的事情，就是忘记本文。上面这些内容只是一些纸面上的东西，远不如你在实践中形成的经验靠谱。
不要想着只依靠这些内容，应该带着大概的概念，去形成适合你自己的远程工作习惯。
原文微博：https://weibo.com/ttarticle/p/show?id=2309404587094684074721