1分1秒を争う障害対応のためのリーダブルコード

Slide 1

Slide 1 text

1分1秒を争う障害対応のためのリーダブルコード 2013/10/26 Ohotech 特盛 #5 素敵なおひげ(@stknohg) 1

Slide 2

Slide 2 text

自己紹介  ハンドルネーム  素敵なおひげ  Twitter : @stknohg  Blog : http://stknohg.hatenablog.jp/  誰？  札幌市内で働く”残念”SIer。基本何でも屋ですが、最近はWindows系のインフラ設計やシステムの基盤アプリケーションを作ったりしてます。  数年前からCLR/Hの裏方として活動中。 2

Slide 3

Slide 3 text

今日の内容 1. はじめに 2. リーダブル？コード 3. 障害対応のためのリーダブルコード 4. まとめ 3

Slide 4

Slide 4 text

リーダブルコード 4

Slide 5

Slide 5 text

読みやすいコードとは  コードは理解しやすくなければいけない。  コードは他の人が最短時間で理解できるように書かなければいけない。 5

Slide 6

Slide 6 text

本日の趣旨  リーダブルコードは、より良いコードを書く・コードの品質を上げるのを主題としているが、緊急を要する様な障害対応の場合にも『読みやすいコード』は有用であることをお伝えしたい。 6

Slide 7

Slide 7 text

お断り  今日のお話は事実を基にしている箇所があるかもしれませんがフィクションです。  あくまでフィクションです。  具体的なコードはスライドには載せられません（できません）のでご了承ください。 7

Slide 8

Slide 8 text

今日の内容 1. はじめに 2. リーダブル？コード 3. 障害対応のためのリーダブルコード 4. まとめ 8

Slide 9

Slide 9 text

こんな処理があったとして… 9 現在時刻 17:00 ※実行すると対象の時刻に荷物を配達するためのデータを作る感じの処理だと思ってください。

Slide 10

Slide 10 text

落ちた！ 10

Slide 11

Slide 11 text

まだ大丈夫明日までまだまだ余裕があるし… 11

Slide 12

Slide 12 text

次にこんな場合… 12 現在時刻 11:30

Slide 13

Slide 13 text

また落ちた！ 13

Slide 14

Slide 14 text

これはヤバいあと30分しか猶予がない… 14

Slide 15

Slide 15 text

はやくコードを読んで調査しないと！ 15

Slide 16

Slide 16 text

アプリが何の情報も出してないのでどこを読むべきかわからない… でもどこ読んだらいいの！？ 16

Slide 17

Slide 17 text

リーダブル？コード  コードが読めなければ始まりすらしない。 ログ重要。超重要。 17

Slide 18

Slide 18 text

リーダブルコードに至るまでのログ設計  ログ取得の方式は何でもよい  ログの粒度は業務次第  取りすぎれば必要な情報を得るのに時間がかかる  足りなければ意味をなさない  何を取得するべきか  情報ログはそれなりに  致命的なエラーログはしつこいくらいに 18

Slide 19

Slide 19 text

リーダブルコードに至るまでのログ設計  最低限必要なエラーログ  スタックトレース  (DBを扱う場合)エラー時のSQL  あると望ましいログ  重要なパラメーター値  先ほどの例でいえば『対象時刻』など  画面のキャプチャ画像  入力項目が多い画面だと有効 19

Slide 20

Slide 20 text

リーダブルコードに至るまでのログ設計  ログを取得すべきタイミング  業務要件次第  基本重要と思われる処理の前後  何が重要かは実装者次第なところもある  エラー時はライブラリ・フレームワークが自動でログを採取する仕組みがあることが望ましい。 20

Slide 21

Slide 21 text

今日の内容 1. はじめに 2. リーダブル？コード 3. 障害対応のためのリーダブルコード 4. まとめ 21

Slide 22

Slide 22 text

ログファイルから読むべきソースを判断する  スタックトレースがあればとりあえず見るべきメソッドまではわかる。 22 スライドではお見せできないログファイルの例至って普通のテキストログとスタックトレースです。

Slide 23

Slide 23 text

ソースを読む 23 スライドではお見せできないソースをお楽しみください。 1クラス7000行ほどのちょっとした処理です。

Slide 24

Slide 24 text

1分1秒を争う障害対応のためのリーダブルコード  リーダブルコード内にあるいくつかのテクニックを紹介する。  ()書きの部分は書籍での章番号を記載。  具体的なコードは書籍で確認していただきたい。 24

Slide 25

Slide 25 text

巨大な式を分割する  緊急を要する状況下で調査する対象が大きすぎるととても間に合わない。  巨大な式を分割する (8章)  メインとなる処理から見える処理の抽象度を揃える  無関係の下位問題を抽出する (10章)  適切な抽象化  変数のスコープを縮める (9.2)  グローバルな変数があると常に調査対象がグローバルになってしまう  短いコードを書く (13章) 25

Slide 26

Slide 26 text

制御フローを読みやすくする  制御フローが簡易であればある程、より迅速な対応をすることができる。  If/elseブロックの並び順 (7.2)  関心を引く条件や目立つ条件を先に書く  関数から早く返す (7.5)  ガード節は非常に有効  ネストを浅くする (7.7)  ３段を超えるネストはツライ(個人の感想です) 26

Slide 27

Slide 27 text

名前に情報を詰め込む  緊急を要する状況下では、変数や関数の名前が持つ情報の役割は極めて大きい。  抽象的な名前よりも具体的な名前を使う (2.3)  GetData()メソッド、Dataって何を指してる？  Tmpやretvalなどの汎用的な名前を避ける (2.2)  スコープや生存期間が短い場合はその限りでない  誤解されない名前 (3章) 27

Slide 28

Slide 28 text

コメントは正確で簡潔に  コメントが冗長であったり内容が不正確 (古い情報であったり、そもそも嘘が書いてある) だと、対応の邪魔になってしまう。  読み手の立場になって考える (5.3)  他人に読ませるためのコメント  過去の自分は他人  コードの意図を書く (6.6)  コードを見ればわかることはコメントにいらない  関数の動作を正確に記述する (6.4)  コメントもメンテナンス対象 28

Slide 29

Slide 29 text

今日の内容 1. はじめに 2. リーダブル？コード 3. 障害対応のためのリーダブルコード 4. まとめ 29

Slide 30

Slide 30 text

まとめ  ログ重要。超重要。  『読みやすいコード』はソフトウェアの品質を上げるだけでなく、障害時に迅速な対応を可能にする。  ただ、この点を含めて“品質”という気もする。  そもそも論として『読みやすいコード』が書けていれば1分1秒を争う障害対応には至らないのかもしれない… 30