nDiki : リファクタリング

リファクタリング - refactoring

リファクタリングする - 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 より

リファクタリングとは、ソフトウェアの外部的振る舞いを保ったままで、内部の構造を改善していく作業を指します。-- リファクタリング-プログラムの体質改善テクニックより

ポイント

book

rimage:ISBN:4894712288

web

関連情報

2011年5月20日 (金)

今日のさえずり: 「マーチン・ファウラーが言うところの」と前置きした方がいいね

rimage:/nDiki/Flickr/5738525795.jpg

  • 08:18 やっぱりリンゴントウ食べたい。
  • 12:31 RT @gxeb: おはようございますーGXEB事務局ですー参加申し込みは来週の月曜日の朝までで締め切らせていただきます！現在、だいたい2倍～3倍くらいの倍率です！どうぞよろしくお願いします。http://gxeb.org/?p=99
  • 12:32 えー、GXEB の倍率すでに2～3倍なのか。参加申し込みずっと続いてたのでまだ定員超えてないとふんでいたのに。
  • 12:52 紙の給与明細書久方ぶり。
  • 13:21 テリヤキマックバーガーLLセット 550円。 (@ マクドナルド 渋谷新南口店) http://4sq.com/jYUPL7
  • 13:28 コークグラス GET。 http://flic.kr/p/9K6rMV
  • 13:29 @tomonobu_sato 貰いましたよ。けっこうイイです。
  • 13:36 グラスとして使うかペンスタンドとして使うか迷う。グラスとして使うなら数いるし。
  • 13:55 サンスイという釣具屋に CHUMS のバッグがあったのでふらりと。
  • 17:10 ある fixtures 用のモジュール使うと自動的にあんなところが Test::MockObject で潰されるというのに気がつかなくて「生だと動くのに prove 下だと動かな動かない……」とコードの海をただよっていたと。
  • 18:01 退勤。
  • 18:35 ひもの屋、宇田川店の方でした。
  • 22:26 @as_tone えっ?
  • 22:29 帰宅。今日は歓迎会ありがとうございました。
  • 22:50 @as_tone また誰かなのかと。
  • 22:57 「死ねばいいのに」って生で聞いたの初めてな気がする。
  • 24:01 やはりリファクタリングの話をする時には「マーチン・ファウラーが言うところの」と前置きした方がいいね。 http://bit.ly/jHx9KB
  • 24:06 そういえば確認したら宇田川じゃなくて宇田川町だった。そして港区にも宇田川町と呼ばれていたところがあったことを知ってびっくり。
  • 24:38 機能追加・修正や不具合修正とは帽子を被りなおす必要があること、外部的振る舞いを保たなければならないこと、少しのステップずつテストをかけながらやることなどについてどれか欠けてもリファクタリングじゃない。
  • 24:44 @yudoufu 「機能変更しながらリファクタリング」といった誤用はありますね。
  • 25:25 ちなみにリファクタリングの話は誤用の指摘とかじゃなくて、自分が言ったのはそういうのを含意してますよと。
[ permalink ]
[ 5月20日全て ]

2011年5月22日 (日)

今日のさえずり: ついにあの人が Facebook か

rimage:/nDiki/Flickr/5744927648.jpg

2011年05月21日

  • 09:03 掃除機紙パック交換。
  • 10:52 RT @biac: 誤用率はサマータイムとどっちが多いかってくらいw QT @bleis: RT @Naney: やはりリファクタリングの話をする時には「マーチン・ファウラーが言うところの」と前置きした方がいいね。 http://bit.ly/jHx9KB
  • 11:11 このちんすこう美味い!
  • 14:04 定例。 (@ 品川区立 品川図書館) http://4sq.com/lD05Z3
  • 14:12 「うさこちゃんのだいすきなおばあちゃん」重い。
  • 14:55 ブレイク中。 (@ ドトールコーヒーショップ 京急新馬場店) http://4sq.com/jbsefp
  • 17:13 RT @s_harada: Android端末でmixiやってる人は騙されたと思って公式アプリを使ってみて欲しい。ゴチャゴチャしてなくてとても使いやすいよ。
  • 18:24 エビフライとエビの天ぷら、どちらが好きですか? 今晩のおかずはエビフライです。

