プログラムの処方箋～健康なコードと病んだコード

勉強会（第18回）
プログラムの処方箋
～健康なコードと病んだコード

2011/6/24 さがわ

もくじ
はじめに
病んだコードとは？
プログラミングで大切なこと
リファクタリングって何？
病んだコードの症状と処方箋
まとめ

はじめに
自分で書いた数ヶ月前のソースコードを久しぶりに
見たり、既存のシステムのソースコードを見て、
「何だこれ！？何がしたいのかわからない…。」
と感じたことはないですか？ありマウス。

そういうソースコードは「病んでいる」かもしれません。
今回の勉強会を通して、病んだ状態のソースコードが
どういうものかを十分認識して、
健康なソースコードが書けるようになりましょう。

はじめに
今回の勉強会で扱うプログラムの例は「Java」を
採用しています。
しかし、話題としては、どのプログラミング言語にも
共通することを取り上げています。

また、若干記述が変わりますが、「C#」等、
他のプログラミング言語でも書けるサンプルです。

プログラミングをするときに、

とりあえず動くことしか考えない
設計の機能を満たすことしか考えない

そんなふうにプログラミングされたソースコードは、
いつの間にかソースコードが病気にかかっている
かもしれません。
おまえが一番
あたしゎ大丈夫だょ！アヤシイ。。。

「でも、動くこと、設計を満たすことは
あたりまえなんじゃないの？」ちがうの？

それらは当たり前のことですが、
「保守」のことをよく考えて
プログラミングをしていないのが、
病気になってしまう原因です。

「病んだソースコード」とは…
内容がわかりづらく、変更のしにくい、

保守のしづらいソースコード

のことです。


プログラミングで大切なことは？
機能要件を満たしていること
正しく動くこと（バグがないこと）
「保守」のことをよく考えること

「保守」のことって、どんなこと？


運用が開始され、「保守」のフェーズで
必ず起こることが２つあります。

何かわかりますか？

それは… 残業と徹夜！


それは…
「障害」と「機能改善」
です。
この２つは、
「それが起こるのが早いか、遅いか。」
というだけで、必ず起こります。
Accidents will happen.


保守のことを考える。～１つ目
「障害」に対して、
障害を発見しやすくする
だいたいどの辺りかすぐわかるように！
修正をしやすくする
あちこちを直す必要がないように！


保守のことを考える。～２つ目
「機能改善」に対して、
機能改善、拡張をしやすくする
まだ必要のない機能をあらかじめ入れる必
要はないけど、予測をたてておく！
既存のコードをできるだけ変更しなくても
良いように！


「保守」フェーズを考えることは、
システム開発のどのフェーズにおいても、
とても重要です。
常に頭に入れておきましょう。

一歩進んだ技術者になるために…
「保守」のことを常に頭に入れよう！

ここで「リファクタリング」という言葉
に少し触れておきます。

リファクタリングとは、端的に言ってしまうと、
「病んだコード＝保守しづらいプログラム」を
機能はそのままに、
「健全なコード＝保守しやすいプログラム」に
書き直すことです。

適切な「リファクタリング」が
プログラムに対して適用されると、
プログラムがすっきりと分かりやすく、
保守のしやすいものになります。

ただし、リファクタリングには
気をつけなければいけない点があります。

リファクタリングは保守しづらいとはいえ、
いちおう動いているコードに対して行います。
ということは…
動いていたものが動かなくなる可能性がある。
再テストの必要がある。

…というリスクがあるので、
慎重に作業する必要があります。
キミのバグを直すほうが
めんどくさそうだな。よっぽどメンドクサイの！

リファクタリングにはコストがかかります。

しかし、適切なリファクタリングにより洗練
されたコードは、そうではないコードに比べて、
保守で発生する「障害対応」「機能改善」の
時間を大幅に削減できるので、
結果的にコスト安になるでしょう。

リファクタリングを避けなければいけない
場合もあります。
それは…
「変更よりも最初から書き直したほうが早い」
場合です。

