nDiki : リファクタリング

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

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

WiKicker 開発 ソースコード DiKicker ソフトウェアプロジェクトマネジメント Eclipse Subversion Perl 書評 C++ テスト駆動開発 インストール ソフトウェア開発 コンピュータ書籍 検索 GUI 開発ガイドライン Wiki 日本語 実装 Emacs フレームワーク テスト駆動開発入門 charset プリント NaneyOrgWiki Perl v5.8.0 プロジェクトマネジメント CVS MVC

■ 過去の今ごろ

過去の6月27日より。

• プロファイリング
  • リファクタリングで1つのメソッドが小さくなっていくと、どこで処理に時間がかかっているのかわかりにくくなりがち。

• ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)
• [ WiKicker ] 日記機能開発開始 (2003-12-27)
• 過去の今ごろ (2003-12-31)
• [ WiKicker ] もりもりリファクタリング (2004-05-01)
• テスト駆動開発入門 (2004-08-02)

■ テスト駆動開発入門

[ コンピュータ書籍 ]

契約による設計における段階的な表明を追加するプロセスの話などが昨日出た。 自分ももちろん assertion を書くのだが、それとは別に最近はテスト・ファーストによる開発がお気に入り。 しかしまだ「単体テストのカバー範囲」・「テストケースが充分であるか」・「リファクタリング時のテストの追随」などまだ勇気を持てていない部分がある。

ということで(テストとはまた別ではあるのだが)テスト駆動開発もちょっとチェックしておこうかと思い Kent Beck のテスト駆動開発入門を購入。

紙質も比較的チープ。 本屋でぱっと開いてみると細かいコードの断片が散らばっていて、何かプログラムの初学本っぽくてちょっとどうかなというのが最初の感じ。

しかし読み始めてみると面白く Part 1 までまず読み切った。 レッド/グリーン/リファクタリングのサイクルの中で、コードやテストが書き換わっていく様が非常にわかりやすい。 Martin Fowler のリファクタリング-プログラムの体質改善テクニックと同様細かい作業ステップを実演していて、雰囲気が良くわかる。

「テスト駆動開発はテストではなく開発方法である」というのも納得。

「動作するきれいなコード」を書くために続きを読もう。

[ 書評 ]

• テスト駆動開発入門読了 (2004-08-05)
• Scheme でプログラムを書く (2004-08-09)
• 創発 蟻・脳・都市・ソフトウェアの自己組織化ネットワーク 読了 (2004-07-09)
• 契約による設計と状態遷移モデルの抽出とか (2004-08-01)
• ソフトウエア開発 55の真実と10のウソ読了 (2004-06-08)

■ テスト駆動開発入門読了

短めなのですぐ読み終わった。 入門と銘打ってあるが、重要なエッセンスがカバーされているので1冊で結構テスト駆動開発の意味がわかると思う。

• グリーンにする(テストを通す)ために、アサートで期待する定数を返すようなメソッドをまず作ってしまう。

というのが衝撃的である。 自分でも実際そうした事はあるのだが何か罪悪感があった。 しかし TDD では続くリファクタリングのフェーズがあるので、悪ではない。

また

• 「テストの中とコードの中の重複を取り除く」リファクタリング

というのもなるほどという感じ。 コード中での重複はもちろん気を使っているつもりだが、テストとの重複というのは考えたことがなかった。

ぜひ実践してみたい。

[ 書評 ] [ コンピュータ書籍 ]

• テスト駆動開発入門 (2004-08-02)
• 創発 蟻・脳・都市・ソフトウェアの自己組織化ネットワーク 読了 (2004-07-09)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)
• LaTeX2e マクロ&クラス プログラミング基礎解説 (2005-04-28)
• Scheme でプログラムを書く (2004-08-09)

■ Perl でテスティングフレームワークを書いてみる

一昨日 Scheme で書き始めたのだが、やはり不慣れな言語でTDDをやってみるのも大変。

ということでPerlでやってみる。やはり最初はこちらの方が楽。 Perl では「これだ」という xUnit が無い。

• Test::Unit : メンテナンス停止中
• Test::SimpleUnit : 不明
• Test::Class : Test::Builder 系のテストフレームワークが必要

WiKicker は Test / Test::Harness を使用する標準的なテストを採用しているが、fixture の処理が面倒に感じている。 なので何か良い xUnit が欲しいのだが、テストのためだけに要求モジュールを追加するのもよろしくないので簡易的なものを自作するのも悪くないかも。

TDDはリズム感があって良いな。 まだリファクタリングフェーズでどの程度リファクタリングしてから、次のレッドフェーズにはいるかの匙加減がまた掴みきれていない。