2011年05月22日

  • 10:34 sandbox. http://flic.kr/p/9KEfQG
  • 13:46 ついにあの人が Facebook か。
  • 14:13 すごい勢いで暗くなってきてる。
  • 15:25 スーパーの帰りにちょっと降られたけれどまあセーフ。
  • 18:21 プリンタインク切れ。PGBK が2つも残っているから、次はバラで買うか。
  • 21:40 RT @yasa_gurek0: 上司に見とけと言われた電車D done. 複線ドリフトはんぱない。
[ permalink ]
[ 5月22日全て ]

2011年5月23日 (月)

Perl での一時変数のインライン化はコンテキストの変化に注意

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; の方が推奨されている。

Perl での一時変数のインライン化は Java や C++ に比べて要注意ってことで。

[ permalink ]
[ 5月23日全て ]

2012年4月16日 (月)

今日のさえずり: 一晩指輪外してたけど、指凹んでるの戻らなかった

rimage:/nDiki/Flickr/6936063756.jpg

2012年04月16日

[ permalink ]
[ 4月16日全て ]

2012年9月14日 (金)

今日のさえずり: 息をするようにリファクタリングして master merge したい

  • 09:55 ノーマル。 (@ 株式会社ミクシィ (mixi, Inc.)) http://t.co/IeJtR7yh
  • 10:31 秋葉原ラジオ会館といえば、Bit-INN東京とエフ商会。
  • 14:11 GoodNotes に 3.4 になって Dropbox へのミラーリングができるようになった。ただ iPad 側でミラーリング対象を指定できない(全部書き出される)のと、Dropbox 側フォルダとして第一階層しか指定できない(/ 入れても駄目)なのがちょっと惜しい。
  • 14:27 「その道の権威」(intely)。
  • 14:31 「あなたも『その道の権威』になれる可能性が高まります。」(intely) なれるとは言ってないよ。
  • 20:34 初めて git rebase で --onto してみた。
  • 20:58 久しぶりに「ゆとりの法則」読んでおくか。
  • 21:23 退勤。秋の予感。
  • 22:00 息をするようにリファクタリングして master merge したい。
  • 22:46 23:00 からのワールドビジネスサテライト見忘れそうになって飛び起きた。
  • 23:16 千趣会のちょこちょこに学べ。
[ permalink ]
[ 9月14日全て ]

2012年9月28日 (金)

YAPC::Asia Tokyo 2012 1日目

昨日の前夜祭から一晩明けて、1日目。今年は去年みたいに #yapcasia タイムライン専用スクリーンが無いのかぁ。ちょっと残念。タイムラインとか Growl 芸とか YAPC 名物な気がしてたので。LTソンの方に機材まわしたからかな?

会場は小綺麗だけれど物販 NG 他利用規則がいろいろ厳しくて、ちょっと窮屈な感じかな。そういう意味で、東工大は良かったですねぇ。

ホールのすぐ横が会場ということもあって懇親会もすごい賑いで、どんどん大きなイベントになっているんだなぁ感じた。 懇親会では、ネックストラップに入れておいた Twitter 名刺をみて、声をかけていただいたりして光栄でした。@toku_bass 氏、メガネラボの @issm 氏と直接お会いできました。

トーク・LT

トーク・LT は例年通りレベルが高く濃いもの揃いで素晴しかったですね。

  • Larry Wall 氏のライブリファクタリング芸いつもすごい。
  • 今回は フリークアウト (FreakOut) が元気だなあという印象。トークとか LT とか T シャツ着てる人たちとか。
  • tokuhirom 氏のプレゼンテーション、現在時刻と経過時間が出ててとても良さそげ。
  • 最後に実行したコマンドの終了ステータスに応じて、Bash プロンプトを切り換えるも便利そう。

メモ

ファシリティ系:

  • 伊藤謝恩ホールのテーブル席のコンセントはダミー。

回線系:

  • 伊藤謝恩ホールはNTTドコモつながりにくい。人が多いとほぼ不通。
  • ということで、普段は SSID 詐称とか怖いので使わない会場無線 LAN を スマートフォン・iPad で利用させていただいた。こちらも LT など人が多い時は仕方がないけど途切れ途切れな感じ。
[ permalink ]

