良いプログラムを書くために心がけたい、たった１つの事「FOF」

# 世の中にはプログラミングの原則がたくさんある

## 1. KISS
「Keep It Short and Simple.」
コードは短くシンプルにするやで

## 2. DRY
「Don't Repeat Yourself.」
繰り返したらあかん、コピペプログラムは禁止や

## 3.YAGNI
「You Aren't Going to Neet it.」
それ、きっといらんで

## 4.PIE
「Program Intently and Expressively」
エモいコード禁止
読みやすいコード書くンゴ

## 5. Naming is important
名前は大事やぞ
常に自分の子供に名前をつける感覚でいてや


etc...

# ちょっと思ってること

<ins>
この記事書いた後に<br>
そうそうこれこれという記事を見つけたので追記しました。<br><br>
</ins>

[あなたはDRY原則を誤認している？](https://qiita.com/yatmsu/items/b4a84c4ae78fd67a364c)

---

プログラミングの原則のDRYは結構怪しい
同じことを繰り返し書くな、コピペ禁止

これははごもっともだと思うんですが
この原則、正しく使われてない気がしています

なんというかDRYを意識しすぎて
なんでも共通にしようとする作用が強すぎるというか

<font color="red">**DRYを意識してるけど、YAGNI（それきっといらんで)を意識してない**</font>
そんなコードをよく見かけます。

commonじゃないcommonファイルとか
基底じゃない基底クラスとか

はい、話が逸れました。
戻ります。


# プログラミングの原則守られなさすぎ問題

上にあげた５個だけではなく、もっとたくさんの原則がたくさんあります

- そもそも原則が多い
- すぐ理解できないような原則もある
- 結局のところ守られてない

世の中は守りたい人と守れない人の攻防戦？

と、いろんな原則があるにはあるんですが
現実はうまく行かないですよねということで

僕は

<font color="red">
**まずこれ、まずこれだけ守ってください!
それ以外はとりあえず大丈夫なんで！**
</font>

と思う唯一無二の原則(<font color="red">**願い**</font>)を伝えたいと思います


# FOF(First, One File)

<font color="red">**「まず１ファイル」**</font>

お願いします、まず１ファイルだけで作ってください。
という原則(願い)です。

# どんなクソースであろうと１ファイルに収まっていればマシ

所構わず、そこら中にクソが飛び散っていても気にならない
という人はそうそういないですよね(と思っている)

大抵の場合はなんでそんなところで！？勘弁してくれ...
と思うはず

しかし、汚れているのがトイレだけ
トイレだけであれば

許しがたい気持ちもあるでしょう

でもですよ？
そこら中に飛び散っているよりはだいぶマシでしょう

<font color="red">
**汚れている範囲が限定される
これだけで心身の負担はとても軽くなりますし
掃除するのもだいぶ楽になると思うのです**
</font>

# プログラムの原則を適用するのはFOFの後でいい

まずプログラム初心者は

1. **１ファイルでとりあえず作って**
2. **先輩にレビューをしてもらい**
3. **KISSやDRYなどを適用して綺麗にしていく**

のがよろしいんじゃないでしょうか

すでにあるコードを綺麗にするわけなので
自ずと**YAGNI**の原則も達成されます。

そっちの方が理解もしやすいでしょうし
スキルも伸びることでしょう

# FOFはコードレビューの負荷を下げる

そうなる前にコードレビューしなさいよ
という話ではあるんですが

- おや、すごく固定的な処理がグローバルな共通処理にいるぞ？
- え、そのクラスの作り方はちょっと...
- う、うわぁ！もうあちこち組み込まれて出来上がってる！
- うーん、これは修正するより、０から作った方が早いんごねぇ...

こういうとき、レビュー辛くないですか？


逐一指摘をすれば機嫌を損ねてしまうプログラマーもいるし
もうよくね？って空気でたり(よくないよ！)

また、こういうコードが上がってくる場合は
基本的にコードの良し悪しという議論が成立しないことも多いですし
(良し悪しと好き嫌いの区別がついてないケースが辛い)

<font color="red">**不毛な争いはお互いに不幸です。**</font>

そうならないためにも
まずはFOF、１ファイルだけでコードを組んで
複雑になる前にレビューをするって大事なステップだと思うんです。

# FOFはクソースの承認を抑制する

納期や、修正コストなど様々な理由から
<font color="red">**クソースであっても承認してしまうケース**</font>もあるかと思います。

もちろん後で火を吹いて後悔するんですが
承認するときは承認するときの事情がある(言い訳)

しかしFOFであれば！

- 作る側も修正前提で作る
- レビュー側も修正前提で見る

gitを使っていると
とりあえず作ってるので大丈夫か見てくださいな(WIP)
という文化がありますが

<font color="red">**WIPなのに割と作り込んでてもう軌道修正厳しいわー
というつらみもあったりするわけです**</font>

FOFは意味のあるWIPを活性化させると思うのです。

# FOFのいいところ

**ルールが単純**
「とりあえず１ファイルで作ってね」という指示でOK

**レビューが簡単**
１ファイルじゃない時点で指示守れてないよね

**修正前提の原則**
修正前提でやっているので修正も指摘も精神衛生上楽になる。

**影響範囲がファイルスコープに収まる**
「Open-Closed Principle(OCP)」の原則
拡張が容易で、その修正の影響は受けない

ファイルの修正が容易であり、そのファイルを修正することで他に影響が出ない。


# まとめ

というわけで
もちろん最初から**KISS**や**DRY**などの原則ができていて
綺麗なコードであれば**FOF**なんていらないんですが

現実はなかなかうまくいかないものでして...

<font color="red">というか僕自身がうまくやれないので
とりあえず１ファイルでやるようにしてるんですっていう...</font>

プログラムができるようになり
オブジェクト指向がわかってきたと思い始めたあたりですかね

やたらとクラスを意識したり
共通化を考えたりするとどんどんあれこれ増えていって

<font color="red">**最終的に振り返ってみると
設計ミスったってなって修正するわけですよ
そういう事ないですか？**</font>

### FOFにすると勝手に守られる原則たち
- まず１ファイルってのがシンプル(KISS)です
- そしてそのファイルの中では同じことは繰り返さない(DRY)
- 必要な処理しか入ってないですし(YAGNI)
- 1ファイルだと読みにくくならないように気を使う(PIE)
- そして修正も楽だし影響も少ない(OCP)

という様々な原則が自動的に守られやすい

### FOFだと守れない原則

１ファイルだとクラス名や関数名が長くなりやすいので
**Naming is important**が厳しいです。

ですが、最終的にそこは分けようって目安になります。
FOFの後、綺麗にすればいいんです。

### 終わり

長々と語りましたが
**FOF(First, one file)の原則**、いかがでしたでしょうか


~Fin~