共计 4479 个字符，预计需要花费 12 分钟才能阅读完成。
笔者从 2020 年疫情暴发之前，始终从事后端开发工作。2020 年因为工作起因，退出了 SAP 一个代号为 Spartacus 的开源我的项目的开发团队。这个我的项目是一个基于 Angular 的电商 Storefront 框架，其代码贡献者来自全世界各个地区。
实际上，这个我的项目的开发工作由六个麻利开发团队组成，笔者是惟一一位来自 APJ 即亚太地区的开发人员。从此，我开启了为期两年多，始终继续到当初的近程办公生涯。
本文通过下列几个方面，向大家分享笔者所在的开发团队，在近程办公畛域的教训和团队日常的近程办公，所应用过的一些工具。
目录如下：
- 代码托管和项目管理：Github
- 即时通讯(文字版)：Slack
- 即时通讯(语音版，视频版，会议)：Microsoft Teams
- 常识治理：Atlassian Confluence
代码托管和项目管理：Github
咱们我的项目的代码托管在这个 Github 仓库上：https://github.com/SAP/spartacus
每当有新性能开发时，咱们会创立名为 epic/XXX 的代码分支，待开发和测试完结后，将其合并到 develop 分支上。
已有性能的缺点修复，则应用分支 fix/XXX 来实现。对于新版本的公布，应用 release/XXX 分支实现。
通过定义这些分支的命名标准，身负不同类型开发工作的共事们，可能在不同的分支上工作，彼此互不影响。
Github Pull Request 的 Code Review Web 界面，将代码批改前后的状态，提出代码审查意见的 Reviewer 和提出代码审查的申请者所需的下一步批改等动作，完满地进行了封装和出现，使得不在同一办公室的开发人员们，可能在这些 Web 界面高效地进行代码审查工作。
下图是我的共事在某处代码进行审查后提出的批改倡议，批改倡议蕴含批改后的源代码，以及通过文字表白的该倡议背地的思考。
Github 的缺点 (Issue) 治理也是其一大亮点。
来自寰球的 Spartacus 使用者和代码贡献者，能够依照当时筹备好的模板，给咱们的代码仓库创立 Issue. 这些 Issue 能够是现有性能 bug，也能够是新的性能申请。每个 Issue 能够调配一到多个标签(Label)，用来标识该 Issue 的特色，以及须要解决的畛域问题。目前咱们的代码仓库有 7804 个曾经敞开的 Issue，还有 702 个处于 Open 状态。这八千多个 Issue，通过总共 534 种不同类型的 Label 来形容。
每个 Issue 能够调配给一个我的项目(Project)，这个我的项目是 Github 提供的我的项目进度治理模块中的模型之一。在 Github Project Dashboard 里，咱们能清晰地看到调配到同一个 Project 的所有 Issue 列表，如下图所示：
这些 Issue 能够别离被搁置到名为 To Do，In Progress，Code Review & Local，QA from Server After Merge 的列之下。
每一次麻利开发的 Sprint Planning Meeting 完结之后，开发团队以后 Sprint 须要做的工作，以 Issue 的形式呈现在上图 Project 最右边的 To Do 列之下。每天团队的 Daily 例会上，大家通过 Microsoft Teams 软件，拨入会议近程加入，由 Scrum Master 在本人的电脑上应用分享桌面将 Github Project Dashboard 投影进去，其余团队成员从 To Do 列表里抉择本人当天要 work on 的 Issue.
一个 Issue 被某人支付之后，会从 To Do 列移至 In Progress 列。当开发人员实现该 Issue 须要的性能开发或者 Bug 修复，并实现本地测试之后，这个 Issue 从 In Progress 进入 Code Review & Local QA 状态, 期待组内其余开发人员摘取，进行代码审查和穿插测试。当代码审查和穿插测试都由另一位开发人员实现之后，Issue 进入 QA from Server After Merge 状态, 此时团队的品质管制工程师(Quality Enginner) 就能够开始更高级别的集成测试了。
通过 Issue 关联的 Milestone 面板，咱们能够轻易监控一个 Project 的实现进度：
以上介绍了通过 Github 治理的 Issue 的一个典型生命周期，咱们团队正是通过这种形式实现的我的项目工作治理。只管另一款免费软件 Jira 也提供了更业余的我的项目与事务跟踪治理性能，在工作工作量记录，我的项目整体进度把控和工作执行明细显示方面更为杰出，然而 Github Project 也有其亮点，那就是对 Github Issue 和 Pull Request 的深度集成，后者更是咱们这种开发人员来自寰球各地，横跨多个时区的全球化开发团队所看重的特色。
即时通讯(文字版)：Slack
程序员每天除了编写代码，提交代码和审查代码之外，免不了要和其余开发人员进行各种互动，比方探讨技术问题，公布组内布告，向其余成员求助等等。
如果是比较简单的通过文字沟通即可解决的问题，咱们团队的成员偏向于在 Slack 这款软件里进行文字交换。
集体认为，同大家日常生活中应用的微信相比，Slack 在软件开发畛域的近程团队成员沟通中，有下列显著的劣势：
1. 所有聊天记录 (包含文字和文件) 均长久化在服务器端，便于查问
很多应用微信群进行工作沟通的敌人都已经埋怨过，微信群聊天记录仅仅保留在本地，很容易失落。而 Slack 不存在这个问题，因为一条音讯(无论纯文字还是蕴含了文件)，一经发送，就会保留到服务器端，并且 Slack 反对了弱小的查问性能。
上面是 Slack 的查问窗口，咱们能够看出，Slack 反对如下几种查问形式：
- Google Like 查问，即在下图放大镜的图标后，间接输出查问关键字
- 在指定的 Slack Channel 里查问，例如下图的
Find in ec-spartacus, 意思是只在名为ec-spartacus这个 Channel 里搜寻 - 只搜寻指定类型的交互记录，例如 Messages(文本交互信息)，Files(文件)，Channels(搜寻名称蕴含输出关键字的 Channels) 和 People (搜寻名称蕴含输出关键字的 Slack 用户)
以笔者为例，我是 2020 年 8 月退出目前这个开发团队的，应用 Slack 搜寻，笔者能够轻松定位到任意产生在 2020 年 8 月之前的交互记录：只须要在 Range 里指定搜寻的起始和完结日期：
就能够疾速找到我须要查找的蕴含某关键字的交互记录：
2. Slack 的文字音讯反对相似 Markdown 的语法，便于程序员交换
Slack 的文本反对加粗，斜体，删除线，援用，插入代码等多种格式化选项，同纯文本相比，这些格式化成果进步了开发人员浏览文本信息的效率。
除此之外，Slack 的文本编辑器，反对品种丰盛的 Emoji 表情符号，能给程序员每天枯燥的生存削减一丝亮色：
3. Slack Thread 对于基于文本的探讨话题的高效组织
应用微信群探讨工作问题的敌人都有这样的苦恼：微信群里的信息流，没有层次结构的概念，所有的信息流都位于同一层级，因而很容易呈现同一群里，同一时刻有若干不同主题的探讨同时产生的状况，群的使用者很难凭借浏览这些文字记录，取得每个不同主题的探讨的上下文。
Slack 引入了 Thread 的概念，来高效治理一个 Channel 内不同主题的并行探讨文本流。
一个 Thread 代表一个主题，能够蕴含一到多条文本信息。一个 Thread 除了第一条原始文本信息之外的其余文本信息，称之为 Reply. 当用户针对 Thread 第一条文本音讯进行回复时，这些回复的音讯就称之为 Reply，主动同 Thread 的第一条音讯关联起来。
下图是一个例子，屏幕右边的区域显示了两条 Thread，别离蕴含 4 条和 7 条 Reply. 单击每条 Thread，抉择 View Thread 菜单项，能够在屏幕左边的明细页面区域里，查看该条 Thread 所有的 Reply.
通过引入 Thread 和 Reply 这组具备相似父子蕴含关系的概念，Slack Channel 能够高效治理不同主题的文本探讨。
4. Slack 开箱即用的泛滥 App 和弱小的扩大性能
在 Slack App 市场 https://slack.com/apps，能查阅泛滥蕴含能够显著进步近程工作效率的开箱即用的 Slack App：
咱们能够为 Slack Channel 增加这些现成的 App：
也能够自行开发合乎团队理论工作须要的新 App.
比方咱们团队目前在应用的一个自开发的 Slack App，如下图所示。每当开发人员有新的代码提交，导致继续集成服务器的 Central Build 失败后，该 App 就会推送一条音讯到 Slack Channel 中，并且蕴含三个链接，别离指向失败的构建，导致构建失败的代码提交，和构建的历史信息。
有了 Slack App 这种即时的提示信息，开发人员可能防止手动去查看构建状态，从而可能更快地对失败的构建做出响应。
即时通讯(语音版，视频版，会议)：Microsoft Teams
对于近程办公的麻利开发团队来说，Daily Scrum，Planning Meeting，Review Meeting 这些会议都须要放到线上进行。另外，当开发人员遇到复杂度较高的问题，靠纯正的文本信息探讨难以解决时，也须要通过语音加上共享屏幕的形式来交换。
只管 Slack 自身也提供了语音通信的性能，然而对于在线会议，咱们团队最终抉择的是 Microsoft Teams 这款软件。除了在不稳固的网络连接环境下，咱们测试出 Teams 的体现优于 Slack 之外，咱们能够应用 Teams 的 Recording 性能，将重要的会议过程记录下来，并以 MP4 的格局不便地进行导出。这些会议的 Recording 对于新退出团队的共事以及因为种种原因错过了会议的共事十分有用。
常识治理：Atlassian Confluence
Slack 里的文本信息流尽管搜寻起来十分不便，然而比拟碎片化，不适宜用来保护零碎的、篇幅量较大的、图文并茂的常识类文章。因而咱们抉择了 Atlassian Confluence 用来搭建团队 Wiki, 实现团队的常识分享。
Atlassian Confluence 能够反对多用户对文档的编写，可能不便高效地创立软件研发过程中的需要文档、产品架构设计文档、项目管理文档、技术分享等文档。
其丰盛的页面控件，多种类别的开箱即用的模板，基于富文本和文档源代码级别的编辑形式，使得开发人员和非技术人员都可能编写出业余的文档。
其版本治理和差别比拟性能，即使在多个用户别离对同一文档进行编写的状况下，也能依据须要，轻松回溯出每一次批改的明细信息：
总结
本文通过笔者的理论工作教训，分享了笔者所在的全球化软件开发团队，在近程办公这个畛域，所应用过的一些工具和教训。尽管因为疫情以及团队成员所在地理位置的起因，开发团队的成员们不能在同一间办公室里面对面地工作，然而感激古代突飞猛进的 IT 技术，通过本文介绍的这些工具，即使近程办公，咱们的开发效率也没有受到太大的影响。
心愿疫情可能早日彻底完结，所有开发人员都可能回归到疫情之前失常的开发工作中去。