• [ WiKicker ] 日記機能開発開始 (2003-12-27)
• WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
• Perl CGI プログラムのテストには WWW::Mechanize::... (2006-02-18)
• [ WiKicker ] SpeedyCGI (2003-10-17)
• [ Perl ] Devel::Cycle (2004-01-23)

■ WiKicker 0.24 半年ぶりのリリース

NaneyOrgWiki の方でバグレポートをいただいたのを機に、これを修正してリリースパッケージを作成。 リリースは昨年の6月6日以来、約半年ぶり。

バグ修正以外で、大きな機能追加は

• 書き込み禁止パターン指定機能

ぐらい。 内部的には若干リファクタリングが行われている。

おまけの DiKicker の方はちょこちょこ修正があるが、もともとまだきちんとドキュメント化していないので変更点もきちんとおっかけていない。 DiKicker も安定してきたし、正式版扱いにしてもいいのだが利用者はいるのかな。

• [ WiKicker ] 日記機能開発開始 (2003-12-27)
• DiKicker の出力する HTML コードを小さく (2006-10-05)
• [ WiKicker ] 久しぶりにメンテナンス (2004-04-02)
• 私的10大ニュース2004 [ web ] (2004-12-31)
• [ DiKicker ] フッタの処理を追加 (2004-05-03)

■ Algorithm::RabinKarp でソースコード中の重複を発見

blog.bulknews.net で紹介されていた、Algorithm::RabinKarp Perl モジュールを試してみた。

ハッシュを使って文字列検索を行う Rabin-Karp アルコリズムを実装しているモジュールで、モジュールをインストールすると rabin.pl というスクリプトが一緒にインストールされる。

これを使うと例えば

 rabin.pl '*.pm' lib > rabin.txt

で lib ディレクトリ内の *.pm ファイル全てのなかで重複する部分を発見してくれる(内部的には File::Find::Rule を使ってファイルを処理している)。 リファクタリング対象になりそうなところを探すのに便利そうだ。

実際使ってみると重複個所がいろいろ発見できて面白い。 ただ、

• 文字単位で、行の途中から/行の途中までを抽出するため、ソースコードの重複表示としてはちょっとみにくい。
• 出現回数が多い部分が先に表示される。

などちょっと出力が見にくい面がある(結果の上から見ているとなんだか気持ち悪くなる)。

とりあえず rabin.pl をいじって、最長文字列を先に表示するようにソートの条件を変えたりして遊んでみた。 モジュールの使い方を覚えてスクリプトを自前で書くと、自分好みの重複発見ツールが書けそうだ。

• Plagger で Twitter のあれこれをメールで通知 (2008-12-25)
• WiKicker 0.29 リリース - ビルドまわりの改良など (2006-02-13)
• Linux で使えるデスクトップ検索ツール Beagle でローカルファイ... (2006-08-08)
• WiKicker に JSON でのページ出力機能を追加 (2007-04-03)
• CGI プログラム、Out of memory! に泣く (2001-01-04)

■ ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler

ときたまやってくるソフトウェア開発の計画作成、今までは GanttProject を使っていたのだけれども、挙動が安定しないのと印刷機能が貧弱なのとで満足できていなかった。

ということで今回は新しいツールを使ってみることにした。チョイスしたのは TaskJuggler。

Linux 上で動くツールである。 GanttProject は Windows でも Linux でも使えるのが利点だったのだが、ここ数年の中でプロジェクトファイルを共有することも無かったので、まあ Linux だけでしか動かなくてもいいかなと。

@ テキスト形式でのプロジェクト記述

TaskJuggler が特徴的なのは、プロジェクトをテキストファイルで記述するところである。 一般的なプロジェクトマネジメントツールは GUI 上でガントチャートを直接編集したりできるのだが、TaskJuggler はそんな軟弱者向けの機能は用意されていない。

あくまでテキストで書く。プロジェクト・リソース・タスク・レポートをテキストファイルに書く。 でコンパイルするとガントチャート等のレポートが生成される。実績もテキストで入力する。

書き方に問題があればコンパイルエラーになるし、定義したタスクの依存関係等でプロジェクト期間からはみ出てしまうような時もコンパイル時に怒られる。 渋い。

@ TaskJugglerUI

とっつきにくく見えるが、慣れると以外とそんなに難しくない。 effort と length と duration の違いが分かればあとは楽勝。

TaskJugglerUI という GUI ソフトウェアでは、補完機能の優れたエディタが内蔵されているしサイドバーのリストからタスク等を選んで、対応する行に移動することもできる。

