- - PR -
デバッグ力&即時解析
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-02-10 01:37
プログラムをする際の
・デバッグ力 ・即時にプログラムを読む 上記2点はどのようにすれば、効率があがるでしょうか?何か工夫されてる点や、このようにすれば養えるなどありましたら教えていただけますと幸いです | ||||||||
|
投稿日時: 2006-02-10 05:29
数をこなす
| ||||||||
|
投稿日時: 2006-02-10 08:53
そのソースのレベルに依存します。 私の場合は、"せめて" 構造化されていないと全く読めません。 (というより読む気になれない、デバッグする気になれない、家に帰りたくなる) 構造化くらいしてあれば、あとはコモンセンス次第でしょう。 そうでない酷いソースは、場数を踏むしかないでしょう。
そんなわけで、同じプロジェクト内であれば、事後のコトで考えるのではなく、 事前のコト (ポリシ) を決めることで効率があがるでしょう。 事後だとその人のコモンセンスとか、忍耐力に依存しそう... # それより、これって Insider.NET 会議室と関係あるんですか? _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||
|
投稿日時: 2006-02-10 08:59
プログラムを読むほうはとにかく数をこなすしかないでしょうね。
他人の書いたプログラムを読むときには、自分だったらこのように処理を書く、という 思い込みがあるとそれがプログラムを読み取る邪魔をすることがあります。 この人はどういう考え方で処理をプログラムに置き換えているのか、というのを読み解く つもりで読んでいくといいかもしれません。 デバッグのほうは、とにかくこまめにチェックを入れて、どこまでは自分が思った とおりに動いていてどこでおかしくなっているのか、をまず探しますね。 チェックを入れる方法はたぶんその人なりに一番やりやすい方法というのが 数をこなすことで身についてくると思います。 | ||||||||
|
投稿日時: 2006-02-10 12:47
.NET会議室的には、デバッガを駆使しようという事になるんじゃないでしょうか。
動かしながらパラメーターを改竄している内に、大体の流れがつかめます。 あと、最初の一行から、デバッガで一行ずつ実行する人もいます。 「こいつOSやライブラリのバグをつついてないか?」って時に有効です。 いの一番にユニットテスト作っておくのが最速! というのが最近の潮流かも。 | ||||||||
|
投稿日時: 2006-02-10 13:11
そもそもそんな時困らないようにすべきなんだけどな。
修正を重ねてごちゃごちゃプログラムになっていくんだよな。 | ||||||||
|
投稿日時: 2006-02-12 09:21
参考にどうぞ→設計しよう/デバッグしよう
| ||||||||
|
投稿日時: 2006-02-12 14:27
他人の書いたソースを沢山読むのがいいかな?
自分がいくらソースかいても井の中の蛙で終わってしまうし。 汚いソースに読みなれていると何とか読めるようになってしまうかな? でもそれやると、自分のソースも汚くする要素があるので、 自分なりに、理想はここだ!ってのを持ってないときついかも知れません。 僕がデバッグする時のコツは書いた他人の思考をトレースして、 「その人だったら、こう書くだろう」って書いていくような気がします。 あとは・・・メンドクサイ事を地道にやることかな? 後で自分が自分のソースメンテする事になっても、 文句言わないで済むようなソースがいいですね。 例えば・・・関数作るとして、 ・1関数1機能 ・関数名と機能が完全にリンクしている ・初期化/前処理/本処理/後処理/初期化の順番を意識する ・変数は使いまわさない ・スコープの広い変数(長い行数使われる変数)は長い名称にする とか、この辺だけでもやってると即時コーディング力上がると思うけどなぁ なんでかっていうと、めんどくさい事やってると、 気がつきにくいめんどくさい事が何かってわかるからです。 んじゃ、まとめる為にはどうしよう・・・とか色々考えるし、 考えればそれだけ設計力が上がるので デバッグ力も上がるだろうし。 こんな所で回答になってるのかなぁ?(;^_^A アセアセ _________________ |