Log.debug("nice catch!")に参加してきたよ

GREEさんパネェ！！

イベントページはこちら
http://connpass.com/event/607/


スライド

例外設計における大罪
http://www.slideshare.net/t_wada/exception-design-by-contract

ログ、その時の為に。
http://dev.handwerkszeug.org/docs/java-ja_20120627/#/

クライアント側でつかまえて
http://www.slideshare.net/kaorashibacaki/ss-13477391

エラー処理の抽象化
http://tanakh.jp/pub/exception-logging-study-2012-06-28/exception.html#1

LOG.debug(marker,”使え”) // Speaker Deck
https://speakerdeck.com/u/yoshiori/p/logdebugmarker

和田さん

• TDDだとロギングのコード書き忘れやすい
  • 動作確認がいつでも出来るので動作確認のログを書き忘れやすい
  • 例外はむしろ厚くなりやすい
  • →TDDを行うとロギングコードを書き忘れやすい仮説

• 例外設計の大罪
  • 放置
    • 大規模開発だと例外処理コードを書かせたくない、なんて話も
      • 非検査例外にまるめてFWでキャッチするようにしているコーディング規約もある
    • 最近の静的解析は例外の握りつぶしを検出できる
    • やっちゃいけないgoto文とやっていいgoto文があって、やっていいgoto文をサポートしたのが例外
    • java7にはtry-with-resourcesがある
      • close()の例外をまたcatchしないといけない問題をシンプルに書ける

• • 乱用しない。例外は例外的な問題にのみ利用すること
    • 制御フローに例外を使わない
    • 乱用はGOTO乱用と同じようなもの
    • すべての例外ハンドラを除去してもプログラムは動作することが出来るだろうか
      • 答えがNoなら例外で無い時に例外が使われている

• • 過剰防衛なプログラム
    • DRYじゃないのはアカンけど過少防衛に比べればまだマシじゃない？
    • 可読性が下がる、メンテナンス性が下がるのは言わずもがな
    • 冗長性のある検証は損傷を与える。複雑さは品質の敵
    • 契約による設計
      • 責任が呼び出し側にあるのか、呼び出され側にあるのか、そのルールを決める
      • 例外処理とは予想外の状況=約束が破られた時に起こるもの
      • 例外は呼び出す側が契約条件を満たしたが呼び出された側が契約を履行できなかった時に投げるもの

• • 技術的例外とビジネス例外を明確に区別する
    • 両者を同じ継承ツリーに入れない
    • 技術的例外は貫通させてフレームワークに任せる。
    • ビジネス例外は準正常系なので呼び出し側で対処する。

• • 出来てはならぬことを禁じるのではなく出来ていいことだけを出来るようにする
    • デフォルトでエラー側に倒す

たいちさん

• ログって？
  • ユーザのシステムに対する行動記録

• ログの受益者
  • 開発者ロール(コードを書く人)
    • ホワイトボックス的に障害解析をする人
  • 運用者ロール
    • ブラックボックス的に障害解析をする人
    • 再現しないように開発者に依頼する
    • 再現してもシステムを運用し続ける
  • 分析者ロール
    • KPIとか。知らないので今回は話さない。
  • 開発者は運用者というロールを想定すべき

• ログが果たすべき役割
  • アプリケーションやフレームワークの動作理解の為
  • 正しく動作してるのかしてないのかを切り分ける
  • 0 or 1ではなく、見た人によって正しさが変わる場合ログは役に立つ
  • 障害の原因となった可能性のある状態を適切に発見する

• 顕在化しやすい場所とその原因となる場所で出てないとダメ
  • 障害を切り分けやすいことと動作を理解しやすいことは共通するところもあるけど一致はしない