さながら Eclipse でコードを書いているような感じ。

下手にガントチャート上でタスクをドラッグアンドドロップして、日にちを動かすよりも思った通りに定義していけるので良い。

@ 印刷

ガントチャートについては、それなりに見やすいフォーマットの印刷物を生成してくれる。 印刷からプリンタとして「Print to File (PDF)」を選択すれば日本語も含めて問題なく PDF 化できるので、でき上がったものも配付しやすい(ここら辺は KDE 側の範疇か)。

GanttProject では PDF 出力がイマイチで結局、画像ファイルにエクスポートしてプリントアウト/配付していたのでこれは便利。

@ 面倒な点といえば

面倒な点があるとしたら、タスクに ID をつけてその ID で依存関係などを指定してあげなければいけない点か。 識別子を考えるのが面倒なのと、タスクの数が増えてきた時にその指定したい ID を探す(思い出す)のが面倒である。

あと、識別子の名前変更リファクタリング機能があればいいな (一括置換だと関係ないところまで置換してしまう可能性がある)。

@ ということで

ソフトウェアエンジニアには使いやすいツールだと思う。

マクロ機能やインクルード機能などもあるのでもう少し使いこんでみたい。

• http://www.taskjuggler.org/

• Evernote 使用開始 (2009-03-03)
• フォト イメージング エキスポ 2005 (2005-03-18)
• コミットメント・リスト vs ガントチャート (2005-10-19)
• amaroK で Linux 上の iTunes 音楽データを聞く (2006-01-22)
• GanttProject で開発スケジュールを作成 (2004-08-26)

■ 今日のさえずり - 「健康診断受けてもいいんですか?」と医者に言われた

• 15:13 これから健康診断。[mb]
• 15:24 健康診断に行く前にトイレにいってしまったことを思い出してあせった。[mb]
• 15:26 採尿、身長、体重、聴覚、視力まで完了。[mb]
• 15:47 問診、血圧、レントゲン、心電図、採血して、健康診断終了。[mb]
• 15:49 あっ、そういえば胴囲もはかった。[mb]
• 16:09 [photo] 家にあったロベール・ドアノーのポスターを貼った http://tinyurl.com/256wyy
• 18:17 SO905iCS ソフトウェア更新きてる。「プリインストールされていない『きせかえツール』をご利用の場合、特定操作を行うと、メニューのカーソル表示が一部されない場合がある。」
• 20:02 そういえば健康診断で「2週間前に風邪ひきました」といったら、「健康診断受けてもいいんですか?」と医者に言われた。[mb]
• 20:03 そういえば健康診断で、尿に血が混じっていたらしい。振り絞りすぎたか?[mb]
• 20:11 [photo] キョロペッツ http://tinyurl.com/235zvk
• 24:12 お客様の検索に関連する最近の上位キーワード ランキング「リクナビ」「sparknotes」「浜崎あゆみ」「spark notes」「xerox」「punyu」「ハローワーク」「アスクル」「痛い」「確定申告」
• 24:18 [B!] twitteriapp http://ti.eath.jp/
• 24:41 @k12u リファクタリングには単体テストが必要。

• 15:20 健康診断 (2008-03-18)
• 16:00 健康診断 (2006-02-27)
• 健康診断 (2004-02-02)
• 16:00 健康診断 (2005-02-21)
• 15:30 健康診断 (2007-03-16)

■ スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。

自分がプログラムをスクラッチから書き直したいと思った時、またスクラッチから書き直したいと言われた時のためにまとめておこう。

@ スクラッチから書き直したい理由

スクラッチから書き直したいと思う理由はだいたいこうだ。

• もっと良くできると思うから
  • 「もっと良いやり方がある」「自分ならもっとうまく書ける」
  • 「統一されていない」「もっと汎用的にできる」
  • 「今なら新しい開発環境(・新しい実行環境・新しいライブラリ・新しい言語)を使って簡単によりいいものが素早く作れる」
• よくわからないいから
  • 「何をやっているかわからない」「どう直していいかわからない」
  • 「もう直しようがない」
  • 「作り直した方がはやい」
• あいつのだから
  • 「あいつが書いたコードだから」

どんなプログラムでも開発が進み詳細がわかってくると、こうしておけば良かったと思う点がでてくるものだ。

さらに、他人が書いたプログラムだとよく分からない。

It's harder to read code than to write it. (プログラムというのは書くより読むほうが難しい。) -- Things You Should Never Do, Part I - Joel on Software

