@IT会議室は、ITエンジニアに特化した質問・回答コミュニティ「QA@IT」に生まれ変わりました。ぜひご利用ください。
- PR -

デバッグ力&即時解析

投稿者投稿内容
aluck
会議室デビュー日: 2005/01/25
投稿数: 19
お住まい・勤務地: 某S
投稿日時: 2006-02-10 01:37
プログラムをする際の
・デバッグ力
・即時にプログラムを読む

上記2点はどのようにすれば、効率があがるでしょうか?何か工夫されてる点や、このようにすれば養えるなどありましたら教えていただけますと幸いです
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2006-02-10 05:29
数をこなす
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-02-10 08:53
引用:

aluckさんの書き込み (2006-02-10 01:37) より:

プログラムをする際の
・デバッグ力
・即時にプログラムを読む


そのソースのレベルに依存します。
私の場合は、"せめて" 構造化されていないと全く読めません。
(というより読む気になれない、デバッグする気になれない、家に帰りたくなる)

構造化くらいしてあれば、あとはコモンセンス次第でしょう。
そうでない酷いソースは、場数を踏むしかないでしょう。

引用:

上記2点はどのようにすれば、効率があがるでしょうか?
何か工夫されてる点や、このようにすれば養えるなどありましたら教えていただけますと幸いです


そんなわけで、同じプロジェクト内であれば、事後のコトで考えるのではなく、
事前のコト (ポリシ) を決めることで効率があがるでしょう。
事後だとその人のコモンセンスとか、忍耐力に依存しそう...

# それより、これって Insider.NET 会議室と関係あるんですか?

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
どっとねっとふぁん
ぬし
会議室デビュー日: 2005/02/23
投稿数: 935
投稿日時: 2006-02-10 08:59
プログラムを読むほうはとにかく数をこなすしかないでしょうね。
他人の書いたプログラムを読むときには、自分だったらこのように処理を書く、という
思い込みがあるとそれがプログラムを読み取る邪魔をすることがあります。
この人はどういう考え方で処理をプログラムに置き換えているのか、というのを読み解く
つもりで読んでいくといいかもしれません。

デバッグのほうは、とにかくこまめにチェックを入れて、どこまでは自分が思った
とおりに動いていてどこでおかしくなっているのか、をまず探しますね。
チェックを入れる方法はたぶんその人なりに一番やりやすい方法というのが
数をこなすことで身についてくると思います。
Lichtenstein
ベテラン
会議室デビュー日: 2003/11/06
投稿数: 61
投稿日時: 2006-02-10 12:47
.NET会議室的には、デバッガを駆使しようという事になるんじゃないでしょうか。
動かしながらパラメーターを改竄している内に、大体の流れがつかめます。

あと、最初の一行から、デバッガで一行ずつ実行する人もいます。
「こいつOSやライブラリのバグをつついてないか?」って時に有効です。

いの一番にユニットテスト作っておくのが最速! というのが最近の潮流かも。
未記入
大ベテラン
会議室デビュー日: 2005/03/12
投稿数: 148
投稿日時: 2006-02-10 13:11
そもそもそんな時困らないようにすべきなんだけどな。
修正を重ねてごちゃごちゃプログラムになっていくんだよな。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2006-02-12 09:21
参考にどうぞ→設計しよう/デバッグしよう
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2006-02-12 14:27
他人の書いたソースを沢山読むのがいいかな?
自分がいくらソースかいても井の中の蛙で終わってしまうし。

汚いソースに読みなれていると何とか読めるようになってしまうかな?
でもそれやると、自分のソースも汚くする要素があるので、
自分なりに、理想はここだ!ってのを持ってないときついかも知れません。

僕がデバッグする時のコツは書いた他人の思考をトレースして、
「その人だったら、こう書くだろう」って書いていくような気がします。

あとは・・・メンドクサイ事を地道にやることかな?
後で自分が自分のソースメンテする事になっても、
文句言わないで済むようなソースがいいですね。

例えば・・・関数作るとして、
・1関数1機能
・関数名と機能が完全にリンクしている
・初期化/前処理/本処理/後処理/初期化の順番を意識する
・変数は使いまわさない
・スコープの広い変数(長い行数使われる変数)は長い名称にする

とか、この辺だけでもやってると即時コーディング力上がると思うけどなぁ

なんでかっていうと、めんどくさい事やってると、
気がつきにくいめんどくさい事が何かってわかるからです。

んじゃ、まとめる為にはどうしよう・・・とか色々考えるし、
考えればそれだけ設計力が上がるので
デバッグ力も上がるだろうし。

こんな所で回答になってるのかなぁ?(;^_^A アセアセ
_________________

スキルアップ/キャリアアップ(JOB@IT)