2018年7月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
無料ブログはココログ

 

« 平成28年度春期情報処理技術者試験プロジェクトマネージャを受けてきた | トップページ | 今週届いた本 »

2016年4月24日 (日)

「詳細設計書不要」「コメント不要」について

「詳細設計書不要」「コメント不要」について。
これらは「不要な(と思われる)ものを作るのに工数を掛けたくない」「メンテの範囲を少なくしたい」という欲求からの発言であろう。

そも「詳細設計書」「コメント」も必要性があって存在する。
それを無視して一概に不要というべきではない。
無論、不要論を唱える者のはその者なりの理由があるのは分かる。

いわく、コード=詳細設計書なのだから、コードを読めばいい。コードから詳細設計書を作ればいい。
いわく、コーディングしてみないと、出来るか分からない。
いわく、コードを修正したら、詳細設計書も修正しなければならない。でも出来ないことがあるから差異が出てしまい、意味がない。コメントも同様。意味が無いものを作る必要性はあるだろうか。いやない(反語)。

でも待ってくれ。それってオカシイと思わない?
詳細設計書の存在意義は、コーディングする前に設計するためにある。設計工程で不明点を明確にしたり、モジュール間の整合性を取ったりするのだ。(加えて言うなら、設計書からテストを起こす。本来、あるべき動作(仕様)を確認するのがテスト。コードからテストを作るのではない!)
コード=設計仕様書なのではなく、要件定義→外部設計→詳細設計→コーディングの流れの一つの工程で結果的にコード=設計仕様書となるだけ。時間がないから詳細設計書を書けなくてコーディングと詳細設計を同時に行い、コードから詳細設計書を作るという本末転倒なチームや顧客は居る。だけど、それはオカシイ。オカシイ作業がまかり通っているだけ。そして、そういう所は大概、品質が悪く、保守性が悪く、失敗プロジェクトが多い。
作業の意味を考えず、必要な作業をすっとばしているのだから当たり前だ。

一方、コメントは(詳細設計のように)工程の一部ではないので、入れる義務はないと思われるかもしれない。
でも、コメントは”保守性”を高めるために、機能の意味を説明するためにある。
”保守性”は工程ではなく、もっと長いスパン(システムの寿命)で必要となるものである。
「コードは読めば分かるように書く」というのは、もっともなのだが、それにはチームの文化を全員が保持しており、そのコードの保守をその文化を持ったメンバが保守できることが前提となる。
でもチームのメンバがずっと同じであることはほとんどないだろう。企業は、組織の硬直化を防ぐために、チームのメンバが変える必要がある。チームからみると構築された役割が壊され品質を下げるようなデメリットしか感じないだろうが、様々な知識や方法論を広げるという役割がある。

何にしろ、存在意義を無視して特定の条件でしか成り立たない危うい過激な意見に同意しても、益はない。存在意義を理解し、その上で改善を行い、成果物を排除できるような環境を作るってのはありかもしれないけれど、それって環境を育てるのに時間がかかるし、あっという間に壊れそうだよね。素直に詳細設計書をちゃんと作る、コメントをちゃんと入れる、メンテもちゃんと行うって確認するルールを作って運用する方がナンボも簡単だと思うんだけど。

« 平成28年度春期情報処理技術者試験プロジェクトマネージャを受けてきた | トップページ | 今週届いた本 »

コメント

記事を読みましたが、システム開発の工程が一般的なフローと違うように思います

>要件定義→外部設計→詳細設計→コーディング

確かにこれだと「設計工程で不明点を明確にしたり、モジュール間の整合性」はできませんね

本来は外部設計と詳細設計の間に機能設計があるはずです。そこで上述のことを行うべきです。

現状ネットで話題になっている詳細設計不要論は、ウォーターフロー型開発のV字工程がもとになっているので、そこをまず参照していただきたく

工程の名称は、文献や企業によって異なっていることがままあります。それはVモデルの工程とテストの対応も然り。ですので、そこら辺は生暖かい目で見守っていただければありがたいです。
ここら辺を厳密に語るには、どこをベースにするかという議論からしないといけなくなりますので・・・。