いっそ作り直してしまいたいと思うのはどの開発者でもあることだ。

@ スクラッチから書き直してはいけない理由

しかし多くの場合スクラッチから書き直すことはリスクとデメリットだらけだ。

• 今までの投資を失うから
  • 「そのプログラムには検討・不具合修正に膨大なエネルギーが投入されている」
  • 「ユーザは今のプログラムのために学習コストをかけている」
• 時間がかかるから
  • 「その新しいプログラムが今と同じレベルの価値を実現するまでは時間がかかりすぎる」
  • 「スクラッチし直してから投入したのでは、もはや価値を失っている可能性が高い」
• 前轍を踏むから
  • 「どう直していいかわからないと思う時は往々にして目標がわかっていない。目標がわからずに作ったものは結局またスクラッチから書き直したくなる」
  • 「あなたが連続的にプログラムを修正できないというのなら、どちらにせよ新しく作り直したプログラムもあなたは連続的にプログラムを修正できない」(リグレッションテストの習慣はあるの? リファクタリングスキルはあるの?)

ほとんどの場合は、漸進的に今のプログラムを修正・改良していった方が得策なのだ。

@ スクラッチから書き直してもいい場合

そうはいってももちろんスクラッチから書き直した方が合理的な場合もある(書き直してはいけない場合も書き直した方が合理的だと思ってしまうわけではあるが)。

それは次のような場合だろう。

• ソースコードがない場合 (ディスククラッシュした。利用する権利がなくなった)。
• もはや開発環境も実行環境も手に入らず、移植も困難な場合。
• 個人的な趣味のプログラムの場合。
• スクラッチから書き直したプログラムに対して、また「スクラッチから書き直したい」という欲求にかられない自信がある場合。

本当にスクラッチから書き直した方がよい場合は止める理由はない。

さてこの記事をスクラッチから書き直したいと思う時がきませんように。

@ 参考

• Joel on Software
  • Things You Should Never Do, Part I - Joel on Software
• はじめからやり直したい症候群
• 最上の日々 - なぜ最初から作り直したくなるのか
• [を] アホでマヌケな米国(アメリカ)ハイテク企業

[ ソフトウェアプロジェクトマネジメント ]

• ナノパーセント日 (2005-10-26)
• Joel on Software - 必読書 (2008-08-14)
• C++ 用ソースコードフォーマッタ Uncrustify (2009-08-10)
• 個人目標設定における課題 (2006-02-06)
• 事業方針を「どのようにすれば〜」化すれば何かが見えてくる (2006-01-05)

■ C++ 用ソースコードフォーマッタ Uncrustify

私が Perl が好きな理由の一つとして perltidy が存在しているという点がある。 perltidy のソースコード整形は柔軟にカスタマイズができて、自分の好みの整形設定を作っておける。 このツールおかげで後で整形できるので、荒々しくコードを書いてガンガンリファクタリングしていくことできる。

久しぶりに C++ の開発をするにあたって、C++ の同様のツールを探してみた。 perltidy のように長い式の折り返しを適切に調整してくれる整形ツールはあまり見つからない。いくつか試したところ Uncrustify にたどりついた。

• http://uncrustify.sourceforge.net/

@ 設定

 uncrustify -c /dev/null --update-config-with-doc -o ~/.uncrustify.cfg

するとデフォルトの設定が書き込まれた設定ファイルができる。 これを好みの設定に書き換えていく。

@ ソースコード整形する

 uncrustify source.cpp

とすると整形されたソースコードが source.cpp.uncrustify に出力される。

 uncrustify --replace source.cpp

とすると source.cpp 自体を整形されたソースコードで置き換えてくれる。

@ Emacs からの呼び出し

perltidy の時の設定(記事)で OK。 shell-command-on-region では

  uncrustify -l CPP -q

を実行するようにする。Uncrustify は標準入力からソースコードを渡す際にはどのプログラミング言語が指定してあげる必要がある。

好みの設定は現在模索中。 長い式の中の、引数なしの関数呼び出しの開き括弧と閉じ括弧の間で折り返されることがあってそれが気持ち悪いのだが、それ以外は好みの設定になりつつある。 もうちょっと設定いじってみて確定するつもり。

• Perl プリティプリンタの定番 perltidy (2006-04-23)
• Linux で使えるデスクトップ検索ツール Beagle でローカルファイ... (2006-08-08)
• スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスク... (2008-06-14)
• 今日のさえずり - 京都の小学校のコンピュータ室にいったら、Squeak が (2008-03-06)
• 今日のさえずり - これ Emacs なのよね (2010-01-26)