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

Ohotech 特盛 #5で発表した内容です。

ブログで幾つか補足をしています。
- https://blog.shibata.tech/entry/2013/10/28/002943

Transcript

1. 1分1秒を争う障害対応のための リーダブルコード 2013/10/26 Ohotech 特盛 #5 素敵なおひげ(@stknohg) 1
2. 自己紹介  ハンドルネーム  素敵なおひげ  Twitter : @stknohg  Blog : http://stknohg.hatenablog.jp/  誰？  札幌市内で働く”残念”SIer。 基本何でも屋ですが、最近はWindows系の インフラ設計やシステムの基盤アプリケーション を作ったりしてます。  数年前からCLR/Hの裏方として活動中。 2
3. 今日の内容 1. はじめに 2. リーダブル？コード 3. 障害対応のためのリーダブルコード 4. まとめ 3
4. リーダブルコード 4
5. 読みやすいコードとは  コードは理解しやすくなければいけ ない。  コードは他の人が最短時間で理解 できるように書かなければいけない。 5
6. 本日の趣旨  リーダブルコードは、より良いコードを 書く・コードの品質を上げるのを主題と しているが、緊急を要する様な障害対応 の場合にも 『読みやすいコード』 は有用であることをお伝えしたい。 6
7. お断り  今日のお話は事実を基にしている箇所が あるかもしれませんがフィクションです。  あくまでフィクションです。  具体的なコードはスライドには載せられ ません（できません）のでご了承ください。 7
8. 今日の内容 1. はじめに 2. リーダブル？コード 3. 障害対応のためのリーダブルコード 4. まとめ 8
9. こんな処理があったとして… 9 現在時刻 17:00 ※実行すると対象の時刻に荷物を配達するためのデータを作る感じの 処理だと思ってください。
10. 落ちた！ 10
11. まだ大丈夫 明日までまだまだ余裕があるし… 11
12. 次にこんな場合… 12 現在時刻 11:30
13. また落ちた！ 13
14. これはヤバい あと30分しか猶予がない… 14
15. はやくコードを読んで 調査しないと！ 15
16. アプリが何の情報も出してないのでどこを読む べきかわからない… でも どこ読んだらいいの！？ 16
17. リーダブル？コード  コードが読めなければ始まりすらしない。 ログ重要。超重要。 17
18. リーダブルコードに至るまで のログ設計  ログ取得の方式は何でもよい  ログの粒度は業務次第  取りすぎれば必要な情報を得るのに時間がかかる  足りなければ意味をなさない  何を取得するべきか  情報ログはそれなりに  致命的なエラーログはしつこいくらいに 18
19. リーダブルコードに至るまで のログ設計  最低限必要なエラーログ  スタックトレース  (DBを扱う場合)エラー時のSQL  あると望ましいログ  重要なパラメーター値  先ほどの例でいえば『対象時刻』など  画面のキャプチャ画像  入力項目が多い画面だと有効 19
20. リーダブルコードに至るまで のログ設計  ログを取得すべきタイミング  業務要件次第  基本重要と思われる処理の前後  何が重要かは実装者次第なところもある  エラー時はライブラリ・フレームワークが 自動でログを採取する仕組みがあることが 望ましい。 20
21. 今日の内容 1. はじめに 2. リーダブル？コード 3. 障害対応のためのリーダブルコード 4. まとめ 21
22. ログファイルから読むべき ソースを判断する  スタックトレースがあればとりあえず 見るべきメソッドまではわかる。 22 スライドではお見せできない ログファイルの例 至って普通のテキストログとスタックトレースです。
23. ソースを読む 23 スライドではお見せできない ソースをお楽しみください。 1クラス7000行ほどのちょっとした処理です。
24. 1分1秒を争う障害対応の ためのリーダブルコード  リーダブルコード内にあるいくつかのテク ニックを紹介する。  ()書きの部分は書籍での章番号を記載。  具体的なコードは書籍で確認していただきたい。 24
25. 巨大な式を分割する  緊急を要する状況下で調査する対象が大き すぎるととても間に合わない。  巨大な式を分割する (8章)  メインとなる処理から見える処理の抽象度を揃える  無関係の下位問題を抽出する (10章)  適切な抽象化  変数のスコープを縮める (9.2)  グローバルな変数があると常に調査対象がグローバルに なってしまう  短いコードを書く (13章) 25
26. 制御フローを読みやすくする  制御フローが簡易であればある程、より 迅速な対応をすることができる。  If/elseブロックの並び順 (7.2)  関心を引く条件や目立つ条件を先に書く  関数から早く返す (7.5)  ガード節は非常に有効  ネストを浅くする (7.7)  ３段を超えるネストはツライ(個人の感想です) 26
27. 名前に情報を詰め込む  緊急を要する状況下では、変数や関数の名前 が持つ情報の役割は極めて大きい。  抽象的な名前よりも具体的な名前を使う (2.3)  GetData()メソッド、Dataって何を指してる？  Tmpやretvalなどの汎用的な名前を避ける (2.2)  スコープや生存期間が短い場合はその限りでない  誤解されない名前 (3章) 27
28. コメントは正確で簡潔に  コメントが冗長であったり内容が不正確 (古い情報であったり、そもそも嘘が書いてある) だと、対応の邪魔になってしまう。  読み手の立場になって考える (5.3)  他人に読ませるためのコメント  過去の自分は他人  コードの意図を書く (6.6)  コードを見ればわかることはコメントにいらない  関数の動作を正確に記述する (6.4)  コメントもメンテナンス対象 28
29. 今日の内容 1. はじめに 2. リーダブル？コード 3. 障害対応のためのリーダブルコード 4. まとめ 29
30. まとめ  ログ重要。超重要。  『読みやすいコード』はソフトウェアの品質 を上げるだけでなく、障害時に迅速な対応を 可能にする。  ただ、この点を含めて“品質”という気もする。  そもそも論として『読みやすいコード』が 書けていれば1分1秒を争う障害対応には至 らないのかもしれない… 30
31. 参考文献 リーダブルコード 31
32. ご清聴ありがとうございました 32