エンジニアの心得③

皆さん、こんにちは！

当方、都内のとあるITベンチャー企業に勤める中堅エンジニアのオリハラです。

今回は、システムエンジニアにとって、基礎的だけどとても重要なことである、コーディングのベストプラクティスついて簡単に触れていきたいと思います！

 

さて、注意書きが長くなってしまいましたが、コーディングにおけるベストプラクティスとはなんぞや？と疑問に思っている方向けに解説しますと、プログラミング言語での上手なソースコードの書き方のことを言います。

 

開発において（特に大規模な組織での開発）、ソースコードを書く際に、エンジニアの中ではいくつかの暗黙の了解となっている決まりがあります。それがこれから触れていく、コーディングのベストプラクティスです。これから取り上げるのは、そのごく一部（私が最も重要と感じた３つほど）なので、しっかり勉強したい方は、この記事を読んだ後も自分で調べてみましょう。

 

一つ目は、関数の行数は10行程度に済ます、です。

長いコードは個別にテスト可能な小さな単位に分割する必要があります。

知らない人が作った、ソースコードの中に一つの長ったらしい関数があるとします。そのソースコードを読んでやっていることを理解しろと言われた時、80行も100行もあると、誰でも読解するのに時間がかかり嫌になります。だから、できるだけ処理を最小限に分割して、分かりやすく組み立てる必要があります。メンテの面でもとても重要です！

 

二つ目は、マジックナンバーはハードコーディングせず定数化する、です。

文字列や数値で固定のプリミティヴ値（4であったり、”hogehoge”であったり）を設定する場合は、その値を定数化してあげて、その定数に適切な名称をつけてあげます。

そうすることで、その定数値が変更された場合は、定数となる変数に代入しているところだけを修正すればよくなるため、こちらもメンテナンスが非常に楽になります。これについては特に条件判定（if文の中）で、使われるのは避けるべきです。値が変わってしまうと、条件が通らなくなってしまったりするので。。

 

三つ目は、長いコードや複雑なコードが良いと考えるのをやめる、です。

こちらは一つ目と似たようなものですが、とても重要なベストプラクティスなので、取り上げました。

スタンドアローンの開発なら構いませんが、例えば、大規模な組織的な開発になると、コードの可読性が重要になってきます。

ここでいうコードの可読性を簡単に表現しますと、「ほぼ初心者でもそのソースコードをみて、処理の流れを把握できるくらいシンプルであること」です。

 

ではなぜ、コードの可読性が重要かというといいますと、大規模な人数で行われる組織開発では、各エンジニアのスキルが一律ではないのと、最初から最後まで、そのプロジェクトに参画している可能性が100％ではないことが理由に挙げられます。

自分がいくら卓越していて複雑なコードを書けるからと言って、複雑かつ長いコーディングを施すと、その箇所に修正が入るとき、後に引き継いだ人が読み解くのに困難を極めます。そして、読み解くことにたくさんの時間を使ってしまうと、プロジェクトの効率も下がってしまいます。そのため、できるだけソースコードは短く、シンプルであることが望ましいです。

 

これまでに三つほど、コーディングのベストプラクティスをご紹介しましたが、少しはお役に立てたでしょうか。実際、こういったところを全く気にせずにエンジニアとしての道を歩み続けてしまいますと、ただの自己満足コードを増やすことになり、プロジェクトとしてもお荷物的な存在になりかねません。。。（そのままマネージャーになってしまうと、ほんとうに恐ろしいです。。）

 

なので、エンジニアとしてこれからも働く方には是非とも注意していただきたいと思います！

 

さて、今回はシステムエンジニアとして、基礎的だけどとても重要なことである、コーディングのベストプラクティスついて触れてみましたが、いかがだったでしょうか。少しでも役立つ情報となれば幸いです！

 

今回は以上、またの更新を楽しみにお待ちください！

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