平凡なエンジニアがDenoにコントリビュートするためにやったこと

## はじめに

今年の1月ごろからDenoへコントリビュートを開始しました。
そこから現在に至るまで、半年程コントリビュートを継続しています。
この記事では、その経験を通して学んだこと・よかったことなどについてまとめます。

## 自己紹介

- Webエンジニア歴は5年程度 (25歳)
- Node.js/TypeScriptは3年以上経験あり
- Deno歴は半年とちょっと
- **Rustに関するスキルは初心者に毛が生えた程度のレベル**
- **勉強が苦手です**
  - 学力が低かったため、大学には行っていません。
  - プログラミングを始めたころは`for`文の挙動が理解できず詰みかけました
- **英語力も実践には程遠いレベル**
  - **Google翻訳やDeepLなどのサービスを利用すれば、ある程度読めるというレベルです**
  - **リスニング・ライティング・スピーキングに関してはまったく自信がありません**

私はWebエンジニアとして、取り立てて優秀なわけではありません。
この記事では、そういった私がいかにしてDenoへコントリビュートするようになったのか、またそこから学んだことについて書いていきます。

## 想定読者

- OSSへのコントリビュートにハードルを感じ、なかなか踏み出せない方
- エンジニアをやっているが、自分の能力に自信が持てない方

先程も述べたとおり、私は取り立てて優秀なエンジニアではありません。

この記事では、そんな私がどのようにしてOSSへコントリビュートしたのかについて伝えたくて書きました。

そして、かつての私と同じように、少しでも**OSSへのコントリビュートにハードルを感じている方**の助けになれば幸いです。

## Denoとは?