今日のさえずり: ライブリファクタリング芸いつもすごい

2012年09月28日

[ permalink ]
[ 9月28日全て ]

2013年1月29日 (火)

今日のさえずり: アルフと言えば「留守番はまかせて」

2013年01月29日

[ permalink ]
[ 1月29日全て ]

2015年8月22日 (土)

YAPC::Asia Tokyo 2015 2日目

rimage:/nDiki/Flickr/20794290452.jpg

今日も朝から YAPC::Asia Tokyo 2015 の2日目です。まずは一杯の無限オレンジジュースからスタート。最初はトラックCから。 C の部屋に入れたのはこれが初めてです。なるほど狭め。

「Mackerel開発におけるScalaとGo、そしてPerl」 songmu @songmu 氏 #yapcasiaC

言語の特性にあわせて様々なプログラミング言語を活用しているというトーク。サーバサイドで使われているということでちょっと Scala が気になりますが、やはりここでもコンパイルが遅いという話が出ていました。

Go は小さなシングルバイナリを作れるというところがやはり大きな利点。あとはやっぱり Perl はビルドなどのためのツールを作るのに便利だよねという話でした。

「Perl 5.22 and You」 Ricardo Signes @rjbs 氏 #yapcasiaA

Ricardo Signes 氏のトークを聞くのは YAPC::Asia Tokyo 2013 1日目の時(記事)以来です。

前回同様 Perl の機能追加・削除についての話が中心。直観に反するような挙動が修正されるというところは言語としての完成度があがって良いなと。一方、さらに experimental として追加される文法は、ますます変態的になっていくなという印象もありました。

ランチ

今日は一人でぶらりとTFTビルへ。

「Adventures in Refactoring」 Ben Lavender @bhuga 氏 #yapcasiaA

リファクタリングを行う理由の中で「Developer Education」という話があって、理解のためにリファクタリングをしてもらうのも良いと言っていて、ああそうだよなと思いました。リファクタリングの素養はあるけれども、チームのコードは知らないという状態の時にはいいなと思います。

あとは、基本的には Martin Fowler の「リファクタリング」を読んでいれば OK な感じです。

ちょっとうつらうつらしてました。あと「カレのヒゲ」はマイクにこすれるので通訳的に要注意のようでした。

「Parallelism, Concurrency, and Asynchrony in Perl 6」 Jonathan Worthington @jnthnwrthngtn 氏 #yapcasiaA

Perl 6 における 並列・並行・非同期処理の話。 Perl 6 では言語レベルでこのあたりのサポートがしっかり入ってくるという印象でした。昨日聞いたトークといい、やはり Perl 6 が気になってきました。

「Go Debugging, Profiling, and Optimization」 Brad Fitzpatrick @bradfitz 氏 #yapcasiaA

Go の各種ツールを使って時間やメモリを消費している部分を見つけてどんどん削っていく様子をライブで実演してくれました。なるほど、ちょっとしたコードでも工夫すると劇的に最適化できるみたいです。

実演中アセンブラコードをチェックしているところや、データが 1 word から 3 words で管理されているという説明などをみて、ああやっぱり Go は C/C++ 的なマシンへの近さやコンパクトさがあるよなとあらためて感じました。

「Lightning Talks Day 2」 #yapcasiaA

YAPC::Asia Tokyo 最後のトーク(になるかもしれない)となった LT は Kuniwak (@orga_chem) 氏の「Vim script性的解析の光と闇」でした。

CONBU さんが LT の時間内で設営・撤収デモまで実演していて、その素早さに驚嘆でした。まさに神業のレベルです。会期中お世話になりました。

「Wrap Up!」 Daisuke Maki @lestrrat 氏 #yapcasiaA

今年はキーノートが無いので LT が終わるとクロージングです。

今年の参加者はなんと約2,130人。今の形での開催は最後と言われている YAPC::Asia は今後どうなっていくのでしょうか。 YAPC::Asia Tokyo 2015 は「The End.」のスライドで幕を閉じました。皆さんお疲れさまでした。

YAPC::Asia Tokyo 2015 を終えて

去年の YAPC::Asia Tokyo 2014 では Go 言語の勢いを感じ、その後ちょっとした規模ですが業務ツール開発に使ってみたりしました。

