yapc-hokkaido-2016

モジュールメンテナンスを通じて感じる最近のPerl

Transcript

1. モジュールメンテナンスを通して感じる 最近の Perl YAPC::Hokkaido DeNA Co.,Ltd Shohei Yoshida
2. 自己紹介 • @syohex • 京都の組込み企業で 8 年働いてました • 今年の 7 月から DeNA で働いています AndApp • API サーバ (Go) • Windows 向け SDK, 基盤 (C++) • OSS 活動では主にメンテナンスをしている – Emacs, Perl, Go
3. Perl • Mouse • Text::Xslate • Data::MessagePack, AnyEvent::MessagePack • Minilla • plenv • Perl::Build • etc
4. その他 • Emacs – MELPA – markdown-mode, php-mode, coffee-mode, git-gutter, auto-complete, popup.el, go-eldoc, emacs-jedi etc • Go – peco • zsh – zsh-completions
5. 目次 • メンテナンスを通じて感じる最近の Perl • メンテナンスの話 – メンテナ側の話 – コントリビュータ側の話 • おわりに
6. 最近 Perl の印象 • 一部を除き積極的には開発されていない • 新しいこともあまり行われない – 新機能開発はあまり行われず – 新しいモジュールも出ない • 古いモジュールが壊れたまま放置 – パッチ , PR が放置されることが少なくない • 反応が乏しい
7. モチベーションの低下 • そもそもあまり触らなくなった • Perl に革新的なことが起きない – バージョンを重ねるごとによくなっているけど – ( 個人的に ) そこまで熱意を保てるものではない – 技術的チャレンジがない – それでいて壊れることが稀にある
8. 昔 Perl を盛り上げていた人たちは • メインの使用言語が他の言語へ – Java, Scala – Go – Ruby, Python • みんな年を取った – 自由に使える時間が減った
9. Perl を通じて思うこと • バリバリ開発している時期ならいいけど , それ をすぎるとメンテナンスは重荷に • 早めにメンテナンス方針を立てていれば – タイミングとしては開発が一通り完了した時点 – 問題が溜まった後では遅い • コントリビュータの意識も重要
10. ここから メンテナンスの話
11. メンテナ側の話
12. 検討すべきこと • 継続してメンテナンスする場合 – 負荷を減らす – 共同メンテナンス • メンテナンスをやめる
13. メンテナンスを継続する
14. 負荷を減らす • issue を閉じて , Pull Request のみにする – 問題調査は骨が折れる – issue だけの人対策 (stackoverflow へ誘導 ) • 反応がない issue, PR は閉じる – 無駄に溜まった issue, PR の数は精神的によくない • Issue/PR template は効果はそれほどでもない • 自動化できるものは自動化を
15. 負荷を減らす • サポート対象を減らす – (Perl だと )5.8 とかいつまでサポートするんだ – 自身に問題ないけど , 依存パッケージの minimum version 更新でテストがこける原因になったりする
16. 対応をほどほどに • No と言おう , 断ろう – 何でも対応しようとすると自分の首を締める
17. 共同でメンテナンスする • 一人は辛い – 辛いときは些細な PR を見るのも面倒 • 共同メンテナを見つける – commit 権限 – パッケージリリース権限 (Perl だと comaint) • issue, PR が溜まりまくる前に !!
18. メンテナンスをやめる
19. やりすぎは身を滅ぼす • 真面目にやりすぎると燃え尽きる • 他のことにまで影響が出るのはよくない • 燃え尽きるぐらいならやめた方がいいのでは
20. やめるときは明示的に • 単に投げ出さない • 曖昧な状況はよくない – とりあえず github にはあるけれど • パッチ送っても反応無し • メールを書いてみても反応無し
21. やめるときは明示的に • メンテナンスしないことを明記 – ( 早めに )issue, ドキュメントに書く • ( もう少し ) 余力があれば – 代替手段の提示
22. コントリビュータ側の話
23. Issue, Pull Request • メンテナは対応に時間がかかる – バグの確認・調査 , レビュー – なるべく時間がかからなく済むよう心がける • PR は自分のコードを他人に管理してもらうこ とになりうる行為
24. 良いレポート • バグレポート – 再現手順 , 環境の情報 • 可能な限りミニマルに – 自分が受け取った時 , 再現できて , 直せると思え るものを送ろう
25. 良くないレポート • 動かない , 壊れてるとだけ書かれる どうしろと • この機能足したら便利なはず 本当に ? ユースケースを提示しよう
26. 良くないコメント • +1, I have same issue – 意味ない , reaction で十分 – 何かコメントするなら新情報を
27. Pull Request の前に • 過去の PR を調べよう • 同じことを何度も指摘させないように – かなり萎える原因になっている印象 – あなたにとって一回目でもメンテナは同じことを数 十回言っているかもしれない • github 等だと過去のコメント数をチェック
29. Feature Request • 新機能追加 , 拡張などは積極的に提案しよう – やる気のある内しか実現 ( マージ ) できない • 時期を間違うと一生実現しないかも – バグ対応ばっかりやっているときにそういう提案が あると気持ちの切り替えになることも – ユースケースを示す – コード書く前に一度相談してみる
30. 最後に • ソフトウェアのメンテナンスは大変 – 燃え尽きてしまうことも – 計画的なメンテナンスで負荷の軽減を – コントリビュータの意識でメンテナな負荷は下がる • Happy maintenance
31. ご清聴ありがとうございました