ある日、こんな案件がありました。
A, B, Cの3つの会社があります。
Aの会社で特別なデータを取り扱いたいため条件分岐を使ってAの会社だけ特別な処理を行わせたいです。
あなたなら今回のケースで、将来B, Cの会社にもすぐに対応できるように実装しますか？
実装するときに拡張性を持って実装することは確かに大事です。
では今回は実装するのが正解なのでしょうか…？
こういう場面はエンジニアで仕事をしていると何度も何度も起こります。
そういった迷う場面には昔から「こうした方がだいたい上手くいく」という規則が存在します。
今回はそういった原則を紹介していこうと思います！
YAGNI原則
You Aren’t Going to Need It.
それはきっと必要にならない
https://ja.wikipedia.org/wiki/YAGNI
冒頭の例の場合、YAGNI原則から実装すべきではないと判断することが出来ます。
Aで起きたからB, Cでも同じようにやった方が後々良いだろうは基本的に実装すべきではありません。
直近の予定でB,Cも変わる可能性が十分にあるのであれば実装しても良いと思いますが、「いつか必要になるだろう」は基本的に無駄になります。
仮に複数化の対応が必要になった時、再びあなたが担当だった場合なら良いのですが、もし違う人が担当になった場合、その時のあなたの意図は担当者には伝わらず、読みにくいコードだけが残ります。
実装した時間が無駄になるだけでなく、たった1つだけの条件だったはずなのに複数対応の処理が含まれていたらコードの読みやすさも落ちてしまいます。読みにくいコードは不具合の原因にもなります。
YAGNI原則に基づき、コードは必要最低限にしましょう。DRY原則
Don’t Repeat Yourself.
繰り返すな
https://ja.wikipedia.org/wiki/Don%27t_repeat_yourself
「コードを乾かせ」でも「forを使うな」じゃないですよ👀
一言でいうと「コピペするな」です。
なぜコピペがダメなのでしょうか？考えたことありますか？
「コピペすると勉強にならない」とか「コピペは処理が適さない場合可能性があるからバグる」とか色々意見があります（間違ってはいないと思う）が、ここでの一番の問題はコードの管理が難しくなるからです。
繰り返し使う値は変数にまとめよう
例えば以下のようなコードがあったとします。
これでも正しく動きますが、ここで参加者が5人減って、お金が税込み分の30円増えたとしましょう。
そうなった場合、どの300を295に変更して330に変更するか分かりにくいですよね？
以下のように定数を設定するとぐっと読みやすくなり、不具合も防げそうな実装になったと思います。
「この数字は繰り返し使いそうだ」と思った数値は変数や定数に保存しておいて、1箇所の変更でまとめて更新できるようにしましょう！
似た処理はできるだけ関数にまとめよう
例えばゲームで、とある攻撃を行った時の処理があったとします。
そこまで違和感がないと思います。
でもここで「攻撃したらComboカウントを増やしてほしい」という仕様が増えたとしましょう。
この状態のコードでは1つの漏れもなく全ての攻撃の関数にComboに+1する処理を実装しないと行けません。
では次のコードを見てください。
繰り返し行われている処理をattackBaseという関数にまとめてみました。
ダメージを与える処理の場合は必ずこの処理を使うので必ずcomboCountが増えることが保証されますね。
また攻撃処理の場合は「必ずエフェクトが出て」「必ずComboカウントが増える」という仕様がコードからわかると思います。
このように繰り返しを減らしていくと不具合を防いで、仕様の把握もしやすくなります。
コピペすることは絶対悪ではないのですが、この処理まとめられそうだなと思うところは積極的にまとめていくことが書く上で大切です。
DRY原則に基づき、コピペをせず、まとめられる処理はまとめよう。ちなみにDRYの反対の状態のコードを「WET（Write Everything Twice.）」と表現することもあります。
興味があればこちらも調べてみてください〜
KISS原則
Keep It Short and Simple.
簡潔かつ単純にしておけ。
https://ja.wikipedia.org/wiki/KISS%E3%81%AE%E5%8E%9F%E5%89%87#:~:text=KISS%20%E3%81%AE%E5%8E%9F%E5%89%87%20(%E8%8B%B1%3A%20KISS,Keep%20it%20simple%2C%20stupid.%E3%80%8D
「キスしろ😘」じゃないですよ👀
一言でいうと「複雑な処理を書くな」です。
ベテランエンジニアは難しい処理をガンガン書くイメージがありますが、本当に良いエンジニアは読みやすいコードを書くエンジニアです。
プログラムを書くときに大事なことは「今の処理がどうなっていて、そこにどういう処理を書くと機能を追加できるかを判断すること」です。
プログラムを書く時「コードを読むこと」が一番大切な工程になります。
読みやすいコードを書くことに手を抜かないでください。
チームのメンバーや数ヶ月後の自分自身が、書かれたコードを理解できずに時間を掛けて読む羽目になったり、不具合の原因になったりするのを防ぎましょう。
読みやすいコードに関してはリーダブルコードなどが参考になります。
また、簡潔にしておいた方が良いのはコードだけではありません。
何かを作るための仕様も出来るだけ簡潔にしておくと開発のときに迷うことが減ります。
もしもあなたが仕様の決定に関わることが出来る立場であれば、簡潔に調整するように努めましょう。
クライアントは要望だけを伝えることに集中しすぎて完成形が整理されていない場合があるので、常にシンプルさを求めるエンジニアの経験はきっと活かされるはずです。。
KISS原則に基づき、簡潔な処理・仕様を心がけよう。エンジニアの勉強はコードの書き方だけじゃない
今回は比較的有名な3つの原則を紹介しました。
無駄なことはせず、同じことを書かずに、簡単にしておく。
「頑張る」とは相反する原則なんですよね笑
そういった考え方をエンジニアの三大美徳なんて言ったりします。
とりあえずで100行のコードを書くことよりも、よく考えた上でわかりやすく価値のある10行のコードを書きましょう！！
今回紹介した原則をもっと知りたい方は プリンシプル オブ プログラミング という本があります。
確かに検索すれば出るのですが、そもそも原則の名前を知らないと検索が出来ないということもあるのでこういう本から学ぶこともおすすめします！
ここまで読んで頂きありがとうございました！
コメント