あまりにもバグが多いコードは、
そのほうが工数削減になります。

まず、リファクタリングをする為には、
「病んだコード」と「健康なコード」が
どんなものであるかを知っている必要が
あります。

そもそも、最初から「健康なコード」が
書かれていれば、リファクタリングの
必要はありませんよね？

今回の勉強会では、
リファクタリング「最初の一歩」として、
「病気の状態＝保守のしづらいコード」
を知ることからはじめ、
最初からリファクタリングの必要ない、
健康なコードが書けるようになる
ことを目指します。

～こういうコードは要注意！

さて、ここからは「病んだコード」を
診断していきます。

あなたの病気レベルは？
私はもう死んでいる。。。

「風邪？肺炎？」
「インフルエンザ！？」
はたまた･･･。


インデントがグチャグチャ

へ？インデント！？
何スかそれ？


...
// 最大数まで処理したらループを抜ける。
int MAX_COUNT = 10;
int count = 0;
while(count < MAX_COUNT) {
if (flg==true) {
...
} else {
...
}
for (int i=0; i<list.size(); i++)
...
}
count++; // カウントを1増やす。
}

「あれ？なんか無限ループしちゃうんだけど、何で？」


...
int MAX_COUNT = 10;
int count = 0;
if (flg==true) {
...
} else {
...
}
for (int i=0; i<list.size(); i++)
...
} ←このカッコ、for分に対応するようで、実は「while」のカッコ。
count++; // カウントを1増やす。
} ←このカッコがWhileに対応するようだけど、実は違うカッコらしい


...
int MAX_COUNT = 10;
int count = 0;
if (flg==true) {
...
} else {
...
}
for (int i=0; i<list.size(); i++) {
... ←処理が1行で終わる場合でも、カッコを付けるスタイルが
一般的には好まれる。
}
} ←whileの開始に揃えてインデントを記述する。
count++; // カウントを1増やす。 ←この行は「whileの外」なのがわかります。
}


「インデント」が揃っていないだけで、
プログラムの可読性が著しく低下します。
グチャグチャ
ぜったいダメ！

プログラムは必ずきちんとインデントする！

インデントを「タブ」または「スペース」とするか、
インデントの幅をいくつにするかは、
開発プロジェクト内で統一しておきましょう。


重複したコード

何？ショートカット・キー？
「Ctrl + c」「Ctrl + v」とか超好き。


// 正社員を出力
ArrayList empList = getEmpList();
Iterator it = empList.iterator();
while (it.hasNext()) {
String empName = (String) it.next();
System.out.println(empName);
}
// 協力会社を出力 ※バグあり
ArrayList empList2 = getEmpList2();
Iterator it2 = empList2.iterator();
}

「”社員名(empName)”にフリガナを付けて出力したいんだけど…。
もしかして、出力箇所を全部修正？（涙」
「似たような名前のメソッドがあるけど、なんかやな予感…。
やっぱり…両方直すのか…。欝だ。」


ArrayList empList = getEmpList();
Iterator it = empList.iterator();
String empName = (String) it.next(); 同じような処理が存在。
} 同じような処理が2箇所以上

