正しくソフトウェア開発をするためには、最低限の知識を抑えておく必要があります。 正しい手法を知らないままに実装を行うと、実際にソフトウェアを使う段階で色々と不都合が出たり、そもそも開発ができなかったりします。 まずは正しい知識を身につけましょう。
開発プロセスを知る
まずはソフトウェアを開発するための標準的なプロセスを知る必要があります。 開発プロセスを知ることで、品質の高いソフトウェアがどうやって開発されているかを知ることができます。
ソフトウェアの開発ステップには、大まかに設計・実装・テストがありますが、手法として一般化しやすいのは設計とテストです。 これらの手法を見ていきましょう。
設計手法を知る
機能は複数のデータ構造とアルゴリズムを組み合わせて実現されます。 したがって、構造を作る方法を知る必要があります。 以下の方法が知られています。
- 構造化設計
- 機能をモジュールで分割して設計する方法です。
- オブジェクト指向設計
- データと操作をセットにしたオブジェクトで設計する方法です。
- デザインパターン
- すでに知られている設計パターンをまとめたものです。
- 関数型デザイン
- 用語や概念がまだ一般化されていない感じですが、操作だけで設計する方法と言えると思います。
主にオブジェクト指向設計について、知っておくとよい原則や法則があります。
- Don't repeat yourself - Wikipedia（DRY原則）
- 同じことを繰り返さない
- KISSの原則 - Wikipedia
- シンプルで愚鈍にする
- SOLID - Wikipedia
- 単一責任の原則
- 責務を1つにする（凝集度を高くする）
- 開放閉鎖の原則
- 拡張可能にし、破壊的変更をしてはいけない（後方互換性を保つ）
- リスコフの置換原則
- サブクラスは親クラスの振る舞いを完全に含む（オブジェクトを親クラスで操作できる）
- インターフェース分離の原則
- クライアントごとにインターフェースを分ける（不要な機能を提供しない）
- 依存性逆転の原則
- モジュール間をインターフェースでつなぐ（結合度を低くする）
- 単一責任の原則
- デメテルの法則 - Wikipedia
- 2つ以上先の参照をしてはいけない（依存関係を単純にする）
設計図法を知る
構造の作り方が分かったら、それを表現しなければいけません。 表現の方法としては、UMLを用いるのが一般的な方法です。 合わせてICONIXプロセスも抑えておくとよりよいでしょう。
データ構造とアルゴリズムを知る
より速く動作し、より小さいサイズで動作するソフトウェアをつくるためには、最適なデータ構造とアルゴリズムを選択する必要があります。 基本的なデータ構造とアルゴリズムの実装は、フレームワークやライブラリ、外部サービス等で実現されていることも多いので、実装方法を細かく把握する必要は必ずしもありませんが、それらを選択して利用するためには、それぞれのデータ構造とアルゴリズムがどんなケースでどんなメリット・デメリットがあるかの知識が必要です。
ただし、要求やドメインによって必要となる技術が大きく異なるので、いざというときに引っ張り出せるように、常にいろんな技術にアンテナを張っておきましょう。
テスト手法を知る
ソフトウェアは実装したら終わりではなく、要求通りに実装されているかテストして確認する必要があります。 テスト仕様をつくる際の観点としては、次の2つがあります。
- ホワイトボックステスト
- テスト対象の内部仕様でつくるテスト
- ブラックボックステスト
- テスト対象の外部仕様（入出力など）でつくるテスト
テストケースを網羅的かつ効率良く作る方法としては、次のようなものがあります。
- 同値クラス分割
- 出力が異なる入力値のグループでテストケースを作る
- 境界値分析
- 境界値の前後のテストケースを作る
- デシジョンテーブル
- 入力値と出力値の組み合わせでテストケースを作る
- 状態遷移
- テスト対象の状態遷移を網羅するようにテストケースを作る
デバッグ手法を知る
テストしたらバグが出ます。 バグを直すためには、原因を突き止める必要があります。 すぐ原因が分かる場合もありますが、再現できてもなかなか分からない場合や、そもそも再現ができない場合もあります。 再現ができれば、デバッガーなどを使い、ステップ実行、ウォッチドッグタイマー、コールグラフ、メモリダンプなどの機能を駆使してデバッグすることになりますが、 再現ができなければ、現象から再現するための条件を見つけていくことから始めなければいけません。
いずれに場合でも重要なことは、仮説を立てるということです。 現象と仕様を照らし合わせ、バグが発生する条件の仮説を立てます。 そして、仕様やコードを確認したり、実際に動かしたりしながら、仮説を検証していきます。 これを地道に繰り返していくことが、デバッグを終わらせる近道です。
