📖

【必見】プログラミングを学ぶ上で絶対に覚えておきたい原則10選

2023/09/22に公開

はじめに

DRY, KISS, 車輪の再発明, などなど...
プログラミング界隈には、一見「???🤔???」となるような、原理原則がたくさんあって困惑しますよね。。。
今回は備忘録的に、特に有名だと思った10個を独断でピックアップして記録していきます。

1. DRY


Don't Repeat Yourself.
同じ内容のコードを複数箇所に書いてはいけない。(1箇所にまとめるべき)
同じ内容のコードは1箇所にまとまっていた方が、手直しが発生した場合に修正が容易になります。
複数箇所に散らばっている場合は、その数だけ修正が必要になるためミスが発生しやすくなります。




2. KISS


Keep It Simple, Stupid.
コードをシンプルに保つ。(無駄なコードを書かない)
自分の興味で新しく覚えた技術を使ってみたり、仕様書にないけど将来必要になりそうなコードを書いてみたり、本来必要なもの以外を書くと、コードが無秩序になるので、必要なものだけを書いてコードは常にシンプルに保ちましょう。




3. YAGNI


You Aren't Going to Need It.
コードは必要最低限のみ記載する
「たぶん必要になるだろう」「必要になるかもしれない」
というコードを書いておいても、結局利用されないものがほとんどです。
コードは「今」必要なものだけを記載しましょう。




4. 車輪の再発明


既にあるものを、もう一度作ること
Rubyのgemやライブラリなど、既に世の中に出回っているものを自分で再発明してしまうことの比喩です。
学習目的でに再発明をあえて行うことは是ですが、通常業務において再発明は推奨されていません。
「車輪」を知らない場合は、知識不足なので、それを補いましょう。
「車輪」を作りたい場合(プログラマのエゴ)は、コードが複雑・属人化するので、既知のものを使いましょう。




5. プログラマの3大美徳


プログラマは「怠惰」「短気」「傲慢」であれ

「怠惰」
面倒・繰り返しの作業は自分でやらず、怠惰になれるようにプログラムで自動化すること。
そうすることで、全体の時間・労力が削減され、正確性も保証されます。
「短気」
コードが意図通りや効率的に働いていなかったら、短期になり、すぐに書き直すこと。
そうすることで、コードが常に正しく保たれます。
「傲慢」
誰に見せても恥ずかしくないコードを書き、責任を持つことで、仕事の成果について傲慢になること。
そうすることで、読みやすくシンプルなコードを保つことができます。




6. プログラミングに銀の弾丸はない

ソフトウェア開発において魔法のような解決策はないということ
ソフトウェアは、複雑かつ変化し続けるものです。
それに対応し続ける銀の弾丸は存在しないので、1つ1つの問題に地道にアプローチして解決していくしかありません。




7. ラバーダッキング

説明する(言語化する)というデバッグ手法
写真のようなアヒル(ラバーダック)に対してでも、人形でも、同僚でも、自身で書いたコードを言語化して、順を追って説明すると、コードの矛盾点などを新たに発見することがあり、疑問点の解決や、エラーコードの発見につながります。
言語化して説明するという単純な行為が、効果的なデバッグになります。




8. 割れた窓の法則

悪いコードはソフトウェアを腐敗させる
ソフトウェアに「割れた窓」(悪いコード)が少しでもあると、修正や機能追加をするプログラマも、それに影響され、ソフトウェア全体に腐敗が伝播してしまいます。
ソフトウェアのコードは常に割れた窓のない清潔な状態に保ち続けることが大切です。
cf. 割れ窓理論




9. 名前重要


命名は最重要課題
名前はコードを読む人へのUIです。
適切に命名されているコードは「何を」「どのように」行なっているかを理解できます。
メソッド名を見ただけで概要が把握できたり、変数の持つデータの内容を理解できたり、開発者体験を上げてくれる基礎となります。




10. ボーイスカウトの規則


最初に来た時よりも、コードをきれいにして帰る
「自分のいた場所は、そこを出ていく時、来た時よりもきれいにしなければならない」というボーイスカウトの規則と同じく、コードも掃除してから帰ることで、コードの腐敗を抑止できます。
この規則をみんなが守ると、時間が経つごとにシステムの品質が徐々に向上していくこともあります。




出典

プリンシプルオブプログラミング
今回ご紹介した内容がより細かに掲載されています。
初学者の方にとてもおすすめです👌


さいごに

プリンシプルオブプログラミングを読んで、改めて原理原則ってパッと見よくわからないよなぁと思ったので、自分の備忘録も兼ねて書きました。
また、最近読んだ頭がいい人の脳の使い方で、アウトプットまで行ってこそインプットは定着する的なことが書いてあったので、その意図もあって書いてみました。
この記事があなたのお役に立ったのなら幸いです🍀


LCL Engineers

Discussion