cwnicol programming

プログラミング関連の投稿をすこしだけ

仕様理解方法

※自分用メモ

 

構造
 クラス図
 関数ツリー

 構造体定義+構造体実態存在場所、static
→構造体名でgrep, その変数が使われている箇所をgrep

シーケンス
入出力
デバッグ実行

----
○処理把握

ドキュメントから仕様を把握。

エントリーポイントを起点に
必要な程度の関数ツリー把握。

構造体のデータ構造を見て、
次に、実体化される場所を把握する。
----

○巨大なプログラム改造

1.ある程度の変更構想を考える。

2.上記は完全にはできないので、作りこみ。
デバッグ実行しながら、テストデータを
必要に応じて使用して、中身を具体的に
作りこんでゆく。

1.2.を完成するまで繰り返す。

 

幅優先で知識を深めていき、仮説思考で必要な個所の

知識をさらに深めていく。

-----------

A3に行数はソースのものを入れてエクセルで
4in1両面印刷。余白調整後、拡大率65%。印刷方向を

左上、左下、右上、右下変更。

ソースを見ながら(見たい変数をハイライトすると
追いやすい)、分かったところをメモ。

VSはif, whileで折り畳みができるので適時折りたたむ。

------------
アルゴリズムを詳細に知りたい箇所はフローチャートにおこす

------------

異常系はとりあえず読み飛ばして、正常系を追っていく

 

-----------------------

以下コピペ。

まず、その処理部分全体の機能を仕様書などから把握する事。
ソースプログラムのヘッダに説明コメントなどがあればそれも読む事。
 次に機能を前提に入力と出力を把握する事。
 そして、機能・入力・出力から「たぶんこんなアルゴリズム」という仮定を作り、それを踏まえてソースコードを読む事。その際、コメントも活用する事。
 読んでいて自分が最初に立てた想定と違う展開の場合は都度実際のロジックを仮定にフィードバックさせ仮定を更新しながら読む事。

 漠然と「ある変数にある変数を足し込んだ」といった感じにロジックを追っていても「なぜそうなのか?」は見え難いです。
 お仕事でプロが作られた物なら仕様設計、試験設計に関する各種仕様書があるはずですし、製造時にはソースプログラムを書くに当たってのコメント規約などもあって保守の備えがされているはずですが。。。

参考まで。