はじめに
わたしは社会人3年目のひよこエンジニアです。皆さんに撮って良いコードとは何ですか？わたしはコードを見たときにクラス、関数、変数がどのような役割を期待されているのかどうかが名前から把握できることです。しかし、良いコードの条件はそれだけではないということを後述の書籍から知りました。
今回は良いコード／悪いコードで学ぶ設計入門 保守しやすい 成長し続けるコードの書き方を参考に、今後のコーディングにさらに磨きをかけていきたいと思っています。
前提
本記事では上記書籍を読んでみた感想等を実際の業務にあっている内容のみ記載していきたいと思っています。そのため、書籍の要約かと思いきや、私自身に役に立つ内容ですので、ご了承ください。
全体的な感想
個人的に衝撃的だったのは、良いコードって名前の命名だけに気を付けていれば良いだけではないのか。。。という事でした。本書で述べている良いコードには、もちろん名前の命名もそうですが、そのほかのロジック的な観点も記載がありました。確かに言われてみれば、「確かにそうだ」と納得しました。
良いコード／悪いコードで学ぶ設計入門 保守しやすい 成長し続けるコードの書き方
自己防衛責務
クラスや関数にはそれ単体で動作するように設計することが推奨されます。なぜなら、仮に引数として不正値(想定しない値)が渡された場合エラーとなるからです。たとえば、消費税の計算をする関数に「-100」が渡されると計算がうまくされずエラーになってしまいます。
そのような問題を解消するために関数の最初に不正値を検知したら例外をスローするという処理を実装します。
Money (amount) {
if (amount < 0) {
throw new IllegalArgumentException ('金額には0以上を指定してください。');
}
・
・
・
}
イミュータブル
値はイミュータブル(不変)にして再代入を避けるということが推奨されます。なぜなら、途中で変数に値が再代入されると予期せぬエラーが怒ってしまう可能性があるからです。たとえば、引数として渡された値は正常値なのに途中で不正値が再代入されることでエラーが発生してしまいます。
そのような問題を解消するために新しい変数を宣言する際には定数を宣言するようにします。
const amount = 100;
DRY原則
DRY(Don't Repeat Yourself)と呼ばれる原則のことです。つまり、コードの重複を許すなという原則です。しかし、この原則は単にコードの重複を許すなという事ではなく、同一の概念から生まれるコードは重複を許さないという意味です。つまり、概念が違えばコードは重複してもよいという考え方になります。
概念が違う同一コード、もしくは似たようなコードだからとすべて重複をなくすと蜜結合となってしまいます。
技術以外の要因
わたしは個人的に技術以外の要因は大いにあると思っています。もちろん、天才集団の集まりであれば技術的に解決する方が早いでしょう。しかし、私を含め世の中の多くの人は天才ではないと思います。そもそも天才は母数が少ないから「天才」というラベリングがされるのです。そのため、そんな天才ではない平凡な技術者はどのような要因によりどのような問題が生じるのでしょうか。
コミュニケーション不足
同じ開発のメンバーで同じアプリケーションの実装をしていると仮定します。ソースをリリースし、テストを実施するとエラーばかり。生産性を上げるどころの話ではありません。むしろ、生産性が下がってしまいます。
本書ではこのような問題の原因はメンバー同士のコミュニケーションが希薄だからだと解説しています。確かに、メンバー同士のコミュニケーションが希薄だとメンバーが何を開発して、どのようなロジックで、どのような記述をしているかわかりません。それらを解決するためにコミュニケーションが必要だと認識しました。
心理的安全性
チームメンバーとコミュニケーションをとる(関係の改善)には、心理的安全性の向上が不可欠です。本書では、心理的安全性とは「自分が発現することを恥じたり、拒絶されるなど、不利益を被ることがないことをチームで共有されている心理状態」や「安心して自由に発言したり、行動できる状態」と記載されていました。つまり、安心できる環境ということですね。
したがって、心理的安全性を向上させることによって、自然とコミュニケーションが増え、チームメンバーとの関係が改善され、最終的にはエラーの数が少なくなるという結論に至ります。
さいごに
以上、書籍から印象が強く残っている内容を記載いたしました。内容が濃いため、全て紹介することはできませんが、ご容赦ください。