パスワードを忘れた? アカウント作成
474007 journal

L.Entisの日記: クローズアップ現代 9

日記 by L.Entis
クローズアップ現代 ソフトウェア危機
~誤作動相次ぐハイテク製品~


83万行中の1行のミスで止まった自動改札の話からスタート。
しかし、コンシューマ用ならまだしも、改札みたいな業務用には、アサーションコードを埋め込んで(リリース用にも)、ログを記録しておくとか、そういうことは出来ないのか、と見ていて思ったのですが…
頻繁にアサーションコードを埋め込んでおけば、問題が起きた時点で、かなり問題の箇所を絞り込めると思うのですが………


ソフトウェア現場の説明。
ゲスト「現場ではデスマーチと呼ばれています」
でもほぼこの一言ですね、説明は。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • ログ1行取るのに数ミリ~数十ミリ秒かかりますし、
    真面目に吐くとどんなにディスクあっても溢れますし、
    そのせいでディスク壊したら本末転倒ですし、
    せいぜい、断末魔(ERRORとかFATALとか?)が精一杯だと思います。

    昨今の改札ってディスク積んでるのでしょうか??
    • 最近のだけで良いと思うので、別に大した容量も必要ないのでは?

      それに、
      >真面目に吐くとどんなにディスクあっても溢れますし
      って、バグだらけのコードをリリースしてるってことですか?
      私が言ってるるのは、アサーションの記録ってことですよ?
      正常なプログラムなら、どんなにマメにアサーションコードを埋め込んだところで、アサーション条件の判定に必要な数クロックが消費されるだけで、それ以上のコストは必要ないはずです。
      (当たり前ですが正常時の記録は不要です)
      親コメント
      • アサーションが上手く取れた記憶があんまり無かったりします。

        ・そもそもアサーション的なコードが入ってない。
        ・アサーションを入れてみたは良いけれど、
         1.Javaのオブジェクトみたいな奴を式に入れてやたら重い
         2.メソッドのin/outに入れたらループで何万回も呼ばれて重い
         3.選択してる時間ないし、重いから全部取っちゃえ。

        過去の経験ではこんなんばっかり。
        うーん、ロクな案件に関わってないのがばれてしまいますね。
        親コメント
        • ・アサーションを入れてみたは良いけれど、
           1.Javaのオブジェクトみたいな奴を式に入れてやたら重い
           2.メソッドのin/outに入れたらループで何万回も呼ばれて重い

          こう言ってはなんですが、私の感覚からすると、ちょっとセンスが悪いような気が…
          それとも、Java が重いだけ?
          親コメント
          • 両方です。
            でも、実際の開発現場では基本的に「センス」は役に立ちません。
            新人や、日本語の通じない人もいますし、センスのないPGもいます。
            それゆえに彼らに具体的で画一な指針を提示する必要があります。
            そうすると、必然的にメソッドのin/outでパラメータを出力となります。
            Javaでオブジェクトが渡されると、それはもう。。。

            確かに、Javaは重いですねぇ。
            かつてVBが重いと不評を買っていましたが、Javaはもっと酷いです。

            親コメント
      • assertしたという記録よりも、それを引き起こした条件のほうが重要なので動作追跡のログも必要です。
        搬送システム納入してますが、一時間のログサイズがメガ単位なんて普通です。
        親コメント
        • ログに記録する関数を仮に log_asertion として

          #define assert(expr) if ( !(expr) ) log_assertion( #expr, __FILE__, __LINE__ )

          では不十分ですか?
          アサート条件を満たさなかった場合の、アサート条件式、ソース名、行番号が出力されますが。


          あと、動作追跡が必要な件もあるでしょうが、私が言っているのは最小限のコストで出来るでしょうという話をしているので。
          それに、アサーションエラーが普段からでまくるのは、プログラムがバグだらけか、アサーションコードの書き方が間違えているというのは異論はないかと思います。
          (例えば、ユーザー入力された値が範囲内かどうかをアサーション判定するのは誤り。しかるべき処理を通過した後の値が、しかるべき処理で定義された仕様通りの値の範囲に収まっているか、またしかるべき処理に入力される値が、定義された仕様通りの範囲に収まっているのかを判定するのに使用するものですからね。)
          親コメント
          • >#define assert(expr) if ( !(expr) ) log_assertion( #expr, __FILE__, __LINE__ )
            >
            >では不十分ですか?
            >アサート条件を満たさなかった場合の、アサート条件式、ソース名、行番号が出力されますが。

            十分な場合もあるでしょうが、たいていの場面では不十分だと思われます。
            これに加えてスタックトレースが欲しいところです。
            細かい動作ログが無くても、スタックトレースがあれば調査が格段に楽になりますから。
            親コメント
            • >十分な場合もあるでしょうが、たいていの場面では不十分だと思われます。
              >これに加えてスタックトレースが欲しいところです。

              スタックトレースなら、log_assertion 関数でスタックを出力するようにすれば言いだけのような気がしますが…
              呼び出し規約などにもよるかと思いますが、呼び出され側から呼び出し元を特定していく作業は大抵可能かと思います。
              それに、あなたも書かれているように、ここでは完璧なログの話をしているわけではありません。
              仮にスタックの記録がなかったとしても、アサーションエラーのログが全く無いよりは1つでもあれば、ずっと絞り込めるでしょうという話をしているのです。

              因みに、付け加えて、完全にストップした場合に、環境ダンプくらいは今ならそこそこ安いコストで出来るとは思いますけどね。
              親コメント
typodupeerror

UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア

読み込み中...