プリンシプルオブプログラミング
名著「プリンシプル オブ プログラミング」を読みました.
このエントリでは, 「自分は実際にこの法則に基づいてこうするようになりましたよ」という @nossey 自身のパターンを紹介します.
必要最低限のコーディング
- DRYの法則
- KISSの法則
「Don't repeat yourself」
「Keep it simple stupid」
とか良く言われますが, 具体的に一体どういう事でしょうか.
コメント(DRYの法則)
いわずもがな, 同じロジックが複数箇所で使われるなら, コードのコピペは厳禁です.
ただ, ロジックに限らず, コメントについても同じような意識をもつようになりました.
public class Component {
// コンストラクタ
public Component(){
....
}
// 更新
public void update(){
....
}
}
母国語に訳しただけのコメントはいらないです.
これらのコメントに意図はなく. メソッド名の繰り返し(Repeat)でしかありません.
また, メソッドやプロパティを追加するたびにコメントを書いていると, 「コメント書くのが目的」になり, コードはどんどん不要に複雑化していきます.
C#におけるKISSの法則の例
コードを書く際に「明確な意図」をもつようになりました. 賛否両論あるでしょうが, 以下のコードを見て下さい.
public class Person
{
// 1.こういう書き方はせず
private string Name;
// 2.こういう書き方をする
string Name { get; set; }
}
privateを書かない事でコード量が減らせます
(C#ではスコープに何も指定がない場合, 自動的にprivateになります)
「でもフィールドじゃなくプロパティにしてるせいでコード長くなってるじゃん!」という反論がありそうですね.
これにはちゃんと理由があって, 開発環境にVisual Studio Enterprice Editionで開発しており, **CodeLens**の恩恵を受けたいからです.
CodeLensの恩恵を受けるにはフィールドではなくプロパティでなければいけないので, 意図して{ get; set; } を付けています.
と, ここまでつらつら書きましたが,
- 「コード量を減らす努力をしているか」
-
「明確な意図があって書いているか」
という二点が大事かと思います.
割れ窓理論とボーイスカウトの法則
割れ窓理論
まずは典型的な「割れ窓」を見てみましょう.
public Person{
...
bool IsCertified()
{
...
#if false
// Utilのライセンスの判定処理がうまくいかない場合があるので, 一旦マスク
if (!Util.IsRegisteredLicense(Name))
return false;
#endif
return true;
}
}
このIsCertifiedに機能追加する人の心理を考えて見ましょう.
-
#if false - #endifかぁ...意味ないコードがあって, 他も読みにくいな... - まぁもともと汚れてるし, 機能追加の際にちょっと冗長なコメント書いても良いか
- (数週間後)コメントが冗長で読みにくいな...まぁ, 気づいた他の誰かにやらせりゃいいよね
...あとは分かりますね.
「割れた窓がある状態で放置された物件は, 窓以外の箇所も汚くなっていく」という現象は, コードやプログラマーについても当てはまります.
これを防ぐ方法論の1つが, GitHub/GitLabなどを利用した「コードレビュー」や「Issue」です.
ボーイスカウトの法則
「ボーイスカウトはキャンプ場から帰る際, 来た時よりも綺麗にして帰る」
自分が機能を追加する際, 明らかに不要な箇所は一緒に消してしまうようにしました.
先ほどのコードと見比べて下さい.
public Person{
...
bool IsCertified()
{
if (!PropertiesValid())
return false;
return true;
}
}
僕「何かライセンス認証のUtilがバグってたので, Issue作りました. Personからは該当処理消してます. 見ていただけますか?」
担当者「おk」
...とするのが良いでしょう.
プルリクエストの粒度として若干問題はあるかもしれませんが, ついでに, 明らかに不要処理は削除してプルリクエストを出すのは, ボーイスカウトの法則を活かした好例です.
さいごに
銀の弾丸はありません. 本エントリで紹介した具体例も適さない場合などもあるでしょう.
しかし, 「おおよそ上手くいくであろう」というプログラミングの原則は, 言語が変わろうが活きてきます.
そういう意味でも, プリンシプル オブ プログラミングは間違いなく名著ですので, 是非読んでおきましょう.
「3年目までに身に付けたい」なんて副題が付いてますが, 関係ありません.
「プログラミング方法論聞いても, 具体的にどうすりゃいいのかピンとこない」という人へ, 本エントリが助力となれば幸いです.