コーディングのプロセス改善はコーディング規約とツリー管理から
コーディングのプロセスはまずコーディング規約とツリー管理から改善する
ソフトの品質は最終的にソースコードの品質で決まります。テストや設計レビューの影に隠れてしまい注目される事が少ないのですが、ソースコードを作成するコーディングプロセスは実はソフトの品質を良くするために結構重要です。では、コーディングプレセスを良くするには何をすれが良いのでしょうか？
コーディングプロセスの改善にも色々なポイトがありますが、この記事ではグータラ親父がコーディングプロセスの改善のために注意していた、コーディング規約、マスターツリー管理、単体テストの内容、コードレビュー の４つのポイントのうち最初の２つについて紹介していきます。これらのポイントに注意して、現状のコーディングプロセスで不足している所を見つけ出して改善していく事で、コーディングプロセスの品質を改善していく事ができます。
コーディング規約は決まっていて皆が守っているか
コーディング規約はソースコードを書くと時に守る必要のあるソースコードの書き方を決めたルールです。コーディング規約に従ってコードを書く事で、他のソフトエンジニアがソースコードを理解し易くなりコードレビューによる潜在バグの指摘の効率が良くなります。また、ソースコードが理解し易いという事は、ソースコードを書いた本人にとってもメリットは大きいです。ソースコードは、例え自分が書いたコードであっても、書いてから半年も経てばどんなソースコードを書いたのか忘れてしまいます。そんなタイミングで市場でバグが見つかると、自分の書いたソースコードを読み返して潜在しているバグを探すのですが、ソースコードが読み難いとなかなかバグを見付けられず、困った事になってしまします。そうならないように、ソースコードの理解のし易さを維持するための決め事がコーディング規約です。
コーディング規約にはコードの表示面での決め事（ルール）とコードの内容面での決め事（ルール）の２種類があります。変数の名前の付け方の規則などはコードの表示面についての決め事で、セキュア―コーディングガイドはコードの内容面での決め事です。コーディング規約としては、この２つの面の両方について決め事を作ってあるほうが、良いコーディン規約と言えます。
（１）コーディング規約で決めておくと良い表示面での決め事（ルール）
表示面での決め事にも色々ありますが、以下のような事はコーディングルールとして決めておくのが良いでしょう。
- 名前の命名規則：変数や関数の名前をどんな方法で付けるのか、大文字/小文字の使い方やハイフンやアンダースコアによる単語の区切り方などを決めておきます。
- 制御構造の表現方法：If や Whitch などの条件によってその後の処理を変えるような命令を書く時に、条件に合致した場合の処理と条件に合わなかった場合の処理を、ソースコードのどの場所に書くのかは、決めておきましょう。 if then の後の処理を if then の同じ行に続けて書くのか、1行改行して次の行に書くのか。次の行に書くなら先頭の文字は if then のどの位置に揃えるのか、この制御構造の表現方法が統一されているかいないかで、ソースコードの可読性が大きく変わります。
- ブロック構造の表現方法：制御構造と同じく、一連の処理を１つの纏まりにまとめるブロック構造についても、その表現方法を決めて置きましょう。C言語で言えば、 { } を使ったブロック構造を書く時に、ブロックの始まりと終わりを示す { や } を他の文と同じ行の前や後ろに付け足すのか、行を変えて書くのか、見栄えの問題ですがこれも可読性に影響します。
- インデントの使い方：TAB に代表される行さげ（インデント）を、どんな時に使うのかも、決めて置きましょう。同時に、インデントの位置は 4文字毎とするのか 8文字毎とするのかも決めておくのが良いです。
- ファイルコメントの様式：ソースファイルやヘッダファイルの先頭に記載するコメントにどんな事を記載するのかを決めておきます。ソースコードの所有権者の名前、ソースコードに対する品質保証の有無、ソースコードの改編・転用の可否や条件、ソースコードの製作者名、ソースコードの作成日時や改定日時、そのファイルのバージョン 等そのソースファイルの扱いに関する事を漏れなく書いておくようルールを決めるのが良いでしょう。
- 先頭コメントの様式：関数の先頭やひとつの機能モジュールの先頭に、その関数や機能モジュールを説明する先頭コメントを付けるのかどうか、付けるのならどんな事を書いておくのかを決めておきます。先頭コメントを付けるのなら、その関数や機能モジュールの機能とインターフェースと性能、利用時エラー応答の定義、その他の利用時の注意、等の項目を書くようにすると良いでしょう。
- 文中コメントの様式：ソースコードの中に短いコメントを散りばめる事について、実施するのかしないのか、実施するならばどんな場所にどんな様式でコメントを書くのかを決めておきます。文中コメントを付けるのならば、対応するソースコードを理解するための補足説明に加えて、そのコメントの作成者と記述日時も書くようにしておくのが良いです。
- コメントに使う言語：日本国内だけで開発・保守をするならば日本語コメントで良いのですが、不ショア開発や輸出先でのソフト保守が必要な場合には、コメントは英語で記述する必要も出てきます。どの言語でコメントを書くのかも、コーディング規約で決めておくと良いです。
（２）コーディング規約で決めておくと良い内容面での決め事（ルール）
コーディング規約では表示上の決め事とは別にソースコードの内容に関係する決め事もあります。多くは、コーディングのガイドラインとして提示されている事が多いのですが、コーディングのガイドラインにも色々なものがあります。自社のソースコードでは、どのガイドラインに準拠してソースコードを書くのか、採用するコーディングガイドラインをコーディングルールの中で決めて置くことが必要です。一例をあげると、以下のようなコーディングガイドがあります。これ以外にも色々あるのですが、どれを採用するのかは決めておくのが良いです。
- IPA が公開している「組み込みソフトウエア開発向けコーディング作法ガイド」
- Microsoft の定めている「C# コーディング規約」
- Google の定めている「Google C++ スタイルガイド」
- JPCERT/CC が公開している「CERT セキュアコーディングスタンダード」
- ORACLE が定めている「開発者のためのセキュアコーディングガイド」
- MISRAの設計ガイドを守るために必要な「MISRA-C コーディングガイドライン」
（３）皆がコーディング規約を守る仕組み
コーディング規約は決めたルールをソースコードを書く人が皆で守らないといけません。マスターツリーに登録される新規開発・修正したソースコードがコーディング規約に従っている事を確実にするための仕組みが不可欠です。一般的な方法は、コードレビューの時にコーディング基準に違反していないかという観点でもレビューをするという方法です。また、コーディングプロセスの中に、ソースコードの静的解析ツールの利用が取り込まれている場合には、表示面での取り決め（ルール）の多くは静的解析ツールのカスタムチェックポイントとして追加できる事もあります。何等かの方法でコーディング規約が守られている事を確認する仕組みがある事が大切です。
マスターツリーの管理手順は具体的に決まっていて正しく運用されているか
ソフトの開発にとってマスターツリーはとても重要です。特に、複数のソフトエンジニアが複数の開発拠点で分散して開発作業を進める事が普通になってきた最近のソフト開発では、マスターツリーの管理がしっかりとしていないと、ソフト解発の作業が効率的に進みません。マスターツリーの管理にとって大切な事は、バージョンの定義とツリー品質の維持の２つです。では、順番に見ていきましょう。
（１）バージョンの定義
ソースコードのマスターツリーは通常は製品毎に用意してその製品のソフトウエアのソースコードを管理します。そのマスターツリーでは、どんな種類のソースコードをどんな番号体系で管理するのか、というのがバージョンの定義で、このバージョンの定義を最初に決めて置く事が大切です。
バージョンの定義では次の２つの点について考えます。一つ目は登録するソースコードの種類です。マスターツリーに登録するのが、①新規の製品として開発中のソースコードを管理するのか、②完成した製品のソースコードだけなのか、③その両方を含むのか、が登録するソースコードの種類です。
大規模なソフト開発では、新規開発のチームと保守開発のチームが分かれている事もよくあります。このような場合では新規開発のチームは①の種類のマスターツリーを使いますが、保守開発のチームは②のマスターツリーを使います。小規模な開発では①も②も同じマスターツリーを使うので③になる場合も多いです。どれが良いという事ではなく、そのマスターツリーはどんな使い方をするのかを明確にしておく事が大切でです。
（２）ツリー品質の維持
マスターツリーは常に正常な状態に維持されていないと困ります。正常な状態とは、開発途中であればその時点でのベースラインとなるソースコードが維持されている事で、製品のリリース後ならばリリースしたソフトのソースコードが維持されている事です。
ソフトの開発では、マスターツリーから取り出したソースコードは正常な物という前提の元に、そこに新たなソースコードを付け足したり既存のソースコードを修正したりする事でソフトの開発を進めます。ですので、マスターツリーから取り出したソースコードがコンパイルできなかったり、コンパイルしても動作しなかったりすると、ソフトの開発が進みません。マスターツリーには常に正常なソースコードだけが登録されている事が必須です。
マスターツリーが常に正常なソースコードだけが登録されている様にするには、マスターツリーへのソースコードの登録に関するルールとその運用がきっちりと出来ている事が大切です。 例えばマスターツリーに登録するソースコードは、①事前にローカルツリーで動作確認が済んでいて ②必要なコードレビューが実施されていて ③取り出された時のマスターツリーから現時点までのマスターツリーの変更内容と今回登録するソースコードとが相互に影響しない事が確認されていて ④開発チームで決められた手順に沿って登録作業が進められている というような事が漏れなく実施される事が必要です。
また、ソースコードの登録作業については、個々のソフト開発エンジニアが決められた手順に沿って登録処理を行う場合もありますし、大規模な開発では個々のエンジニアがマスターツリーに登録するような運用だと、上記のようなルールが厳格に守られない場合もあるので、マスターツリーへの登録作業を専任者のみが行うような体制を採用する事もあります。
いずれにしても、マスターツリーの品質を維持するための手順やルールが決められていて、それを確実に守る仕組みがある事は、コーディングプロセスの品質として非常に大切です。
コーディングプロセスの改善では単体テストとコードレビュープロセスも大切です
コーディング規約とマスターツリー管理のプロセスが改善されたら、次は単体テストとコードレビューのプロセスの改善です。どちらも、組織やソフト開発エンジニアによってやり方が様々なので、開発チームとして統一されたコーディングプロセスが運用されているかどうかも含めて、品質の良いコーディングプロセスにしておく事が大切です。