メインコンテンツへスキップ
見出し画像

【開発哲学3_23】〜『CODE COMPLETE第2版 第23章(下巻)』の感想〜デバッグ

    感想

    煮詰まったら離れる

    が、開発時でもデバッグ時でもやっぱり大事だねえ。

    「総当たりハック」って、そういやプルートフォースって言ってたな💦

    結構忘れてるから、読み返してよかった。

    データベースリファクタリング(次の本を読み終わったら、感想を書く予定)

    の冒頭にも書かれているとおり、

    発展型プログラミング = ひとつ変更したら検証する

    が最良ってことね。

    この章でも書いてるけど、

    DXとかRPAのトレンドの波に乗りたい + 希望的観測
    =元々、手作業でやっている業務を何とかデジタル化、自動化できないか
    👉エンジニアを連れてくれば、今のルールのまま、自動化できるはず
    ↓
    「いや、エンジニアならば、自動化できるべき。」 = 勝手な願望
    で、マニュアル化しようにもマニュアル化すらできないくらい、規則性のない作業は、素直に手作業でやるしかないし。

    それでもやりたいのであれば、まずは規則性を持たせるように、社内のルールを変えないと時間を無駄にするだけ。規則性が全くできない作業をプログラミングにやらせるのは無理。なぜなら、

    人間が手作業でやってる規則的な作業をコード書いてPCにやらせてるだけ

    だから。

    「それでも実現させるのがプロだ」

    と使命感と自負でやりたい方はどうぞご自由に。
    結局は本来の社内のやり方を変えるしかないんだから。
    本当のプロは、できないものは最初からできないって言うし、
    要求を聞いた段階で、そう言い切れるのが本当のプロだしね。

    詳細

    見出しとしては、

    1. デバッグの概要

    2. 欠陥の検出

    3. 欠陥の修正

    4. デバッグの心理学的考察

    5. デバッグツール

    6. 参考資料

    7. まとめ

    て感じ。

    前章とセットで読むといいかな💦。

    前章で、

    • テスト:あくまでもエラーを検出する作業

    • デバッグ:テスト結果を受けて、バグコードを改修する作業

    って明確に分かれることが書いてあるし、テストの中でも、

    • ダーティテスト:あらゆる角度からコードの不備を検証する

    • クリーンテスト:コードが動くかどうかを検証するする

    があるんだけど、

    プログラミング = コードを書くこと

    でコードしか追わず、コードの本しか読まない人って、
    いざ、結合テストとかやると、コード以外の要因でエラーどころか動かなかったり、ストレステストでオーバーフローってことも屡々。
    しかもいろんなツールや基板や環境にも依存するから、コードだけ追っていても想定外のエラーも出るしね。

    「うちには余裕がない」

    って言って、

    テストとデバッグを大体一緒くたに考え、ひとつのエラーを検出後、すぐに該当箇所をデバッグをする。

    感じで、
    全体での洗い出しが終わる前に、コード改修に取り掛かる
    から、他のエラー箇所を改修する時に、場当たり的に改修したデバッグ後のコードが新たなエラー原因になっていることも屡々。
    それやると、却って余計な時間がかかるだけなのに、、、。
    (👉終わりなきモグラ叩き)

    対象範囲の全てテストが終わってから、デバッグする。

    が基本。てか独自のやり方とかやると却って回り道になると思う。

    最近は、

    Swiftとか静的プログラミング言語で、インテリセンスが充実していたり、

    誤ったコードを打ったりすると、自動的に警告を赤とか黄色のマークで発してくれて、コーディングエラー=バグをわかるようにしてくれてる

    開発環境も多いし、それが主流じゃないかな?

    かと言って、

    完全に警告を消したとしても、ルーチンをつなぐ順であったり、不統合のつけ間違いとかでエラーは発生するし、だからこそ、実機テストまでは行って、期待値どおりに製作物が動くかどうかを検証までは必要なんだけど。

    そう言えば、去年だったか

    とあるアプリで、通知機能に不具合があるのでは?ユーザーから指摘を受けていたのに、3ヶ月以上放置されていて、コードをちゃんと確認してるから、実機テストを初回リリースの段階で1度もやってませんでした。。
    みたいな報道されてたアプリあったなあ。
    九次受け請けまで絡んでたプロジェクトだったか。

    ⒋デバッグの心理学的考察

    で書かれてる思い込みから起こるコードの読み間違いと、
    コードが完璧だとゆー自信や確認不足が、
    バグの一番多い原因かもしれない。
    👉アンコンシャスバイアス
    (=プログラミングに限らずどんな分野や仕事にも言えるかも、、、💦)

    「コード書いてれば、こういった本に書いていることは身につく」

    で、
    コードだけ書いて、プログラミングの考え方を身に付けない
    のと
    コードを書きながら、こういった本を読んで、読んだことを実践しながら、きちんと作法を身につける
    では大違い。かと言って、
    こういった本に書いてることを全部理解してからコードを書くだと、イメージ出来ないから理解できない
    と思う。

    順番が違うだけ。だけど、順番が大事

    まとめ

    デバッグは、
    そのプログラミング言語の知識がない人にはできない。

    デバッグしながらコードを学べる
    は、
    趣味で個人開発のやるならいいけど、
    お客さんにとっては、いい迷惑でしかない。

    💃お客さんは、プログラマの練習台じゃないし、
    成果物はプログラマの教材じゃない
    🕺

    参考

    JSTQB(テストやデバッガ向けの資格)

    については、こちら(持ってないけどー)。

    そもそも一般的な期待値や要求の指標

    については、(一部だけど)こちら

     
     
    タダの道楽者💫ネガティブなコメント一切お断り 裾野が広がりゃそれで良い 洋書と古典とSwiftをこよなく愛するオッさん👀 色即是空🕺 記事はマガジンの方が読みやすいかな💦 ちょい難とダラダラ💃 無駄な対立軸と課題探し思考は要らんな。 変幻自在➕縦横無尽➕融通無碍🟰天衣無縫

    あなたへのおすすめ