@kazuo_reve 新人の方によく展開している有益な情報
https://qiita.com/kazuo_reve/items/d1a3f0ee48e24bba38f1
で参照・引用しているURLを一つづつ確認してみよう。
確認する視点は３つ。
-
書いた時点と今とで事情が変わっていないか。
-
書き手と、読み手で見えかたが逆の事象はないか。
-
真偽の論理的な書きぶりの事項は、統計的もしくは確率的に扱った方がよくないか。
まとめは、時と場合と統計に区分する。
書き手と読み手で見えかたの違いは、場合分けをしていればおきないかもしれない。
自分が属している場合と違う場合も書き込めばいいのだから。
37 @kazuo_reve， トラブルシューティング(デバッグ)について実体験から学んだこと
面倒見: @kazuo_reve 新人の方によく展開している有益な情報（36)
https://qiita.com/kaizen_nagoya/items/1ba016fddd70bb264429
1. 時
投稿日 2020年02月29日 更新日 2021年10月31日
2 場合
分類し直して、優先順位をつけてみる。
2.1 記録する
仕組みを明らかにする。
2.2 仮説検証を停滞させない
仮説はどんどんたてていく。検証はできないものがあることを確認する。
社会事象は検証できないかも。仮説（204）
https://qiita.com/kaizen_nagoya/items/6b989b26f7ea2ac342cf
2.3 急がない
停滞させないようにしていれば、急がなくてもいいかも。
事前に試験プログラムを作るとか方針が大事。
方針がおかしいのに急いだら、泥沼に入っていくかもしれない。
2,4 原因より現象
再現しなくても、対策を立てられることはいろいろある。
原因がわからなくても、対策を立てられることはいろいろある。
OS, 言語、枠組みなどを、過去の版、現在の版、新規提供のベータ版の３つで、3×3×3の27通りで実行してみて、出る現象に着目する方法をしばしば取っている。
OS、言語、枠組みの次の版の変更に向けての準備にもなる。
OS、言語、枠組みの方で、次の版ではバグへの対応が住んでいるのに現行の版での修正に力を注いでも意味がない。
まして、現状の構造を変えるような修正は次の版でのバグの原因になるかもしれない。
長期的な方針を持ってバグ取りするには、経験者の知見を集めてみるとよい。統計データを集めてみると、経験と勘と度胸が確率と統計に基づいた結論と同じになることを知るかもしれない。
2.4 作った人/直す人以外の人がデバッグするのもよい
立場によって見えかたも違えば、再現する現象も違う。
人の静電気の影響が違えば、タイピングの速度も違う。
特定の人がそうさすると出現するバグというのはしばしば経験している。
3 統計
3.1 参照記事の課題
3.1.1 デバッグするときのコツをまとめてみた
変数の値をprintして確認
変数に正しい値が格納されているのか確認し、バグがあるか判断します。この方法の欠点として、print文を消し忘れるとソフトウェアが正しい挙動をしなくなることです。
printして確認の課題は、printして確認すると期待通り動くが、printをしないと違う動きをする場合があることである。例えば、printするために確保した領域が、値の上書きや、時間の調整をしていて、時間的にも空間的にも期待した動作さけをする場合がある。printを消すと、OSや言語によっては、空間を壊したり、時間の順番が入れ替わることがあるかもしれない。
コンパイラを書くのは難しいか。仮説（175）
https://qiita.com/kaizen_nagoya/items/a87c65d487bc7a67da11
ログを吐かせて変数の値を確認
この方法は、print文と同じように変数の値を確認しますが、ログとして残るだけなのでprint文の欠点のような事態には至りません。
ログをはかせるのは、print文以外の、ツールに植め込みの機能を使うという意味だろうか。いずれにしてもprint文を使ってログを吐かせる方法と、ツールに埋め込みの機能を使う場合で、同じ処理を経由するのであれば、違いような気がする。どういうツールを使うと、違いがあるかの記載があると分かるかも。
3.1.2 デバッグの進め方について個人的に意識したいことをまとめてみた
よくデバッグでは、再現条件を明確にすることがまず大切だと言われます。そのために様々なユーザー操作やパラメータを変更したテストによって、情報を収集し、理解をしていくことが必要になってきます。細かくマイルストンを置いた形で進めたとしても、各マイルストンで得た情報で理解を進めることが出来なければ、次のアクションに移ることが出来ません。
「ゴール」が何を意味するかわからなかった。システムのゴールか、開発作業のゴールか、顧客のゴールか、その違いが何があるかを記述していると嬉しい。「現時点」という言葉も何を意味しているかわからなかった。現時点は、常時変化しており、何かを言ったことにならないような気がする。「ゴール」「現時点」が、著者たちの分野での特別の意味があるのだろうが、想像力が乏しくて、現時点ではわからない。
3.1.3. デバッグのコツ
現象の再現
開発者の手元で現象を再現することは重要です。
再現方法が不明な時点では、「実行環境」、「進行状況」、「直前の操作」が重要な手がかりです。
確実に修正されたと認めるには、現象とその再現方法が分かっていなければなりません。
再現性のあるバグに焦点を絞っているようです。再現性のないバグの解決の方法として、空間に余裕を持たせたり、時間に余裕をもたせたり、処理速度を速くするなどの方法があります。課題としては、これrの対応方法は、再現性のある別のバグを発生させる可能性が高いことと、再現性のない別のバグを誘発する可能性があることです。再現性のある別のバグと思った事象が、再現性のないバグの原因の一つで、特定の組み合わせで起こり、１０年に１度とかしか起きないために再現試験ができないような事象です。そして、１０年に１回しか起きないような現象が、出荷すぐに起きることがあることは経験上の印象が強く記憶に残ってしまいます。
3.1.4 デバッグについて自分なりに整理してみた
正常に動作する似た環境と比較して仮説立案の参考にする
愚直に仮説と検証を繰り返して事実となる情報を集める
仮説と検証を繰り返しても、なかなか原因が見つからないこともあります。しかし原因特定のための情報は仮説と検証を繰り返すことで徐々に集まってきます。
ときには当てずっぽうな仮説で検証することがあっても、得た事実は次の仮説を考える上での貴重な材料になるので、整理しておくといいかもしれません。
「当てずっぽう」というのは、連続系生命体の計算能力と記録能力に依存した高度な方法です。
時々、批判的な意見を見ることがあります。はずれた時の言い訳をしているのかもしれません。
当てずっぽうで当てる人が羨ましいだけかもしれません。「当てずっぽう」が駄目だという人は、まだ経験も勘も度胸もないだけかもしれません。
経験と勘と度胸。裏打ち可能な分布と確率。証拠能力が高い。統計と確率(12)
https://qiita.com/kaizen_nagoya/items/f5ec32472774d17e46ec
3.1.5 デバッグついて（不具合の特定について）
- お客さんに再現したパターンをヒアリングする。
なるべく詳細に聞くことが求められます。
どうった操作をした。
いつ（いつ頃から発生したか）
誰が（どのユーザ、他の人は起きていないか）
どういった環境 どのサーバ、ブラウザ（バージョン）、ネットワーク環境は
どういったデータか？（可能ならば入力、使用したデータをもらう）
再現するための情報を必死に聞き出します。
再現しない不具合を解決するのがプロだと思うといいかもしれません。
また、再現しても、運用で回避するしか費用対効果が見合わないことがあるかもしれません。
- 原因と思う箇所を、ピンポイントで特定する
これは読みや勘を必要としますが、ある程度場所が絞り込めていたら
経験のあるエンジニアであれば、最後はこれで特定することができます。
勘と言っても、過去の類似の経験から、ビビビとくるもので、完全な山勘ではありません。
新人のエンジニアにはできない芸ですね。
再現性のないバグも、この方法で解決することがあります。
過去に、再現性のないバグを、どれくらい克服してきあtかによります。
再現性のないバグを検知する仕組み自体が別のバグを発生させる可能性もありますし、再現性のないバグ自体を抑止してしまうこともあります。この損得も、経験の有無で判断が真逆になる可能性があります。
3.1.6 プログラミング一般で使えるデバッグ方法
プログラム一般では使える方法は原則的にない。
特定のプログラミングで使える方法のうち、興味深いのは次の５つ。
ミニプログラムで動作を確認する
直近の修正箇所を疑う
データを疑う
処理の実行速度をわざと遅らせる
スレッドの数を大幅に増やす
時間に関するデバッグは、デバッグモードが実行モードと違い、デバッグでは確かめられないことが多い。
最後の３つは時間に関する試験に役立つ。
3.1.7 デバッグ力を高める！ ～5 年間の経験から学んだ、競プロ・アルゴリズム実装におけるバグ取りの戦略～
具体的な場合を想定しており、全体にものすごくわかりやすい。ここまでの記述は、著者は知っているが読者は知らない初期条件、制約条件での話で、たまたま同じような条件で仕事をしている人には役立つg、そうでない人には、その美味しさが分かるのに時間がかかるかもしれない。
大事そうなところがいっぱいあり、仕事の条件によって違うかもしれない。私は、次の点が気にいった。
「バグ取りの時間短縮」の重要性
典型パターン 10 個
1 点目：入出力の形式を間違える
2 点目：型（int, long long など）を間違える
3 点目：添字を書き間違える
4 点目：境界や不等号を間違える
5 点目：操作を 1 個書き忘れる
6 点目：場合分けを忘れる
7 点目：オーバーフローや誤差のせいで不正解となる
8 点目：配列外参照をする
9 点目：複数テストケースの問題で、初期化を忘れる
10 点目：そもそも解法が間違っている
6-2. 実行環境の違いが原因で手元で正しく動いてしまう
3.2 社会調査
社会的な事象では、統計による検証はできないと仮定して考えるとよい。
統計は嘘をつくための道具かもしれないと。
統計の嘘。仮説（127）
社会事象は検証できない。仮説（204）
4 まとめに代えて
新人プログラマ応援 - みんなで新人を育てよう！
今、Qiitaでは、「データに関する記事を書こう！」という行事をやっている。
この文章は、テーマ2『データに関する記事を書こう！』参加記事でもあります。
いくつかの事項は、データを取ってから追記できればいいかもしれない。
あるいは、お手持ちのデータがありましたらコメントいただけると幸いです。
自分の頭で考えることが大事なのではない。
何か行動すれば、必然的に、自分の頭で考えなくてはならないところに追い込まれる。
自分の頭で考えるようになるには
「自分の頭で考える」ということ。
行動して、測定すればいい。
ぼくの先生「人がやらないことをやれ」プログラマになるまで。仮説（37）
小学校の絵の先生には、色を置いてみるという試行錯誤を教わった。
中学校の技術の先生には、人がやらないことをやれと教わった。
考え方など教わらなくてもいいのだ。
行動すれば、その責任は自分で考えて、よりよくするのが試行錯誤で、人がやらないことをやった人が考えることかも。
DoCAP 芸術でも技術でも運動でも
4.1 参考文献
@kojimadev 1年以上かけて生産性倍増＋成長し続けるチームになった施策を全部公開
@torifukukaiou【毎日自動更新】新人プログラマ応援 - みんなで新人を育てよう！（2022年04月） LGTMランキング！
@torifukukaiou 【毎日自動更新】データに関する記事を書こう！ LGTMランキング！
@kazuo_reve 「新人の方によく展開している有益な情報」の中で大学時代に得ておけばよかった情報
@kazuo_reve 私が集めた有益な情報・知識のまとめ
@kazuo_reve 私にとって有効だった学び方5選
@kazuo_reve 自分のQiitaの記事を分析してみた
@kazuo_reve 私が効果を確認した「小川メソッド」
@e99h2121 育児していたからこそエンジニアのお仕事に役立ったこと10選
@e99h2121「女性こそエンジニアになるべきだ？」デブサミウーマン登壇記録
@e99h2121 新人さんにすすめる有益なツール達 2022春
@e99h2121 新人さんにすすめる有益な技術書達 2022春
@ohakutsu 新卒1年目のエンジニアがQiitaの速度改善をした話
@ohakutsu 新卒2年目から見た達人プログラマーの振る舞い
4.2 自己参照
ソースコードを読むための技術: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（１）
スペックアウト手法: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（２）
変更の影響範囲を特定: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（３）
質問は恥ではないし役に立つ: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（4）
質問するときのパターン・ランゲージ: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（5）
「できない人」ほど、人に聞けない: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（６）
分からないをすぐ伝える: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（７）
15分ルール: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（８）
検索の仕方: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（９）
エラーメッセージの読み方と対処: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（10）
Google検索のコツ: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（１1）
新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（12）
日報、週報、月報、年報: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（１3）
新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（１4）
分報（分単位報告）: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（15）
分かる: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（16）
わかったつもり: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（17）
開米瑞浩 図解: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（18）
要求仕様: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（19）
SE用語: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（20）
文章の推敲: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（21）
結城浩 数学文章: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（22）
結城浩 推敲: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（23）
あいまい表現: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（24）
やまとことば: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（25）
鍵語による見直し: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（26）
開米瑞浩 MECEとロジックツリー: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（27）
芝本秀徳 考える: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（28)
佐藤航陽 論理: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（29)
清水吉男 設計: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（30)
「@kazuo_reve 新人の方によく展開している有益な情報」はじめ記事を参照して頂いた時にしていること。
@kazuo_reve「「新人の方によく展開している有益な情報」の中で大学時代に得ておけばよかった情報」に付け加える3つのこと。
プログラマにも読んでほしい「QC検定にも役立つ！QCべからず集」
図を使って分析すればこんなに簡単。安全（１１）
５月病にならないで
文書履歴(document history)
ver. 0.01 初稿