概要
プログラミングはなかなか楽しめる趣味なんだが、結構時間もかかる。とくに時間がかかるのは、デバッギングだ。プログラムの不具合を探したり、それらを解消することだね。デバッギングは面倒くさいし本来やりたいことでもないくせに、時間がかかる(本来やりたいのはつくること)。であれば、なるべく効率化して、それにかかずらう時間を減らすべきだ。
……と、趣味 pythonista はつねづね思っていたのだが、この本は「そのとおり!」と賛成してくれた。楽しめたところをノートする。
楽しめたところノート
イシュー・トラッキング・システムを使え
- 課題管理システム……ようは GitHub のことだよな。
- 使っているぜ。道は間違っていないようで安心だ。
- 課題管理システム(GitHub でいえば issue)に登録されていない問題を扱うことは断固拒否せよ。
- 進捗をドキュメントに残せ。類似のバグを追いかけるとき貴重になる。
- Issue がそのままドキュメントになるようにコメントを残せってことね。
- 優先度の低い問題は無視して「解決しない」と明示しクローズせよ。
- 趣味ならともかく、仕事でやる場合はリソースが有限だから、こういうこともあるのだろうな。「やらない」と決めることも、イシューへの対応なのだ。
- 優先度が低いのは、レガシー環境のサポート、見栄えの問題、すでに回避法がドキュメントされているエラーだ。
- 逆に高いのは、データ損失、セキュリティ、クラッシュフリーズの問題。およびコード衛生の問題だ。品質の低いコードは重大なバグの温床となるからだ。
- 「コード衛生」って初めてきく言葉だったけれど、ようは「リーダーブルコード」を書くようにすればいいんだろうな。
- (2019-03-04)Dustin Boswell and Trevor Foucher『リーダブルコード』
- Git で履歴を調べ、バグの発生タイミングを特定する。
- てか Git を使っていることは当然になっているな。
- 真面目にプログラミングやるならば、 Git を使うことはもはや当然なのだろう。
システム監視ツールを使え
- Nagios を使え。監視インフラストラクチャだ。
- おっ、これは全然知らねえ。
- ↓のようなシェルスクリプトを Nagios プラグインとして登録すると、サービス失敗時に GitHub issue を自動でオープンする。
- えっ、それぼくが、エラー発生時に Slack にレポートを飛ばすようにして、それを見て自分で issue を作ってたやつの自動化じゃん!
- でも正直そこまで自動化することには興味をもてないな……。ある程度までは、面倒でも構成をシンプルにしておかないとあとで見たときにわけわかんなくなる。
#!/bin/sh
TITLE="$1"
BODY="$2"
# 改行をエスケープから戻す
NLBODY="$(printf '%b' \"$BODY\")"
ghi open -m "$TITLE
$NLBODY
" >/dev/null
- こういうシステムを自分でつくろうという誘惑は退けること。
デバッガを使え
- デバッガはもっとも重宝されているアプリケーションだ。
- ステップ実行やブレークポイント、逆デバッグを使ってデバッグせよ。
- Visual Studio はでーきれーなのだが、やはりデバッガとしてはこいつが優れているようだ……。
- 筆者はコマンドラインインターフェースが好きなのだが、デバッガは GUI を使うほうがつねに生産性が上がる。
デバッギングに適したプログラミングをしとけ
- アプリケーションにはデバッグ機能を追加しておけ。マインクラフトにもデバッグモードがある。
- ああーなるほど。普段はデバッグのときだけ
print([今の状況])をコードに挟み込んでデバッグをしているけれど、main(debug=True)みたいに実行すれば自動的にすべてのデバッグ用コードが有効になるようなオプションを用意しておけってことね。
- ああーなるほど。普段はデバッグのときだけ
- ロギング文を追加して、恒久的に保存されるデバッグインフラストラクチャを設定。
- Python の logging モジュールは最近よく使っている! より洗練されたログ用の print みたいなイメージ。
- ユニットテストに適したコードを書くこと。
- 乱雑なコードはバグ発生の温床だ。
- 最初からリーダブルコードを書いておけばいいんだが、乱雑なコードがすでにあるならば、化粧直し(コード規約に沿った書き方にすること)、リファクタリング、バグ修正の順番にコミットせよ。
テストは手動でやるなそんなもん
- 変更->結果のターンアラウンド時間は最小化せよ。早い段階から、デバッグサイクルを回す時間を短縮しておけ。
- 同感だね。冒頭で書いたように、デバッギングにかかずらう時間は減らすべきだ。
- テストは高度なスクリプト言語 Python, Ruby, Perl で自動化しよう。
- あ、そっか。テストしたいことって Python プログラムだけでなく SQL だったりするから、 SQL をテストするプログラムを Python で用意しておく、なんてこともあるわけか。
- コンピュータの時間は安価で、人間の時間は高価だ。いいからデバッグタスクは自動化しろ。
- テスト自動化は基本やな。
デバッギングの小技
- エラーメッセージを検索するときは二重引用符で囲え。
- 知ってはいたけれどあんまり意識して使っていなかった。"やってみます。"
EXPLAIN SELECT ...って SQL 書くと、なんでそのクエリが時間をくうのかわかる(こともある)。- Windows で Linux コマンドラインを使うときは Cygwin を使う。
- あ、 GitBash じゃないんだ。
- Git 補完スクリプトを取得して打鍵数を減らす。
- Git コマンドの入力をラクにするやつらしい。
- ↓に書いた。けれど、緑さんは GitHub Desktop で Git を見やすく使っているし、使うコマンドも
resetやstashくらいだから必要ないかな……。
if ! [ -f ~/.bash_completion.d/git-completion.bash ] ; then
mkdir -p ~/.bash_completion.d
curl https://raw.githubusercontent.com/git/git/master/contrib/completion/git-completion.bash \
>~/.bash_completion.d/git-completion.bash
fi
source ~/.bash_completion.d/git-completion.bash
- Python の pprint.PrettyPrinter クラスを使え。
- おっ、なんだそれ、知らないぞ。
- pprint はよく使うのだけど、インデント幅や折返し文字数をキーワード引数に出来る(出力オプション)ことは知らなかったぜ!
PrettyPrinterインスタンスを使うと出力オプションを使い回せるってことね。
import pprint
pretty_printer = pprint.PrettyPrinter(indent=1, width=80, depth=None, stream=None, *, compact=False, sort_dicts=True)
- 依存しているサードパーティ製コードのソースコードを入手しておけ。
- あー、 JavaScript ライブラリなんかは min ファイルだけゲットして満足しちゃったりするもんなー。ハイ、ソースコードも DL しておきます。
- 自分のワークステーションから離れて作業するのは生産性低下の元凶の主たるものだ。出来るだけ自分のスクリーンとキーボードでトラブルシュートできるよう、デバイスのエミュレータ、ソフトウェアシム、リモートアクセスを用意しておけ。
- 他人のぱそこでプログラミングなんてゼッテーしたくねーもんな。
- 自分のツールを適切に構成して生産性を上げる。構成は Git で管理して、ホスト間で共有すること。
- はーいやってまーす!! さらに Sublime や VSCode の設定も共有して同期してるぜ!!
- ログファイルやスタックトレースのような長い行を読むために……
- ウィンドウを最大化しろ。
- 高解像度なモニタを使え。
- ノーパソの画面で見るな。外部モニタ使え。
- フォントサイズを小さくしろ。
- 連続紙に印刷しろ。
そのほか
- Linux カーネルは900万行のプログラムで出来ている。エアバス A380 は400万個の部品で出来ている。
- デッドロックとは、スレッドが死の抱擁状態にあること。死の抱擁状態とは、他のリソース待ちのために作業進行できないことだ。
- 「2つの列車がポイントに接近したら、どちらも停止し、相手が通過するまで待て」みたいな状況のことだ。
- ようはマルチスレッドコードの話なんだけれど、マルチスレッドは書いたことがあんまりないからよくわかんないな。
三行で
- あとでラクするため
- さきにちゃんとやっとけ
- Git とテスト自動化は最低条件