// 協力会社を出力
あった場合、共通化を考える。
ArrayList empList2 = getEmpList2();
Iterator it2 = empList2.iterator();
while (it.hasNext()) { ←上の処理で利用した変数を利用している。(バグ）
バグ発見！
}


outputEmployeeNameList(permanentEmpList);
// 協力会社を出力共通化することで、
outputEmployeeNameList(partnerEmpList);
多岐に渡る修正等が発生しに

※共通可したメソッドくくなる。
public void outputEmployeeNameList(List<String> list) {
for (String s : list) {
System.out.println(s);
}
※余談ですが・・・
}
Iteratorを利用する場合、while文はバグの温床になりやすいので、
for文、可能であれば拡張forループ(JDK 1.5以降)を利用したほうが良いです。


「重複したコード」は、プログラムの
「コピー＆ペースト」で発生しやすいです。

プログラムの「コピペ」をする前に、
そのプログラムの意味をよく理解して、
できるだけ「共通化」を考えましょう。


分かりづらい命名

それにしても、FBは最高だな！！！
あ、そういえばHK、ほんとANだよな。


int akb = 48;
String h = c + ":" + n;

private void getENM(int akb) {
…
}

「”akb”って、なんやねん！！！」
「hには何が代入されてるんだろう・・・。」
「getENM…なるほど・・・わからん！」
「get？何が返ってくるのだろう…。え？戻り値なしかよ！w」


int akb = 48; ←書いた自分にしか分からないことは書かない。
String h = c + ":" + n; ←変数名が短すぎてわからない

private void getENM(int akb) { ←メソッドの役割と異なる名前
… ※getXXXなのに値を返さない。
}


int departmentNo = 48;
String headerName
= String.format("%s:%d", departmentName, departmentNo);

private void outputEmployeeNameList(int departmentNo) {
…
}

変数名は多少長くても、分かりやすく書く。
メソッド名やクラス名は役割にそぐった名前を付ける。


例外①…慣用句
for (int i=0; i<list.size()-1; i++) {
for (int j=0; j<list.size()-1; j++) {
for (int k=0; k<list.size()-1; k++) {
}
}
}

慣用的に使われるfor文の「ループ変数」等は、
「i, j, k」のほうがわかりやすいかもしれません。


例外②…スコープの短い変数
while (employeesRecordSet.next()) {
emp.setName(employeesRecordSet.getString("employee_name"));
}

while (rs.next()) {
emp.setName(rs.getString("employee_name"));
}

パッと見で処理が見渡せるようなケースで「スコープが短い変数」を
利用する場合、変数名が長いと逆に冗長かもしれません。


変数の命名方法にはいくつか「記法」が存在します。
Pascal（パスカル）形式
各単語の頭文字を大文字で記述する。
例）EmpName
Camel（キャメル）形式
各単語の頭文字を小文字で記述する。
例）empName
Hungarian（ハンガリアン）記法
型の情報だけで補えない情報を補う。
例）yenPay, dolPay
型の接頭辞を付与する。(iはint, sはString等)
例）iEmpCode, sEmpName


これは私の主観になってしまいますが、
通常の変数であれば、Camel形式に加えて「ドメイン」を
よく考えておいて変数名を付けると便利です。

「ドメイン」とは…型の集合のこと、DBの論理設計で利用されます。
下記の例のように、グループと型をあらかじめ決めておきます。
Name(名)…文字(32) Date(日)…日時
Type(種別)…文字(2) Amt(金額)…数値(BigDecimal)
ID(番号)…数値(int)
No(番号)…数値(int)
Flag(フラグ)…ブール(true/false)


「xxxNameはこの型」とドメインを決めておくと、プログラムを
読みながら、そこから変数の型をかんたんに推測できます。
※DBの論理設計とあわせて考慮すると、とてもコーディングがしやすくなる。

Name(名)…文字(32) …empName(社員名),userName(ユーザ名)
Code(コード)…文字(8) …categoryCode(カテゴリコード)
Type(種別)…文字(2) …categoryType(カテゴリ種別)
ID(番号)…数値(int) …empID(社員ID),userID(ユーザID),customerID(顧客ID)
No(番号)…数値(int) …salesNo(売上番号), lotNo(ロット番号)
Seq(通番)…数値(int) …orderSeq(注文通番), receiptSeq(領収書通番)
Flag(フラグ)…ブール(true/false) …deleteFlag(削除フラグ)
Date(日)…日時 …startDate(開始日), issueDate(発行日)
Amount(金額)…数値(BigDecimal)…salesAmount(売上金額)


変数名やメソッド名について記法をいくつか紹介しました。
ここではそれぞれを詳しく説明しませんが、
どれも一長一短あるので、
どれがすぐれていると一言では言い難いです。

しかし、どの記法を用いるにしても、
大事なことは、プロジェクトで記法を統一し、
わかりやすい名前を付けることです。


長～いメソッド

ん？メソッドを分割！？
男はだまって翌月一括払いダゼ！


private void DataGrid1_ItemCommand(object source, System.Web.UI.WebControls.DataGridCommandEventArgs e) |
DataView dv = new DataView(dt);
ViewState["Sort"] = dv.Sort = sort;
DataGrid1.DataSource = dv;

DataGrid1.PageSize = viewnum;
if (dt.Rows.Count < (DataGrid1.PageSize * DataGrid1.CurrentPageIndex))
DataGrid1.CurrentPageIndex = (int) (dt.Rows.Count / DataGrid1.PageSize);
if ((dt.Rows.Count == (DataGrid1.PageSize * DataGrid1.CurrentPageIndex)) && (dt.Rows.Count != 0))
DataGrid1.CurrentPageIndex = DataGrid1.CurrentPageIndex - 1;

DataGrid1.Visible = true;

if (dt.Rows.Count != 0) {
StringBuilder sb = new StringBuilder();
sb.Append(dt.Rows.Count.ToString()).Append("件");
FindRecordsLabel.Text = sb.ToString();
} else {
FindRecordsLabel.Text = AllegroMessage.S10002;
}

if (searchCondition.HasErrors) {
setMessageLabel(searchCondition.ErrorMessage);
}

「300行…508…1,078…。ま、まだ続いている！
い･･･いったい、どこまで続くというんだ！？」


private void DataGrid1_ItemCommand(object source, System.Web.UI.WebControls.DataGridCommandEventArgs e) |
DataView dv = new DataView(dt);
ViewState["Sort"] = dv.Sort = sort;
DataGrid1.DataSource = dv;

DataGrid1.PageSize = viewnum;
if (dt.Rows.Count < (DataGrid1.PageSize * DataGrid1.CurrentPageIndex))
DataGrid1.CurrentPageIndex = (int) (dt.Rows.Count / DataGrid1.PageSize);
if ((dt.Rows.Count == (DataGrid1.PageSize * DataGrid1.CurrentPageIndex)) && (dt.Rows.Count != 0))
DataGrid1.CurrentPageIndex = DataGrid1.CurrentPageIndex - 1;

DataGrid1.Visible = true;

if (dt.Rows.Count != 0) {
StringBuilder sb = new StringBuilder();

メソッドが長すぎると、
sb.Append(dt.Rows.Count.ToString()).Append("件");
FindRecordsLabel.Text = sb.ToString();
} else {
FindRecordsLabel.Text = AllegroMessage.S10002;

処理内容の把握がとても難しくなります。
}

if (searchCondition.HasErrors) {
setMessageLabel(searchCondition.ErrorMessage);
}

また、改修の影響範囲なども見えにくく
なってしまいます。


// 検索条件を設定する
Condition condition = new Condition();
condition.empID = 10;
// 取得した社員一覧を出力するコメントを書いた処理があった場合、
List<Employee> list = search(condition);
そのコメントを「メソッド名」とした
for (Employee employee : list) {
... メソッドにしてしまえば、
}
コメントもいらなくなる。

setSearchCondition();
outputEmployeesList(condition);


メソッドを短くするときは、
「コードを短くする」とは考えず、
「メソッド名とその実装の距離を縮める」
と考えるのがポイントです。

また、メソッドの分割を考えたとき、
「メソッドの命名に困ってしまう」ということは、
「そのメソッドにはまだ分割の余地がある」
ということです。


多すぎる引数

だって、貯金と引数は多ければ
多いほど良いってばぁちゃんが･･･


多すぎる引数
/**
* ｘｘｘを出力します。
* 出力内容は引数の社員種別とxxxフラグによって制御し、どうたらこうたら…
*/
private void printEmpInfo (
int empID,

ずらずらと引数が多すぎる。
string empName,
int empType,
...,
...
) {
...

「ど、どうやって使うんだこのメソッド・・・。」
「引数がたくさん・・・、わかりづらいなぁ。」


多すぎる引数
/**
*/
private void printEmpInfo (Employee employee) {
System.out.println(employee.getEmpID);
...

関連のある情報はクラスにする。
オブジェクトを引数に渡す。


多すぎる引数
メソッドに引数が多すぎる場合、
「引数にオブジェクトを利用する」と
きれいにまとまります。
渡す値が増えた場合でも、メソッドの
呼び出し元の修正が不要です。

反面、メソッドが「引数クラスに依存」してしまうという
デメリットもあることも意識しておきましょう。


不適切なコメント

◎ｘ☆＝ё！！！
Ж▽￡Ф＠￥Ё！！

通報しますた。


/**
* 出力内容はフラグによって制御し、どうたらこうたら…
* ○○の場合、ｘｘｘｘｘ。△の場合、ｘｘｘｘｘ。
* このケースの場合、ｘｘｘｘｘで、ｘｘｘｘする。
* それ以外の場合、ｘｘｘｘｘｘ。
*/
private void koreHaMuzukashiiSyoriDesuYo(…) {
// 最初にxxxxします。
...
// 下記の処理では、xxxをxxxして、その後xxxx。
...
// この変数にはxxxxが格納されているので、xxxxxの後にxxxxします。
...

「ちゃんとコメント書いてあるけど・・・んんっ！？」


/**
* 出力内容はフラグによって制御し、どうたらこうたら…
* ○○の場合、ｘｘｘｘｘ。△の場合、ｘｘｘｘｘ。
* このケースの場合、ｘｘｘｘｘで、ｘｘｘｘする。コメントを書くこと自体、
* それ以外の場合、ｘｘｘｘｘｘ。
*/ まったく悪いことではないですが、
private void koreHaMuzukashiiSyoriDesuYo(…) {
// 最初にxxxxします。
...
きをつけなければならないことが
// 下記の処理では、xxxをxxxして、その後xxxx。
... あります。
// この変数にはxxxxが格納されているので、xxxxxの後にxxxxします。
...


コメントはコードでは表せない説明の為に書きます。
「コメントがたくさん書いてある」ということは、
「それが分かりづらい処理である」ということです。

コメントを解りづらい処理の「消臭剤」の為に使ってはダメ。
そういった処理はそもそも、ロジックを見直しを検討が必要。
自分で「たくさんコメントを書いているな。」と思ったら、
いったん手を止めて、設計やロジックを見直しましょう。


コメントには、プログラムが処理を進めていく
具体的な方法を書くべきではありません。
処理内容の説明ではなく、
なぜそのように書かれているのか？
という理由や、
最終的に何が達成されるのか？
を説明する。
× // UserRegistryのデータでRegistryオブジェクトを更新する。
○ //登録情報を後で参照できるようにキャッシュする。


コメント
その他、コメントについては、

過去の勉強会
「第4回良い？悪い？コードコメントの書き方」

で詳しく取り上げています。
興味のあるかたは、そちらもご覧くださいな。

まとめ
常に保守のことを考えよう
障害対応、機能追加のことをよく意識しよう。
他人のため、数ヵ月後(数日後？)の自分のために、
読み安いプログラムを書くことを心がけよう。

リファクタリングの第一歩
まずはコードの健康状態（病んだコード、健康なコード）
を知ることからはじめよう。
できそうなところから、意識してコードを改善してみよう。
書きっぱなしではなく、何度もコードを見直して、
より良い状態に改善をしよう！（定期的な健康診断を！）

参考文献
Martin Fowler『リファクタリングプログラミングの体質改善テクニック』、ピアソン・
エデュケーション、2000年。
Joshua Bloch『Effective Java(第2版)』、ピアソン・エデュケーション、2008年。
Pete Goodliffe『Code Craft～エクセレントなコードを書くための実践的技法～』、毎日
コミュニケーションズ、2007年。
どれも良書ですよ！

プログラムの処方箋～健康なコードと病んだコード

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to プログラムの処方箋～健康なコードと病んだコード

Similar to プログラムの処方箋～健康なコードと病んだコード (20)

Recently uploaded

Recently uploaded (8)

プログラムの処方箋～健康なコードと病んだコード