はじめに：本書の紹介と位置づけ
こんにちは、readline.fmです。 readline.fmは、つんどくが庶民の2人が、何かの本を読んだ感想を雑談するポッドラストです。
ハッシュタグは、ハッシュリードラインFMです。 Mixi2にreadline.fmのコミュニティもありますので、そちらでも感想やワイワイお待ちしております。
ホスト役は、げんえいさんときんじょうです。 それではげんえいさん、よろしくお願いします。
よろしくお願いします。
なんか、いつにも増して滑舌が悪い気がするけど。
年度末ですから、しょうがないです。
3月31日なので、会社によっては明日から新人が来たり、あれ来ないねってなったりするんですかね。
そうですね。弊社も明日、新人がたくさん入ってくるので、今回の本を渡したいなって気持ちになりましたね、ものすごく。
まさに新人に大事な本をやっていこうと。
すごい、きれいにつなげられた。
えーと、それは何の本でしょうか。
今回は、ロバートシーマーチンのクリーンクラフトマンシップですね。
みんな大好きボブおじさんですね。
そうです。多分いっぱいシリーズで出てるんですよね、クリーンシリーズっていうのは。
みんなが一番知ってるのはクリーンアーキテクチャーとか、クリーンコードとか。
他にも出てますけど、もしかしたらこれ一番知名度が低いんじゃないかって俺の中で思ってるんですけど、どうなんでしょうかね。
なんか、いよいよクリーンじゃなくていいなってなってますよね。
そうそう。
クリーンじゃないクラフトマンシップってなんだろうなーっていう気持ちになりながら。
そうそう。
今回はちょっとロバートシーマーチン読むんだったらクリーンアーキテクチャーでいいんじゃないっていう気配も感じられるんですが、
今回はちょっと別の視点でクリーンクラフトマンシップを読んでいきましょうという感じですかね。
クラフトマンシップとは何か
そうですね。ただレベル感で言うとどのくらいクリーンコードの次ぐらいなんですかね。
クリーンコード結構ビギナー向けというか、これから頑張るぞそうな気もしていて。
そうですね。自分はでも読んだのがクリーンアーキテクチャーを全部ではないけども気になるところをかいつまんで読んで、
コードは読んだはず、コーダーアジャイルとか多分持ってはいるけど読んでないんですよね。
クリーンアジャイルはなんかあれですね、スクラムは嬉しすぎるみたいな話をしてる。
なんだっけ、基本に立ち返りみたいなサブタイなんですよね。
そうですね。基本に立ち戻りっていうサブタイついてますね。
立ち戻りか、はい。で、だいたいXPの話をするという感じですね。
面白かったですよ。なんかその境外化してるゾンビスクラムじゃないですけど、
カゴカルトっぽいスクラムではこうだからっていうのに、
とらわれすぎないようにする必要あるよねっていうのを厚く語ってる感じでしたね。
いいですね、いいですね。読みたくなってきたな。
でもその中でいうと、レベル感としてはそうですね。クリーンコードの次とか、新人で読んでもちょっと背伸びして読むみたいな感じのぐらいのレベル感なのかなという気はしましたね。
逆に言うと、今もアーキテクトですとか、テックリードやってますみたいな人が読むと、
なんていうか、もうちょい早くここら辺はすっかり抑えておくべきだったなみたいな風になるかなという感じがするかな。
そうですね。本の内容があれなんですよね。規律、基準、倫理っていう大きく3つに分かれていて、
規律のところがもう完全にTDDの話とリファクタリングの話をしていて、この辺は別の本でも読めるし知れることだよねみたいな話だったりするんですよね。
なのでアーキテクトやテックリードだと、もう知ってるよとかやってるよみたいな話が結構多かったりするっていう感じですよね。
そう願いたいですね。
そうですよね。で、基準のところは結構あれですよね、XPとかみたいな価値観みたいなところが多かったような気がする。それだけではもちろんないですけど。
規律、基準、倫理っていうレイヤーで話していって、だんだんとちょっと答えのない世界に進んでいくみたいな感じですよね。
そうですね。
で、東映ページ数的には規律で半分以上いってるのかな、確か。
規律が終わるのがもう230ページとかなので、300ページぐらいあるうちの、230ページ?300ページ超えたら落ちるのかな。
残り100ページでその後ろ2つを話しているというような本の構成になってるので、実は3分の1ぐらいしか、人によっては読むべき場所がなかったなってなっちゃう本かもしれないっていう感じはありますね。
まあでも技術上そんなもんでいいと思うんですよね。
まあね。
軽く内容紹介というか、あれしてみますか。公式サイトとか出版社の書いてあるやつを紹介すると、出版社アスキードワンゴですね。
そうですね。珍しい。
あれ?クリーンシリーズって割とここから出てません?そうでもないっけ?なんか表紙は見覚えあるなってなる気がする。
アスキードワンゴからクリーンシリーズは多分全部出てるはずで、ただあんまり他のこれ以外の本をアスキードワンゴで買うってことがないなと思いながら。
観数型ドメインモデリングとか買ってますけど。
買ってたよなと思って。
リーディングクオリティーとか持ってますね確かにとか思いながら。
リーディングクオリティーも確かに。
そうですね。観数型デザインbyロバートシーマーチンもアスキードワンゴですね。
そうなんですよね。
まあいいんですよ。脱線するのが早い。
内容紹介なんだろうな、最後の方だけ読むか。
ソフトウェア開発の社会的責任
本書の目的はソフトウェア開発者とそのマネージャーたちに、規律の必要性を印象付け、堅牢で対障害性のあるソフトウェアを構築するために最も効果的な規律基準倫理を教えることにある。
っていう風に言ってますね。
そうか、規律の必要性を印象付けっていうのは狙ってるのか。
そこは結局、最初テクニックの話だよねっていう風に冒頭から読んでいくとなるんですけど、後ろの方に読んでいくと、結局こういうテクニックっていうものがないとマインドだけなってもしょうがないよねっていうところ。
なぜそれが必要なのかっていうことを実は後ろで解説してるみたいな構造に本書になってたりするんですよね。
あれもあれなんだよな、スクラムとかには技術サイドの話が少なすぎるみたいなやつをここでも言いたそうにしてるなみたいな感じで見てましたね。
そういう厳重もちらっとは実際この本の中にはあったりはしますけど、結局品質とかそこらへんをちゃんとやっていこうってなると、当然高い技術力とかプラクティスとか必要だよねっていうような話ではあるんで、言ってることはそうねって感じ。
そうそう、わかるって思いながら読んでましたね。
本文入ってきますか。
そうですね。
全部で3部構成で、第一部規律、第二部基準、第三部倫理っていう風になっているんですが、第一部に入る前に第一章クラフトマンシップっていう章があって、
タイトルにクラフトマンシップって書いてある本なので、そもそもクラフトマンシップってなんだっけっていうのをちらっと触れつつ、この本ではこういう話をしていくよっていうのを紹介していってますね。
ここ第一章は何か触れておきたいこととかありますか。
そうですね。
初めにからクラフトマンシップあたり。
そうですね、初めにクラフトマンシップあたり。この本が想定しているクラフトマンシップって、結局クラフトマン、クラフトマンシップって何なのっていうことは、ちょっと話しておいた方がいいのかなっていう気がしますね。
自分がクラフトマンのところを初めにで丁度定義があったんで抜き出していて、クラフトマンとは特定の分野に関する高度なスキルを持ち、物事を成し遂げる人である。
道具や業界に設立しており、仕事に誇りを持ち、仕事に対する尊厳とプロ意識を持って行動できると信頼されている人であるっていうのがクラフトマンの定義としてありますね。
第一章の方を見るとクラフトマンシップとはっていうのがあるんですけど、これはクラフトマンとクラフトマンシップの違いなのか。
何かをうまくやる方法を知っている状態である、それは優れた指導と豊富な経験の結果であるっていうのがクラフトマンシップとはっていうくだりで言われてますね。
その続きを見ると、最近までソフトウェア業界にはそのどちらもなかったっていうふうに書いてあったりしつつ。
少なくとも技術は必要だし経験も必要だしみたいなどちらですよ。
技術をどう生かすのかっていう、生かすべき技術、中身っていうのとそれをどう使う、どうあるべきかっていうのをやっていこうなって感じですよね。
この本の中でたびたびなんでそれがすごい大事なのかっていうことを主張しているところとして、あれですよね、社会のためにみたいなところがやっぱり大事で、
ソフトウェアを作るのにミスをしてしまったり失敗してしまったりして、いろんなこういう事故がありましたよみたいな話がたびたび出てきて、ちょっと気を引き締めんといかんなみたいな気持ちになるような事例がたくさん出てくるんですけど。
ずしっと来るというかドキッとするようなものが出てきますよね。同じ話を10回ぐらいしてるなと思ったけど。
でもやっぱ人命に関わったり、大きなお金に関わったりするものが出てきたりとか、あとこの事例が載ってるのは結構最近の本だなって感じたのがホルクスワーゲンの排ガス規制の不正問題とかの話が載ってたりとかして、確かにこれ結構最近あったよなっていうことを思ったりとかして。
そうそう、我々の大好物の年代の話を触れてなかったですけど、最近の本なんですよね。
そうですね、そうそう。この本は結構最近で。
2020、原著が2021で翻訳が2022なんで、これ翻訳めっちゃ早いなっていうのもあるんですけど。
僕は確かに原著が出て翻訳される前に読んでたんですけど、今回改めて読み返してみて、COVID-19の話とかがあって、完全にアフターコロナで書かれてる本なんで。
っていうちょっと言及もあったりして、それはめっちゃ最近の本というか、あれがもう5年前かみたいな両方を完全に挟まれつつ。
で、働き方とかチームワークみたいな話が出てるんで、フルリモートになってどうだったみたいな話とかが出てきてるわけですけど。
そうですね、ゲイさんが今言中してくれたようなフォルクスワーゲンの話だったり、いろいろとリアルタイムにちゃんと覚えてるような話が出てるわけですね。
パンチカードとかの話は今回はしなくていいと。
そうですね。.
NETとかしなくていいと。
ひたすら.NETの話をこする、APIをこすり続ける話、必要はもうないということですね。
でも結局、つい最近の話題まで入ってるよねってことになるとどうなるかっていうと、
アンドリュー・セン・ホリッツとかが言ってた、ソフトウェアが世界を飲み込んでいるっていうエッセイが結構有名で、
世の中どんどんソフトウェアが支配してるよという話が、あれが多分2010年前後ぐらいだった気がしますけど、
10年ぐらいだったと思いますけど、それ以降の世界においてどんどんソフトウェアってものが重要になっていて、
そういうことを扱っているのを仕事にしてるんだよっていうことをすごく気にしなさいねというか、
意識しなさいねってことになってるよなっていうことを思いましたね。
プロとして働くってどういうことなんだっけとか、っていうところにちゃんと眼差しを向けるというか、
胸を張って行動かけてるのかみたいなところを突きつけてきますよね。
また戻っちゃうんだけど、表紙が良くて、日本語版の表紙だと、より良く働き生産性を高め、
自分が書いたものに誇りを持つっていうふうに書いてあるんですよね。
最近は自分が書いたものじゃなくて、AIが書いたものに誇りを持つみたいな時代がちょっと近づいてる感じはありますけど、
クラフトマンシップっていうところを考えた時には、こういうことをちゃんと堂々と言える、誇りを持っている状態になれるためにどうしていきましょうかねっていう感じはありましたね。
そうすると一周回って、自分のやってる仕事ってなんだろうっていうのが出てくるので、
コードをどうやって書くかっていうのは別にタブで保管してても、プロンプトでバーってやっててもいいと思うんですけど、
動くものを作ってるのは自分なんだっていうのは、ちょっと大事にしていきたいよなっていうようなことを思わされたりしますよね。
そういう意味で新人の人とかでも全然読んでもOKというか、むしろ新人だからこそ読みたいみたいな。
技術的にレベルが高い話とか、逆に前回のアラインドみたいなソフトスキルとか、どういう力学で組織っていう生き物が成り立ってるのかみたいなハイレベルの話でもないので、
割とキャリアの早いうちに読んでおくのがいいんじゃないかなって個人的には思ったりしつつ。
そうですね。しかもこれでTDDまで学べたらもう最高ですよね。
そうですね。TDDはTDDでやっておくといいなという気もしつつですけど。
でも初めに序文から第一章はそんなところですかね。
そうですね。
本当にクラフトマンシップとはっていう話とか。
自分たちの食料がいかに社会に対して影響を与えてしまうポジションにあるのかっていうのを改めて意識していこうぜ的な話ですね。
そうですね。
第一部：規律の本質とプラクティス
で、まあ第一部いっていきます。
そうですね。ただ起立の中であえてこれを触れておきたいぜみたいなのってどうですかね。
どうだろうか。具体の話っていうよりかは起立ってどういうこと言ってるのっていうのは紹介しておくと僕らがこの後しゃべりやすくなるんじゃないかという気はしてはいて。
わかりやすいのが目次だと思うんですけど、第一部が本当に長いんですよね。
200ページくらいあるね。
全部で14章あるうちの8部までが第一部。
半分以上じゃん。
そこで触れられてるのがエクストリームプログラミングだったりテスト駆動開発、テスト駆動開発の応用、テスト設計、リファクタリング、シンプルな設計、努力的プログラミング、受入テストってなってて。
てか全部XPじゃねえかって思って。わざと言えないんですけど。
そうですね。
本当にここらへんの具体の話を知りたいんだったらマジでXPの指導本とか。
XP関連でおすすめの本はいくらでもあるんでそっちを読んだほうがいい気はしていて。
どっちかっていうと規律基準倫理っていう階層化されたこの本の世界観の中で、どういう位置付けでどういう意味合いでこの規律としてそこらへんのプラクティスとかが紹介されているというか、
位置付けられているのかなっていうところだけちょっと触れておく分には面白いんじゃないかなっていう気はしたんですが。
どうですかね。規律とはって話じゃないですか。
そうですね。第1部の一番最初の例というか最初の文章がすごくいいのかなと。
規律とは何でしょうかと。規律とは本質的な部分と任意の部分で構成される一連のルールであると。
本質的な部分は規律にパワーを与える。規律が存在する理由となる。任意の部分は規律に形と実態を与える。
任意の部分がなければ規律は存在できないっていうふうな文章で始まっていて。
この本のこの例でいくと、例えば下界っていうのは手を洗いますよと。
本質的な部分っていうのは手を清潔にしていることであると。
任意の部分っていうのはじゃあどんなふうに手を綺麗にしましょうかねって言ったときに、
厳格な基準に沿って手を洗ってるんですよって言って、石鹸を使ってブラシを使って、
指ごとに上の部分、左下、右の部分を10回洗うっていうような。
爪も10回洗いましょう。それを繰り返すっていうような話をしていて。
10回っていうのはいいのかどうかっていう。5回じゃダメなのかとかいろいろあるんですけど、
とりあえず十分だっていうことが大事ですよみたいな話をしていて。
同じようにソフトウェアの中で本質的な部分、規律っていう部分と、
それを取り巻く任意の部分、エンパワーしてくれるような道具立てみたいな部分があるんだよっていうような話を
ここからしていくよっていうことを言ってますね。
形式化されたルールに従えばOKじゃなくて、ちゃんとクラフトマンシップを体現していくには、
なんでそのルールがあるんだっけとか、そのルールによって何を達成できればいいんだっけっていう裏側というか根っこの部分みたいなところに
ちゃんと意識を向けるというか、そっちもちゃんと扱っていこうねっていう話として、
ここから半分ぐらいTDDの話をしていくわけですね。
でも難しいですよね、医者は手を清潔にするっていうのって本質的なことなんだけど、
じゃあみんな清潔にしてくださいねって言われても、いきなりじゃあ清潔ってなんだろうとか、
清潔のために何やったらいいんだろうとかゼロから考えだすとめっちゃ大変だし、
でもじゃあルールを作ると、じゃあ10回洗えばいいんだねって。
同じ場所で10回洗っても洗ってない部分があったら意味ないじゃんみたいなことになって、
本質を考えるみたいなことを言われみたいな。
多分プログラミングも同じで、鉄則道開発ができます。
何のために鉄則道開発してるんですかって言ったら、
いやなんか先輩に言われたんでみたいなことになったりとか、
いやリファクタリングをしたいですって言っても、
なんでリファクタリングしたいんですかって、
リファクタリングをしたいからですみたいなことしか言えないとトトロシアン系みたいなことになって、
結局そのテクニックだったりとか色々あるけども、
これ何のためにあるんだろうってことはやっぱり絶対考えないといけないってことなんですよね。
なんかCIがちゃんと整備されてるんで、CI統合してからレビューリクエスト投げてくださいって言った時に、
なんかテスト消しときましたみたいなね、最近そういう奴らがよくいるんで。
そういうことじゃねえんだよっていうのがやっぱりルールだけ、形式だけで歩いちゃうとそうなるよねっていう。
そうですね、だから本質的な部分、トニーの部分で。
てかボブおじさんはこういう分け方好きですよね。
なんか技術的詳細とか些細な部分はどうでもよくていいみたいな。
コアが大事みたいな。
そうですね、このページをパラッとめくるとサークルオブライフってやつで円が書いてある。
これはなんかやっぱ円も好きなのかみたいな気持ちになってきたんですけど。
サークルオブライフはめちゃくちゃ、てかケントヴィックじゃないのかこれ言ってるのは。
ロン・ジェフリーズって言われてますね。
でもこのサークルオブライフってXP文脈でめちゃくちゃ出てくるやつなんですけど、一番3つのレイヤーの円が重なってて、一番内側が結構わかりやすいというか技術プラクティスっぽいやつなんですよね。
一人から二人でやるものみたいな言い方が近いのかな。そこの中にTDDがあったり、リファクタリングがあったり、ペアリングって書いてますけど、ペアプロがあったりとかシンプルな設計みたいな書いてあって、
その一つ外側に継続的インテグレーションとか行動所有とか、メタファーとかって話があったり、その外側にチーム開発とか受入テストとか、小さくリリースしようとか、計画ゲームとかっていう、チーム全体を巻き込んだプラクティスみたいなものがあってて、
この規律って言ってるのは一番中心にある部分。本当に一人一人が今から始められるようなものが載ってる的な位置づけとして説明されてますね。
なぜか中央にある四つと左下にある一つだって書いてあって、なぜか受入テストも一応入ってるんですよね。規律が。
一つだけ色ついてないんですよね。なんでだ。
いや、でもこっちのも色ついてないですね。
色ついてるついてないって言ってなんかハイライトされてるんですよね。その一番内側にある点が。
左端のもつけといてくれればいいのに。
まあそれはそれはいいんですが。
規律を抽象的な観点で、規律とはこういう話をこの本の中でしてましたみたいなところをまとめると、だいたい今言ったような形になるのかなと思いつつ。
テスト駆動開発の応用：ロンドン学科と資格語学科
なんかちょっと気に入った下りとかグッときたフレーズとかって。
第一部全体でありました。第一部が終わるとこの本半分終わるんで。
あっという間だな。
あっという間。
そうですね。
まあ改めていい話はしてるんですよね。ただいい話はしてるんですけど、およそXPの話ではあるので。
なんかあるかな。
ちょっと飛んじゃうけど、なんかどういうふうにテストっていうものを考えてるのかなみたいなところがちょっと見て取れるような部分があったので。
3章のところでテスト駆動開発応用っていうのが3章ですけど。
何ページかがちょっと行方不明になってる気がしますが。
258ページじゃないですか。
いやー違うんだな。
我々は金の版と紙版のせいでページ数が違うっていうのが今ちょっと大変なことになってるんですけど。
紙版だと142ページで話が書いてあって。
ロンドン学科と資格語学科の話をしている部分があって。
要は全部Mockするかそのテスト対象以外を全部Mockしますかとか。
極力Mockするっていうことをやめましょうかみたいな部分の話の中で。
じゃあどこをMockしてどこをMockしないのかっていうことをこのボボおじさんどう考えてるのかなって言ったときに。
テストがアーキテクチャの境界線を超えるときはロンドン学科になるよと。
テストが境界線を超えないときは資格語学科になるよっていう風な言い方をしていて。
これはすごく分かりやすい基準みたいなところだなと思って。
例えば外部のライブラリーに依存しているところは差し替えるし。
パッケージバイフィーチャーで作っていればその違うパッケージに依存をするような部分は差し替えるし。
一方でそうじゃないときは資格語学科前はいくつかテストするんだっていうようなことを書いていて。
これすごくいい基準だなと思って説明しやすいなと思って思いましたね。
これアーキテクチャの境界線って言ってるのどこら辺のルールだっけって今思っちゃったな。
なんかあれじゃないですかクリーンアーキテクチャの人じゃないですか。
あそこでいうレイヤーをまたぐときには要するに外のレイヤーに対して変にという依存してしまってテストが脆くなるのを防ぐために
レイヤーの境界をまたぐときにはMockしたりしよう例みたいな感じですよね多分。
そうですね。
それを考え…ああそうだずがった。
結論結構ボックしてるなこういうのの人。なるはなる。
そうですね。
だからレイヤーを超えるとっていうとじゃあデータベースのところはMockしましょうねとかってなるし。
コントローラーのテスト…まあでもこれはユニットテストコンポーネント単位のテストするときだからコントローラーをテストするときに
コントローラーのその依存しているものを全部Mockするってことはもちろんないと思うけど。
でもあるんじゃないですかなんかコントローラーがビジネスロジックコントローラーのテストを書くときにビジネスロジックっぽいテストを書かなくて
なんかインプットとアウトプットを受け取ってプレゼンターに渡すみたいなところだけテストすれば
あとの中身はあっち側の責任野郎って感じだと思うんで
ここらへんはスタブとか使うんじゃないかなっていう気はしますね。
自分があんまりコントローラーのテストを書くときにこう普通にインテグレーションテストで担保するっていう考え方をしてるから
それ以外やることないやろって
そうむしろそれ以上にコントローラーにこの理学的なことをやろうとしていて
要はレイヤーをある程度切るぞみたいなことをやろうとしていて
コントローラーにテストしたいことがたくさんあったらそれはそれでちょっとおかしいよねみたいな感じになりそうだなと思いながら
極力コントローラーの責務って多分薄くなっていくはずなのでやってたら
なんかゲットとポストから取り出したのを詰め替えるくんってテスト本当にいるみたいだね
そうでしかもインテグレーションテストも書くんでしょってなったらってなっちゃうから
まあでも多分クリーンアーキテクチャーというかこのボボおじさんがよく使ってる方の具体的な設計アーキテクチャー図の中でいうと
まあそういう感じなんだろうなーっていう気はしますけど
アーキテクチャーなんて別にその組織でその過程の味があればいいと思うんで
この辺とかは多分TDDをやり始めてとかテスト書き始めて
何をモックして何をモックしないかみたいな基準みたいなのは何か持っとかないと
なんでここはモックしてるんですかって聞かれた時に
いやなんかモックした方がいいかなと思ったんだよとかって答えざるを得なくなるとちょっと辛くなるから
そうですねモックに誘われたんでみたいなことを
そうそうちょっとたまには違うことやってみるのもいいかなと思ったんですよね
一番よくないな
ってなるから何かある種の指針みたいなところで
ボボおじさんはこんな風に考えてるからそれをヒントに
じゃあ自分の現場ではどういう風にやるといいのかなみたいなことを考えていくと
いいのかなっていうのをちょっと読みながら思いましたね
リュードみたいなものはすごい色々出てきそうだなって思いつつ
なんかこういう紹介性を超える時は論々学派
アウトサイロイン的に書くというかモックとかスタブとか使うよねーっていう話は非常にわかりやすいですもんね
そうなんだよなーっていう
何でもかんでもモック使いすぎないみたいなところはやりたいので
テストしやすいコードとモジュールの変更
コストだけかかってやたら技能性のテストを生み出していっても仕方ないので
本当そうなんですよ本当にそうなんですよ本当にそうなんですよ
あなたは何をテストしてるんですかねみたいな
上手にモックできたことをテストしましたねみたいな
じゃあこのテスト消すねみたいな
いやでも結局なんかテストを増やしていくってのは多分結構やろうというか簡単にできる
じゃあできるようになっていくんで慣れてくると
何をテストしなくてもいいのかってことを見極めてテストの数を減らして高速にCIを回していくみたいなことっていうのが
だんだんあるタイミングで転換点を迎えてテスト多すぎるんで消すみたいなことをやってくると思うので
そういうことを考えると無駄にテストを増やさないっていうのはやっぱ大事っちゃ大事なんですよね
そうですねテスト消すのなんかやっぱり罪悪感ありますしね
なんかこれで検知できないこれがあれば検知できてたのになとかってなった時ちょっとあっってなっちゃうし
そうですねそこら辺がテスト駆動開発応用の章に書いてあることです応用って言ってるのがあれか
第2章がテスト駆動開発で第3章がテスト駆動開発応用なんですけど
第2章でTDDこんな感じだよねっていうルール説明とか進め方みたいな話をしてて
それによってこういうものが得られるよねっていうようなベネフィットみたいなのを第3章の応用の方で書いてるねって感じですかね
そうですねそうですね
他は第1部どうでしたか
そうですね
第4章のこれ源さんが書いてくれてるモジュールに対してテストを書くと壊れやすくなるってどういうくだりでしたっけ
これはあれですねなんとかクラスみたいのを作った時にそのクラスに対して一体値対応のテストを書くみたいなことを
暗黙的にこれがこういうルールなんだろうなみたいなことを思ってテストを書き始めると結局そのモジュールが変更された時に何をテストしたかったんだっけみたいな
つまりクラスに対してテストを書くとやってると何を確認したくてそれをテスト書いたんだっけっていうのはないのでバンバンバンバン変更が入って
振る舞いは一緒だとしても壊れてしまうみたいなことが起きるよねっていうような話が書いてあって
いやーやったことあるからわかるなって思いながらはい
結局なんかこれとこれとこれひとまとまりでテストしておけば最終的にそのインアウトは変わってないからテスト自体はいいんだけども
それを一個一個に対してテスト書いていってさらにモックなんかしちゃったりしちゃったら直すものが大量に増えてテストがどんどん壊れていって
辛いみたいなことが起きるんだろうねっていうのを思い出しながらちょっとメモってたって感じですね
なんかせっかくコードと別のところにテストっていうのを書いているのにめちゃくちゃな依存しやがってみたいな
依存ってめっちゃ結合しとるやんみたいなやつですかね
本当そうなんですよ
そうなんだよテストは書けるようになってきたら多分どんどんテスト書いていってよしこれで大丈夫だって言って
次変更する時にここを直したいなと思ったらなんか直した結果のモックのところを全部書き直さないとなとか
あれこっちのテスト直したら中が壊れるなみたいなこっちのテストこっちのソースコード書いた時に
意図してないところまでその影響がいってテストがぶっ壊れるみたいなことが
それは良いことなのか良くないのかでも振る舞いはそんな変わってないんだよなみたいな時に辛いみたいな気持ちがありますね
いやー難しいな
そうだから第一部はなんかそういう本当に具体的な設計良いコードをどうやって作っていくんだっけみたいな話が多めですよね
そうですねでもテストが書けるこの本の中のどこかにもあった気がするけどテストが書けるっていう
ちょうど第6章にそれメモしてたなテスト可能なコードは分離されたコードであるっていう話が書いてあってそうよねっていう
なんか結局テストしづらいなって思ってる時ってなんか構造がおかしかったりとか
そうなんだよな
設計がいまいち減っている場合が多いのででなんかこう無理やりオーバーロードとかして
木を無理やり書き換えてこれはちょっと大人の都合でこうですみたいな
謎の魔術が起きてたりとかしてちょっと直すとそのテストが爆発するみたいなことってよくある
よくある稀によくあるやつなんでちゃんとテスタブルなコードを書きましょうねってなっていくと
結局自然とこうソリッドの原則にのっとったというかいう感じに近づいていくんだよなーみたいなことを思ったりしますね
やっぱり責任を期待する責任が曖昧だったんだなーっていう風になりますよね
あれもこれもチェックしないとなって言われると何なんだこれはみたいなことになっちゃうから
なんでこのクラスのというかこのメソッドのテストをするのになんでデータベース引っ張ってこなきゃいけないんだみたいな
いやそうそうそうそう
こいつが欲しいの値があれば十分だっただけではみたいなやつ
そうそうそうそういやほんとそうなんですよ
なんか数時間前にやったなそれ
そういうものと戦っていくのがもしかしたらエンジニアなのかもしれない
金城さんはどうでした
