Kindleで技術書が最大70%OFFのセール中!詳しくはこちら

【達人プログラマーへの道】シンプルで良いコードを書く方法を解説

  • 書いたコードがバグっていて、頻繁に障害が起こり迷惑をかける。
  • 仕様変更があっても、コードを修正することが難しい。
  • 数カ月後に自分が書いたコードを見たら、なんでこういうコードになったのか思い出せない。

せっかく勉強して、やっとプログラミングの文法を覚えて、実際にプログラムを書いてみても、悲しい結果となる方も多いかと思います。

なぜ、こんなことが起こるのかと言うと、それは「悪いコード」を書いているからです。美しいコードを書ける人は、生まれつきの才能で書けるわけではなく、技術を習得しているから書けるのです。

この記事を読めば、達人と呼ばれるプログラマーになるために必要な「美しいシンプルなコードを書くための技術」について知ることが出来ます。

こういう人に読んでもらいたい
  • 最初に良いコードの定義を知って、ゴールから逆算して成長したい初心者のエンジニア
  • 良いコードを書くために、知ると差が出るプログラミング思想を知りたいエンジニア
  • コードレビューをしているけど、どういう観点でレビューをすれば良いのか分からないエンジニア
目次

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

良いコードの定義を言います。良いコードとは、シンプルなコードです。

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

初級エンジニアから中級エンジニアを目指して

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

良いコードを書くことが出来るかどうかが、初級エンジニアから中級エンジニアにキャリアアップするための登竜門です。

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

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

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

コードをシンプルに書く技術を学ぶ参考図書

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

この記事が気に入ったら
フォローしてね!

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

目次
閉じる