在のようなオブジェクト指向の開発環境が一般化する前の言語では、データ構造を設計し、それに対する処理の流れを設計してしまえばよかったですし、いきなりアセンブリやCOBOLでコードを書き出さなくても、そういった設計は事前に設計図上で時間をかけて検討するということは可能であり、コンパイルに膨大な手間と時間がかかっていた時代であれば理にかなっている行為であったと思います。しかし、少なくとも現代的な開発環境上でJavaなどのオブジェクト指向言語を使って開発することを考えた場合、それらの伝統的な設計の他に
インターフェースの設計
アノテーション(注釈)などのコード中のメタデータの使い方の検討
パッケージなどのモジュール分割
適切な数のレイヤーの分割
デザインパターンの適用
ジェネリクス(総称型)などの型の設計
jarファイル分割などの物理的なモジュールの設計
eclipseなどのプロジェクト分割
mavenやant+ivyを使ったビルドシステム構築
単体試験方式の確立
OSSライブラリーなどの依存関係の調査
共通化可能なアスペクトの設計
などなど、IDEを起動してあらかじめサンプルを作りながら検証しないと本質が理解できない要素があまりにも多く存在します。Javaのプログラムは、単純にifやforループの集まりとして捉えることはできないということです。実際、Seamなどの便利なフレームワークを活用すれば、型変換なども含めて大部分はロジックを書かなくても宣言的に再利用できてしまいますし、アーキテクチャーの設計といった場合、個別のロジックに絡まない以上のような要素の設計の方がむしろ重要になってきます。これらはUMLなどを使ってある程度コーディングなしで設計できる部分はあるとは言え、アノテーションなどの言語固有の設計要素や開発ツールのくせを考慮した実装方式は実際にコーディングして慎重に検証しながら考える以外に効率的に設計することは難しいです。このような要素をあらかじめ開発フェーズまでに明確にしておく、つまり、生産性の高いプログラミングモデルを決めておくということは、経験上開発プロジェクトの成功の上に欠かせない作業項目であると考えます。まずはコード上でじっくり設計を考えた後で、説明資料として後から必要に応じて要点をUMLで文書化するという流れの方が作業手順としてしっくり来ることが私の経験上ほとんどです。コードこそが設計の本質をもっとも正確かつ簡潔に表現できる手段なのであり、UMLはそのある側面を捉えやすくする方便としての一表現に過ぎないなどと言うと怒られてしまうでしょうか?(間違えないでいただきたいですが、EAとかSOAなどの粒度のアーキテクチャーではなくて、単一のアプリケーションのアーキテクチャーを設計することをここでは念頭に置いています。もちろん、プログラミングモデルの検討以外に、セキュリティや性能、保守性などアーキテクトとして検討すべきことは他にも山ほど存在するという前提で。)
あと、複雑な業務領域のシステムでは、DDD(Domain-Driven Design: Tackling Complexity in the Heart of Software)を使ったドメインモデリングが有効ですが、JPAなど採用するデータアクセスフレームワークの特性に応じて設計のフィージビリティーを確認するには、早期にエンティティクラスを作成しながらモデルを洗練させることが有効です。また、JSFなど複雑なプレゼンテーションフレームワークを利用するなら、あらかじめ画面紙芝居を開発して、そのフレームワークで画面遷移などが簡単に実現できることを実際に検証しながら画面設計をするべきです。
コーディングなどは単価の低いプログラマーの仕事であり、アーキテクトにやらせるのはもったいないなどと考えて、開発フェーズまでコーディングしないなどというやり方をしていては、後々設計の足りていない箇所がたくさん見つかり、結局個々のプログラマーが場当たり的に設計しだすのでアーキテクチャーは余計に混乱することになると思います。アジャイル開発を採用せず、ウォーターフォールで開発するのであれば、なお一層のことアーキテクトチームや事前開発チームのような体制を作って、要件定義と並行して早期にプログラミングをしながら設計を固めるというのが大事だと思います。(RUPの推敲フェーズのようなものを取り入れるべき)
さらに、付け加えるとこのような事前開発は、技術リスクの軽減効果だけでなく、開発メンバーのスキルアップという教育面での効果も高いです。

コメントありがとうございます。
纏めると「アーキテクトによっては、設計書を書き起こすより、作りながらブラシュアップするのがベスト」という事でしょうか。
(名無しのSenさんも記述している)条件付きでなら賛同します。
#議論するのに、その“条件”ってのが一番厄介ですがね。共通認識を擦り合わせないと、泥沼になるだけです。

そもそも、自分が言いたいことは、他者に対して&未来に担当する者(自分を含む)に対して、意思疎通するためのツールとして設計書の存在意義があるのに、(日本で蔓延っている歪んだ)ウォーターフォールに盲従しているわかってない奴らに作らされる目的がはっきりしないゴミと混同して、何も書かないで全否定ってのは短絡すぎないかという事です。(この記事を書いた元の議論はそういう事が発端でした)

チームで動いているならば、意思疎通をして結果を文書として残しますよね?それって設計(書)ですよね?
人の考えた設計をチーム全員が(会話だけで)全て理解でき、その人の発言を全員が全て記憶できるスゴイ人ばかりなのでしょうか。(ホントなら羨ましい)
実際はそれができないので、設計を他人と共通認識に落とし込み、それを間違わずにコード化し、動作確認の元ネタとするために設計書を作るのが目的だよね、面倒だからといってないがしろにして良いものじゃないよね、そういう事を言いたいのです。

あと、「コードこそが設計の本質をもっとも正確かつ簡潔に表現できる手段」というのは賛同しかねます。
設計書がないとコードが正しいか担保できません。またコードは簡潔ではないです。冗長です。コードを読んだらすべて覚えていられるわけでもないですし。簡潔に書かれているのが設計書です。(処理の概要=設計 を詳細化してコードに落とすのだから当たり前)
設計書は、要件という目的地にたどり着くための地図です。コードを見ればいいと言う話は、地図を見ずに初見の場所に行けと言うのに近いです。人はミスしますし、コーディングは人が行う物です。つまり、誤った地図なのかもしれません。(自分は100%バグを組み込んだ事がないとか、フレームワークにバグなんて入っているわけないじゃないですか〜と仰るならそうなんでしょうね)

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/117572/65145347

この記事へのトラックバック一覧です: 「詳細設計書不要」「コメント不要」について:

« 平成28年度春期情報処理技術者試験プロジェクトマネージャを受けてきた | トップページ | 今週届いた本 »