前置き
今年の目標に小規模～中規模のリファクタリングができるようになることを設定しました。まずコードの良し悪しの判断基準が明確に分からなかったので名著である『良いコード悪いコードで学ぶ設計入門』の内容を纏めることで今後のphp,Laravelのアプリケーションの開発に生かしたいと思いました。
1章 悪しき構造の弊害を知覚する
- 技術駆動命名や連番命名をしない
sample.php
class MemoryStateManager{
void changeIntValue01(int $changeValue){
$intValue01-=$changeValue;
//以下略
}
}
MemoryStateManagerみたいな関数の技術駆動命名結構してたかもしれない
他者から見ると意図がわかりにくいのか、知らなかった。注意する。
- 条件文の巨大なネスト
ネストが深くなると仕様変更などに時間がかかるという話
- 様々な悪魔を招きやすいデータクラス
DataClass.php
public class ContractAmount{
public int $amountIncludeingTax;//税込金額
public float $salesTaxRate;//消費税率
}
データクラスとは自由にデータの出し入れ可能な構造を持つクラス
(上だとContractAmountは税込金額と消費税率をpublicなインスタンス変数で持っている)
このデータクラスを用いて計算ロジックを別のプログラムに組んだ場合が以下
ContactManager.php
//契約を管理するクラス
public class ContractManager{
public ContractAmount $contactAmount;
//税込金額の計算
public calculateAmountIncludingTax(int $amountExcludingTax,float $salesTaxRate):int{
//計算
float $multiplier = $salesTaxRate+float(1.0);
float $amountIncludingTax *= $amountExcludingTax
return intval($amountIncludingTax)
}
//契約締結
public conclude():void{
int $amountIncludingTax=calculateAmountIncludingTax($amountExcludingTax,$salesTaxRate);
$contractAmount = new ContractAmount();
$contractAmouont.amountIncludingTax = $amountIncludingTax;
$contractAmount.salesTaxRate = $salesTaxRate;
}
}
データを作成するクラスであるContractAmount、データを計算するクラスのContactManagerが離れている(低凝集)ため、開発生産性が下がる以下の問題を引き起こす。
- 重複コード
同じロジックを別のメソッドに実装してしまう - 修正漏れ
重複コードが生まれるため、修正漏れが発生しやすくなる - 可読性低下
コードの意図が読みずらくなる - 未初期化状態(生焼けオブジェクト)の発生
ContractAmountは初期化の必要なクラスのため、代入する値によっては例外が発生する - 不正な値の混入
バリデーションロジックを実装する際、漏れが生じ無効な値が入りやすくなる
感想
エンジニアになって低凝集のコードを見たり、修正に苦慮することが最近増えてきたように感じる。私も結構そういうコードを書いてしまっているかもしれない。型付きに慣れていきたい。今後意識していく。
時間はかかるかもしれないが、この書籍の内容を全17章分一通りアウトプットしつつ良いコードの定義を理解することを今年中にやる。
参考書籍
良いコード悪いコードで学ぶ設計入門 著:仙塲大也