新手

面朝大海，春暖花开；
世界那么大，我想去看看；
自由是勇敢者的权利；

一个优秀的码农不应该被束缚在一个 4 尺见方的小格子里； 这是我们的梦想； 这是我们为梦想踏出的第一步； 希望大家在这里能实现一种不同的人生。

准备工作

工欲善其事必先利其器
  1. 一般情况下推荐在 Mac 下工作，闲鱼上可以以很低的价格获得一台非常适合 IT 工作的 Macbook 或者 Macbook Pro，操作系统和软件的准备请参考 36node 团队的 dotfiles。
  2. 不论采用哪个系统，一定要准备好可以使用 Github、Google、Youtube、Stack Overflow 等网络，同时网速需要足够的快，这是生命线。
  3. 需要能够参加视频/音频会议，所以请准备相关设备，通常只需要一个带摄像头的笔记本以及带麦克风的耳机。
  4. 登陆冒险者大厅，注册以及完善相关的个人资料，通常这部分会通过邮件进行邀请。
  5. 完整阅读《冒险者指南》，加入诸如 36node 团队的飞书。
  6. 36node 团队发布的任务通常是 js 技术栈的，可以通过36node/sketch来了解。
  7. 找到一个 Mentor 来领路。

如何去接任务

天下事有难易乎？
为之，则难者亦易矣；
不为，则易者亦难矣。
  1. 在冒险者大厅的首页，会有一系列可以领取的任务，任务相关的介绍请参考任务介绍。
  2. 通过浏览项目和任务介绍，选择技术栈，找到你感兴趣的任务，申请加入对应的项目组。目前这一步可以在飞书中联系相关的项目负责人来完成。
  3. 领取任务之前需要查阅相关里程碑的资料，了解整个项目组当前迭代的目标。也可以查看历史信息，对整个项目有更全面的了解。
  4. 领取任务时，请了解它的等级、验收标准以及截止日期，确保有充分的时间去完成。

如何完成任务

不能制约自己的人，不能称之为自由的人。 —— 毕达哥拉斯

在实际编码之前，应当在 issue 中回复设计思路或者实现方法摘要，以减少返工。架构师会认真审阅这些评论并回复。

我们采用的分支模型

use-fork-and-pr

领取到任务后的流程：

  • 假设领取到一个新增 todo-list 的功能的任务。
  • Fork 到你自己的名字空间下， 从主分支 checkout 一个分支，命名为 feat/todo-list；分支名必须以 feat 开头，如果是 fix bug，则以 fix 开头，类似 fix/a-typo-bug。
  • 开发完成后，本地测试，调整代码，如有必要可以和产品远程 share 屏幕讨论。
  • 推送分支 git push -u origin feature/deadline。
  • 然后在 github 上提交 pull request， reviewer 选对应的架构师；这时候分支会被自动 build & test；分支 review 过程中，根据 comment 意见，讨论并修改，然后再提交。

PR 规范

随着 pr 数量的增加，review 的工作量越来越大，也需要咱们更规范 pull request

分支的命名应符合如下规则

feat/topbar
fix/typo
docs/add-some-reademe
  • message 规范 [阮一峰老师的规范]
  • 用 rebase -i master 压缩成有意义的一条或者几条消息
  • 在 PR 的 issue 中写一下提交包含的内容
  • 一些尚未完全确定的需求，询问是否要更改
  • 提交信息里可以使用 fix/fixes/fixed , close/closes/closed 或者 resolve/resolves/resolved 等关键词，后面再跟上 Issue 号，这样就会自动关闭这个 issue，大厅上的任务也会同步关闭。
git commit -m "fix(screwup): top bar overflow fixes #12"
这将会关闭 Issue 这将会关闭 Issue #12，并且在 Issue 讨论列表里关联引用这次提交。

团队协作

软件是团队协作的产物，即便我们只领取其中少量的任务，也需要了解如何和其他人合作。

  • 我们主张采用异步沟通和同步沟通结合这样的模式进行长期的远程协作，未来会考虑在各大城市增设冒险者之家，方便大家一起开会交流。
  • 微信群用来组织团队活动。
  • 飞书是36node团队的主要沟通手段，少量的微信视频或电话会议。
  • Github 是我们沉淀 code 和产品的仓库，凡事都记录 issue 是一个良好的习惯。

异步沟通可以提高沟通效率，降低占用的同步时间，避免约时间约不上的尴尬。但是要发挥它的最大价值，需要我们做到如下几点：

  • 认真对待每一次发送的消息，可以是简单的，但是完备、充分、带有辅助信息，让接收者能够尽量一次性获取所有上下文。
  • 文档是我们沉淀产品、设计、技术架构的地方，也是其他人最依赖的知识库，可以快速上手某各项目。
  • 在合适的时间，尽可能及时的给出回复或者一个响应约定，等待总是痛苦的，相思成灾。多上飞书和冒险者平台总没错：）

Coding 哲学

  • 硬编码风格通过 ESlint 和 Prettier 来强制约束，我们信仰黑客精神，规则尽量通过机器来约束
  • 简化你的代码，想一想是不是可以更精简又易懂
  • 多花一点时间去思考，但也不要过度设计
  • 时刻关注代码测试
  • 不要把一些愚蠢的错误留给产品去发现，那是一件丢人的事情
  • 我们的目标是创造，所以一定不要沉默，大胆提出想法，也许你是对的

results matching ""

    No results matching ""