Node.jsの開発者である[Ryan Dahl](https://github.com/ry)さんが開発している**Rustで実装されたTypeScript/JavaScriptランタイム**です。

詳しくは、@kt3kさんの[Deno ってなんだっけ?](https://qiita.com/kt3k/items/e1647683ad08ff6b6e95)の記事がおすすめです。

## なぜ始めようと思ったのか?

きっかけとしては、以下の理由からです。

- 元々、OSSへのコントリビュートに興味があったこと
- Denoのドキュメントを読んでいたら、たまたま誤りを見つけたこと

## コントリビュートを始める前

正直なところ、**最初はかなり抵抗がありました。**

- これほどの規模のOSSに自分が関わっても大丈夫なのだろうか?
- 自分の拙い英語で伝わるだろうか?

[最初のプルリクエスト](https://github.com/denoland/deno/pull/3592)を作成した時は、マージされるまで、とても不安でした。
ですので、無事マージされたときは、**とても嬉しかったです**。

## 実際にコントリビュートをしてみてどうだったか?

最初にコントリビュートを行うときは、とても不安でした。
しかし、今振り返ってみると、これは杞憂だったと思います。

- 最初は不安かもしれませんが、コントリビュートを繰り返していくうちに、それに対する心理的なハードルは下がっていきます。
- Denoのコントリビュータや日本のコミュニティである[deno-ja](https://scrapbox.io/deno-ja/)にはとても親切な方々が多かったこと
  - 実際に、日本のDenoコントリビュータである@kt3kさんや@keroxpさんには、[deno-jaのslackチャネル](https://scrapbox.io/deno-ja/Slack%E3%81%AE%E5%8F%82%E5%8A%A0%E6%96%B9%E6%B3%95)にて、助けていただく機会がありました。本当にありがとうございます:bow:

## 具体的にどういうことをしたの?

#### ドキュメントの修正

ドキュメントが不足しているまたは誤った箇所を見つけた際に、その修正を行いました。
具体的には、以下のようなことを行いました。

- 関数・クラスへのJSDocコメントの追加
- ドキュメントのtypoを修正

#### issueで起票されたバグまたは自分で発見したバグの修正

Denoではバグ修正を行った際は、たいていの場合、以下の理由でテストコードの追加も求められます。

- そのバグが正しく修正されたことを保証するため
- 今後、同じバグが再発しないことを保証するため

そのため、テストコードの存在を保証するために、以下の手順でバグ修正を行っていました。

1. まず自分の環境でそのバグを再現してみます。
2. ソースコードを読んで、バグの原因を突き止めます。
3. 原因がわかったら、そのバグが修正されたことを保証するためのテストコードを書きます。(この時点ではこのテストは失敗します)
4. 3で書いたテストコードが成功するよう、ソースコードを修正します。
5. テストコードが成功したら、プルリクエストを作成します。

#### いくつか新機能の追加もやりました
- `deno doc`コマンドの関数オーバーロード対応
- `Deno.ppid`の実装

## コントリビュートをやってみてよかったこと

#### 対象のOSSに対する理解が増す

ソースコードを読み、それを修正し、実際に動かして確認することは、OSSの理解を深める上で有効な手段だと思います。
OSSへのコントリビュートをする際は、自然にそれらのことが行われるため、理解が深まる要因になりました。

#### 世界中の人々と関わる機会ができる

Denoも含め、多くのOSSには、世界中の人々が開発に参加しています。
プルリクエストやissueを作成すると、そういった様々な方々から意見をいただくことができます。

普段こういった機会はなかったため、とても貴重な経験だったと思います。

#### 自信につながる

たとえ些細なことであったとしても、何かしら行動して結果を出せれば、それは自信につながるのではないかと私は思います。

## 大変だったこと・どうやって乗り越えたか?
#### Rustが難しい

Denoの中心部分はRustで書かれています。
そういった部分に対してコントリビュートする際は、ある程度Rustが書ける必要があります。

ですが、Rustは難易度の高いプログラミング言語であり、網羅的に学習しようとすると、かなり時間がかかると判断しました。

そのため、基本的に以下の方針で学習を進めました。

- ひとまず[Rustプログラミング入門](https://www.amazon.co.jp/Rustプログラミング入門-酒井-和哉/dp/427422435X)と[プログラミング言語 Rust, 2nd Edition](https://doc.rust-jp.rs/book/second-edition/) に目を通して、最低限の知識を得る。
- 後は、Denoのコードを読みながら、必要なことをその都度調べながらやってました。

学習時間を最小限に抑えつつ、ある程度はRustを触れるようになったため、方針としては概ね間違っていなかったのではないかと思います。

#### 英文を書くのが難しい

私の英語力はさほど高くありません。

そのため、issueやプルリクエストを作成するときは、DeepLやGoogle翻訳等のサービスも積極的に活用することにしました。

実際には、以下のような手順で英文を書いていました。

1. まず自分で英文を書いてみる。
2. 自分で書いた英文を日本語化し、それをDeepLやGoogle翻訳で英翻訳してみる。
3. 自分で書いた英文と似たような文章をGoogleやGitHubで検索する。
4. 自分で書いた文章と2・3で得られた文章を比較する。
5. 手直し
6. 2-5の繰り返し

## OSSへのコントリビューションを通して学んだこと

#### 完璧を目指すことにとらわれない

私のRustや英語に対するスキルは高くありません。

もし私がこれらのスキルの習熟度を完璧にすることに執着し、行動を先延ばしにしていたら、**実際にDenoへコントリビュートするのは数年は先になっていた**と思います。

そうならなかったのは、ある程度割り切って行動をしたからだと思います。

こういったスキルは、完璧を目指して突き詰めようとすると切りがないため、ある程度の割り切りも必要なのではないかと感じました。

#### 英語であっても日本語と変わらず、わかりやすい文書を書くことは大事

Denoでは、コミュニケーションはissueやチャット上でのテキストベースでのやり取りが中心になります。
新機能の追加や大きな変更等に関わる重要な決定も、そういったテキスト上でのやり取りで決定されることが多い印象を受けます。

そのため、読む側にとってわかりやすい文書を書くことが、レビュアや作者の方の負担を減らすことにつながります。

- 要点を簡潔に記載する
- たとえリポジトリにissueテンプレートがなかったとしても、できるだけ文章を構造化する
- 必要な情報についてはしっかり記載する
 - どうすればバグを再現できるのか?
 - バグが発生した状況または環境は? (OS、Denoのバージョン等)
 - 重複するissueが複数作成されたときは、内容がしっかりしている方がcloseされずに維持される

#### 迷ったときは、思い切ってやってみることも大事

冷静に考えると、もし仮にOSSへのコントリビューションで失敗したとしても、大きな被害を被るわけではありません。
ですので、**迷うくらいであれば、思い切ってやってみる**ということも大事だと思いました。

## これからDenoへコントリビューションを始めたい方へ

#### まずは比較的難易度の低いタスクから取り組む

コントリビューションのハードルを下げるためにも、まずは比較的難易度の低いタスクから取り組むのがよいと思います。
具体的には、以下のようなタスクから取り組むことをおすすめします。

- `good first issue`のタグがついたissue
- 標準モジュール(deno_std)で提供されている関数・クラスへのJSDocコメントの追加
- 標準モジュールに対するコントリビューション

まずは、これらのタスクを通して、ディレクトリ構成等について徐々に把握していくのがよいと思います。
そして、徐々に難易度の高いタスクへと取り掛かっていくことが挫折を防ぐ上で有効だと考えます。

#### わからないことがあれば質問する/助けを求める

これもコントリビューションのハードルを下げる上で有効な手段だと思います。

Denoについてわからないことがあるときは、以下の箇所で質問をすると、概ね回答をいただけると思います。

- [DenoのDiscordチャネル](https://discord.gg/deno)
- [deno-jaのslackチャネル](https://scrapbox.io/deno-ja/Slack%E3%81%AE%E5%8F%82%E5%8A%A0%E6%96%B9%E6%B3%95)

実際に、DenoのDiscordチャネルでは、日夜頻繁に質問が交わされています。(英語ではありますが...)

## まとめ

この記事で伝えたかったことは以下の点です。

- 完璧を目指すことにとらわれない
- 迷ったら、思い切ってやってみよう
- まずは難易度の低いタスクから始めよう
- わからないことがあれば質問しよう/助けを求めよう

この記事が、少しでもOSSへのコントリビュートにハードルを感じている方に対する助けになれば幸いです。

## 関連記事

- [Deno にコントリビュートする (1)](https://qiita.com/kt3k/items/0267c355997fc1a0539f)
- [Deno にコントリビュートする (2)](https://qiita.com/kt3k/items/87e931ecade61155c4ca)