アクセスありがとうございます!次は「とあるエンジニアのエソラゴト」で検索して頂けると嬉しいです!
テクニカルスキル

あなたが達人プログラマーになる方法を知りたいなら、シンプルなコードを書く方法を教えよう

良いコードを書く達人と、悪いコードを書く凡人の違いは何か?

プログラミングは文法を覚えるだけでは、一人前と言えない

こんな経験はないでしょうか?

  • 書いたコードがバグっていて、頻繁に障害が起こり迷惑をかける。
  • 仕様変更があっても、コードを修正することが難しい。
  • 数カ月後に自分が書いたコードを見たら、なんでこういうコードになったのか思い出せない。
せっかく遊びたいのに勉強をして、やっとプログラミングの文法を覚えて、実際にプログラムを書いてみても、悲しい結果となる方も多いかと思います。

なぜ、こんなことが起こるのかと言うと、それは「悪いコード」を書いているからです。

  • コードレビューをしているけど、どういう観点でレビューをすれば良いのか分からないエンジニア
  • 最初に良いコードの定義を知って、ゴールから逆算して成長したい駆け出しエンジニア
  • 良いコードを書くために、知るべきプログラミング思想を知りたいエンジニア

悪いコードを書いてしまうのは、プログラミングの思想を知らないだけで、頭の良さの違いではない

プログラミングは自由度が高く、「つよつよエンジニアの方と駆け出しエンジニアの方が同じ処理のプログラムを書いたとしても、全然違うコードが出来上がること」があります。

駆け出しエンジニアから脱するためには、「良いコード」を書けるようにならないといけないのです。

では、良いコードを書くことは、才能なのでしょうか?

いえ、そんなことはありません。

「良いコードを書くというのは、才能ではなく、技術」です。考え方さえ学んで、あとは実践していけば誰でも身につくのです。

プログラミングの思想を知り、それを使って経験を積むことで、「悪いコード」から脱して、「良いコード」が書けるようになるのです。

読者
じゃあどうやったらいいの?

以降では良いコードを書くために知っておきたい考え方を記載していきます!

良いコードとは、「シンプルなコード」である

KISSの原則

KISS ~ Keep It Simple. Stupid ~
シンプルにしておけ、愚か者よ

引用元:https://ja.wikipedia.org/wiki/KISS%E3%81%AE%E5%8E%9F%E5%89%87

上記はプログラマーの間では非常に有名な「KISS」の原則です。

良いコードを書く時に最優先すべき事は、「シンプルさを保つこと」です。

プログラミングとは「複雑さとの闘い」です。

複雑なコードは自分でも何を書いていたか分からなくなってくるし、他人にとっては意味不明で、いわゆる「保守性の低いコード」であると認定されてしまいます。

実は、「複雑さな仕様をどうやって簡潔なコードに落とし込むか」がプログラミングの本質です。

このことだけでも、まず頭に入れておくと、良いプログラムを書くという下準備が出来て、「シンプルなコードとはどういうコードか?」ということを自然と考えられるようになると思います!

シンプルにする理由は「コードの変更がしやすい」ことだ

読者
なんでシンプルにしないといけないの?

それは複雑なコードは、「この箇所を修正すると、どういう副作用があるのか」が分かりにくく、簡単に修正をすることが出来なくなります。

レガシーな技術を使っているから保守できないのではなく、モダンな技術を使っていても複雑に処理が絡み合ったスパゲッティコードであれば、保守が出来なくなるのです。

私は、「コードが複雑なため、保守が出来ない、または修正と成果に対する費用対効果が悪くなったシステムのことをレガシーシステムと言う」のだと思っています。

将来的に色んな技術を触ってみたいと思っているのであれば、手遅れにならないうちにこの考え方を抑えておいた方が良いです。

コードをシンプルに保つ技術

1つのクラス、メソッドに複数の役割を持たせない

