もっと手を抜こう - (2006/03/11 (土) 00:31:43) の1つ前との変更点
追加された行は緑色になります。
削除された行は赤色になります。
作業対象のソースコードの解析を行っていたわけですが。
とりあえず、一通りの処理の流れは把握できたように思います。
doxygenのおかげでクラスの継承関係は把握できたので、流れは追いやすかったです。あとは、制御対象機器周りの細かい機器依存部のみ。
週明け月曜日にはなんとか、実務レベルの把握ができると思います。
・・・正直、かなりほっとしているわけですが(笑)
C++についてもだいぶ慣れてきました。
長らくC言語しかやってなかったから、それが一番しんどかったかも(笑)
ソースの書き方もそうだけど、ソースの解析手法もC言語とC++では、効率のいいやり方はだいぶ違うと思います。
C言語の場合は関数単位で見ていけばいいので、特に気をつけるべきことはあまりないように思います。関数名もプロジェクト内でユニークなものなので、grepかけたら終わりです(笑)
ですがC++にはクラスの継承、関数のオーバーライド・オーバーロードがあります。したがって、単純にgrepかけてみても求めるものが求める場所(ソースファイル)になかったり、逆にいっぱい同じ名前で検索に引っかかったりするわけです。
なので方法としては、次のようになると思います。
(グローバル関数でないかぎり)スコープが限定されているのでどのクラスのメンバかはすぐにわかるので、それをもとにヘッダファイルを見てみると、そこで宣言されているか、されていないにしてもそのクラスがどのクラスから派生しているのかがわかるわけで。
あとはそれを順にたどっていくことで目的の関数にたどり着くはずです。
・・・ただし、そんな馬鹿正直なことをやっていると継承が深い場合や多重継承(javaとちがって、C++はこれができてしまうから)の場合などは時間も手間もかかってしまいますが(笑)
特に、インターフェースを統一するためにあるクラスを基底においてある場合などは結構よくあるパターンな上に継承の階層が激しく深かったりします。
こういうときは、前述のdoxygenのようなツールに頼るのが一番だと思います(ドキュメントがすでにしっかりしているのなら、それに越したことはありませんが・・・)。
オブジェクト指向言語のソース解析は、UMLなり何なり、とにかくクラス図。話はそれからだと思います。まだ解析初めて二日目だから、あんまり偉そうに言ってしまうと怒られちゃうかもしれませんが(笑)
「ツールに頼ると実力がつかないから、自力でやったほうがいい」という方もいらっしゃるかもしれません。
ですが「実力を付ける」だのというのは、仕事でそれができるのならそれがベストですけれど、その過程で作業的に無駄が入るのであればそれは間違っています。
それならば、作業としては効率優先で行い、自分の時間(週末や帰宅後など)を利用してやるべきです。
私はC++についてだいぶ忘れかけていた状態から、3日ほどで18MBのソースを把握することができるところまで来ているわけです。まじめに自力だけでやったとしたら、(ドキュメントもほとんどないため)おそらくは1週間ほどはかかってしまったことでしょう。
かつ、その過程においてツールを使ったからといってC++を使えないわけでもありませんし。ソースをまったく見ていないわけではないし、ツールに頼っているのは階層関係の把握と定数定義を探すのに時間がかかるのを避けたかったわけで。
それ以上の解析については結局人間が(というより自分が)やるしかないんだし、そもそもソースを解析するというのはソースを把握、理解するためにあるわけです。
ソースを理解していくということは、そのソースがC++で書かれている以上、C++を身に付けざるを得ません(でないと、いかにツールを使ったとしても「理解」はできないはずです)。
私の持論として「結果が同じとなるなら、それにかける手間はできるだけなくす」のがいいことだと思っています。
それは単にらくだから、ではなく時間的な意味でも、作業的な意味でも余裕を作ることができるということです。
もちろん、手間をかけたときよりも結果の品質が下がるなどということがあってはいけません。それは大前提ですが。
結果の品質には注意が必要ですが、極力手を抜くこと。
「高品質かつ低コスト」これがベストだと思います。
表示オプション
横に並べて表示:
変化行の前後のみ表示: