リファクタリングする - refactor
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. -- Refactoring: Improving the Design of Existing Code より
リファクタリングとは、ソフトウェアの外部的振る舞いを保ったままで、内部の構造を改善していく作業を指します。-- リファクタリング-プログラムの体質改善テクニックより
Perl ではスカラーコンテキストとリストコンテキストが肝の一つなんだけれど、ここ最近 C++ を使うことが多かったこともありリファクタリングでちょっとポカった。
#!/usr/bin/perl use warnings; use strict; use Data::Dumper; sub f { return; } sub g { return undef; } my $f_value = f; my $g_value = g; my $f_hash = { a => 1, b => $f_value, c => 3}; my $g_hash = { a => 1, b => $g_value, c => 3}; print Dumper($f_hash, $g_hash); #$VAR1 = { # 'c' => 3, # 'a' => 1, # 'b' => undef # }; #$VAR2 = { # 'c' => 3, # 'a' => 1, # 'b' => undef # };
リファクタリング前のコード。$f_hash も $g_hash も同じ。 ここでリファクタリングのスタンダード「一時変数のインライン化」を行う。
my $f_hash = { a => 1, b => f, c => 3}; my $g_hash = { a => 1, b => g, c => 3}; print Dumper($f_hash, $g_hash); #Odd number of elements in anonymous hash at test.pl line 13. #$VAR1 = { # 'a' => 1, # '3' => undef, # 'b' => 'c' # }; #$VAR2 = { # 'c' => 3, # 'a' => 1, # 'b' => undef # };
ああ。f の呼び出しがリストコンテキストに変わるので、 return; が undef ではなく () を返すようになり無名ハッシュを生成するリストの中で消えてしまうため、キーと値の組み合わせがずれてしまう(そして無名ハッシュを奇数個の要素で作ろうとする警告も出る)。
コンテキストは理解しているんだけれど、リファクタリング前のコードでスカラー変数で受けているので、つい f がスカラー値だけを返すサブルーチンだと錯覚してしまうと。
g みたいに明示的に return undef; してればいいかというと、これはこれで落とし穴があり、一般的には return; の方が推奨されている。
昨日の前夜祭から一晩明けて、1日目。今年は去年みたいに #yapcasia タイムライン専用スクリーンが無いのかぁ。ちょっと残念。タイムラインとか Growl 芸とか YAPC 名物な気がしてたので。LTソンの方に機材まわしたからかな?
会場は小綺麗だけれど物販 NG 他利用規則がいろいろ厳しくて、ちょっと窮屈な感じかな。そういう意味で、東工大は良かったですねぇ。
ホールのすぐ横が会場ということもあって懇親会もすごい賑いで、どんどん大きなイベントになっているんだなぁ感じた。 懇親会では、ネックストラップに入れておいた Twitter 名刺をみて、声をかけていただいたりして光栄でした。@toku_bass 氏、メガネラボの @issm 氏と直接お会いできました。
トーク・LT は例年通りレベルが高く濃いもの揃いで素晴しかったですね。
ファシリティ系:
回線系:
今日も朝から YAPC::Asia Tokyo 2015 の2日目です。まずは一杯の無限オレンジジュースからスタート。最初はトラックCから。 C の部屋に入れたのはこれが初めてです。なるほど狭め。
言語の特性にあわせて様々なプログラミング言語を活用しているというトーク。サーバサイドで使われているということでちょっと Scala が気になりますが、やはりここでもコンパイルが遅いという話が出ていました。
Go は小さなシングルバイナリを作れるというところがやはり大きな利点。あとはやっぱり Perl はビルドなどのためのツールを作るのに便利だよねという話でした。
Ricardo Signes 氏のトークを聞くのは YAPC::Asia Tokyo 2013 1日目の時(記事)以来です。
前回同様 Perl の機能追加・削除についての話が中心。直観に反するような挙動が修正されるというところは言語としての完成度があがって良いなと。一方、さらに experimental として追加される文法は、ますます変態的になっていくなという印象もありました。
今日は一人でぶらりとTFTビルへ。
リファクタリングを行う理由の中で「Developer Education」という話があって、理解のためにリファクタリングをしてもらうのも良いと言っていて、ああそうだよなと思いました。リファクタリングの素養はあるけれども、チームのコードは知らないという状態の時にはいいなと思います。
あとは、基本的には Martin Fowler の「リファクタリング」を読んでいれば OK な感じです。
ちょっとうつらうつらしてました。あと「カレのヒゲ」はマイクにこすれるので通訳的に要注意のようでした。
Perl 6 における 並列・並行・非同期処理の話。 Perl 6 では言語レベルでこのあたりのサポートがしっかり入ってくるという印象でした。昨日聞いたトークといい、やはり Perl 6 が気になってきました。
Go の各種ツールを使って時間やメモリを消費している部分を見つけてどんどん削っていく様子をライブで実演してくれました。なるほど、ちょっとしたコードでも工夫すると劇的に最適化できるみたいです。
実演中アセンブラコードをチェックしているところや、データが 1 word から 3 words で管理されているという説明などをみて、ああやっぱり Go は C/C++ 的なマシンへの近さやコンパクトさがあるよなとあらためて感じました。
YAPC::Asia Tokyo 最後のトーク(になるかもしれない)となった LT は Kuniwak (@orga_chem) 氏の「Vim script性的解析の光と闇」でした。
CONBU さんが LT の時間内で設営・撤収デモまで実演していて、その素早さに驚嘆でした。まさに神業のレベルです。会期中お世話になりました。
今年はキーノートが無いので LT が終わるとクロージングです。
今年の参加者はなんと約2,130人。今の形での開催は最後と言われている YAPC::Asia は今後どうなっていくのでしょうか。 YAPC::Asia Tokyo 2015 は「The End.」のスライドで幕を閉じました。皆さんお疲れさまでした。
去年の YAPC::Asia Tokyo 2014 では Go 言語の勢いを感じ、その後ちょっとした規模ですが業務ツール開発に使ってみたりしました。
YAPC::Asia Tokyo 2015 では近年になく Perl のトークを見た気がします。しかも今回は Perl 6 のコードををよく見た気がするのは気のせいでしょうか。今回はこれを機に Perl 6 にチャレンジしていきたいと思います。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会8回目。今日は第8章 技術的負債。
スクラムのコアコンセプトの部でわざわざ技術的負債について1章割くというのがふーんという印象でした。ベロシティに大きな影響を与えるので避けて通れないというところでしょうか。あるいはウォーターフォールと違って返済していくチャンスがあるからでしょうか。
技術的負債。当初は
意図的に手抜きをしてすばやく仕上げるという意味
技術的負債を抱えるということは、今後の作業のための時間を担保にした融資を受けるということだ。
からきていて、後々返済する必要が出てくる代わりに先に経済的効果を得ているものを指しています。単純にまずい設計や実装のことまで技術的負債と世間で呼ばれていることがありますが、個人的には違和感を感じています。本書ではナイーブな技術的負債と呼んでいますね。
技術的負債ですが
大切なのは、どんなプロダクトであっても技術的負債からは逃れられないということだ。私はここで、技術的負債をなくすよう努力しましょうなどと言うつもりはない。仮にそんなことができたとしても、負債をゼロにするためには大変なコストがかかるだろう。
ということで必ずしも罪悪感を感じる必要のあるものではないことがわかります。きちんと把握してコントロールしていくことが重要です。
ただ
技術的負債の経済的意味についての適切な認識
については、正直なところなかなか正確に見積もれることがない気がします。技術的負債を生むという選択をした時にそこまで見積もる余裕がない、あるいはあっても先のことなので詳細化しきれない、そういうケースが多いのではないかと。
サイズが大きいものは方法2の方が時間をとって返済しやすく、サイズが小さいものは方法3の方が「フィーチャーよりも優先度が低くていつまでも返済されないということがない」ので返済しやすいようです。
あたりがポイント。
ということで、技術的返済のみに注力するのは価値を提供し続けるというのに反するで望ましくないとありました。
また実際のところ利息がほとんど発生しない技術的負債もあるので、きちんと見極める必要がありますね。
インクリメントの完成に高いコミット意識をもって毎スプリント取り組んできている CS 開発チームがいくつか大きなリリースを終えたので、スクラムマスターと相談して今日からの1週間スプリントは「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良いことにしました。
リファクタリング・技術的負債の返済・開発環境の整備や、調査・学習・ドキュメントの整理など、いつものスプリント中にはなかなかできないことを各自でしてよい1週間です。
普段から持続可能なペースを意識してスプリントプランニングしていますが、それでも頑張り続ければストレスも溜まってくるでしょう。適切なタイミングでブレイクを挟むことで、バーンアウトを防ぎ長期的にデリバリーし続けられるチームでいられればと思っています。
ちなみにこの取り組みは去年別のチームが unwinding period と呼んでやっていたのを真似てみたものです。
今回スプリントがどういう感じだったのかは、いつも通りスプリントレトロスペクティブでふりかえってみます。
[ スクラム ]
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。