• ユニットテストで洗い出しにくく、本番環境で他システムと結合した時に起こりやすいところにログを仕込む
  • こういうところで出すログは特別扱いしてもいいんじゃね？
    • インタフェース(バウンダリ)
    • ミドルウェアとのI/O
    • ファイルI/O
    • 粒度の大きいシステム間通信(RESTとか)
    • 粒度の大きいモジュール間通信

• ログの出力制御
  • 必要な情報が出る様にピンポイントでログが出力される様に制御する
    • 問題はほぼ解決していて念の為確認すると言った色合いが強い
  • スタックトレース等を見て関連性のありそうなものを定性的な基準で選択する
  • TRACEやDEBUG等、全てのログがでる様にした上でフィルタしながら解析する
  • ほぼ障害が解決している状況を除くとログを何らかの形でフィルタリングしながら解析をしなければならない。
  • ログの出力制御を設定する作業者とログ出力コードの実装者の対象に対する理解が適切に合致していない場合、名前空間のみをフィルタリングの基準として採用していると解決に必要な工数が大きくなりがち
    • →そこで、名前空間やレベルに加えてログ解析の為に新たな項目を追加してはどうだろう？

• 新しい項目の提案
  • 一般的な出力項目
    • 日付や時間、モジュールの名前空間、ログレベル
  • 問題が顕在しやすい箇所のログにマーカ文字列を追加する
    • DESIGN : 粒度の大きなモジュール間間の結合面で。拡張ポイントで
    • BOUNDARY : ファイルやネットワーク、他の依存ライブラリに対するインターフェースに関連する項目
    • LIFECYCLE : オブジェクトのライフサイクルに関わるところ。initとかcloseとか。

• ログtips
  • traceやdebugは容赦なく出す
    • 開発者規模が大きい開発とかではAOPなんかをつかって自動的に出すようにする
      • 個々の開発者に任せない(忘れたり、コピペコードに由来して意味のないログコード仕込んだり)

• • 適切にログローテーションしよう
    • ファイルシステムによってはファイルエントリ数に上限がある
    • 32bitシステムだと2GB以上のファイルをうまく扱えない

• • ログの動作コストも測ろう
    • ログを出さなきゃバグは分からないけどログがバグになったら仕方ないよ

• • ログの容量見積りをする
    • traceやdebugは運用で出ないからいいけどinfoとかwarnでどれくらい出るか
    • ログローテーションの話ともかぶるけど、ヘタするとえらいことになる

• • ログの削除ポリシーを決める
    • ログを消すことに責任を取る人を決めなきゃいけないことに対する抵抗感
    • 消さないと運用コストが底上げされる

ログを出す目的を、役割を基準に考えよう！

解析しやすいログを出そう！

気づき

過剰防衛なプログラムは気をつけなきゃなーと思った。過少防衛よりはいいかもしれないけど、やはり複雑さは品質の敵。結局のところ、メンテナビリティが低下していいことなんて一つもないし、他のバグを仕込む余地を与えるだけなのかも。

技術的例外とビジネス例外を区別するということ。同じ「入力が不正」という状況であっても、システム側の問題でパラメータが不正な入力と化してしまったのか、それともユーザのアクションが業務ロジック的に受け入れられないものであるのかは、確かに違うものだなーと。

問題が顕在化しやすい箇所のログは厚くする…のはそうなんだけど、単に詳細に出すというだけでなく、後で解析しやすいような仕組みを入れるんだよ、ということ。(マーカ文字列とか)
後は問題の顕在化しやすい場所、というのを言語化してもらった。感覚的にはあったんだけど、言葉にしてもらうと心強いなーと。

開発者は運用者というロールを想定すべき…なのだけれど、今までの経験的に作った人が運用までする、というケースばかりだったので感覚が薄かったなぁ。

ステマされた良書たち。Effective Java読んでないとか今更言えないよなー

Effective Java 第2版 (The Java Series)

Clean Code アジャイルソフトウェア達人の技

Clean Coder プロフェッショナルプログラマへの道

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

すごいHaskellたのしく学ぼう!