Upgrade to Pro — share decks privately, control downloads, hide ads and more …

yapc-hokkaido-2016

 yapc-hokkaido-2016

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

Syohei YOSHIDA

December 11, 2016
Tweet

More Decks by Syohei YOSHIDA

Other Decks in Programming

Transcript

  1. 自己紹介 • @syohex • 京都の組込み企業で 8 年働いてました • 今年の 7

    月から DeNA で働いています AndApp • API サーバ (Go) • Windows 向け SDK, 基盤 (C++) • OSS 活動では主にメンテナンスをしている – Emacs, Perl, Go
  2. その他 • Emacs – MELPA – markdown-mode, php-mode, coffee-mode, git-gutter,

    auto-complete, popup.el, go-eldoc, emacs-jedi etc • Go – peco • zsh – zsh-completions
  3. 最近 Perl の印象 • 一部を除き積極的には開発されていない • 新しいこともあまり行われない – 新機能開発はあまり行われず –

    新しいモジュールも出ない • 古いモジュールが壊れたまま放置 – パッチ , PR が放置されることが少なくない • 反応が乏しい
  4. モチベーションの低下 • そもそもあまり触らなくなった • Perl に革新的なことが起きない – バージョンを重ねるごとによくなっているけど – (

    個人的に ) そこまで熱意を保てるものではない – 技術的チャレンジがない – それでいて壊れることが稀にある
  5. 昔 Perl を盛り上げていた人たちは • メインの使用言語が他の言語へ – Java, Scala – Go

    – Ruby, Python • みんな年を取った – 自由に使える時間が減った
  6. Perl を通じて思うこと • バリバリ開発している時期ならいいけど , それ をすぎるとメンテナンスは重荷に • 早めにメンテナンス方針を立てていれば –

    タイミングとしては開発が一通り完了した時点 – 問題が溜まった後では遅い • コントリビュータの意識も重要
  7. 負荷を減らす • issue を閉じて , Pull Request のみにする – 問題調査は骨が折れる

    – issue だけの人対策 (stackoverflow へ誘導 ) • 反応がない issue, PR は閉じる – 無駄に溜まった issue, PR の数は精神的によくない • Issue/PR template は効果はそれほどでもない • 自動化できるものは自動化を
  8. 負荷を減らす • サポート対象を減らす – (Perl だと )5.8 とかいつまでサポートするんだ – 自身に問題ないけど

    , 依存パッケージの minimum version 更新でテストがこける原因になったりする
  9. 共同でメンテナンスする • 一人は辛い – 辛いときは些細な PR を見るのも面倒 • 共同メンテナを見つける –

    commit 権限 – パッケージリリース権限 (Perl だと comaint) • issue, PR が溜まりまくる前に !!
  10. Issue, Pull Request • メンテナは対応に時間がかかる – バグの確認・調査 , レビュー –

    なるべく時間がかからなく済むよう心がける • PR は自分のコードを他人に管理してもらうこ とになりうる行為
  11. 良いレポート • バグレポート – 再現手順 , 環境の情報 • 可能な限りミニマルに –

    自分が受け取った時 , 再現できて , 直せると思え るものを送ろう
  12. 良くないコメント • +1, I have same issue – 意味ない ,

    reaction で十分 – 何かコメントするなら新情報を
  13. Pull Request の前に • 過去の PR を調べよう • 同じことを何度も指摘させないように –

    かなり萎える原因になっている印象 – あなたにとって一回目でもメンテナは同じことを数 十回言っているかもしれない • github 等だと過去のコメント数をチェック
  14. Feature Request • 新機能追加 , 拡張などは積極的に提案しよう – やる気のある内しか実現 ( マージ

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