タグ

デバッグとプログラミングに関するrin51のブックマーク (6)

  • エンジニア・光成 滋生の「バグを突き止める技術」 | サイボウズ式

    サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第18回(これまでの連載一覧)。サイボウズ・ラボの光成 滋生さんにお話を伺うシリーズ(1)です。 連載は、「WEB+DB PRESS Vol.80」(2014年4月24日発売)に掲載された「エンジニアの学び方──効率的に知識を得て,成果に結び付ける」の続編です。(編集部) 文:西尾 泰和 イラスト:歌工房 この連載では「エンジニアの学び方」をテーマにインタビューを行い、どういう「学び方」をしているのか探求していきたいと思っています。第2弾は、サイボウズ・ラボのエンジニアとして、楕円曲線などの難しい数学を使った暗号の論文を読んで実装したり、サイボウズが遭遇した問題の原因を掘り下げていって最終的にLinuxのバグを修正したり、と幅広い活動をされている光成滋生さんです。 光成さんが、どういうプロセスで問題の原因を

    エンジニア・光成 滋生の「バグを突き止める技術」 | サイボウズ式
  • デバッグのアンチパターン | EarOwlの日記 | スラド

    その1 : 問題が再現する状況を確認した後、『ここを変えたらどうなる?』『こういうパターンではどうなる?』といったことを思いつくままに色々試していく。 『原因の調査のために、情報はとにかく多いほうが良い。』それは間違ってはいないが、思いついたパターンを闇雲に試すだけでは、情報も増えるがそれ以上にノイズが増えていることが多い。 (ひどい場合には必死になってノイズばかりを拾っていることも。) 現象を 1回確認したら、まずはそこから最大限まで情報を得て、原因を絞り込む。その上で、絞り込めない部分があればその部分を確認するための動作を試してみる。このような方法で進めていく方が、大抵の場合はより速く原因に辿りつくことができる。 その2 : 問題が発生した『後』の動作を延々と追いかける。 原因が何であるかにもよるが、ひとたび問題が発生したらそこから先の動作は進めば進むほど予測不能となっていく場合は多い

  • 最適なデバッグは可能性を潰していく事 - 神様なんて信じない僕らのために

    minekoaさんのエントリを読んでいて、 「そうそう、コンパイラがこんなこと言うときは実際にはあんな事が起きてるんですよ」みたいな知識データベース。そしてコンパイラが検出出来ないタイプのバグについても、現象に「あれ?、どこかでみたぞ、これ」となる。そういう「良くあるパターン」の蓄積はデバッグのスピードアップに大きく貢献します。 正しい。けれど、それはそれとして。 根的な問題として、「問題の切り分け」というのが出来ていないからデバッグ出来ないというのが、「デバッグができないこと」なのではないかと思います。 デバッグという基礎素養 - みねこあ 「最適なデバッグはまず適切で高い可能性から潰していく事、最後に残った事が真実」 だなあと思いました。 デバッグをするときに経験があると 「そうそう、こういうときはこれだよね」 というのが解ります。 ハングアップが一番簡単で、 スタックを見ても良いし

    最適なデバッグは可能性を潰していく事 - 神様なんて信じない僕らのために
  • 経験の浅いプログラマーがデバッグできない理由

    経験の浅いプログラマーがデバッグできない理由 「大半の人間がデバッグできない理由」を読んで思いついたことを書きます。 Lights Out っていうパズルゲームがあって、 これは1つのランプを消すと、周りのランプがつく、みたいなルールになっていて、 それを全部消すというゲームです。 たとえば Lights Out - 2 Flash Games, Lights Out Game とか。 今は入手できないのですが「牡丹灯籠」という実装が好きでした。 通常の Lights Out だと消えてるランプをクリックできるのですが、 牡丹灯籠はできなかったんじゃなかったかな、たしか。 ルールもそうだし、グラフィックが切なくてよかったですねー。 んで、ゲームをするとして、とりあえずいろいろクリックしていくわけですね。 そんで、自分の知ってるパターンに収束したら、 あとはパターンに沿って消していけば全部消

  • デバッグという基礎素養 - みねこあ

    経験の浅いプログラマーがデバッグにてこずってるのって、 これと似ていて、 むやみやたらにクリックするのだけど、 自分の知ってるパターンに収束させることができない、みたいな。 これについては、経験を積めば、 自分の知ってるパターンが増えてきて、 バグだ、と思ったときには既に自分の知ってるパターンだから直せる、とか、 ちょっと試行錯誤すればパターンに落とし込めるとか、 そうなるんじゃないかな、と。 経験の浅いプログラマーがデバッグできない理由 については、コンパイラの吐くエラーが実は直接的が原因を示していない、とか、そういうレベルの話では実感だな、って思います。 「そうそう、コンパイラがこんなこと言うときは実際にはあんな事が起きてるんですよ」みたいな知識データベース。そしてコンパイラが検出出来ないタイプのバグについても、現象に「あれ?、どこかでみたぞ、これ」となる。そういう「良くあるパターン」

    デバッグという基礎素養 - みねこあ
  • ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習

    最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識がになりました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない!vs. 現場に任せてくれない!の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン(あるいは権威勾配に関する一

    ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
    rin51
    rin51 2014/05/26
    悪習やってるわorz だから成長が鈍いんだなあ。上から目線でdisるわけでもなく1つ1つ丁寧に書かれている。こういうひとに指導されたかった
  • 1