ブッククラブの紹介
ken
はい、リスナーの皆さん、こんにちは。London Tech TalkのKen Wagatsumaです。
はい、ということで、今回はですね、Tidy First?という本をブッククラブ第3回目の本として読んでいるんですけれども、
これは結構割と薄い本で、ケント・ベックが書いたPart I、Part II、Part IIIに分かれているので、3回に分けてブッククラブを今やっています。
ついこの前、第2回目が終わったところなんですけど、
本日はですね、Junpeiさんをゲストに呼んで、Part Iの振り返り収録をしていこうと思っています。
Junpeiさん、今日はよろしくお願いします。
よろしくお願いします。
ken
はい、Junpeiさんはね、簡単にLondon Tech Talkとしては、第1回目にWebサイト開発振り返り会で出ていただいたので、
本日は2回目の収録になりますね。はい、よろしくお願いします。
はい、よろしくお願いします。
ken
はい、ということでですね、今回Junpeiさんをお呼びしたわけなんですけども、
今回のブッククラブは結構新しい取り組みとして、2つのタイムゾーンとしてやっていて、
というのも結構人数が増えたので、10人超えたかな、合わせて。
それで、Japan and Europa Time ZoneとPacific and Europa Time Zone、西海岸ですね、北米のとやってますと。
で、結構スケジュール合わせるのが大変なんですけど、みんなさん頑張って参加してくれて、
Junpeiさん残念ながらちょっとパート1出れないときになっちゃったので、多数決で。
せっかくだから一緒に収録して、収録で振り返る感じにしちゃおうかなという、一朝二夕な感じを狙っていて。
個人的にそこがすごくありがたくて、今回参加しているという形です。
ken
はい、もう2回目はなんと全員参加してくださったので、ちょっと同じような理由でゲストを探し、
誰にしようかちょっと迷っているんですけど、今回パート1を振り返しておこうかなと思います。
タイリングのテクニック
ken
じゃあまず最初にJunpeiさんに、今回はTidy Firstという本を読もうと思ったんですけど、
今回のBook Clubに参加しようと思った何かきっかけとかモチベーションとかトリガーがあったらぜひ聞いてみたいなと思うんですけど、ありますか?
そうですね、Book Club、DDIA本の読書会も結構前ですけど、参加してあれがすごく良かったので、
やっぱり読む良い機会ですし、読んだ感想だったり、気になるところを参加者と一緒に話せるっていうのがすごく良くて、
2回目のそのスマート本はちょっと参加できなかったんですけど、今回は時間が取れるというのもあって、
かつそのTidy First、ケント・ベックの本が去年リリースされて、いつか読みたいなと思ってたので、ちょうど良いタイミングで開催されて参加したというような形ですね。
ken
なるほどなるほど、じゃあちょうどJunpeiさんのツンドクリストにあった本でもあったということですか?
そうですね。
ken
ちなみになんかツンドクリストにあって、何か他に読みたいなっていう本、何か覚えてたりしますか?
どういう系の技術書をよく読むんですか?
そうですね、ちょっと最近あんまり読書に時間取れてないんですけど、Tidy Firstと似た本だとツンドクではないんですけど、
もはや古典ですけど、リーダブルコードを。やっぱり内容って忘れてしまうので、日本語で読んだんですけど、英語でも読み直したいなっていうのはあったりしますね。
あとは、フロントエンド普段書いてるので、リアクトのドキュメントだったり、
新しくなったりしたので、気になったところ、仕事で何というか、この動作どうだったっけなとか、たまに読むことはあるけど、
もうらして何が書かれてたとか、そういった部分でもちょっと時間取って読みたいなっていうのはあるので、
自分の使っているライブラリのドキュメントとかも、ツンドクではないですけど、確かに読んで読みたいなというようなのはあります。
ken
ああ、そうだったんですね。今回Tidy Firstを選んで、僕も個人的にすごい良かったなって思うのが、
リファクタリングとかタイリングに関することなんで、いろんなバックグラウンドの方が参加してくれてるんですよね。
じゅんぺさんみたいにフロントエンドを書いてる方もいれば、SREの人もいれば、マシンラーニングエンジニアの人がいるみたいなところで、
この本を通じていろんなバックグラウンドの技術者と話せるのは個人的に良いなと思ってて、
フロントエンドの話にちょっと脱線しちゃいますけど、リアクト最近大きなアップデートがあったっておっしゃいましたが、
それってどんなアップデートですか?メージャーバージョンが上がったみたいな感じですか?
まだ上がってないんですけど、リアクトカンファレンスがちょっと前、数ヶ月前にあって、
そこでリアクトのメージャーバージョンアップ19のリリースが近いと。
リリースキャンディデートでリリース準備をしてる。
ドキュメントというかアナウンスもあって、こういう風に変わっていく。
特にそのフォーム周り、インプットフォームですね、リアクトの裏側がちょっと変わるっていうのがあったりして、
そのライブラリとか、例えばリアクトフックフォーム、実際によく使われてるライブラリも受けたりとか。
特にリアクトサーバーコンポーネント、そのネクストJSのアップデートとかが結構入ってて、
そろそろそのメージャーバージョンアップが来るんじゃないかという感じで、
来る予定ではあるんですけど、その辺の調査とか、
実際にGitHub上のディスカッションとかがまさに今ホットな話ではあるんですけど、
今年度中にメージャーバージョンアップがリリースされるんじゃないかっていうのがあったりして、
そういった観点で、当然ドキュメントもアップデートされたりしてるので、
キャッチアップという意味でもちょっとやっていかないとなっていうところが。
ken
なるほど、結構ワクワクしますね。
リアクトは僕フロントエンドエンジニアではないですけど、
数年前に投資して結構ラッキーだったというか、
いろんなフロントエンド技術が当時ありますけど、
リアクト結構いろんな会社に転職しましたけど、使う場面が多いので、
数年前にちょっと頑張って勉強したいとはもう貯金でずっと食いつぶしてるみたいな感じはあるんですけど、
メージャーアップデートの話は知らなかったんで、
じゃあ出たらフロントエンドからやりたいな、来てください。
そうですね。
ken
嬉しいですね、ブッククラブ。
じゃあ今回のパート1の振り返りをしていこうと思いますね。
パート1は以前ソロ会でこういうタイリングファース読んできますよって収録をしたんですけど、
そこにも簡単に言ったんですけれども、
ちょっとじゅんぺいさんの印象とかも聞いていきたいんですけど、
僕の印象としては、パート1はタイリングのテクニックが羅列して書いてあって、
明日から使えるようなTipsが基本的には書いていると。
パート2、パート3になると、いつタイリングするとか、
なぜするのっていうところのより深い議論に入ってくるんだけど、
パート1はすぐ使えるツール群というか、そういうのが書いている印象でしたね。
じゅんぺいさんはパート1読んでみてどのような感想を持ちましたか?
そうですね、ほぼ同じで、
WATSの具体的なテクニックというか、Tipsが羅列されている、
各チャプターが短いと1ページとか、2、3ページに固まってて、
トピックごとに明日から使えるTipsを書かれているっていうような形ですね。
ken
うん、そうですよね。
結構ブッククラブの中でも、個別個別のチャプターかな。
各個人が気になるものをピックアップして、議論したり質問したりしました。
これじゅんぺいさんにも聞いてみたいんですけど、結構多かったのが、
例えばガードクラウズの話ですね。
とか、あとはNew Interface Old Implementationみたいなところとか、
あと読み手を意識して、コヒジョンオーダーとかリーディングオーダーみたいな、
呼ぶ順番とかロジックの順番を入れ替えるっていうのもタイリングの一部だようであったりとか、
あとは結構当たり前のことではあるかもしれないんですけど、
Dead Code、使われてないコードを消していこうという話だったり、
その各参加者が自分が知らなかった、もしくは結構学びがあったテイクアウェイとして、
フロントエンドでの実践
ken
チャプターを上げていくっていうところがあったんですけど、
じゅんぺいさん個人的には、このチャプター、もしくはこのテクニック、
記憶に残っている何点ありますか?
今回の本を読んで新しく知ったテクニックでもいいですし、
よく使っているけれども新しい観点を与えてくれたとか。
そうですね。ガードクラウズ、確か一番最初の方に出てきて、
有名なアーリーリターンして、ネストを深くしないようにしようっていう。
よくやっている、読みやすさの観点でもいうような手法なので。
あとはDead Code、使わないコードは消そうって単純なんですけど、
実際コード、特に新しいソースコード、あまり馴染みのないコードを新しく読むときは、
関係のないコードが残っていると、そこだけで混乱してしまいますし、
時間取られてしまうので、消すっていうのは非常に効果的だなと思います。
ken
このDead Codeちょっと深掘りしてみたいんですけど、
Dead Codeの章で結構議論になったのが、
まず使われてないコードを消しましょうということはみんな同意したと。
でもここ2つ難しいポイントがありまして、
まず1つはDead Codeを消すというカルチャーをチームにちゃんと入れるっていうまず難しさがあると。
例えばフィーチャー開発が忙しいようなときに、
ちゃんとDead Codeを消す時間を取るかどうかみたいな話もありました。
2つ目がDead Codeを検知するツールの話ですね。
目視で何万行と書かれているコードの中からDead Codeを1つ1つ消していくって基本的には無理なので、
例えば使っているツールであったり、
言語特有のツールだとかやり方っていうのが結構議論になったんですね。
じゅんぺいさんが普段はフロントエンドということなので、
例えばちょっと教えてもらいたいんだけど、
勝手な想像としてはJavaScript、TypeScriptとかでコンポーネント書いたり、
あとはもしかしたらCSSとかも書いてたりするのかなと思うんですけど、
Dead Codeを探すっていう普段のフロントエンドにおける作業の様子というか、
あとカルチャー回して聞いてみたいですね。
例えば僕が個人開発でフロットしているときとかは、
使われていないCSSのクラスネームを探すであったりとか、
TypeScriptだったら短いスコープであったら使われていないバリアブルとかファンクションとかは、
Syntax HighlightとかLinterでも出してくれるんですけど、
もうちょっと細かいところで使われていないマルトクラスがあったりモデルがあったりとか、
結構普段どういうふうにDead Codeを探し合っているのか、
かつそのDead Codeを消すタイミングっていうのは、
フィーチャーを実装するプルリクにしれっと混ぜるのか、
もしくはちゃんとDead Codeを消す時間をチームで作っているかとか、
そこら辺ちょっと聞いてみたいなと思ってます。
なるほど。
今チームがすごく小さくて、
フロントのチーム自体が私含めて3人。
ちょっと前まで2人で、最近1人加わったみたいな感じなんですけど、
なので小さいという前提で話すと、
別途時間を作るっていうよりは、
普段のフィーチャー開発と一緒に、
そこに関連するコードでちょっといらないコードを見つけたときとかは、
一緒に消しちゃうっていうことが多いですね。
もっと人が多かったり、大きなチームだと、
もしかしたら影響範囲が大きくなるので、
チーム内で意思疎通を図って、
リファクタリングだったりタイリングの時間をとって、
そういう期間をとってやるっていうプラクティスとかもあるのかなと思うんですけど、
自分の普段の業務の中で、
一緒にやっちゃうことが多いですね。
あとツールに関しては、
今チーム内でVS Codeも共通で使っているので、
VS Codeのリファレンス、コードナビ、
Macだとコマンドプラスで参照モードが開けたりとか、
別途コマンドもあったかな、
VS Codeの機能で使われているかいないか、
関数単位だったら見れるので、
それだけ明らかに使われていないファイルだったり関数だったりは基本的には消してしまう。
ここが多いです。
チームの文化的なところで言うと、
ゴミはなるべく置いたままにしないようにしよう、
デッドコードとドキュメント化
割れ窓理論とか確かあったと思うけど、
ぐちゃぐちゃなソースコードだとそのままにされてしまうっていうのがあるので、
なるべくきれいにはしましょうぐらいのざっくりとした意思疎通というか、
共通でやってる。
最近チームが小さいままなんで、
新しく入ったオンボーディングとかそういった点は用意はできてないんですけど、
もし進化がさらに増えてきたときは、
そういう点はあらかじめドキュメント化したり、
レビューで指摘とかそういった形になるのかなと思います。
ken
そうですよね、やっぱりオンボーディングもしっかり、
ドキュメントもしっかり、チームのカルチャーもしっかり、
いろんな方、全方位でちゃんと指摘していかないと、
ちゃんとデッドコードを消していこうみたいな風潮ってなかなか作れなかったりするので、
そこは本当に同意だなと思いました。
コードコメントの重要性
ken
デッドコードに派生して、
Delete Redundant Comment っていう冗長なコメントを消そうみたいなところもあって、
ここでジャパンとヨーロッパのタイムゾーンで盛り上がったのが、
コメントに何を書きますかみたいなところでもちょっと議論盛り上がったんですね。
これもちょっとじゅんぺさんの話聞いてみたいんだけど、
一人の方がTwitterのT和田さんのツイートを引用して、
こんな考え方もありますよというのをご紹介してくれたんですけど、
コードとテストコードとコミットログとコードコメント、
4つ書く場所があったとして、
T和田さんはテスト駆動開発で有名な方なので、
彼の意見としてはコードにはHow、何をするかを書き、
テストコードにはWhat、つまりそのコードが何をするかを書き、
コミットログ、Gitコミットログで実はWhy、なぜその機能を実装するかを書き、
最後、コードコメントにはWhy Notを書くという意見が一つあったんですね。
つまりコードコメントにはなぜそうしなかったかとか、
ken
ちょっとハック的なコメントを実装してしまったりだとか、
何を書くというコメントがあって、
それを踏まえて参加者同士の中で、
いや、僕はこれは反対だなとか、
いや、私はコードコメントこういうのを書きますみたいな結構盛り上がったりしたし、
なるべくコードコメントを書かないようにしてますとか、
あとファイルのヘッダーファイルも書かないようにしてますみたいな結構色が盛り上がったんですけど、
純平哲学を聞いてみたいコードコメント、
普段どういうのを書いてますか。
チームの状況でもいいですし、個人の意見でもいいんですけど。
そうですね。
最初の2つ、コードにはHow、テストコードにはWhatは同意かなと思います。
コードコメントにはWhy、コードコメントにはWhy Not。
あんまりそうですね、
コードコメントのところ、Why Notっていうのは意識したことがなかったので、
なんか面白い意見だなと思います。
あえてやってないこと、
Why Notなんで、それをコメントに書く、
後で読む人に対して疑問に感じるであろうことをあらかじめ書いておくみたいな、
そういう意図があるのかなと思いますね。
最近そのアプリケーションディシジョン、
何だっけ、もう言ってこない、ADRみたいな、
なんでこういうアーキテクチャにしたのかとか、
なんでこういうアプローチを選んだ、ライブラリを選んだみたいな、
ドキュメントについての手法が最近。
チームの文化とレビュー
ken
知らなかったです、面白い。
メルカリとかいろんな企業で、
テック企業が多いと思うんですけど、
ADRを残すで、ちょっとすみません、
訳字が合ってるから微妙なんですけど、
技術選定の理由とか、
配置とかをドキュメント化なりするっていうのに、
ちょっと意図としては似てるのかな、
そのYノットのところは。
ken
なるほど、なるほどね。
それ面白いですね。
だからもし知っていればいいですけど、
設計段階に書く設計書とかデザイン読具とはまた違って、
今の動く挙動とかをコード以外で言語化するみたいな形なのかな。
結構、設計書というか、
デザイン読具にかなり近いんじゃないかな、
ADRは思いますね。
なんで、意図としては似てるけど、
実際にコードコメントとして書くっていうのだと、
流度はちょっと違うのかなっていうのはありますね。
ken
そうですね。
そのデザインドキュメント、
デザインドッグって会社によってもフォーマットとか、
考慮すべきところとかが結構違うと思うので、
ken
そうですね、あんまり詳しくないですね。
結構、呼び方は何にせよ、
会社の規模とかチーム体制とかによって、
すごい変わってくるので、
例えば、スモールスタートアップとかで、
入った結構最初の創業メンバーとかで、
割と長いことずっと開発できるみたいなものなのか、
結構チームメンバーが多くて出入れが多いところで、
例えばオンボーディングとかオフボーディングも意識した
ドキュメント文化を作っていかなきゃいけないですし、
ある程度固定のメンバーでずっと作っていくことが見えてるのであれば、
そういうメンテナンスが必要なコード以外のものに割く、
作成コストも保守コストもかけるというのは無駄なので、
そこを省く必要もあるし、
結構カルチャーというかチームサイズとか、
チームの出入れとかにも結構要因があるなというところで思いましたね。
このTiwadaさんの書く話に関して言うと、
議論であったのは、
最近で言うとGitHubとかGitHubを使ってプルリクを出す。
プルリクのディスクリプションとして、
なぜこれを実装するのかという説明したりするので、
プルリクのディスクリプションみたいな場所も別のファクターとしてはあるよね、
という意見もあったりしましたね。
結構面白いですね。
他に結構無理があったのは、
プルリクの流れで言うと、
レビューですね。
レビューで何をどこまで指摘しますかということがありましたと。
具体的には、ここのタイリングパート1に書かれていることって結構
オピニオネイティブな部分もあると思うんですよね。
例えば、リーディングオーダーとかコヒージョンオーダーとかって、
コヒージョンオーダーにちょっと特化した話をしましょう。
コヒージョンオーダーはビジネスロジックを一貫性のある形に並べ替えると。
これって開発メンバー全員同意ができるコヒージョンオーダーがあるのかどうかみたいなことになって、
結構人によってはこっちのほうが分かりやすい。
別の人にとってはこっちのほうが分かりやすいみたいになるんじゃないかな。
例えばプルリクが上がってきたときに、
自分が意識してない、
自分がちょっと理解できないようなコヒージョンオーダーで出てきたい。
でもそこ指摘しなくても大きな問題にはならないみたいな、
指摘するかどうか迷うようなそのときに、
どこまでレビューコメントしますかっていう話もあったんですね。
なんかそういう場面って今のチームで経験したりしますか。
プルリクで細かい、現場で言うと例えばNITSとかスーパーニッツって言ったりしますけど、
ところどこまで言うかみたいな、難しいなと思っていて。
じゅんぺいさんのチームとかどうですか。
コヒージョンオーダーの、そうですね、実際の宣言の順番だったり、
の点に関しては私は指摘はしないですね。
実際の機能的な観点で言うと全く影響のないところなんで、
そこは統一が取れてれば、
ken
なるほど。
順番でもいいかなと思ってしまうので。
なんで、ここはなんというか、
あまり気にしない派ですね。
あとはそうですね、ニットピックなところっていうと、
実際好みみたいなところになってしまう指摘事項に関しては、
コメントをすることはあるけど、必須ではないみたいな意味合いでニットピックコメントをしたりは、
個人的には気になるけど別にマージのブロッカーにはならないよみたいなコメントをしたりもしますね。
なんで、あんまり明らかに答えがないものに関しては、
あまりコメントしても時間を取るのもなっていうのを感じてしまって、
ken
無駄な議論というか不毛な議論になってしまうんじゃないかなということですかね。
それが多いかなというのもありますね。
ken
それすごい賛成ですね。
その話をしたときに、とある会社の方が面白い取り組みを紹介してくれて、
そういったコメントをするときに、わりとニットピッキングとかニッツとかいう会社が、
僕の経験者は多いんですけど、
その会社ではなくてパンダの絵文字を付けると。
パンダの絵文字を付けると、いわゆるニットピッキングというか、そういう扱いとしていいと。
なんでパンダの絵文字を付けるかっていう理由が面白かったんですけど、
そのパンダの理由を付ける理由が、英語でPedanticっていう、カタカナではPedanticとかって言ったりするんですけど、
この幻覚的っていう、幻覚的ってわかります?
幻って、これちょっと幻覚的の幻でしか聞いたことない、見たことない感じなんだけど。
Pedanticって英単語を確か調べたときに出てきて、
重要でない、学術的に重要でないけど、
銃箱の罪というか、そういった意味合いだったって覚えてます。
ken
それですね、銃箱の罪をつつくみたいな感じで、
いわゆる物知り顔をするというか、学者ぶるでも重要じゃないみたいな、
そのPedanticからパンダが来てて、
だからパンダを付けるときは、僕は、私はそう思うけど、気にしなくていいですよっていう、
なんかちょっと面白いですよね、一応自分もなんか、面白いジョークの言い方だなと思って、
それでパンダ使おうみたいな話も他の会社の方が言ってる、面白いな。
なんかこういう他の会社の取り組みを共有し合える、面白い場だなというのがありましたね、Pedantic。
ただこれ、自分だけ知ってても、いきなりパンダ使ってきて、他の人にも言わないと、
なんでパンダなのかなみたいな、同意が取れないとなかなか回らないとこだと思うんですけど。
なるほど。
ken
でも僕も、もともとのスタンスとしてはじゅんぺいさんと同じで、あんまり書かないように最近はしてますね。
なんかその、ジュニアメンバーがいたりオンボーディングの一環で、最初の1ヶ月とかは割とチームの開発スタイル、
原告されてない開発スタイルとかを原告する過程で一緒にプルリクでやっていくみたいなのがあるんですけど、
なんかその、プルリク上げた時にいっぱいこういうパンダコメント付いたら、なんかモチベーション下がるじゃないですか。
なんか、それだったらペアプロで30分時間作って一緒にやってあげたりとかの方が、
お互いハッピーかなっていうところはあったりするんで、なんかあんまりパンダマウンティングはしたくない。
あまりそうですね、あのパンダの話はすごい面白いですけど、そこは同意です。
そうですね、なんかでもパンダかわいいなと思って、書くなら僕もパンダしたいな。
ken
あとは結構個人的にあっても、これちょっと意見があったら聞く感じで、
なかったらスキップでいいんですけど、New Interface Old Implementationっていうチャプターがあって、
それ、なんかよく分かんないよねって言ってる方がいたりとか、同じような疑問を持った人も結構いたんですけど、
つまりこれ何を言いたいんだろう、ケント・ベックはみたいな感じで議論になったんですね。
New Interfaceとか言ってるんで、結構言語によってもその印象が変わるところかなと思っていて、
本当にインターフェースが言語に組み込まれてる、プログラミング言語を普段使ってる人からすれば、
ああ、あのことかなみたいに分かるかもしれないけど、インターフェースっていうもうキーワードがない言語だったら、
割と人によって解釈が違うようなところなんですけども、この章、何か覚えてたりしますか?
何か読んで引っかかりがあったり、何か自分としては理解だなみたいな。
そうですね、正直僕もこの章はよくわからなくて、
大変な文章だなっていうのが、確かこの章、大例みたいなのが書かれてなかったと思うので、
1ページですね、チャプター4。文章もかなり短いんで。
ken
そうですよね。
読み飛ばしてしまった。
はい、そんな感じでいいかな。
いや、何かせっかくね、ブッククラブの収録なんで、何かやっぱ本って書いてあると権威効果があるというか、
何か本に書かれていること全部正しいと思って読みがちなところもあるんですけど、
リーダブルコードの意義
ken
割とそのブッククラブの良いとこって何かよく分かんなかったみたいなところをみんなで言い合えるというか、
何かここは意外と正しくないんじゃないみたいなところをみんなで言い合って、
実際第2版で変えられたりとかするし、
今回のインターフェースのインプリメンテーションについても、
ケント・ペックが自分のブログで何かこの項目は削除するかもみたいなことを言っていたりとかあったりしたので、
何かそういう印象をみんなで共有できたのが良かったなと思ってます。
何か他にピックアップしたいテクニックがありますか。
これは面白かったな。
割と何かExpress Parameterとか、普段やってるよみたいな結構あったと思うんですけどね。
Extract Helperとかね。
Helper Methodにっていう、本当リーダブルコードでも書かれてるような、
別関数に、一つのファイル長くしすぎないようにとか、
いわゆるチップスとして普及してるような内容が多いなと思いました。
ken
そうですよね。
次はですね、ぜひ聞いてみて、逆に本で紹介されていない手法で、
自分が気に入っているおすすめの手法はありますか、みたいなのがありましたね。
そうですね、じゅんぺいさんが考えてる間に、面白かったものをいくつかピックアップすると、
これはトモヒサさんが、Railway Oriented Programmingということで、
リザルト型、リザルト型ってわかりますか。
Rustとかにもネイティブで入っているんですけど、
結果がOKかエラーかっていうのを返すんですよ。
タプルって言うとちょっと表現がまずいな。
リザルト、結果がOKかエラーになる、どっちかのパターンになるような結果を、
ファンクションのリターン値として返すんですね。
例えば、使いどころとしてはファイルIoが発生するようなところをディスクから読み込むときに、
例えばこのファイルを読みたいです、みたいなファンクションがあったときに、
このファイル名にタイプが入ってたり、存在しないファイルを渡すと、
もちろんエラーが返ってきますよね。
なので、ファイルを読み込むみたいなファンクションは、
ファイルの中身を返す、ストリングを返すんじゃなくて、
リザルト型を返すと。
リザルト型の中身としては、
ファイルを読み込めたらファイルの中身のストリングを返し、
ファイルが何らかの理由で読めない、
例えばファイル名がタイプがあったり存在しなかったらエラーを返す、
っていうふうにすることで、
例えばファンクションの読み手側でリザルト型として受け取り、
エラーが出たときにはエラーの対応するし、
エラーが出なくて普通に内容が返ってきたときは、
リザルト型のOKとして扱うことができるということで、
例えばCとか普通に書いてると、
例えばマイナス1をエラーとして扱って、
みたいな型をうまく使いつつ、
コンパイルの機能をレバレッジしつつ、
エラーが返ってくるようなパターンってどうやって表現するのって、
結構言語とかツールによって違ってくると思うんですけど、
このリザルト型っていうのは一つ綺麗に使えるようなパターンになるんじゃないかなということで、
リザルト型がネイティブに入っているような言語とかもあったりしますけれども、
これ、ともひささん、確かリザルトボックスっていうツールを作ってたりとかもして、
これは個人的にもうラストも最近やってたりするので、
好きなパターンだなと思いましたね。
はい、じゅんぺいさん、何かありますか?
チーム内の取り組み
ken
リザルト型みたいなのを聞いたとき、何かあります?
タイプ、スクリプト、ネイティブって。
自分で定義するのかな?
自分で定義はできたと思います。
普段のコーディングではあんまりリザルト側の活用まではしてないですね。
なるほど。
ともひささんのレイルウェイオリエンティットプログラミング、
あまり聞いたことがないので、
どんなものなのかっていう、ちょっと面白そうですね。
ken
なければないでいいかなと思います。
結構モーラ的に今回パート1で書かれているので、
他にっていうのだと、
ken
パート1に書かれているのに似たようなのってなってしまって、
パッと出てこないですね。
結構割と基本的なメソッドも書かれてるから。
じゃあ次行こうかな。
この質問自体はですね、すごい面白いなと思ってて、
タイリングを後回しにしないために実践していることはありますか?
これちょっとさっきの質問で似たようなことすでに聞いちゃったかもしれないんですけど、
その会社によってはスパデイみたいな技術的不採用解消を全員が取り組む日が設けて、
みんなでやるようにしたりとか、
じゅんぺいさんはその3人ぐらいのチームでやってるということでさっきも話があったかもしれないですけど、
例えば他の会社ではハックデイみたいなイベントがあって、
そこのイベントでは基本的に機能開発とか技術チャレンジをしてもいいんですけど、
中には好きなテーマを選べるので技術的不採用の編載を選んで、
ハックデイの3日間で何万行も消したよみたいなチャレンジをしている人ともいますと。
じゅんぺいさん、過去の働いた会社とかの例でもいいんですけど、
似たような取り組みをしている現場とか、または新しいアイデアでタイリングを後回しにしないようにして実践することってあったりしますか?
個人的にでもいいんですけど。
正直会社的に期間を取ってっていうのは経験したことがなくて、
さっきの話したこととちょっと被ってしまうんですけど、
チーム内での意思疎通であったり、文化的なところでなるべくタイリングをしていこうっていうような共通認識が持っていくのが重要なのかなと。
そうですね。そういうのがまずあって、あとはそういったところになってしまいますかね。
ken
そうですね。
これ面白いのがパート1でタイリングのティップスを色々書いて、タイリング良さそう、タイリングやっていこう、タイリングを後回しにしないために実践していることはないかっていういい質問が出た後で、
パート2、すでにじゅんぺいさんもパート2のブックから参加していると思うんですけど、パート2ではタイリングをいつやるか、今やるのか、後でやるのか、それともやらないのかみたいなところ、
そもそもやらないっていう選択肢込みで結構議論してたりするのが面白いところかなと思うんで、パート1だけ読んじゃうとタイリングは明日からやろうって思っちゃったりするんだけど、
パート2ではやらないという選択肢も含めて、いつやるのかっていうところに議論が進んでいくところがこの本の面白いところかなと思ってたりします。
次回への期待
ken
パート1だけだったらリーダブルコード的な感じで読んで終わる、リーダブルコード信者みたいになっちゃうかもしれないんですけど、さすがケント・ベックなのっていうのがパート2、パート3で結構出てくるかなと思います。
ということで、どうかな、パート1、何かあとピックアップしたいところあります?
なかったらパート1の全体の感想をお互い言ってクロージングでもいいかなと思ってます。
そうですね、結構網羅的に、チップスが網羅されていて、短い内容で読めたので、一旦、そうですね、大丈夫です。
ken
そうですよね。個人的にもブッククラブ運営としてはめちゃくちゃやりやすい構成で、なんかパート1めっちゃ軽くて、軽いんだけど、なんか読んで使えるなんかチップスがすごいあるから、とりあえずパート1で、まず読む、読んでブッククラブをやるっていう流れを作って、パート2、パート3でも盛り上がっていくっていう、やってて面白い本ですね、これは。
ありがとうございます。じゃあ、パート1の振り返りはこれぐらいにしようかな。じゃあ、パート2、パート3の何か、次はパート3ですけど、意気込みありますか?
そうですね、パート2、ちょうど1週間ちょっと前に2回半の読書会があって、
いつやるのかっていうので、4つの観点を書かれてて、実際そういう感じでケントベックは考えてるんだっていう、興味深かったんで、本としていい構成だなと思いましたし、
パート3、Yの部分に関しても、もうちょっと深く読んでいきたいなと思っています。
ken
ありがとうございます。綺麗にまとめていただいて。じゃあ、タイディファースト、パート1の振り返り収録はこれぐらいにしようと思います。
今日はじゅんぺいさんに来ていただきました。今日はありがとうございました。
ありがとうございました。
