投稿の経緯
そろそろエンジニアになってから一年程度経過するので、原点回帰の意味を込めて自社内でLT会で発表しました。
その内容をQiita上でもまとめようと思いました。
3大原則
・DRY
・KISS
・YAGNI
に関してまとめました。
DRY
DRY
DRY ＝ Don’t Repeat Yourself ＝ 「重複させるな」
コードやなんらかの設定値や設定ファイル、データベースやスキーマファイル*などを重複定義したり多重管理せずに、どこか一箇所だけに定義して管理するようにする。
スキーマファイル: 現在のデータベースの構造を記録したファイル。
なぜDRY化が必要なのか
後でコードや設定値などを変更する時に複数の箇所を同時に改修しないといけなくなり、変更漏れが高い確率で起きるようになり、不具合が発生してしまう。
仮に定数化したURLをたくさん使う場所があっても、一箇所を変更することで終わる
⇨保守性の向上
次に見た人がわかりやすい
⇨’https:login.yahoo.co.jp/config/login’はYahooにログインするために必要なんだな〜
KISS
KISS ＝ Keep it simple, stupid! ＝ 「シンプルにしろ、ばかやろう！」
もともと航空機(パイロットなど)の格言が、ITエンジニアでも広まったもの。
プログラミングは自由度が高いので基本やろうと思えば、複雑なコードもかけるがシンプルなコードを書くようにする。
興味本位や自慢のため無駄に高度なコードを書かないように。
新しく入った人が見づらく、改修や新規開発がしづらくなる。
YAGNI
YAGNI ＝ You ain’t(aren’t) gonna need it ＝ 「それは必要にならないよ？」
「どうせ使わないよ」
「今の段階で必要ではないが、あとで必要になるかもしれない」と思って書いたコードや機能はほとんどの場合使われない。
YAGNIの具体例
例えば、二種類のデータベースの方式があります。
1、規模に応じてよしなに調節してくれるデータベース
(NoSQL系、DynamoDBなど)
2、大量アクセスを捌くには特別な処理をさせないといけないデータベース。
o (RDB) (みんせつはこちら)
一見1のデータベースの方が良さそうに見えますが、
：大量のデータを捌くようになって初めてメリットが得られる。
：トランザクション機能*が使えなかったり、複雑なクエリを実行できなかったりめんどくさい。
トランザクション機能: 複数のテーブルに処理を行うクエリを投げた時、もしどこかでエラーが出てしまってもクエリを投げる前の状態に戻してくれる
将来的な規模拡大を考慮して、メインのデータベースに1を採用したことにより、改修したり新規開発する時間が長くなってしまうため、
他の競合サービスに敗れて大量アクセスが来る前にサービスが倒産してしまう。
最初から1を使うのではなく、2を使って、もしユーザー数の規模が大きくなって処理が大変になったら、部分的に1を使うようにする。
しめ
以上3大原則をまとめた元です。
参考(というかほぼパクリです。)
DRY原則/KISS原則/YAGNI原則について説明します。
https://www.youtube.com/watch?v=nE-AiOkzY70&t=60s