『Effective Debugging』の続き。タイトルオンリーな気がしないでもない。
怪しい箇所を調べる際には事前条件と事後条件を確かめましょうという話。 ルーチン（懐かしい響きだ）の前後、ルーチンが呼び出された前後、重要なアルゴリズムの実行前後にブレイクポイントを置いて調べよう、チェックしようという話。 函数に渡す引数は定義域に収まっているか、とか返り値は妥当な値なのか、などを調べる。 まあ、タイトルオンリーなのでこれ以上は本文読んでねとしか書けないが、最後によいメッセージがあった。
In all cases verify, don't assume.
「すべてのケースを調べろ、想定するな。」と訳せるだろうか。 何かと調べる際には先入観が邪魔したり、「正しいはず」と調べもせずに断定してしまうことがあるが、それを戒める一文である。 プログラミングに限らない話であるので、なるべく意識していきたいと思った次第。
『Effective Debugging』の続き。まさかのGoogle先生。
項目名は検索方法に関するTips（二重引用符でキーワードを囲んで検索すると完全一致になる）だが、項目自体はWebの活用方法に関するものである。 "It's quite rare these days to work in a location lacking Internet access..."とある通り、インターネットから隔離された環境で働くというのは珍しいと筆者は述べている。 Effectiveシリーズで筆者は大学の先生らしいのでアカデミックな内容が続くのかなと思っていたが検索を活用せよという項目があってびっくりした。 Stack Overflowの話、検索しても出てこなかった場合の話が続く。
Black Duck Open Hub Code Searchというサービスが紹介されていてへえと思いつつアクセスしたら今は利用できないという現実を突き付けられた。 *1
昔、プログラマの計算機にはコンパイラが無くコンパイルする場合はソースコードを発注先の社員にメールで送信してコンパイル結果を受け取るという現場の話をどこかで聞いた。 これは極端な例であるが、インターネットにつながっていないという現場は意外に多そうな気がする。
*1:ちゃんと校正されているのかな？
紀伊國屋から注文していた Diomidis Spinellis『Effective Debugging』が届いた。
明日届く洋書、1冊で薄い本だからネコポス扱いで待たなくてよさそう（同人誌ではない）
— Xaro(-ε-δ)Cydeykn (@CardinalXaro) 2016年7月16日
とりあえず「Chapter1. High-Level Strategies」序文と「Item1: Handle All Problems through an Issue-Tracking System」を訳した。 前回の反省を踏まえ、翻訳文を公開できないので自分のための翻訳である。
項目名の通り、課題管理システムを使いましょう、という話である。以前、上長に「課題管理表をExcelで作れ」と言われた。 「Excelですか」と10回ぐらい聞き返したがExcelで作れという指示であった。 結局、プロジェクトの流れと結びついていない課題管理表など使われることもなく上長も恐らくその存在を忘れていることであろう。
筆者はGitHubなどのコードレポジトリに含まれるもの、プロプライエタリなものとしてJIRA、オープンソースとしてBugzilla や Launchpad 、OTRS 、 Redmine 、Trac を紹介しているがどのシステムを使うかは重要ではなくすべての課題を管理することが重要だと説く。 僕の経験に照らせば、Excelだろうがそれを全面に使うべきであったか。使ううちに限界を迎えて上記のどれかに落ち着くであろうが。 ちなみに、筆者は「課題管理システムにない課題への対処依頼は拒否しろ」とまで主張している。 以前、『カンバン仕事術』を読んだときにJIRAに登録されていない課題があってカンバンで可視化できた、みたいなストーリーがあった気がしたが、それとぶつかりそうな主張である（『カンバン仕事術』に課題管理システムとカンバンの両立方法について書いてあった気がする）。
課題には正確なタイトル、問題の再現方法、優先度と重要度、ステークホルダー、環境、そしてコメントなどで進捗状況をドキュメント化することが重要であると述べている。 理由は本文に書いてある通りであるが、ステークホルダーの説明で「Acmeからの提供、25万ドル規模の顧客」のようなタグをつける話があって生々しいと感じた。
前回はMarkdownで翻訳文を書いてPandocでreStructuredTextに変換してSphinxでHTMLに変換する、というreStructuredTextを新たに覚えたくないが故の七面倒な手順を踏んでいた（さすがにすぐにバッチファイルを書いた）が、今回はCommonMarkParserを使ってMarkdownを直接SphinxでHTMLに変換した。幾分手順がすっきりできて気分がよい。
