Clean Craftmanship 読んだ感想
結論: 今後のプログラマ人生における教典にする。それくらい良かった。アンクルボブ好き。
「簿記と TDD は一緒」は会計士の人と出会った時の話のネタにしようと思った。
2/3 くらい？は TDD のやり方の説明。具体的なコードや、ビデオまでついてるのが非常に良いと思った。 確かに、初見の場合、TDD のリズムは本物を見るなどの体験がないと、なかなか想像ができないなぁと思った。
TDD については、ある程度は理解できてるし、実践できてるつもりではあったけど、特にここ数年はサボってやってなかったので、改めてやろうと思った。 …と思っただけじゃなく、実際に一番得意な Ruby で一番最初の例題を写経してみたら、あのリズムの再現が全然できなかったのでショック…あまり書いたことない minitest でやったから、というのはあるが…（たぶん、RSpec でやったらそんなことはないと思われる…多分。） こと、Ruby に関しては、 UnitTest/minitest/RSpec と3種類のテスティングフレームワークあるから、他の言語から来た人は悩みポイントになりえそうか、と思ったり。 それはさておき、リハビリは必要だなぁと感じた。良いきっかけだった。とりあえず、この本に出てくる例題をすべてを写経しようと思った。
今後、新しい言語をさわるときも TDD でやるのが良いんだろうなぁと思ったりした。各言語毎のテストの書き方も同時に知れるのは良いことだし。 と同時に、この本に出てくる TDD の写経を新しい言語で一周する、というのもありかもなぁ、と思ったりした。
さて、TDD のためのルールが15個載っていたので、備忘のために、抜粋して載せてみる。
- ルール1 書きたいことがわかっているコードを書くためのテストを書く。
- ルール2 失敗させる。パスさせる。クリーンにする。
- ルール3 金メダルを目指さない。
- ルール4 最も単純で、最も具体的で、最も退化した、失敗するテストを書く。
- ルール5 可能な限り一般化する。
- ルール6 コードが間違っていると思ったら、先へ進む前に設計を修正する。
- ルール7 複雑なケースをテストする前に、現在のシンプルなケースをやり尽くす。
- ルール8 テストをパスさせるための実装が多すぎる場合は、そのテストを削除して、より簡単にパスできるシンプルなテストを書く。
- ルール9 テストの領域をカバーする意図的で段階的なパターンに従う。
- ルール10 テストに必要のないものをテストに含めてはならない。
- ルール11 テストから本番用のデータを使ってはならない。
- ルール12 テストの構造を本番コードの構造から分離する。
- ルール13 テストを具体的にすれば、コードは一般化される。
- ルール14 ある変換で最適なソリューションにならなければ、別の変換を試してみる。
- ルール15 デバッガーを使ってはならない。
それぞれ、定期的に見返して、分からないものは周辺を読み返すなどしたいと思った。
さて、TDD だけでも非常に良かったが、後半は特に良かった。 過去のアンクルボブシリーズの日本語訳、Clean Code も Clean Architecture も Clean Agile も読んだけど、この本が一番良い。
プロのプログラマーとして生きていく…ということについて、改めて思い直すのであった。
ひとまず、SOLID 原則から復習していこう…
追記(2022/09/12)
「人命に関わるプロダクトには関わりたくないのよ、そんなプレッシャー感じながら仕事したくないからさ～」
って言うのが僕の中の仕事観にあった。
が、これをボブおじさんどこかで聞いてたんすかって感じて真っ向から否定された。
重要なソフトウェアではないので、誰かに害を与えることはないと思うのは簡単だ。
・・・どこかで、完璧なソフトウェアを作ることを諦めていたんだなぁと思った。完璧なソフトウェアは達成される事はないけど、少なくともそこを目指すことを辞めてはいけない、と思ったのであった。
追記2(2022/09/22)
私はすべてのプログラマーがメンターになることを期待している。私はあなたが誰か学習を支援することを期待している。
この言葉も、頭の底に残り続けている。
プログラマをやっていれば、所属が全く違うエンジニアとも働くことがある。所属が同じだろうが違っていようが、出会った後輩には等しく同じように、ちょっとばかし先に業界に入った者として知識を分けていこう、伝えていこう、と思ったのであった。
どうしても自分ひとりでガーッと集中してつくりたくなる事もあるけど、これも必要な仕事の内の一つだと思って、良い先輩の帽子も被っていきたい。
