はじめまして、新卒2年目エンジニアのmiyoshiryです！
アイスタイル Advent Calender2021の12/8投稿分を担当させていただきます。

業務では@cosmeアプリ内などに表示されている記事フィードに関係する配信基盤の開発・運用をしています！

今回は先輩にコードレビューしていただいたときに知った「プログラミングの原則」について書こうと思います！

目次

• 概要
• プログラミングの原則
  • DRY原則
  • YAGNI原則
  • ボーイスカウトの原則

概要

1年目はUTや細かな改修がメインでしたが、2年目を迎え、新機能開発などにも携わる機会が増えました。
そうすると必然的に自分の書いたコードをレビューしていただく機会も増えたのですが、最初のうちはレビューでコメントが数十件になってしまうこともあり心が折れかけていました、、

そんなとき、先輩にプログラミングの原則について教えていただいたので、意識しながら実装したところレビューでの指摘がちょっとずつ少なくなってきました！
なので今回はそんなプログラミングの原則についてご紹介していこうと思います！

DRY原則

DRY原則は“Don’t Repeat Yourself”の略で、同じ機能や意味を持つ情報を複数の場所に重複して持たせるのはやめよう！という原則です。

同じ意味を持つ情報を複数の場所に持たせてしまうと、その情報を変更するときに出現箇所すべてを変更しなければいけません。
改修を行う際に変更箇所が多いとその分動作確認なども細かく行うことになります。

また、僕も勘違いしていたのですが、DRY原則はソースコードにおいての話だけではなくドキュメントやDBスキーマなども含むソフトウェア開発全体においての原則になります。

ソースコードの重複に着目した原則にOAOO原則（Once and Only Once）があります。

僕がこの原則を教えていただいたのは、画像を登録する機能に画像サイズの上限を設定する改修の時でした。
そのときは画像サイズの上限を指定する際にそのまま条件式にサイズを記述していました。

僕の場合、同じ意味を持つ情報の出現箇所が最初から複数あるケースはその情報を定数化するなどの方法で重複がないように意識はしていたのですが、最初の実装では一か所しか出現しない情報のときは直接書いてしまいがちでした。
しかし、DRY原則を教えていただいてからは「その情報が今後ほかにも使われる可能性があるか」というところまで考えて実装するようになりました！

メリット

DRY原則は特に大規模なサービスで効果を発揮します。
先ほども少し書きましたが、DRY原則に則ることで同じ意味を持つ情報が1つになるため、その情報を変更する場合は定義している箇所のみの変更でよくなります。
逆に同じ意味を持つ情報をまとめていなかった場合、サービスが大規模になればなるほど変更箇所も多くなってしまいます。

デメリット

DRY原則のデメリットとしては、小規模なサービスの場合「同じ意味を持つ情報を定義しておく、まとめておく」という作業が、「使用箇所でそれぞれ情報を持たせ、変更があった場合はその箇所をすべて変更する」という作業より時間や手間がかかってしまう可能性がある。ということが挙げられます。
なので、サービスの規模や役割によってはDRY原則を適用しないという選択肢も考えられます。

YAGNI原則

YAGNI原則は“You ain’t gonna need it”の略で、直訳すると「あなたはそれを必要としないでしょう」という意味で、機能追加は実際に必要になるまで行わないほうが良いというプログラミングの原則になります！

使わない機能はコードの複雑性や保守コストを上げてしまう一方で、利益を生み出すことがないため必要になってから追加したほうが良い場合が多いという経験則からきています。

僕がこの原則を教えていただいたのは、記事フィードの編集機能を実装していた時でした。
編集項目のデータの持ち方の関係上、「元データの削除→新規登録」という実装にしたのですが、仕様が変わり「データの更新」になったため削除機能は必要なくなりました。
ですが、僕的にはせっかく実装したので削除機能を残しても良いか先輩に相談したところYAGNI原則の存在を教えていただき必要になったら実装しようということになりました！
個人的にはいい感じに実装できていたので悲しかったですが、今後必要になった時にその処理のまま使える確証もなく、その処理のせいで考慮する箇所が増えてしまい変更しづらいサービスになる可能性があるということを考えると撤去して良かったかなと思います！

YAGNI原則のメリットとしては、必要最低限の機能のみのほうがコードがシンプルになり、変更などが容易になるということが挙げられます。
逆に、現在使わない機能でも今後追加になる可能性が高い場合はあらかじめ入れておくほうが良いこともあります。設計段階で入れておくほうが実装が容易な場合があるからです。

なので、YAGNI原則も必ず適用したほうが良いというわけではなく、適用するかしないかは考えて決める必要があります。

ボーイスカウトの原則

ボーイスカウトの原則は、「来た時よりもきれいな状態にしましょう」という原則になります！
名前のとおりボーイスカウトの「来た時より山をきれいにして帰りましょう」という精神にちなんでいます。

例えば機能の改修などを行う際に、改修を行うクラス内の別のメソッドのリファクタリングを合わせて行う、というようなことがこの原則に当てはまります。

こちらの原則は先輩が実践しており、先輩のコードをレビューしているときに知りました！
今はまだ改修した箇所の周辺のリファクタリングをする余裕がないときが多々ありますが、この原則を少しずつ実践していけるように精進します！

最後に

今回はプログラミングの原則の一部をご紹介させていただきました！

プログラミングに関する原則はご紹介した3つ以外にもたくさんあるので興味がある方は調べてみてください！