もっと気軽にOSSに Pull Requestを出そう!/ Let's make a PR to OSS more easily

7b606c5039f083d13e2d2320ce6ddcfa?s=47 DQNEO
February 10, 2020

もっと気軽にOSSに Pull Requestを出そう!/ Let's make a PR to OSS more easily

PHPerkaigi 2020 で発表した資料です。

7b606c5039f083d13e2d2320ce6ddcfa?s=128

DQNEO

February 10, 2020
Tweet

Transcript

  1. もっと気軽にOSSに Pull Requestを出そう! @DQNEO (ドキュネオ) PHPerKaigi 2020/2/10

  2. 自己紹介 @DQNEO (ドキュネオ) • US版メルカリを開発しています • 趣味: ◦ コンパイラ自作 (去年)

    ◦ 英語 (いま) ◦ 突然アセンブリを書いてしまう
  3. ※注意 このトークは初心者むけです


  4. 質問 PHPの有名ライブラリにコントリビュートした
 ことのある方?


  5. 「コントリビューション」のイメージ ◦ まず、しっかり使いこなす (← すでにハードルが高い) ◦ 新機能追加して便利にしたよ (← 何も思いつかない) ◦

    バグ見つけて直したよ (← バグとかある?) できたらカッコいいが、なかなかチャンスはない
  6. 私のコントリビューション実績 Symfony Guzzle AWS SDK for PHP DietCake DietCube Ethna

    Fluent Logger PHPBench Monolog PHPJava AssertChain ほか多数
  7. 4つの着眼点 1. 作者の関心ゾーンの外側を見る 2. 使ってなくてもコントリビュート 3. 業務で得たノウハウを横展開 4. ダメ元でも送ってみる

  8. テストコードの可読性 着眼点1: 作者の関心ゾーンの外側を見る メインコードの 設計、実装、可読性 • テストコードの可読性 • テストコードのコメント •

    コメント、ドキュメント • CI設定 • 環境変化への追従 異常 ケース
  9. メインコードの 設計、実装、可読性 コメント、ドキュメント

  10. 例: Guzzleの README $client = new \GuzzleHttp\Client(); $res = $client->request('GET',

    'https://api.github.com/user', [ 'auth' => ['user', 'pass'] ]); echo $res->getStatusCode(); // 200 echo $res->getHeaderLine('content-type'); // 'application/json; charset=utf8' echo $res->getBody(); // {"type":"User"...'
  11. そのまま実行するとエラー PHP Fatal error: Uncaught GuzzleHttp\Exception\ClientException: Client error: `GET https://api.github.com/user`

    resulted in a `401 Unauthorized` response: { "message": "Bad credentials", "documentation_url": "https://developer.github.com/v3" }
  12. Pull Request出してみた

  13. PR説明欄を丁寧に書く

  14. すぐマージされた https://github.com/guzzle/guzzle/pull/1658

  15. いまGuzzleのトップページにある サンプルコードは 僕が書いたやつです https://github.com/guzzle/guzzle

  16. https://github.com/symfony/symfony/pull/24618/files PHPDocの修正: symfony union書き忘れ

  17. PHPDocの修正: Aura.Sql https://github.com/auraphp/Aura.Sql/pull/129/files エラーケースは忘れられがち

  18. PHPDocの修正: guzzle/psr7 https://github.com/guzzle/psr7/pull/134/files nullになるケースはなかった

  19. テストコードの可読性 メインコードの 設計、実装、可読性 テストコードの可読性 テストコードのコメント コメント、ドキュメント

  20. テストコードの可読性: Symfony https://github.com/symfony/symfony/pull/11812/files パラメータの可読性向上

  21. テストコードのコメント: Symfony 文章の間違いを修正 https://github.com/symfony/symfony/pull/11811/files

  22. 躊躇しないで シュッとPR出してみるの大事

  23. PRを出す習慣が身につく 「次はもっと大きいコントリビュー ションを!」 マージされるとやる気が出る

  24. テストコードの可読性 メインコードの 設計、実装、可読性 テストコードの可読性 テストコードのコメント コメント、ドキュメント 異常 ケース

  25. 異常ケース: guzzle handler オプションに不正な値を渡したとき

  26. 異常ケースの改善: guzzle コンストラクタで型をチェックする https://github.com/guzzle/guzzle/pull/1745/files

  27. 異常ケースの改善: guzzle エラー報告がわかりやすくなった

  28. Guzzleのコンストラクタに コントリビュートした!

  29. テストコードの可読性 メインコードの 設計、実装、可読性 テストコードの可読性 テストコードのコメント コメント、ドキュメント • CI設定 • 環境変化への追従

  30. 環境変化への追従、CI設定の充実 ライブラリというのは放っておくだけで古くなる • PHPの新バージョン • PHPUnitの新バージョン ◦ 後方互換がしばしば壊れる • 新しいPSRが策定される

    (例 PSR12) • Coding Styleチェッカーや静的解析ツールの進化
  31. travis.yml にPHPのバージョンを追加 これも立派な貢献 https://github.com/dietcake/dietcake/pull/35/files

  32. PHPJava: .php_cs.dist を追加 https://github.com/php-java/php-java/pull/72/files

  33. • エコシステム周りはチャンスの 宝庫 • ひとつの知識を横展開できる

  34. 着眼点2: 業務で得たノウハウを横展開 • 会社の巨大アプリケーションが PHPUnit ver4だった • PHPUnit ver4 →

    ver7 にあげた • バージョンアップに異常に詳しくなった • OSS界隈を見渡すと、古いPHPUnitに依存してるライブラ リが無数にあった • チャンス!!
  35. PHPUnitのバージョンアップ職人 • DietCake 4 → 5 → 6 → 7

    • DietCube 5 → 6 → 7 • Monolog 5 → 6 • PHPBench 6 → 7 • AWS SDK for PHP 5 → 6 • AssertChain 4 → 5 → 6 • Chronous 6 → 7 etc
  36. 詳しくは PHP Conference 2018の資料で 大規模PHPプロジェクトでPHPUnitを3世代アップグレードするためにやったこと https://speakerdeck.com/dqneo/phpunit-upgrade-story?slide=94

  37. 着眼点3: 使ってなくてもコントリビュート • 「読むだけ」でも結構見つかる • PHPStormの警告で気づいたり

  38. Symfony: 使われてない変数 https://github.com/symfony/symfony/pull/24617/files

  39. Symfony: 子クラスでのreturnし忘れ https://github.com/symfony/symfony/pull/24626/files

  40. Symfony: 無名関数の引数の型 https://github.com/symfony/symfony/pull/26821/files

  41. Symfony: 無名関数の引数の型 https://github.com/symfony/symfony/pull/24622/files

  42. 無名関数の引数の型宣言は忘れられがち • array_map(function(ここ $x){....}) • ただし、型宣言を後から追加する場合は、 後方互換を壊さないように注意

  43. 着眼点4: ダメ元でも送ってみる • 失うものはない • 「やった方がいいのにたまたま誰もやってなかった」 ケー スもある • 超有名レポジトリにPRしてみた

  44. React: 英語の難単語を置き換え • 公式ドキュメントで ”mandatory”(=必須)という難単 語があった • 別の単語 ( a

    must ) への置き換えを提案 • 「”mandatory”くらい普通に使うだろ」という反応を 予想していた https://github.com/facebook/react/pull/8809 ↓
  45. Goコンパイラ: 変数名をリファクタ • わかりにくい変数名を見つけた • 10年の歴史のあるコンパイラの変数名 • 何か深い歴史的事情があるのかも、 と思いながらも変数リネームのPRしてみた •

    あっさりOKが出た https://github.com/golang/go/commit/f07059d949057f414dd0f8303 f93ca727d716c62
  46. まずはPR出してみよう!

  47. 余談

  48. 余談: 1年前のPHPerkaigi

  49. 余談: 1年前のPHPerkaigi

  50. 両方達成した!

  51. PHPerkaigiで登壇すると 夢が叶う!

  52. つぎはあなたの番です!!