YAPC::Asia Tokyo 2015 では近年になく Perl のトークを見た気がします。しかも今回は Perl 6 のコードををよく見た気がするのは気のせいでしょうか。今回はこれを機に Perl 6 にチャレンジしていきたいと思います。

[ permalink ]
[ 8月22日全て ]

2016年12月13日 (火)

第8回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会8回目。今日は第8章 技術的負債。

スクラムのコアコンセプトの部でわざわざ技術的負債について1章割くというのがふーんという印象でした。ベロシティに大きな影響を与えるので避けて通れないというところでしょうか。あるいはウォーターフォールと違って返済していくチャンスがあるからでしょうか。

技術的負債

技術的負債。当初は

意図的に手抜きをしてすばやく仕上げるという意味

技術的負債を抱えるということは、今後の作業のための時間を担保にした融資を受けるということだ。

からきていて、後々返済する必要が出てくる代わりに先に経済的効果を得ているものを指しています。単純にまずい設計や実装のことまで技術的負債と世間で呼ばれていることがありますが、個人的には違和感を感じています。本書ではナイーブな技術的負債と呼んでいますね。

技術的負債ですが

大切なのは、どんなプロダクトであっても技術的負債からは逃れられないということだ。私はここで、技術的負債をなくすよう努力しましょうなどと言うつもりはない。仮にそんなことができたとしても、負債をゼロにするためには大変なコストがかかるだろう。

ということで必ずしも罪悪感を感じる必要のあるものではないことがわかります。きちんと把握してコントロールしていくことが重要です。

ただ

技術的負債の経済的意味についての適切な認識

については、正直なところなかなか正確に見積もれることがない気がします。技術的負債を生むという選択をした時にそこまで見積もる余裕がない、あるいはあっても先のことなので詳細化しきれない、そういうケースが多いのではないかと。

技術者レベルでの技術的負債の可視化

  • 方法1: 障害管理システムに記録する
  • 方法2: 技術的負債を表すプロダクトバックログアイテムを作る
  • 方法3: 技術的負債バックログを作る

サイズが大きいものは方法2の方が時間をとって返済しやすく、サイズが小さいものは方法3の方が「フィーチャーよりも優先度が低くていつまでも返済されないということがない」ので返済しやすいようです。

技術的負債の返済

  • 作業中に偶発的な技術的負債が見つかれば対応できるところまで対応する。
  • スプリントごとに既知の技術的負債のいくつかを返済対象として対応する。価値をもたらすフィーチャーの開発と関連するものを一緒に進めることで金利の高いものから勧められる。

あたりがポイント。

「技術的負債返済スプリント」だとか「リファクタリングスプリント」などといった言葉がチーム内で出てきたら、危険信号だ。

ということで、技術的返済のみに注力するのは価値を提供し続けるというのに反するで望ましくないとありました。

また実際のところ利息がほとんど発生しない技術的負債もあるので、きちんと見極める必要がありますね。

[ permalink ]
[ 12月13日全て ]

2017年8月2日 (水)

何もコミットしないスプリントで各自好きなことをする

インクリメントの完成に高いコミット意識をもって毎スプリント取り組んできている CS 開発チームがいくつか大きなリリースを終えたので、スクラムマスターと相談して今日からの1週間スプリントは「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良いことにしました。

リファクタリング・技術的負債の返済・開発環境の整備や、調査・学習・ドキュメントの整理など、いつものスプリント中にはなかなかできないことを各自でしてよい1週間です。

普段から持続可能なペースを意識してスプリントプランニングしていますが、それでも頑張り続ければストレスも溜まってくるでしょう。適切なタイミングでブレイクを挟むことで、バーンアウトを防ぎ長期的にデリバリーし続けられるチームでいられればと思っています。

ちなみにこの取り組みは去年別のチームが unwinding period と呼んでやっていたのを真似てみたものです。

今回スプリントがどういう感じだったのかは、いつも通りスプリントレトロスペクティブでふりかえってみます。

[ スクラム ]

[ permalink ]
[ 8月2日全て ]
月別インデックス

About

Naney Naneymx

Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

※本サイトの内容は個人的見解であり所属組織とは関係ありません。

Process Time: 0.058861s / load averages: 0.48, 0.51, 0.70