重いコンダラ見つからぬ - 脳に収まるコードの書き方⑦ - ReadLog

2024年9月22日 23:52

概要

タイトル：脳に収まるコードの書き方
ジャンル：技術書（情報系）, ソフトウェア開発, プログラミング技法
備考：問題の回避と解決の話

ここは本の紹介と記録を目的としたマガジンです。
時間がない人や面白い本を探している人向けです。
本の一部を引用しながら、少しでも興味を持ってもらうことを目指してます。

この本は、テスト駆動開発を前提として話を進めています。
テスト駆動開発では、実装したい機能を満たしているかを検証するテストを先に作り、後からそのテストをクリアする実装を実現します。
テストはいちいち人力で確認してられないのでテスト用のプログラム「テストコード」を作成しながら進めます。

テストケースを追加していく分には劣化することはありませんが、既存のテストコードを変更する必要が出てくると事態はややこしくなります。
実装コードは変更の度にテストされるのに、テストコードをテストしてくれるものはないので。

テストコードの変更にもいろいろあります。
①そもそもテスト内容や実行結果の想定値が変わる場合と、②動作はそのものは変えないリファクタリングです。

①は後述するとして、リファクタリングによるテスト不正化の回避は「テストコードの改修と実装コードの改修は別々にコミットすること」が提案されます。
テストコードの変更時にはテスト対象の実装コードは変更せず、依然と同様にテストをパスすることを確認を優先しましょう。

問題は①のほう、バグの埋め込みを完全に回避することは困難ですが、この本での提案は以下の通りです。

テストコードとプロダクションコードを同時に編集する必要がある場合は、一時的にせよ、テストを意図的に失敗させることでテストを検証してください。

p.181 11章ユニットテストを編集する

変更したいテストがちゃんと機能しているかを、失敗することで確認するのです。
失敗したことがないテストなんて信用できません。

開発中のシステムが、何もしていないのに動かなくなったり、特殊すぎる条件による不具合に遭遇することがあると思います。
そんな時、なんとなく疑わしいところを直してみたり、とりあえずシステムを再起動したりして問題解決を図りたくなるかもしれません。

が、それは悪手です。

何が起こっているかの理解に努めよ。

p.183 12章トラブルシューティング

経験則的に、過去の不具合を解決できた方法を試したくなるのは分かります。
しかし、原因を特定できていない状態で闇雲に試していたら時間がどれだけあっても終わりません。

解決を目標にするのではなく、問題原因の特定を目標にするのです。

そのために押さえておくべき前提は、「思い込みを持っていること」です。
思い込みによって原因とは関係ないところの袋小路にはまり込み、延々と解決されない問題と納期に悩みたくはないでしょう。

解決されるまではひたすら立ち向かっていたくなりますが、一定の時間で切り上げて他のことをしましょう。
問題から距離を置けば急に分かるかもしれません。

俗に「ラバーダックデバッグ」という方法です。フニフニのアヒルのおもちゃに説明してみると、なぜ見落としていたのか分からない原因に気づけるかもしれません。
…別にアヒルである必要はないです。その辺の人でもチャットツールで聞いてみるでもいいので、思考を整理するためにも説明してみましょう。

この章はこの後、特定された問題の解決の話に進むのですが、特筆すべきことはあまりありません。1つだけ取り上げるとしたらこれです。

目の前の欠陥を「あとで対処する」ことにしないでください。ソフトウェア開発では、「あとで」はやって来ません。

p.186 12章トラブルシューティング

テストコードに不具合を埋め込まないようにしましょう。
そのためにテストコードの改造をするときは実装とは完全に区別し、意図的に失敗させてでもテストコードの動作を確かめましょう。

不具合に遭遇したとき、なによりもまず原因を特定しましょう。
原因の特定ができないときは、誰かに状況を説明してみると糸口が見えてくるかもしれません。

次：まだ

この記事が気に入ったらサポートをしてみませんか？