「コードはコミュニケーションの場である」という考え方
はじめに
コードを書く際、ただ「動けばいいや」となんとなく実装していませんか?
ほんの少し意識を変えるだけで、あなたのコードは確実に質が向上します。
この記事では、「コードはコミュニケーションの場である」という考え方について記載します。
なお本記事は、下記の書籍(以下「プリンシプル」)の内容に基づいています。
「プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則」上田勲 著
結論
常に「他の人はこのコードを見てどう感じるか?」と考えながらコードを書きましょう!
皆様も「あの人のコードは読みやすいな」と感じたご経験はないでしょうか。
いいエンジニアは、他の人を意識してコードを書きます。
なぜ他の人を意識する必要があるのでしょう?
詳しく述べていきます。
「コードはコミュニケーションの場である」とは?
「コードを書く」ということは「誰かにコードを見せる」ということです。
(誰か、の中にはあなた自身も含まれます)
従って、コードを通じて誰かとコミュニケーションをとっている、と考えることができます。
「プリンシパル」では、下記のように記載されています。
コードも、人に見せる「文書(ドキュメント)」です。
そして、「文書」の本質は「コミュニケーションツール」です。
プログラミング = コミュニケーションである、というわけですね。
コードを通じたコミュニケーションとは?
ソフトウェアは、「開発して終わり」ではありません。
むしろ、開発してからが始まりです。
保守・運用業務のご経験がおありであればわかっていただけると思いますが、既存のコードを読む機会は非常に多いです。
新規開発業務であっても、自分自身が直前までに書いてきたコードを読みながらコードを書いていくことになるでしょう。
コードを読むということは、コードを書いた人とコミュニケーションをとっているとも言えます。
「プリンシプル」では以下のように記載されています。
コードは、書く時間よりも、読む時間の方が圧倒的に多くなります。
長期的に見ると、ソフトウェアの寿命が尽きるまで、多くの人が何度もコードを見ることになります。
さらに、保守の時だけでなく、新規のコードを書いている時でも、書いてるそばから、直前に書いたコードを自分で読んでいます。
少し前の自分とも、コードを通してコミュニケーションしているのです。
つまり、コードを書く段階から読み手を意識する必要があります。
では、コミュニケーションを円滑にするためにはどうしたら良いでしょうか?
コミュニケーションを円滑にするには?
コードを読む側の視点に立ってコードを書く意識を持ちましょう。
「プリンシプル」には以下のように記載されています。
コードで良好なコミュニケーションを取るには、コードを書いている時、他の人のことを考えるようにすることです。
最初は、どうしてもコンピュータに正しい処理を行わせることの方に意識が囚われてしまいます。
そこで視点を切り替え、「他の人はこのコードを見てどう感じるだろうか?」と考えるようにします。
すると、問題と解決策について、新たな視点から見直すことができます。
「要件通りに動作する」だけでは良いコードとは呼べません。
読み手に親切なコードこそ、良いコードなのです。
良いコードは、読み手と良好なコミュニケーションが取れます。
では、コードで良好なコミュニケーションを取るにはどうしたら良いのでしょうか?
コードで良好なコミュニケーションを取るには?
「プリンシプル」によると、下記3項目を意識することで良好なコミュニケーションを取ることができます。
- 方法1. シンプル
- 方法2. 柔軟性
- 方法3. 結果の局所化
※ 他にも「繰り返しの最小化」「ロジックとデータの一体化」など、重要な項目が記載されていますが、長くなってしまうので本記事では割愛いたします。
どういうことか、順に見ていきましょう。
方法1. シンプル
コードはできるだけ複雑性を排除し、シンプルにしましょう!
コードがシンプルであるとは、そのコードから「余分な複雑性」が取り除かれた状態を指します。
「余分な複雑性」とは、コードが達成しようとしている目的の複雑さを反映した複雑性のことではありません。
コードをどうにか動かそうとして、格闘した痕跡による複雑性のことです。
保守・運用業務をやっていると、「何をしたいのか分かりづらいコード」に遭遇すると思います。
(私も経験があります……)
コードをシンプルにすると、複雑性がなくなり、読みやすいコードになります。
方法2. 柔軟性
コードは、必ず変更されます!
いつか変更される時のために、柔軟性を意識しましょう。
柔軟性とは何でしょうか?
「プリンシプル」には以下のように記述されています。
コードにおいての柔軟性とは、コードの変更の容易さのことです。
新しく追加するコードに対して、それを反発なく反動なく拒否反応なく受け入れられるということと、自身が壊れることなくクッションを持って受け入れられることの両方をイメージし、「柔軟」という表現が使われています。
コードを書く段階から、変更される時のことを考えておくことが重要です。
方法3. 結果の局所化
要は「モジュール化しましょう」ということです。
「結果の局所化」における結果とは、「変更の影響」のことです。
つまり「結果の局所化」とは、「変更の影響が、局所に留まるようにコードを構成する」ということです。
「結果の局所化」は、それが動機となり、多くの技術が生まれている、重要度の高い原則です。
例えば、モジュール化は、この目的のために生まれた技術の1つです。
モジュールは、そのモジュールの変更の影響を、モジュール内に留めることを目標の1つにしています。
どこかを変更したら、全然関係ない(と思っていた)処理が動かなくなった、というのはよくある話ですよね。
(私も経験があります)
変更の影響が最小限になるよう意識しましょう。
終わりに
本記事では以下の点についてお伝えしました。
- コードを書く = コミュニケーション!
- 読み手を意識して良好なコミュニケーションを取ろう!
今回お伝えしたことは「プリンシプル」のごくごく一部にすぎません。
「プリンシプル」には、他にもエンジニアのためになる知識やノウハウが詰まっています。
興味を持っていただけましたらぜひお手に取っていただければと思います。
それでは。