$30 off During Our Annual Pro Sale. View Details »

yapc-hokkaido-2016

 yapc-hokkaido-2016

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

Syohei YOSHIDA

December 11, 2016
Tweet

More Decks by Syohei YOSHIDA

Other Decks in Programming

Transcript

  1. モジュールメンテナンスを通して感じる
    最近の Perl
    YAPC::Hokkaido
    DeNA Co.,Ltd Shohei Yoshida

    View Slide

  2. 自己紹介

    @syohex

    京都の組込み企業で 8 年働いてました

    今年の 7 月から DeNA で働いています
    AndApp

    API サーバ (Go)

    Windows 向け SDK, 基盤 (C++)

    OSS 活動では主にメンテナンスをしている
    – Emacs, Perl, Go

    View Slide

  3. Perl

    Mouse

    Text::Xslate

    Data::MessagePack, AnyEvent::MessagePack

    Minilla

    plenv

    Perl::Build

    etc

    View Slide

  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

    View Slide

  5. 目次

    メンテナンスを通じて感じる最近の Perl

    メンテナンスの話
    – メンテナ側の話
    – コントリビュータ側の話

    おわりに

    View Slide

  6. 最近 Perl の印象

    一部を除き積極的には開発されていない

    新しいこともあまり行われない
    – 新機能開発はあまり行われず
    – 新しいモジュールも出ない

    古いモジュールが壊れたまま放置
    – パッチ , PR が放置されることが少なくない

    反応が乏しい

    View Slide

  7. モチベーションの低下

    そもそもあまり触らなくなった

    Perl に革新的なことが起きない
    – バージョンを重ねるごとによくなっているけど
    – ( 個人的に ) そこまで熱意を保てるものではない
    – 技術的チャレンジがない
    – それでいて壊れることが稀にある

    View Slide

  8. 昔 Perl を盛り上げていた人たちは

    メインの使用言語が他の言語へ
    – Java, Scala
    – Go
    – Ruby, Python

    みんな年を取った
    – 自由に使える時間が減った

    View Slide

  9. Perl を通じて思うこと

    バリバリ開発している時期ならいいけど , それ
    をすぎるとメンテナンスは重荷に

    早めにメンテナンス方針を立てていれば
    – タイミングとしては開発が一通り完了した時点
    – 問題が溜まった後では遅い

    コントリビュータの意識も重要

    View Slide

  10. ここから
    メンテナンスの話

    View Slide

  11. メンテナ側の話

    View Slide

  12. 検討すべきこと

    継続してメンテナンスする場合
    – 負荷を減らす
    – 共同メンテナンス

    メンテナンスをやめる

    View Slide

  13. メンテナンスを継続する

    View Slide

  14. 負荷を減らす

    issue を閉じて , Pull Request のみにする
    – 問題調査は骨が折れる
    – issue だけの人対策 (stackoverflow へ誘導 )

    反応がない issue, PR は閉じる
    – 無駄に溜まった issue, PR の数は精神的によくない

    Issue/PR template は効果はそれほどでもない

    自動化できるものは自動化を

    View Slide

  15. 負荷を減らす
    ● サポート対象を減らす
    – (Perl だと )5.8 とかいつまでサポートするんだ
    – 自身に問題ないけど , 依存パッケージの minimum
    version 更新でテストがこける原因になったりする

    View Slide

  16. 対応をほどほどに

    No と言おう , 断ろう
    – 何でも対応しようとすると自分の首を締める

    View Slide

  17. 共同でメンテナンスする

    一人は辛い
    – 辛いときは些細な PR を見るのも面倒

    共同メンテナを見つける
    – commit 権限
    – パッケージリリース権限 (Perl だと comaint)

    issue, PR が溜まりまくる前に !!

    View Slide

  18. メンテナンスをやめる

    View Slide

  19. やりすぎは身を滅ぼす

    真面目にやりすぎると燃え尽きる

    他のことにまで影響が出るのはよくない

    燃え尽きるぐらいならやめた方がいいのでは

    View Slide

  20. やめるときは明示的に

    単に投げ出さない

    曖昧な状況はよくない
    – とりあえず github にはあるけれど

    パッチ送っても反応無し

    メールを書いてみても反応無し

    View Slide

  21. やめるときは明示的に

    メンテナンスしないことを明記
    – ( 早めに )issue, ドキュメントに書く

    ( もう少し ) 余力があれば
    – 代替手段の提示

    View Slide

  22. コントリビュータ側の話

    View Slide

  23. Issue, Pull Request
    ● メンテナは対応に時間がかかる
    – バグの確認・調査 , レビュー
    – なるべく時間がかからなく済むよう心がける

    PR は自分のコードを他人に管理してもらうこ
    とになりうる行為

    View Slide

  24. 良いレポート

    バグレポート
    – 再現手順 , 環境の情報

    可能な限りミニマルに
    – 自分が受け取った時 , 再現できて , 直せると思え
    るものを送ろう

    View Slide

  25. 良くないレポート
    ● 動かない , 壊れてるとだけ書かれる
    どうしろと
    ● この機能足したら便利なはず
    本当に ?
    ユースケースを提示しよう

    View Slide

  26. 良くないコメント

    +1, I have same issue
    – 意味ない , reaction で十分
    – 何かコメントするなら新情報を

    View Slide

  27. Pull Request の前に

    過去の PR を調べよう

    同じことを何度も指摘させないように
    – かなり萎える原因になっている印象
    – あなたにとって一回目でもメンテナは同じことを数
    十回言っているかもしれない

    github 等だと過去のコメント数をチェック

    View Slide

  28. View Slide

  29. Feature Request

    新機能追加 , 拡張などは積極的に提案しよう
    – やる気のある内しか実現 ( マージ ) できない

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

    View Slide

  30. 最後に

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

    Happy maintenance

    View Slide

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

    View Slide