修行の場

知人が言っていました。これは修行だと。

ソフトウェアの開発スタイルの一例と各プロセスで役立つツール

背景

ソフトウェア開発において、

  1. ツールを知り、
  2. ツールを理解して、
  3. 適所適材に使うこと

は生産性に効いてきます。 ソフトウェア開発の場面で幅広く使うツールを目的別に解説します。 また、世の中の進歩に対応するため、 上記3つのサイクルを効率よく回すためのテクニックや考え方を説明します。

開発スタイル

どのツールが合うかは人の開発スタイルによって異なります。 例えば、全くテストを書かずに機能を作って最後にテストを書く人がいれば、 テスト駆動を徹底している人もいます。

私はその中間で、次のような開発スタイルで開発スタイルで開発しています。

  • 要件の理解と整理
  • ざっくりしたクラス設計
  • パーツを一つ一つ作る
    • 実装して動かす。
    • 自信が無い箇所があればテストを書いて検証
    • パーツが実装できたら次のパーツに進む。
  • 全部できたら結合テスト
  • 自動テストの品質向上

開発スタイルは人それぞれで、 最適な開発スタイルはおそらく、下記の条件に左右され複雑なの問題なので、決定的に決めるのは難しいと思います。下記条件が変わったら、定期的に振り返りなどをして適用させていくのが良いのではないかと私は考えています。

  • 人の性格やスキル
  • 所属するチームの開発スタイルや置かれている状況
  • 作るもの
  • などなど....

とりあえず、本記事。は、上記の開発スタイルを前提として、 どういった場面でツ。ルを使うのか場面を交えてツールの説明をしていきます。

要件理解・整理。クラス設計

大概の場合はノート。タブレット、ホワイトボードの手書きで整理できます。 私はmarkdownに要件。設計のポイントを書いたりして頭の中を整理することもあります。 このフェーズのアウトプットは、クラス図とシーケンス図をイメージしていて、

  • クラス名と責務
  • 提供するメソッドの一覧
  • クラス間の関係性
    • DB設計の図というよりシーケンス図
    • もう少し詳細には呼び出し関係

になります。アウトプットをドキュメント化するか、メモ程度になるかは状況次第です。

パーツを実装する

ソフトウェアの実装はほぼこのフェーズの繰り返しになります。 クラスを実装して、動作を検証して次のクラスを作る。 更に上位のクラスで作ったクラスを結合して..となります。 また、理想的なソフトウェア開発では、 クラスごとの実装を完全に独立してできます。

ソフトウェアの開発において、 このフェーズが多くの時間を占めるので、 ここを効率化するべきです。

使うライブラリやツールを決める

選択肢を列挙して、指標に応じて決めるだけです。

選択肢はgoogle, github, 社内リポジトリなどを探したり人に聞けばでてくるでしょう。 また、指標はプロジェクトごとに異なります。

使うライブラリやツールを理解する

理解、構築、検証の3つです。

ライブラリ、コマンドツールなどを使って機能を作っていくことになると思います。

基本的に使うものを理解するためには公式のドキュメントを読むことで理解します。 ソースコードをいきなり読むことは次の2つの理由でやめたほうが良いです。

  • 多くの場合はドキュメントを読んで理解するほうが早い
  • ソースコードを読んで使い方を考えるとinformation hidingに反する。ライブラリの将来の変更に弱くなる。

ライブラリやツールはドキュメントを読むことで想定ユースケースをすべてカバーできるのが理想ですが、 そうでない場合はソースコードを読んで使うことになるのは致し方無いと思います。

このフェーズでドキュメントが不明確な箇所の動作確認をしたり、 自分の理解が正しいことをサンプルコードを書いて確かめても良いです。 たまにマイナーな機能だと境界値の挙動がドキュメントから抜けていたりするので、 そういった場合のテストはきちんとするべきです。

パーツを作り、作ったパーツを検証する

使うライブラリやツールの理解をこのフェーズでテストしながらやってもいいです。 クラスやモジュールレベルの検証はユニットテストや、 テストスクリプトを書いたり、 ipythonなどのreplを使って検証するという手があります。

ユニットテスト or ipythonがおすすめです。ipythonなら柔軟にテストできますし、 ユニットテストならあとに残せます。

ユニットテストやipythonに関しては別に書いています。

結合テスト

使うツールや呼び出しているサービスなども含めた結合テストは必須です。 基本はマニュアルテストでしょうが、人員人数やプロダクトの規模によっては 結合テストを検討してもいいかもしれません。 webならseleniumなどプロジェクトに適したテストツールを選べばいいと思います。

自動テストの品質向上

開発途中の自動テストで検出できなかったバグを見つけるために、 自動テストの見直しと品質向上をします。 未実装の境界値テストを実行したり、 バグを見つけられるようなテストケースを作っていきます。