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

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...

ちょっと思ってること

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

あなたはDRY原則を誤認している？

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

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

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

DRYを意識してるけど、YAGNI（それきっといらんで)を意識してない
そんなコードをよく見かけます。

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

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

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

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

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

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

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

僕は

まずこれ、まずこれだけ守ってください!
それ以外はとりあえず大丈夫なんで！

と思う唯一無二の原則(願い)を伝えたいと思います

FOF(First, One File)

「まず１ファイル」

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

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

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

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

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

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

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

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

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

まずプログラム初心者は

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

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

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

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

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

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

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

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

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

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

不毛な争いはお互いに不幸です。

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

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

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

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

しかしFOFであれば！

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

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

WIPなのに割と作り込んでてもう軌道修正厳しいわー
というつらみもあったりするわけです

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

FOFのいいところ

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

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

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

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

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

まとめ

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

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

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

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

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

最終的に振り返ってみると
設計ミスったってなって修正するわけですよ
そういう事ないですか？

FOFにすると勝手に守られる原則たち

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

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

FOFだと守れない原則

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

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

終わり

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

~Fin~

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