単一責任の原則(Single responsibility principle)(英語版)[6]1つのクラスは1つだけの責任を持たなければならない。すなわち、ソフトウェアの仕様の一部分を変更したときには、それにより影響を受ける仕様は、そのクラスの仕様でなければならない。

引用元:https://ja.wikipedia.org/wiki/SOLID
簡単に言ってしまうと、「色々な役割を持ったものをゴチャ混ぜにすることは禁止」ということです。

役割を複数持たせるとコードが複雑になりますし、変更しようとした際に複数の役割を持っていることに気づかず、障害に繋がる可能性があります。

例えば、1つのメソッドの行数が100行を超えるような場合は、「何か複数の役割を1つのメソッドに持たせていないか?」ということを自問自答してみましょう。

そうすることで、可読性の高い良いメソッドを作ることが出来るのです。

重複したコードを作成しない

DRY ~ Don’t Repeat Yourself. ~

繰り返すな

引用元:https://ja.wikipedia.org/wiki/Don%27t_repeat_yourself
「同じコードを重複して書くこと」は厳禁です。

よくあるのは、何かプログラムを書きたい時に、他人が書いたプログラムを安易にコピペしてしまうことです。

コピペするのではなく、共通関数として切り出しましょう。

コピペをしていると、そのコードを修正する際にコピペした分全てを修正する必要が出てきて、修正が難しくなります。

何か修正をする際、影響分析をすると思うのですが、コピペによって無意味な影響範囲がどんどんと広がることを防ぐことが重要です。

テストコードを書く

プログラムをリリースした後に、「やっぱりこういう実装の方が良かったな」と後から修正をしたい時があります。

その際に大切になるのが、修正対象プログラムに「テストコードはあるのか」という点です。

なぜかと言うと、プログラムを修正したらテストをする必要が出ます。

しかしテストコードがなく、手動でテストをする必要がある場合、お金と時間の折り合いがつかず、諦めるということがあります。

つまり、どんどんと「腐ったコード」になっていくのです。

テストコードを書くことで、積極的にリファクタリングをすることが可能になります。

リファクタリング (refactoring) とは、コンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理することである。

引用元:https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0)

読みやすいコードを書く

読みやすいコードを書くことで、結果的にシンプルなコードとなります。

そのためには、以下に気をつける必要があります。

設計の意図が分かりやすい命名をする

命名は他人がコードを読む際に、指針となります。

そのため、しっかりと考えて、意味のある命名をしなくてはなりません。

設計の意図が分かりやすい変数名、メソッド名、クラス名を付けることで、読みやすいコードになります。

具体的には、その変数やメソッド、クラスが果たす役割を名前として、命名します。

例としては、以下のような通りです。

命名をする時、以下のサイトが非常に参考になると思います。

codic: プログラマーのためのネーミング辞書

コメントで書くのは、「why」についてだ

コメントはコードを読む際に、非常に参考になる情報源です。

コメントをどれくらい書くかというのは、非常に難しい問題で、まだまだ議論の余地があるようです。

ただ、絶対に書くべきコメントとは、「why(なぜ、こういう設計をしているのか)」ということです。

whyが書かれているプログラムは、他人がコードを修正する際、修正可否の判断材料となります。

駆け出しエンジニアから中級エンジニアを目指して

良いコードとは、シンプルなコードであるということでした。

上記の考え方や原則を頭に入れながら、他人が書いたコードを見たり、実際に自分でコードを書くことで、どんどんとプログラムを書くのが上手くなっていきます。

ここで注意して頂きたいのは、知るだけではあまり意味はなくて、「実際に手を動かして経験を積む」ことで知識が手に馴染んできて、知恵となっていくということです。

知識がたくさんあるだけのご意見番になるのではなく、是非実践が出来るプレイヤーとなって、楽しいエンジニアライフをお過ごし下さい。

ありがとうございました。

参考図書

上記の考え方を学ぶための本です。
良書ばかりなので、よければ是非!

テクニカルスキル
最新情報をチェックしよう!