yapc-hokkaido-2016

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 等だと過去のコメント数をチェック
28. None

29. Feature Request • 新機能追加 , 拡張などは積極的に提案しよう – やる気のある内しか実現 ( マージ

    ) できない • 時期を間違うと一生実現しないかも – バグ対応ばっかりやっているときにそういう提案が あると気持ちの切り替えになることも – ユースケースを示す – コード書く前に一度相談してみる

30. 最後に • ソフトウェアのメンテナンスは大変 – 燃え尽きてしまうことも – 計画的なメンテナンスで負荷の軽減を – コントリビュータの意識でメンテナな負荷は下がる •

    Happy maintenance

31. ご清聴ありがとうございました