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