#はじめに
新しいプロジェクトチームに配属され、詳細設計から担当しています。
新たに文化に触れてその文化に習って業務を進めているけど、
ギャップを感じたので書いてみようと思います。
##今の文化
###1. 詳細設計書の作成
コードベースでの詳細設計書
日本語とプログラミング言語が分かればコーディング出来るレベルのもの
その言語特有な記述もする
「なんていう名前のクラスの、なんていう名前のメソッドを呼びます」ってことまで書く
仮に、じゃあ別の言語で作ろっかってなった場合には、確実に通用しない
プログラム設計書と言った方がしっくり来る感じ
フローチャート、クラス図は必須ではない・・・とにかく、プログラムっぽい設計書書かないと。
###2. 単体テスト仕様書の作成
詳細設計書を見ながら、１行単位でテスト項目を作成
メソッドが呼ばれること、引数はこれであること、戻り値は何であること
詳細設計書が間違ってても、それをそのまま項目として挙げているので
詳細設計書の間違いにも気付きにくい
###3. コーディング
詳細設計書をもとにプログラミング言語に落とし込む
詳細設計書・・・微妙だなって思うことも多々ある。
思い切って変えちゃうと、詳細設計書書き直し、単体テスト仕様書も書き直し・・・
結局、コーディング完了して、詳細設計書直して、単体テスト仕様書を直すという手戻り
###4. 単体テスト
プログラムベースでのテスト項目
この関数が呼ばれる、その次はこれが呼ばれる・・・
あれ？この場合ってテストしてないじゃん、あれ？これは？これは・・・？
##個人的考え
###1. 詳細設計書の作成
-
関数単位の機能フロー
概要設計書をもとに、大まかな機能ごとにフローチャートを作成
大まかな機能を分割、分割、分割・・・
単一機能レベルまでに落とし込み
落とし込んだ単一機能レベルのフローチャートが完成する -
関数仕様書
単一機能毎に関数仕様書の作成
関数の処理内容を記述（言葉で）
IN と OUT を明確に
IN は、A、B
OUT は、A = 文字列、B = true のときは、X
A = null、B = true のときは、Y
こんなときには、例外が起きる
みたいな感じで、条件を網羅する
この条件網羅が、単体テストのテスト項目になる
この場合、運用のことはあまり考慮せずに網羅する
運用で起きないパターンについては、「テストしたけど起きないよねw」でいいと思う
万が一起きちゃった場合の保険。 -
DB操作系の仕様書
こんな項目を検索
こんな項目を挿入 -
DB操作系のパターン表
これとこれが、これのときにはこれ
あれとこれが、これのときにはそれ
これも全件網羅
###2. 単体テスト仕様書の作成
関数仕様書とDB操作系のパターン表で終わっている
ここでUnitTestのコーディングできちゃうかも
###3. コーディング
関数仕様書を元に、機能を作り
機能フローを元に、処理をくみ上げていく
ここでUnitTestのコーディング（コーディングする前に作っても可）
###4. 単体テスト
UnitTestを流すだけ
結果のエビデンスとって終わり
#まとめ
とにかく現状がいけてないなーって思ったから
こうするとよくなるんじゃない？
って思いつきで書いています。最後、結構雑になりました。
とりあえず、提案してみよう
何か、思うことありましたら意見を頂ければと思います。
夢見過ぎ・・・とか、そんなんもう10年前で終わってる・・・とか
学生ですか？お花畑すぎでしょwww とか、何でも大歓迎です。