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