|
|
|
|
|
本コーナーは、.NET関連の新刊書籍から主要なチャプターをそのまま転載し、その内容を紹介するものです。 同書は『Code Complete 第2版』などで著名なSteve McConnell氏による、開発プロジェクトを失敗させないための本です。プロジェクトを最後まで存続させるための基本的なサバイバル術となる、要求管理、プロジェクト計画、進捗状況の追跡、品質保証、変更管理などのマネジメント技法が平易かつ具体的に示されています。 同書は、1998年に発行された書籍の新訳版（PMBOKに基づいて用語等が見直されている）ですが、その内容は現在でもまったく色あせておらず、プロジェクト開発の本質を突いていることに驚かされます。例えば、現在では主流となりつつあるアジャイル開発という言葉は当時まだありませんでしたが、ここでは「ステージ別納品」という、アジャイル開発の源流ともいえる開発方法が紹介されています。 本稿では、「第3部 ステージ別納品の効用」の「第14章 構築」を転載しています。 この章では、ソースコードの作成から、単体テスト、デバッグ、メインビルドへの統合までのフェーズを、高い生産性を保ったまま確実に行うためのベストプラクティスが記されています。 例えば、ここで紹介されている「ソフトウェア統合手順」 は、1つのモジュールを完全に完成してから次のモジュールの開発に移るというプラクティスです。これにより常に安定した基盤を確保でき、プロジェクトの終盤に発生しがちな“ソフトウェアの欠陥”を抑制できます。 なお、本章で登場する「ステージ1」という用語は、ステージ別納品（要求開発、アーキテクチャ設計の完了後に詳細設計／構築／納品を反復して行うプラクティス）における最初のイテレーションを指しています。 書籍の詳細については書籍情報のページをご覧ください。 |
|
構築（construction）は、ソフトウェアに命を吹き込む心躍るアクティビティである。構築以前のアクティビティを適正に行っていれば、構築では調和のとれた生産的な作業を行うことができる。開発者は構築とスモークテストを連日繰り返しながら、機能を着々とシステムに追加していく。成功するプロジェクトチームは、構築作業の段階でいっそう熱心にソフトウェアを単純化する方法を模索し、いっそう厳しく変更をコントロールする。小規模マイルストーン、欠陥、トップ10リスクリスト、システム自体など、主な進捗の目安を監視しているプロジェクトマネジャーは、進捗状況を正確に把握することが可能である。
構築作業では、コンピュータ上で実際に動作するプログラムとなるソースコードの作成を始める。これによってソフトウェアに命が吹き込まれる。各開発者は、詳細設計フェーズで作成した設計に肉付けするソースコードを作成し、ソースコードの単体テストとデバッグを行い、さらにソースコードをプロジェクトのメインビルドに統合する。
運営の適正なプロジェクトでは、構築作業によって機能が着実に増えていくようすは、プロジェクト全体の意気を高揚させる。プロジェクトのエンジンは徐々に調子を上げて心地良い唸りを立て始め、開発者は互いの仕事の上にさらに作業成果物を追加していく。マネジャーやユーザーは、新しい機能が日ごとに追加されていくのを確認して、システムへの信頼感を増していく。
構築は、ソフトウェアプロジェクトで最も楽しいフェーズにもなれば、議論が続出するフェーズにもなり得る。本章では、生産性が高く、楽しんで作業を進められる構築フェーズを実現する方法について述べる。
ソースコード品質
最初の時点でどのようにソフトウェアを構築するかは、システムのライフタイムコストに途方もなく大きな影響を及ぼす。首尾一貫したコーディング技術を細部にわたり適用することで、RubeGoldbergの漫画［1］のように複雑でわけのわからない仕掛けになるか、あるいは洗練された正確で有益なプログラムになるかの差が生じる。そのような細部にわたる技術はコードを構築する当初から適用しなければならない。なぜなら、後から何千もの細かい部分を選び出して修正することは事実上不可能だからである。これらの細かい点によって、拡張可能なプログラムと保守管理不能なプログラムの差がつくのである。
| 1 訳注 Rube Goldbergはサンフランシスコ出身の漫画家で、複雑怪奇な機械の描写が特徴的なLucifer Buttsシリーズで人気を博した。 |
コーディング規約
Rube Goldbergの漫画のように複雑でわけのわからない仕掛けではなく、洗練されたプログラムを作成するためのポイントの1つは、コーディング規約を設定することである。コーディング規約の目的はプログラム全体に統一性を持たせることであり、たとえて言うならば、寄せ集めの布切れで作成したパッチワークキルトではなく、単一の素材で作り上げた毛布のようなコードに仕上げることである。プロジェクトが進むにつれて、開発者は他の開発者が書いたコードを読む必要が出てくるが、ソースコードを共通の規約によって統一して記述しておけば、開発者は互いのコードが読みやすい。当初から参加していた開発者がプロジェクトを辞めて、新しい開発者がそのソフトウェア開発を引き継いだときでも、コードが一貫したスタイルで書かれていれば、新しい開発者は苦労せずにコードを理解できるはずである。
コーディング規約では、一般的に次のような点に関して標準の規約を設定する。
◆ クラス、モジュール、ルーチン、ルーチン内コードのレイアウト
◆ クラス、モジュール、ルーチン、ルーチン内コードのコメントの付け方
◆ 変数の命名規則
◆ クラスやモジュール内での値の取得（get）や設定（set）などの共通操作の名前を含む関数の命名規則
◆ 1つのルーチンに使うソースコードの最大行数［注14-1］
◆ 1つのクラス内のルーチンの最大数
◆ goto文、論理判定、ループのネストなどの制限を含む複雑性の度合い
◆ メモリ管理、エラー処理、文字列の保存などに対するアーキテクチャ上の標準のコーディングレベルでの順守
◆ 使用できるツールとライブラリのバージョン
◆ ツールとライブラリを使用する場合の規則
◆ ソースコードファイルのファイル名の規則
◆ 開発用コンピュータ、ビルド用コンピュータ、ソースコード管理ツールにおけるソースコードのディレクトリ構造
◆ ソースコードファイルの大きさ（1ファイルにつきC++クラスを1つなど）
◆ コードが未完成であることを示す方法（たとえば、コメントに「TBD（To Be Determined：未決）」と記入する）
| 注14-1 筆者は『Code Complete』（Microsoft Press、1993年、和訳書『コードコンプリート―完全なプログラミングを目指して』、アスキー、1994年、石川勝訳、『コードコンプリート第2版―完全なプログラミングを目指して（上・下）』、日経BPソフトプレス、2005年、クイープ訳）の中で、1つのルーチンに記述できるコードの行数に恣意的な制限を設定すべきではないと主張している。この推奨は、世間一般で行われている50行または2ページという制限設定への対案のつもりで行った。コーディング規約ではルーチンの長さの制限を設定しても構わないし、むしろ設定すべきであるが、制限は200行またはそれ以上にすべきである。またプロジェクトでは、指針としてある行数を定め、ルーチンがその行数を越えた場合には、レビュアーは長いルーチンの設計と実装が正しく行われたかどうかに特に注意してレビューを行わなければならないと決めておくべきである。 |
1つの組織内では、プロジェクトが異なっても統一のコーディング規約を使うべきである。少なくとも同じプログラミング言語を使用するプロジェクトでは、同じコーディング規約を使用すべきである。ただし、プロジェクトごとに固有のアーキテクチャの内容に基づく制限を処理する部分には、場合によっては異なるコーディング規約が使われることもある。
適切なコーディング規約は短くまとめられており、通常は25ページ以下に収まる。プロジェクトのあまり細かい部分まで規約にしようとするのは無意味である。そのような規約では開発者は覚えることができず、したがって守ることもできないからだ。
コーディング規約を作成する作業では、ついつい議論に熱が入りすぎてしまうことがある。しかし、大切なのは細かい規約の1つ1つではなく、規約がどの程度まで守られるかということである。規約を定めることの主要なメリットは、プロジェクトまたは会社の規約にのっとったソースコードを作成できることなのである。
コーディング規約の徹底は、コードのテクニカルレビューの中で行われるのが通常である。コードをレビューする第1の目的は欠陥を検出することであるが、すべてのソースコードをプロジェクトのコーディング規約に沿った記述にすることも、その目的の1つである。
組織内に保守管理専門の部署が独立して作られている場合には、その部署の人をコードレビューに参加させるとよい。保守管理担当者なら、コードを保守管理しやすくするという点に大きな関心を持ってレビューを行うからである。
プロジェクト目標
開発者は、詳細設計と同じく構築作業においても、プロジェクト目標を効果的に実現する方法を模索し続けなければならない。構築期間中には、より単純にするか複雑にするか、安定性を高くするか低くするか、高速にするか低速にするかなど、プロジェクトの本質にかかわるような判断を何度も下さねばならないからである。
開発者は、構築作業の間に文字どおり何千というこのような詳細レベルの判断を下すことになる。これは決して誇張ではない。コードにして75,000行くらいの中規模のプログラムは、約3,500個のサブルーチンで構成される。開発者は、ソフトウェアの複雑性、堅牢性、パフォーマンスに影響する判断を、1つのサブルーチンにつき平均して数回ずつ行う。開発者の判断は、ルーチンを文書化する方法から使用するコーディングスタイル、エラーの処理方法、ルーチンが正しく動作することを検証する方法、そしてもちろん、ルーチンが実際にジョブを実行する方法にまで及ぶ。明確なプロジェクトのビジョンがあれば、この何千という判断の多くをプロジェクト目標と首尾一貫した形で下すことができる。ビジョンを定義していないと、これらの判断のほとんどが一定の方針に沿うことなく下されることは確実である。
|
単純化
構築作業の間も引き続き、プログラムを単純化して複雑な要素を減らすことに努めるべきである。設計とコーディングが単純すぎるという理由で中止になるプロジェクトはほとんどない。逆に、複雑になりすぎてだれも理解できなくなったために中止に追い込まれるプロジェクトは数えきれない。システムを変更したり拡張したりしようとしても、予想外の副作用が次から次へと発生し、システムを拡張し続けることが事実上不可能になってしまうためである。
 |
| INDEX | ||
| 新訳 ソフトウェアプロジェクトサバイバルガイド | ||
 |
1. 第14章 構築（1） | |
| 2. 第14章 構築（2） | ||
| 3. 第14章 構築（3） | ||
 |
||
 |
「BOOK Preview」 |
- 第2回 簡潔なコーディングのために （2017/7/26）
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21）
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために （2017/7/19）
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator （2017/7/18）
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
 |
|
|
|
|
