yapc-hokkaido-2016

 yapc-hokkaido-2016

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

97296a20d14bf2a1d6285fbdf33f8279?s=128

Syohei YOSHIDA

December 11, 2016
Tweet

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. ご清聴ありがとうございました