SIOS Applicationsの過去未来

コードレビュー

　コードレビューの仕組みに関して言えば、SFA＋を開発した当初は、私自身を含めて開発要員は2名しかいませんでした。また開発のフレームワークは、当社の別の部署で開発された「Ninja-VA」を使用するということで決定していました。その時点では開発を行う2名ともそのフレームワークに精通しているわけではなかったため、レビューをするにも正しいフレームワークの使い方は手探り状態で、どのようなコードが正しいのか把握しきれていませんでした。

　その際に、役に立った考え方は、現在では広く知れ渡っているペアプログラミングというエクストリーム・プログラミングの中で定義されている開発手法の考え方でした。ペアプログラミングとは、ご存じの方も多いと思いますが、2人のプログラマーが1つのモジュールを共同で開発します。利点としては、以下のようなことが挙げられています。

・よりよいコード
　相乗効果により設計の質が向上することが期待される。
・作業効率の向上
　次に何をすべきかを考え込むといったことが少なくなる。また、外乱要因に対しても耐性を示し、ほかの人が割り込んできても一方が応対している間にもう一方が作業を進められる。
・多数の開発者による設計
　ペアを頻繁に入れ替えれば、複数の人間が1つの機能の開発にかかわることになる。（これにより、より良い設計が生み出されます。例えば、あるペアが解決できない問題で作業が止まってしまっても、別のペアでは解決できることもあるということです）

　当時は、まだこの手法が広まり始めたころで、私たちもペアプログラミングを最初から強く意識していたわけではなく、ふたりがお互いのやり方を知るために始めたものでした。しかし、結果的にはペアプログラミングのような形になり、コードや内部設計レベルのレビューの役割を果たし、非常に効率よく作業を進めることができました。

　ただ、ペアプログラミング自体は、品質保証で言うところのコードレビューのやり方とは少し外れているところがありましたので、最終的なコードテストは、各種チェックツールを利用して、コードに対するチェックを補完しました。

　ペアプログラミングは連載の第1回（http://thinkit.co.jp/article/909/1/）で説明した、アジャイル開発の中でも代表的な、XP（エクストリーム・プログラミング）という開発手法の中心的な役割を担っています。ウォーターフォール型で開発を進めていましたが、意識していなくても、さまざまな問題を解決するために、当初からアジャイル開発をしていたのかもしれません。意識をもって開発手法を改善していくという取り組みは、前回お話した通りになります。

変更管理／構成管理／リリース管理

　変更管理・構成管理については、当初はExcelとCVSで管理していました。しかし、それぞれが独立して管理されている2元管理状態であったため、どの要求・要望に対する変更がどのソースコードに及んでいるかなどを確認するすべがなく、デグレ（デグレード）などの検出、チェックを行うのが非常に困難でした。

　現在ではRedMineとSubVersionを連携することでこれらの情報を一元管理できるようになりました。この2つのシステムについては、前回の連載でも触れましたが、プログラムを変更する元となったシステム要求・要望とソースコードへのコミット履歴が連動する仕組みになっているため、デグレなどのリスクを事前に回避することが可能になりました。