「プリンシプル オブ プログラミング」を読んで意識していることまとめ(実例付き)

# プリンシプルオブプログラミング
名著「<a href="https://www.amazon.co.jp/%E3%83%97%E3%83%AA%E3%83%B3%E3%82%B7%E3%83%97%E3%83%AB-%E3%82%AA%E3%83%96-%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B03%E5%B9%B4%E7%9B%AE%E3%81%BE%E3%81%A7%E3%81%AB%E8%BA%AB%E3%81%AB%E3%81%A4%E3%81%91%E3%81%9F%E3%81%84%E4%B8%80%E7%94%9F%E5%BD%B9%E7%AB%8B%E3%81%A4101%E3%81%AE%E5%8E%9F%E7%90%86%E5%8E%9F%E5%89%87-%E4%B8%8A%E7%94%B0-%E5%8B%B2/dp/4798046140/ref=sr_1_1?ie=UTF8&qid=1517311561&sr=8-1&keywords=%E3%83%97%E3%83%AA%E3%83%B3%E3%82%B7%E3%83%97%E3%83%AB+%E3%82%AA%E3%83%96+%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0">プリンシプル オブ プログラミング</a>」を読みました.
このエントリでは, 「自分は実際にこの法則に基づいてこうするようになりましたよ」という @nossey 自身のパターンを紹介します.

## 必要最低限のコーディング
- DRYの法則
- KISSの法則  
「Don't repeat yourself」  
「Keep it simple stupid」  
とか良く言われますが, 具体的に一体どういう事でしょうか.

### コメント(DRYの法則)
いわずもがな, 同じロジックが複数箇所で使われるなら, コードのコピペは厳禁です.
ただ, ロジックに限らず, **コメントについても同じような意識をもつようになりました.**

```csharp:ダメなコメント例
public class Component {

    // コンストラクタ
    public Component(){
       ....
    }

    // 更新
    public void update(){
       ....
    }
}
```

**母国語に訳しただけのコメントはいらない**です.
これらのコメントに意図はなく. メソッド名の繰り返し(Repeat)でしかありません.   
また, メソッドやプロパティを追加するたびにコメントを書いていると, 「コメント書くのが目的」になり, コードはどんどん不要に複雑化していきます.

### C#におけるKISSの法則の例
コードを書く際に「明確な意図」をもつようになりました. 賛否両論あるでしょうが, 以下のコードを見て下さい.

```csharp:privateなNameの書き方
public class Person
{
    // 1.こういう書き方はせず
    private string Name;
    
    // 2.こういう書き方をする
    string Name { get; set; }
}
```

privateを書かない事でコード量が減らせます
(C#ではスコープに何も指定がない場合, 自動的にprivateになります)

「でもフィールドじゃなくプロパティにしてるせいでコード長くなってるじゃん!」という反論がありそうですね.
これにはちゃんと理由があって, 開発環境にVisual Studio **Enterprice Edition**で開発しており, **<a href="https://msdn.microsoft.com/ja-jp/library/dn269218.aspx">CodeLens</a>**の恩恵を受けたいからです.

CodeLensの恩恵を受けるにはフィールドではなくプロパティでなければいけないので, **意図して**```{ get; set; }``` を付けています.


と, ここまでつらつら書きましたが, 
- **「コード量を減らす努力をしているか」**
- **「明確な意図があって書いているか」**  
という二点が大事かと思います.

## 割れ窓理論とボーイスカウトの法則
### 割れ窓理論
まずは典型的な「割れ窓」を見てみましょう.

```csharp:まずい「割れ窓」
public Person{
    ...
    
    bool IsCertified()
    {
        ...

#if false
        // Utilのライセンスの判定処理がうまくいかない場合があるので, 一旦マスク
        if (!Util.IsRegisteredLicense(Name))
             return false;
#endif
        return true;
    }
}
```

この```IsCertified```に機能追加する人の心理を考えて見ましょう.

1. ```#if false - #endif```かぁ...意味ないコードがあって, 他も読みにくいな...
2. まぁ**もともと汚れてる**し, 機能追加の際に**ちょっと冗長なコメント書いても良いか**
3. (数週間後)コメントが冗長で読みにくいな...まぁ, **気づいた他の誰かにやらせりゃいいよね**

...あとは分かりますね.
「割れた窓がある状態で放置された物件は, 窓以外の箇所も汚くなっていく」という現象は, コードやプログラマーについても当てはまります.

これを防ぐ方法論の1つが, GitHub/GitLabなどを利用した「コードレビュー」や「Issue」です. 

### ボーイスカウトの法則
**「ボーイスカウトはキャンプ場から帰る際, 来た時よりも綺麗にして帰る」**

自分が機能を追加する際, 明らかに不要な箇所は一緒に消してしまうようにしました.
先ほどのコードと見比べて下さい.

```csharp:IsRegisteredLicenseを消して機能追加を行う
public Person{
    ...
    
    bool IsCertified()
    {         
        if (!PropertiesValid())
             return false;

        return true;
    }
}
```

僕「何かライセンス認証のUtilがバグってたので, Issue作りました.　Personからは該当処理消してます. 見ていただけますか?」
担当者「おk」

...とするのが良いでしょう.
プルリクエストの粒度として若干問題はあるかもしれませんが, **ついでに, 明らかに不要処理は削除**してプルリクエストを出すのは, ボーイスカウトの法則を活かした好例です.

## さいごに
銀の弾丸はありません. 本エントリで紹介した具体例も適さない場合などもあるでしょう.
しかし, 「おおよそ上手くいくであろう」というプログラミングの原則は, 言語が変わろうが活きてきます.
そういう意味でも, <a href="https://www.amazon.co.jp/%E3%83%97%E3%83%AA%E3%83%B3%E3%82%B7%E3%83%97%E3%83%AB-%E3%82%AA%E3%83%96-%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B03%E5%B9%B4%E7%9B%AE%E3%81%BE%E3%81%A7%E3%81%AB%E8%BA%AB%E3%81%AB%E3%81%A4%E3%81%91%E3%81%9F%E3%81%84%E4%B8%80%E7%94%9F%E5%BD%B9%E7%AB%8B%E3%81%A4101%E3%81%AE%E5%8E%9F%E7%90%86%E5%8E%9F%E5%89%87-%E4%B8%8A%E7%94%B0-%E5%8B%B2/dp/4798046140/ref=sr_1_1?ie=UTF8&qid=1517311561&sr=8-1&keywords=%E3%83%97%E3%83%AA%E3%83%B3%E3%82%B7%E3%83%97%E3%83%AB+%E3%82%AA%E3%83%96+%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0">プリンシプル オブ プログラミング</a>は間違いなく名著ですので, 是非読んでおきましょう. 
「3年目までに身に付けたい」なんて副題が付いてますが, 関係ありません.

「プログラミング方法論聞いても, 具体的にどうすりゃいいのかピンとこない」という人へ, 本エントリが助力となれば幸いです.