如何成为一位远程开发者 | 新知 · 技能
· 公众号内回复「IT」，送你一张脑洞图 ·
本文来自作者： 方应杭 在 GitChat 上的精彩分享，「阅读原文」看看大家与作者交流了哪些问题。
注：本文既不是干货，也不是胡侃，虽然是以「远程」为中心，但是说的又不仅仅是「远程」，更多的是技术人员的自我追求，包括工作环境、硬技能和软技能。
我的经历
我第一次听说远程开发者，大概是看新闻知道了 37signals 这个开发团队。
37signals
这个团队成立于 1999 年，一开始只有 4 个成员。如今已有 50 个成员，遍布全世界的 32 的城市。总部虽然在芝加哥，但是大部分成员都是「远程办公」。
当时的我听到这些觉得很玄幻，感觉不真实。然而这个团队确实产出了几个不错的产品，比如 Basecamp（一个收费的项目管理软件）和 Rails（一个风靡一时的全栈 Web 框架）。
而且这个团队的联合创始人 Jason Fried 还出过两本书，一本叫 《Rework》，一本叫《Remote》。我对这个团队是如此好奇，于是我把两本书都买来读了读，从此，我确定一个想法，我一定要试试远程工作。
Rework & Remote
Rework 这本书主要是一些商业思考，其中有两点，我很在意。
很多公司心目中理想的员工是：20多岁，没有业余生活，一天工作14小时，在办公桌下打地铺过夜也不会崩溃的那种。
……
这让你（管理者）糟糕的管理能力侥幸蒙混过关，制造出了一个「这是我们能与竞争对手抗衡的唯一办法」。当人们家里有事时，他们会在办公时间内把活干完，因为家里还有事情等着他们去做。
那时的我突然想到，我就是那种20多岁的员工啊，几年后，我就不是了呀。这是不是意味着，几年后，我就不如小年轻有竞争力了？这种拼体力的做法显然不是长久之计。
会议有毒
世界上最可恨的打扰莫过于开会，原因如下……
我在腾讯和阿里待过，相信读者中也有不少在腾讯和阿里待过，你一定会有一个感受：会议太多、太冗长了。
他们说程序员的出路是转管理岗，而管理岗的工作大部分就是开会。我的天哪，把会议作为我的工作内容，我真是要死了。
另一半书 Remote 则是完全在介绍远程工作的优缺点：
为何办公室里无法办公？
如果你问别人，必须把工作做完的时候会去哪儿，极少有人会说「办公室」。就算真有人这样说，他们也会补充一句，「我会一大早赶去，趁着人都没来的时候干活」，或是「等到大家都走了，我留下来工作到很晚」或者「周末时偷偷溜进去」。
他们其实是想说，在办公室里没法工作。当人们真心想把活儿做完的时候，工作时段里的办公室是他们最不愿去的地方。
这是因为办公室早已变成了「干扰工厂」。
同样的观点，Joel Spolsky 也说过，他在《Joel on Software》里说他认为每个程序员应该拥有一间私人办公室，以防打扰。
Remote 还有一些犀利的观点：
别再把人生耗费在通勤路上。
我在阿里的时候，上班要坐一个小时的班车，下班也是，再加上准备时间，我每天有 3 个小时浪费在通勤路上。
何必挤在大城市。
优秀的人不可能都住在一个城市。如果没有远程工作机会，很多人根本就不会对另一个城市的工作机会感兴趣，北上广深杭五个地区的程序员你司只能选择一个，除非你司已经有能力在全国各地开分公司。
大公司都不这么干，为什么我们要这么干？
从大型企业身上寻找最新的高效做法真的不明智。
关于远程的理由我不再继续列举了，如果你有兴趣，可以在多看上买这两本书的电子版看看。
第一次远程
上面说的都是国外的事情，中国真的有远程工作的条件吗？
我在第一个远程工作之前，也有此疑虑。然而我在不知不觉中已经实现了远程工作，连我自己都没发现。
事情是这样的，从腾讯离职后，我回到武汉光谷，在一个跨国的小团队继续做前端开发。当时跟我合作的是一个美国的 Python 后台开发小哥（下文中就叫他 S 吧），需求方在英国。
当时团队有两间办公室，由于我不喜欢空调，所以我一个人跑到没有空调的办公室干活了（这岂不就是传说中的私人办公室）。另外 S 在我入职一周后就飞回芝加哥了，从起就开启了我的私人办公室 + 远程办公模式。
当时我跟 时差大概 12 小时，我们需要在三个月完成一个复杂的类似 Photoshop 的在线广告编辑器（但是功能没有 PS 那么多，只有图层、缩放、裁剪等常见功能）。这段时期是我职业生涯中效率最高的一段时期。我俩用 Gtalk 沟通，需求文档放在 Google Docs，每晚六点我会告诉他我完成了哪些功能，需要他提供哪些接口，然后下班回家。然后他几小时后起床，看了我的邮件之后开始开发，他写完代码后发邮件告诉我，他完成了哪些功能，需要我调试哪些接口。
就这样日复一日，没有会议，没有打扰，静下心写代码的感觉真好。
从那时起我才知道，远程开发离我并不远。
第二次远程
后来我去了阿里，从阿里出来之后，我决定只看远程开发的团队，当时我认为中国最吸引我的团队就是彩程（出品过 Tower.im 和 Zhiren.com）。而且我已经提前一年就开始了解他们了。结果就是顺利的加入了这个团队。
期间面试、工作的体会后面会讲到。
以上就是我关于远程的经历。
如果你也想成为远程开发者可以看看我下面的分析。这个可能是大部分观众想听的（我猜）。
如何成为远程开发者
我主要从事 Web 开发，所以下面的分析主要是跟 Web 开发相关的。
大公司的分工
Turbolinks 5 的开发团队在 Youtube 上发布过一个视频，讲的是 Web 架构的演化，很有意思，我在一年前对这个视频进行了部分翻译，取名为《Web 开发不应该这么复杂》。
十年前 Web 开发就是简单的 MVC，浏览器端就是一些简单的 JS：
现在一个单页面应用的架构是这样的：
后端依然是 MVC，但是前端加了三部分：
一是前端 MVVM、单向数据流框架，这当然还要包含前端路由。
二是为了保证 SEO 和首屏渲染速度，添加了 Server 端的 JS Runtime，用来渲染 View。
三是为了获取符合页面要求的数据，在 Server 端 Model 与 Client 端 的 Model 中间加了一个中间层，比如 GraphQL。
这些变化的好坏暂且不评，但是它预示着大公司（Facebook、Google）的技术架构有了越来越多中间层。
康威定律说：软件产品的结构就是其创造团队的组织结构的镜像。
这种变化反映出大公司的分工越来越细，Facebook、Google 开发团队的组织结构就像是这样：
这与上图中的技术架构非常相似。
这说明大公司的分工越来越细。
分工细有什么好处呢？——好招聘。找两个分别会前后端的开发者，比找一个前后端都不错的全栈开发，成本低多了。
分工细有什么坏处呢？——增加了沟通成本。一个产品，要有五个角色参与：产品、设计、后端、前端、测试，这五个角色还有可能分属不同的部门，因此每次沟通成本都挺高的。
就以前后端为例。中国 Web 开发从 AJAX 兴起以来就掀起了一场「前后端分离」的运动。这场运动创造了一个前所未有的名词：「前后端联调」。
什么是「前后端联调」相比很多 Web 开发者都知道。那就是后端不好好写单元测试与集成测试，让前端发请求调用以达到测试的目的；前端不好好写 Mock 和测试，让后端输出数据以达到测试的目的。
一般来说联调都要耗费一天时间，我见过最坑爹的居然耗费了一周时间。
分工过细使得我们严重依赖「面对面沟通」，这就使得远程开发变得不可能。
远程团队需要多面手
大部分人在尝试远程之前，最疑惑的就是大家怎么沟通的？总觉得视频会议不如面对面来得亲切友好。
但是我实际体验下来的感觉是相反的，远程开发团队的沟通可能更流畅一些。
正是由于知道沟通可能出现问题，所以团队会用各种措施预防沟通不畅的发生。
沟通损耗是必然存在的，就算是面对面也不能避免。损耗一般存在于沟通中转。产品经历跟设计师沟通，设计师跟前端沟通，前端再跟后端沟通，中转几次，信息就面目全非了。
所以远程团队对开发者的要求一般都是老手、多面手。如果你观察过国内远程团队对技术栈的选择，会发现大部分都只招聘「全栈工程师」，比如 Rails 全栈或者 JS 全栈。只招前端或后端的也有，但大部分是外包。
我还记得彩程面试我的时候，虽然对我的定位是主前端的工程师，但是依然会问我关于需求分析、产品设计、后端开发、开源项目、画图软件和自驱动力相关的问题。
因为远程团队希望把需求跟你讲清楚之后，你一个人就能完成大部分分析、设计和开发工作（当然还会有一个人 review 你的所有工作）。
如果说给你个需求，你两天还不动工，还说自己在「等设计稿、等接口」，那就没法开发了。
这就是为什么我说「在大公司呆久了，可能就没法做远程开发者了」。因为这两种团队对人才的需求完全不一样。
我该如何准备
假设你现在很想加入一个远程团队，你需要做哪些准备呢？
1. 最重要的是培养自己的自律，或者是主观能动性。
你需要让这个团队相信你很自律，或者主观能动性很高。换句话说就是你不会在工作的时候浑水摸鱼。
那么如何做到这一点呢？那就是提供证据或者养成习惯，比如
你是某个开源项目的核心贡献者之一，而且你是自发贡献代码的。
你坚持健身或跑步已经五年了。
你在公司里主导过一些项目的立项、开发和维护。
你用代码解决了实际生活中的问题。
等等。只要能证明你不是一个混吃等死的码农，而是一个有追求的程序员的事迹都可以说出来。
2. 盯住几个远程团队
国内的远程团队并不多，我接触过的有彩程、墨刀和 pubu.im，更多信息你可以到 这里 以及远程.work 查看。
我推荐你在每年的三四月份投递简历，因为那个时候是岗位最多的。
你应该提前半年甚至一年就确定求职范围和技术栈，然后针对性的做出一些作品或者 Demo。这样你求职的时候不至于出现技术栈不符的情况。目前需求比较大的技术栈就是 Rails 和 JS。
远程团队招聘一般喜欢直接用一个实际需求来查看你的适应能力。比如让你用一个周末解决一个小需求。
因为这样能直接考察你独立解决问题的能力。比如我当时被要求解决一个线上表格问题。给我一个周末的时间，让我给出初步方案。
那我就得沟通需求、分析需求、画出草图、确认需求、理解现有技术架构，然后去实现它，中途有问题的话就主动沟通。
你会发现代码能力其实可能只占 50% 的比重，更多的是你的做事方式适合符合这个团队。所以你预先了解团队是很重要的。
3. 成为多面手，同时能独当一面
所谓多面手不是说「样样精通」，而是你在技术上不「偏食」，也就是不会对某些技术产生抵触情绪。
在一个远程团队中，你经常需要一个人解决问题，而解决这些问题用到的技术各种各样。
在大公司里你是可以马上让身边的同事支援，但是在远程团队，一些小事自己动手是最好的。你可能会说我不专业做得不好怎么办。没事的，会有人 review 你的代码的。
同时你也要 review 别人的代码（这是一种程序员之间学习和交流的方式），所以你至少要能看懂别人的代码，即使这种语言你用得不多。
同时，你还要能独当一面。一个远程团队虽然都是全栈，但是有些人侧重后端，有些人侧重前端，还有些人是运维、DBA。你应该能在关键时候利用你的经验独当一面。
所以远程团队的招人标准有时候比 BAT 高很多。
在这里我推荐你学习一下 Rails 这款经典的全栈 Web 开发框架。这个框架涉及 Web 开发的各个方面的最佳实践，包括数据库、系统部署、系统测试、后台开发、前端开发。
4. 表达与沟通
这一点是最难提升的。远程团队对成员的表达能力是要求更高的，因为需要你在视频会议中让每个人明白你在说什么，也需要你弄清需求方的需求的明确含义。
提升这部分能力我的建议就是平时要写作和演讲。
把还就没写的博客捡起来，平时有心得就在例会上跟大家分享，都是不错的方式。
日积月累，等你面试的时候，就能侃侃而谈了。
5. 了解如何书写更高质量的代码
很多大公司其实并没有严格实行单元测试、集成测试、代码覆盖率测试、代码 review、持续集成、持续部署等最佳实践。
但是远程团队一般不会有专职的测试，所以你的代码质量是要你自己保证的。这些提高代码质量的措施就显得尤为重要了。
6. 以文档为交流中心
以前我在工作的时候发现，公司里很多基础框架和组件的文档都特别烂（说得就是阿里），你如果要用一个同事写的东西，你就得去他的工位上找他，面对面讨教。
而当时我的工作就是提供框架和组件给我的 12 个后台开发同事。如果我继续依赖这种面对面的沟通，我会忙死。
所以我就把所有的功能都在 gitlab 上以 README 的形式写出来了，即使是坐在我左边的人，要使用我的组件，我也是让他先看文档。这么做之后，沟通更高效起来了。
我的建议是，你平时工作中，也多做一些「去依赖」的事情，这样你在远程与别人合作的时候，就更顺畅。
远程的优缺点
我已经连续远程工作一年多了，说说优缺点吧。
优点
做事效率更高了。
由于不用通勤，所以我一般去楼下吃完早餐就回到家里的办公桌前写代码了。一旦投入代码，就会发现时间过得很快。更重要的是没人打扰你（老婆去上班了）。
时间变多了
依然是由于不用通勤，所以多出来了一些时间，当然这些时间也没闲着，用来准备自己的饭菜了……
不用待在北上广了
目前我是在武汉买的房，北上广的真买不起。
更多时间陪家人了
虽然我工作的时候基本不跟家人说话，但是相伴左右也是一种安心呀。没有了那种在外飘着的感觉。
说起来好像优点也不是很多呀……
缺点
加班并没有减少
由于生活和工作边界的模糊，所以我时常忘了停止工作……大家知道 Deadline 临近的时候，我们的写代码意愿是很高的。所以我只好设置闹钟，强制自己不要工作太久。
疏离感
有些人会因为太久待在家，而感觉与社会脱节了，有一种疏离感。我倒是没有这种感觉。我一般都回去知乎或 V2EX 上吹水，好不快活。
有些人为了消除这种疏离感，会故意去人多的咖啡馆办公。
收入变少
如果你希望拿着跟 BAT 差不多的工资远程办公，可能国内还没有团队能满足你。
收入会有一定的减少。这就是你在决心找远程工作前最需要考虑的问题了。
不过这种问题可以通过降低生活成本（不是降低生活质量）来解决。就比如我从杭州搬回武汉，就省了每个月的房租了。
哪些人不适合远程工作
自律能力差的人
技能单一的人
经验不到两三年的人
与人沟通不流畅的人
特别在乎大公司的高薪的人
一些链接
一早一晚社区【 http://yizaoyiwan.com/ 】
实现【 https://shixian.com/ 】
远程工作【 http://yuancheng.work/remote-frontend-jobs 】
「阅读原文」查看本场chat交流实录