他人の書いたソフトウェアのバグへの対処例 - Qiita

はじめに 本記事は、他人の書いたソフトウェアのバグに遭遇したときにどうするかという流れを、実例を基にして、ストーリー仕立てでなるべく具体的に書きました。このようなときの対処に不慣れな人に、実際のデバッグ、バグレポート、および修正案の提出までの流れを掴んでもらうことが目的です。 バグに遭遇 筆者も参加していたLinux Advent Calendar 2016に、ある日シェルスクリプト（Bash）で作るTwitterクライアントという記事が投稿されました。twitter APIの認証に使われているOAuth1.0aとshell芸に興味があったことより、この記事を読んでみることにしました。 そこで紹介されているtweet.shというbash製twitterクライアントを試そうとしたところ、出力は次のようになりました。 いきなり何かがおかしいです。自分のtwitterアカウントに関するJSON形

[shinyaa31]

『魚の釣り方』的な良エントリ。若手が参考にすると良いんじゃないかな。

[usadamasa]

“例えば最初のバイナリ出力を見た瞬間に「これはgzipで圧縮されたデータで展開後のデータはJSONだなあ」とわかる変た^H^H優秀なエンジニアはけっこういます ”

[trashtoy]

問題の切り分けをするだけでなく, その責任の所在がどこかまで判断してしかるべき場所に適切なアクションを取っているの素晴らしい. 余裕がないと「なんか動かないから代替ツール探そう」になりがち

[mapk0y]

とても丁寧で参考になるお話。/個人的にはバグに遭遇したときに再現させるまでがメインになることが多い

[masutaka26]

そうそう、こんな感じ

[ilyaletre]

バグレポートそれ自体もプロダクトに対する学習プロセスなんだなぁ。

[shag]

文字化けしたバイナリが読めるエンジニア確かにいるよな。文字化けした iso-2022-jp は簡単だからわかるけど。

[lazex]

だいたいそんな感じかなー。OSS使ってみるとよくある。他人のじゃなくて自分が作ったのでも別環境で動かないと同じ

[atsushifx]

いい。DeBugの基本だ

[gam-22]

問題箇所の絞り込みが参考になる

[chess-news]

メカ開発だと、交換実験とかしますね。

[InoHiro]

プロセス勉強になる

[otihateten3510]

他人のと言うよりバグレポートの手順に近そう

[screw-witted]

すごくきっちりした良い仕事。私はレスポンスについてプロトコルの仕様に沿ったものかどうかまで確認した事はなかったです。今後の参考にします。

[mooonymann]

“続いてバイナリデータが何者かを、わかる範囲で調べました。こういう時に役立つのがfileコマンドです。”

[basyura]

curl アップデートしたら twitter できなくなったのこれか

[sanemat]

本筋じゃないけどshell script公開しててcurlのバージョン違いの挙動送られてくるのなかなか地獄感ありそう

[mooz]

こういった思考と試行のプロセス、とても勉強になる

[seiunsky]

いい話だ

[kasumani]

他人の書いたソフトウェアのバグに遭遇したときの対処例 本記事は、日常生活で他人が書いたソフトウェアのバグに遭遇した後にどうするかという流れを、実際に私が経験したことをベースに、ストーリー仕立てで具体的

[masami256]

他の人がどんな感じでデバッグしてるのかというのは参考になる