コーディングとリファクタリングの定義とTDD
こんにちは。
いつもの、雑談まじめな技術。略して、いつまじラジオのJです。
上原です。
はい。本日は、大変広い範囲の話になるんですが、僕らエンジニアしてるんで。
最近、このポッドキャストでも、エンジニアらしい話題を持ってきてないなと思いまして。
なので今日は、コーディング、リファクタリングについてというお題で話していけたらなと思います。
前提として、コーディングって何ぞやってことで、一般的にはプログラミング言語やマークアップ言語を用いて
ウェブサイトやソフトウェアの設計図をコンピューターが理解できるコードに書き起こす作業で、ジェミニが言ってます。
まあまあまあ、そうだなという、ちょっと難しかったけど。
リファクタリングとは、一般的にソフトウェアの外部動作を変えずに、内部コードの構造を整理改善する作業のことで書いてあります。
リファクタリングって、去年か?今年か?今年のわけでいいか。去年か、おそとしか出た。
タイリーファースト、ケント・ベックとかを見てるに、ケント・ベックが感じてそうなリファクタリングという言葉の意味が変わってるなのか、広くなってるのかっていうのはありそうな感じがあるよなという。
そうですね、第一人者ですよね。もともと、なんだったっけな、エクストリームプログラミングかなんかで提唱されたのが初めてなのかな。
ケント・ベックが、まあTDD、テスト駆動とかもそうだけど。
よく言われるのはテストありき、内部の動作、外部の動作を変えないっていう話なんで、テストがテストありきの工程って感じはしますけどね。
レッド・グリーンリファクター?
レッド・グリーンリファクターだね。
実際どうですか?テスト駆動って意識、エンジニアなら割とそれなりにジュニア経てミドルとかになってくるエンジニアだと意識してやったりする時期とかあると思うんですけど。
リファクタリングの実践と関連書籍
そうですね。だから最近は正直ないんですよ。なぜならAIのせいで。
なるほど。
でもTDDって開発手法としてはかなり好きで、ちょこちょこテスト書いて、コード書いて、レッド・グリーンやってみたいな。
っていうのがうまくハマってる時って結構ゲーム感覚でプログラミングができるから結構好きなんで。
取り組む課題が全容が見えてるというわけで、部分的に見えてる時はやったりしてるかな。
全然自分の中でまだフワッとしてるなっていう時はテスト書かず、とりあえず動くもの書いたりするけど。
でもなるべくやれるタイミングではやるようにしてます。
確かに。フワッとしてる時、書けないよね。そもそも固まってないんだからテストが。
書くテストが困らないからとりあえず動かすものを作って、ちょっと自分の頭の中を整理するというか。
なるほどね。
意識するんだけど、今言ってたようにやっぱりフワッとしてる時に。
フワッとしてる時にそもそも手を動かすなって話なのかもしれないけど。
幅との違いだから。
手を動かしたから気づけることもあるし、イメージできることもあるから。
この辺りはテスト駆動を毎回全部やるっていうのは結構僕自身難しいなぁと思っていますね。
リファクタリングはどうですか?やってます?
うーん、そうですね。そんなにガッツリリファクターしたみたいなことはそう多くはないんですが、
とはいえやるときはやってるんで、そういったときはテストがなければテスト書いてリファクターするし、
あればそのままちょこちょこ変えつつテストと行ったり来たりしながらリファクタリングみたいなことは、
最近はそれこそこれもAIのせいでそんなにガッツリすることはないですけど、やったりはしてましたね。
なるほど。リファクターで読んだ本とかあります?
でも、マッチンファウラーの。
リファクタリング。
あれは1回読んだかな。第2版の方読んだんで、僕JS力が低いんで部分的によくわからんなっていうところもたまにあったけど。
そうだった。
まあまあでもあれは1回は読みましたね。
あとクリーンコードとか。
クリーンコードは6章とか5章ぐらいまでしか読んでない。
なんか挫折ポイントがあったのか、そこに。
いや、かなり経験が浅いときに読んでて、とりあえずこの辺まで読もうって決めてその時は読んで、それ以降クリーンコードを読んでない。
なるほど。確かに本の内容によってはかなり難解なもの、なんだろう結構経験積まないとわからないようなことがピンとこないことがある気がする。
リファクター系でいけば、まあがっつりリファクターというよりは説得度ですけど、ケントベックのやつは読んで、あれは社協しましたね。
ああ、TDDな。Tワザさんも書いてるやつ。あ、翻訳してるやつか。
リファクターのフェーズあったんで、まあそういう意味だとリファクターの本と部分的には言えるという意味だよ、それも。
そんなもんかな、まだ覚えてないですよ。
めっちゃメジャーなので、メジャーかつ初学者向けで行くとDWコードとかがその部類ではある気がする。
リファクター要素あったんでしたっけ、全然覚えてない。
なんか関数名短くしろとか。
ああまあまあ確かに。
そういうの結構。あれ読んでる人はまあ多い。
なんかまず読む本ぐらいなイメージあるもん。
そうだね、まず勧められる本。
あとはなんだろう、初学者向けだとふわっとわかった気になれるのは、あのプリンシップルオブプログラミング。
あの白いやつ。
そう。
白と金の。
あんまり深くはほぼわからないけど、なんかそういう単語があるんだぐらい、概念があるんだぐらいは、あれでさらっとおさらいできる気がするな。
あれもいろいろと載ってたもんね。
僕読んでないけど、最近だとなんか良いコード、悪いコードで学ぶ設計入門みたいなのも、これもあれなのかな。
あーみんのくどさんのやつ。
みのさんなのこれ。
悪いコード。
あ、ほんとだ、みのさんだ。
最近第二版出ましたね。
最近でもないか。
あ、そうなんだ。
これはなんかわりと読んでないけど。
うん、これは初版は読みましたね。
初学者向け?これも。
うーん、そんなに難しくなかったと思いますよ。
あー。
多分。ちょっと前に読んだからあんま覚えてないけど。
タイディーファーストはちょっとむずいね。
あーまあ確かに1冊目とかに読む本じゃないかも。
あんだけ薄いけど。
うーん。
内容が。
そうですね、まあ読みやすいは読みやすかったけど、初学者向けではないですね。
僕がなんかそのリファクタリングのテクニックではないんだけど、
結構推してる本として、
まあそういうコーディングをするにあたっての心構えとか思想的なところで、
推してる本としては、
まあ達人プログラマーとユニックスという考え方っていうのは結構してて、
どっちも面白い本だ。
僕、原則としてドライ原則が一番好きなんですよ。
で、達人プログラマーがそれの原点。
だからそういう意味で好きです。
なるほどね。
結構達人プログラマーから学べるものあるよね。
なんだっけ、ボーイスカウトの原則?
大体タイディーファーストみたいな話ですよね。
タイディーファースト。
ちょっと整理するみたいな。
そうそう、立ち寄ったらそのままにするんじゃなくて、
その都度きれいにして帰りなよっていう原則だっけ。
もう一回読んでもいいかな。
第二版結局買ったけど読んでないんだよ。
意外とボリュームあるからな。
そうそう、結構長いんだよね。
今読めば面白く感じるところもあるのかもな。
確かに。
なんかそう、読み返してみようかなみたいな、
昔読んだ本で、
リファクタリングもそうだし、
クリーンコードもそうだし、
達人プログラマーもそうだけど、
昔読んで、
まあもう記憶とかも薄れてるけど、
地肉とはなってるようなものをもう一度読み直して、
見ようかなって最近思ったりして。
いやその、読み直すタイミングが難しくて、
一回読んだ本より、
つんどくこんなにあるんだからつんどく消化する方が、
得だと思っちゃう。
だから知ってるとはいえば忘れてはいるものの、
一回読んだ本より読んでない本を読む方が、
お得感を感じちゃうせいであんま読み直して知ってないんだよ。
いやそう、分かる。それは本当に分かるし、
そういう時もあったんだけど、
なんか最近、いっぱいいろいろ本読む中で、
出会う本出会う本で、
本当に面白い本って、
ほんと一握りで、
だいたい途中まで読んでやめること多くて、
最後まで行こうって感想しようって思える本が少ない、
なーって最近思ってて、
だったら、もう分かってる名著に、
名著をもう一回読む方が、もしかしたら、
なんか、得るものは多いんじゃないかみたいな。
いやーそれはありそうだな。
って最近思うようになってきている。
なんだかんだ読むと、なんだろうな、
似たようなことが書いてるケースがもう多いですしね。
そうそうそう。
なんか、あまり新しいものを得られなかったりすることが、
結構あったから、
その辺りで、もしかしたら前の本を読んだ方が、
得られるものが多いのかもしれないとか思い始めてたり。
確かにな。しかも一回読んでる分、読みやすいってのもあるだろうし。
そうそうそうそう。
で、何の話だって感じなんだけど。
違う話しすぎてるけど、
まあリファクタリング、コーディングの話ですね。
美しいコードの定義と自己評価
なんか、僕はですね、
勉強、結構真面目に勉強した派ですと。
特にマーチン・ファウラーのリファクタリングに関しては、
もう全部社協して、
しかも動かしたりしてとか、
たぶん2、3ヶ月ぐらいあの本だけで、
毎週勉強してた感じですね。
もう社協して2、3ヶ月って早い感じもあるけどね。
まあ確かにあの暑さで、
まあでもほぼ土日あれに費やしてたからね。
ああ。
マジであれしか知らなかった時期があったな。
あれがいいところは、
まあ結構、かなりたくさんのテクニックを紹介していて、本の中で。
で、しかもビフォーアフターをちゃんと用意してくれている。
こういうコードがこういう風に良くなりますよっていうのを出してくれているし、
1個ずつ解説、なんだろう、
こういうところで素結合になってるよとか、
あとデザインパターンのこういうの使うよとか、
そういうのが結構載ってて。
あれをだから2、3ヶ月やって、
ちょうどその時って業務でコードもゴリゴリ書いてたんで、
なんか実践に移せるというか、
土日の勉強をそのまま実践に移すみたいなことは結構して、
そこがやっぱりブレークスルーになったかなって個人的には思って。
なんか、あとちょっと一瞬本の話しちゃうんですけど、
あの本ってなんか珍しいなというか、他であんまないなって思うのが、
例えばAをBにファクタリングするっていうことを書いてる本っていっぱいあるんだけど、
逆のBをAにするパターンも載せたりするじゃないですか、結構。
BをAに、元に戻すってこと?
そう、だから何だろうな、説明がむずいな。
Aの状態をBにするリファクタリングをします、
それが最適なケースもあればBのものをAにリファクタリングするのが最適なケース。
逆のリファクタリング?
ちょっと例出そう。
そんなのあったっけ?
なんか結構そういうのが載ってた記憶があって、あんまそういうのないイメージが。
これもさ、めっちゃ一生懸命やったけど、もう覚えてないから。
リファクタリングをする上で、こういうやり方、こういう順序で、こういう手順でやるのが一番効率がいいっていうのは、
この本からめちゃくちゃ学んだし、
なんかストラテジーとかそういうデザインパターンを具体的にどうやって使うのかっていうのも、
この本で学んだんだけど、
実際の本の中身はあんま覚えてないっていう。
まあ、そりゃそっかって。
まあ、しにくいなってりゃいいって話はありますからね。
まあまあ、そりゃそう。
例えば、関数の抽出があって、で、逆として関数のインライン化みたいな。
あー、はいはいはい。
その逆パターンもなんか載ってるみたいな。
で、この時はこっちやらなきゃいけないし、こっちの時は逆のこっちやらなきゃいけないみたいなのを書いてるのってあんま見ない気がしていて。
確かにな。結構状況に応じて。
これがいつでも最適なんじゃないよっていう、関数をただ抽出するのが最適じゃないよっていうのは、確かに言ってる気がするな。
このマーチン・ファウラーとケント・ベックも所々で確か、なんか書いてくれてるはずなんだけど。
2人はなんか本当に、エンジニアリングとは銀の弾丸はないよっていうのを本当にずっと言ってそうな2人だなって感じです。
すいません、戻します。
まあ、そんな感じで勉強してましたね。
で、この中でそのリファクタリングを学んでいく中で思ったのは、
なんだろう、美しいコードってあると思うんだけど。
はい。
美しいコードってなんだと思う?
なんだと思う?
なんだと定義してる?何か定義ある?
定義はないけど、感覚として読んでて気持ちいいコードは美しいというふうには思います。
読んでて気持ちいいって、どんなところの繋がり、すごい物語のように読めるみたいな。
そうですね、頭に入っていきやすいっていうところな気はするな。
何やってるかわかりにくいコードにはやっぱ美しさは感じないけど、
すっきり読めた時はそこに美しさを感じるというか。
すっきり読めない時って何なんだろうね、散らばってるとかなんかあっち行ったりこっち行ったりするみたいな。
そうですね、なんかいろんな処理入ってるせいで、ここで一番言いたいことがわかんないとか、
あとその関数長くて、初見でうってなるとか。
あとどういうのかな。
なんか関数名が短くて、中身が膨大にあったら圧倒されちゃうよね。
そうですね、一旦それ読むのにふーってしなきゃ読めない。
あれがね、僕だからコード解析する時ってどうする?ずっと頭の中で。
コメント残しながらやってるから、書くように。
あーなるほどね。
その量が少なければ頭に残してやるけど、
一旦それでやっていくんだけど、あーこれ多いわ多いわってなって戻ってコメントしながら切り替える。
あーなるほどね。
動かせる関係があるんだったら動かしながら、デバッグでちょっとずつ動かしながらとか。
確かに。
僕もコメント残してってやり方もちょっと試してみたりしたんだけど、
僕はなんか、めっちゃ多いと塊ごとに一応区切ってメモツールに移して、
それをこうステップごとに何やってるのか書き出していくっていうことをやるかな。
あとなんかするなと思ったのが、一旦開発者を信頼するっていうのもしてて、
メソッド名こうなんだからこの書類はこうだよねって決め打ってるケースもある。
あーなるほどね。
あとあと読むには行くんだけど、とりあえずその一旦はそこはそういうもんだと思って読んでいく。
それがなんか、もうちょっとコンパクトに小分けされてて、関数が。
なので、だったらまあ、で、その関数で関数名からやってることが容易に想像がつきそうな名前なのであればできるけど、
割と名前もね、何したいのかわかんない時とかもあったりするから、難しいなって思いながら。
まあでもなんか、美しいコードの定義って、関数名だけで何しているのか分かったりとか、
なんか構造的にきれいな文章を読んでいるように頭にスッと入ってくる、だったりとか。
まあ責務が分かれてて、モジュール単位で見ればスリムな関数がいっぱいあったりとか。
うん。
まあなんか課題に対する答えとして最も適したテクニックが使われてたりとか。
まあいろんなテクニック多分、トレートとかもあると思うし、なんかそういうのが適切に使われているとか。
そうしてまあ読み手に優しいコードっていうのが、なんかいいコードなんだと思うんですけど、定義がむずい、結局な話。
でもなんか、なんだろうな、割と、僕リファクタリング好きできれいなコード書きたいっていう欲結構あるタイプなんだけど。
はい。
でもなんか、その時に自分でこう見返す?見返して、コード見返して、もうなんかフィードバックってあんまなくて、なんだろうな、
もうだって自分の中の全力出し尽くしてるから、これ以上変更することってないし、自分の中で美しいって思ってたりするんだよね。
そのフィードバックっていうのは、内製してみた上でのフィードバックみたいな。
そうそう、内製してみた上でのフィードバック。
で、まあレビューに回すじゃん、その後に。
で、レビューからもう、今の組織での関係性もあるけど、あんまちゃんと見てくれないし、そんなフィードバックがちゃんとくることもないから、リファクタリングにおいて。
っていうのもあって、じゃあどこで実感するの?ってなると、リファクタリング自体はもうその時は自己満足でしかないんだけど、コードって寿命長いじゃん。
ずっと後に、1年後でも半年後でもいいんだけど、なんかそのコードと自分が書いたコードと出会う時があるわけじゃん。
そうですね。
その時に、やるじゃんって思うと、気持ちいい。
むしろもうそれが、それが気持ちよくてリファクタリングしてるまであるかもしれない。
だからその、やるじゃんっていうのは自分が停滞してるわけじゃなく、ちゃんと成長した上でやるじゃんって思ってるってこと?
そうそうそうそう。
それは確かにいいっすね。
よく考えたなーって。
昔の自分を褒められる。
まあ、何こいつ何してんの?みたいな。こっち迷ってんなーとか複雑にすぎだとか、なんか凝りすぎみたいな時もあるんだけど。
やるじゃんってなった時はもう本当気持ちいい。
まあそうですね、確かに。自分でこれ、なんかいいこと書いてるな誰だ?って言ってブレイブ見て、自分だ!ってなった時は嬉しいもん。
いいの書いてんじゃん。
そうそう。いいの書いてるじゃんって思っちゃうよね。
逆もよくあるけど。なんだこのクソコードって見たら自分みたいな。
まあそれもあるね。
AI時代におけるリファクタリングの重要性
いやでもなんか、僕結構コーディング、リファクタリングの、コーディングはもうもっと広いけど、リファクタリングの技術って結構今後も重要なんじゃないかって個人的には思っていると。
今後っていうのはAIが今ご利用になってる上で今後って言ってるってことですね。
そうそう、もっと重要になってくるんじゃないかって思っていて、そもそもリファクタリングの能力を勉強するとコードの品質っていうものを担保できるようになりますと。
そうすると自然とレビュアになる。コードレビューを担っていくことになると思います。
これがどちらか技術的なところのレビューをするっていうのが一つ、コーディングをするだけの人から一つ上のステージだとするのであれば、
技術を身につけて到達しなければいけない。ジュニアとかミドルのメンバーの目指すべき地点なのかなとは思っていて。
もちろんそれ以外にもドメイン知識、我々プロダクト開発って結局技術だけじゃダメで、業務領域についても詳しくないといけないから、
ドメインかける技術があってやっとコードレビューって完成する。ちゃんとしたコード品質を担保できるんだと思うんだけど。
今後今この前の最近AIの話もなんだかんだして割としてると思うんだけど、前々回のクロードコードの話とかもそうだけど、
やっぱりコーディングはもうあいつらめっちゃやってくれるから、我々に必要なのって多分今後コードレビュー力になるんじゃないかって。
それは思いますね。
そう思っていて、だからこそコードレビュー力って、リファクタリング力とか綺麗なコードってどうやって書くのとか品質ってどうやって担保するのっていうところになってくるから、
リファクタリングってすごく今後重要になってくるんじゃないのかなって思って今日この話題を持ってきた。
一方で言われてるのが、多分AIのステージが今の段階であるとそうだなってすごく思うんだけど、
1、2週間くらい前、この撮ってるのが今2月23日ですが、
1、2週間くらい前にGitHubの元CEOがレビューの仕方は今後変わっていくみたいな、
こうじゃなくてもっとその中心的な目的とかそこのレビューが主になっていくみたいな話があってしてて、
そうなってくる、その未来が実現すると人間がそんなにコードを細かく見ることすらなくなっていくのではみたいなことが騒がれていて、
そうなってくると、そもそもエンジニアいるなって話もあるんですが、
コードのレビューするってことも減っていくのかなと思ったりもしましたね。
なるほどね。だから保守のこと、コードを保守するっていうことを全部任せられるんなら多分そうなんだろうなって思うんで。
それこそドメインを理解した上で、その辺りを担保できる。
結局マーチン・ファーランの本でもさっき言ってたように、状況によって使うべきテクニックって変わってくるっていう話。
で、ドメインによってとか、そのプロダクトの歴史によってできる最前種って変わってくると思うから、
そこまでだからAIが読み取れるようになったら、確かにもういらんよなって思うのと、
もう1個あるとしたら、毎回フルスクラッチで作るとか。文章だけ、目的とかやってることとか機能とかの文章だけが用意されて、
その文章を更新して毎回フルスクラッチで作ってデプロイするみたいな。
でもそれをしても、商用の環境だとやっぱバグとか障害って出せないじゃん。
テストってどれくらいするのとかも、そうなるにはいろんな壁がありそうな気は個人的にはしてるけど。
僕も全然それに現実味を感じないから、そうなんかなと思ってみれるけど。
なんか難しそう。すごい進化してるし、いろんなポッドキャストとか記事とかXとか見てると、やっぱクロードコードでできることって増えてんだなって実感はわかる。
だからテストの重要性なんかは増してくるのかな。そのコードを頑張らない代わりにテスト頑張るようになるみたいな。
でも中身わかんなかったらさ、どうすんだろうね。僕らはさ、ユーザーにプロダクトを売ってる、使ってもらってっていう感じで、
安定に運用保守できることが重要、すごく重要じゃない。
そうですね。
コードの中身わかんなくて、もし障害が起きたときに、怖くねって思っちゃうんだけど。
でもその未来においてはその風格修正もAIに任せるっていう話だから。
ああ、まあそうか。だからAI次第ってことだもんね。
全部AIに依存するってことは、障害が起きてて、いつ終わるんだって、AIがちょっとって。
まあでも人間も同じようなもんか。
開発者に聞いてくれって言って、今まだ調査中でわかんないんですよって言って。
で、それがAIに聞いても調査中でわかんないんですよって返されるだけだから。
まあ確かにビジネスサイドから見れば何も変わってないのかもしれない。
何も変わってない。
確かに。
まあありえるっちゃありえるか。
プログラミングは仕事じゃなくて趣味としか成り立たないという未来も可能性としては。
なんかでもまだやっぱり組み込む、AIに組み込むの。
なんか01で作るのはもう完璧じゃん、本当に。
もうクロードコードとかAIで全然いっぱいできるし、もうそれでいいと思うから。
なんかちょっとしたアプリとかも今は任せちゃっていいと思うんだけど。
運用フェーズに入っているアプリケーション開発するワークロードにどう適応していくかっていうのは結構まだまだ手探りな感じがする。
そうですね。
AIの話に脱線しすぎたんですよ。
AI時代の学習方法と基礎の重要性
いやでもさ、思うんだけど、
ジュニアの子とかジュニアの人とか、ジュニアのエンジニアとかミドルのエンジニアこそ、
AIに頼りすぎず書いたほうがいいと思ってて。
我々はある程度もう学習してきたし、めっちゃゴリゴリに書いてた時期もあって、
大体こういうの作りたいよねっていうのがわかるし、
なんなら書くのめんどくせえなって時だってあるわけじゃん。
そうですね。
でもなんかジュニアとかミドルの人たちはやっぱ、まず書くことを楽しんだほうがいいなって思うんだよね。
うん、なんかそもそも自分が書けないと、さっきの話と関連すると思うんですけど、
AIが出してきたものの良し悪しがわかんないじゃないですか。
結局そうすると、よく言われている上の人間のレビューコストが増えちゃうっていう話になってくるから、
一旦書く、書かないわ、置いとくにしても何かしら自分でちゃんとキャッチアップして、
そこの良し悪しのあんどころを見つけていかないことには、っていうのは思いますね。
いやそう、なんだろうな、僕らが多分エンジニアになった頃とかも、
結構ハンズオン形式とか、もうウェブアプリが結構流行ってたから、
簡単になんかDockerとかインストールして、手順通りにララベルとかReactとか準備したら、
もうなんとなく開発できちゃう、みたいな状況だったと思うんだけど、
でもハンズオン形式ばっかりやってても、やっぱ基礎って身につかないじゃない。
基礎しか身につかないじゃなく。
そう、基礎ってさ、ハンズオンでやってることって上側っていうか、
要するになんか、すごい表面上見えてるもの、表のところしか見えてないから、
もっと基礎の部分って、例えばコンピューターサイエンスだとか、
メモリーとかインフラ周り、ネットワークとかっていうところって、
なんか学ぼうとしないと学べないようなもの。
で今ってそれが、今まではそういうハンズオン形式だったのがさらに上位になって、
AIがもうやってくれるようになってるから、
多分自分でこう、なんだろ、手を動かそうとか、
あの当時僕もコンピューターサイエンスが基礎だから、
基礎を知らないと応用に回せないから、そっちの勉強一生懸命やろうって思って、
気合い入れてやってたんだけど、
だからそれが今は、それがすごく生きてると思うし、
でもなんか、今のAI時代でコードも書かないし、
少なくともリアクトとかララベルのハンズオン形式でやってた時はコードは書いてたじゃない、
でも今コードも書かなくなるってなったら、
自分でそういうのこう、わざわざ手間暇かかる方法を採用してやっていかないと、
身についていかないんじゃないのかなって思ってるっていう。
そうだと思いますね。
なんか聞く話としては、今まではボトムアップでやって、
知識を蓄えてたのが、今はトップダウンというか、
一回ドンと作って、その後の修正なんかで、
こういう時はこういう修正をするのかっていうようなのを学んでいくっていうのが
主流になっていくみたいなのは見たから、
部分的なところの知識は身につくけど、
深い部分、基礎のところとかの理解っていうのはなかなか、
できるにしても以前の学習法に比べればだいぶ遅く、
身につきづらいっていう状況はあるんだろうなとは思いましたね。
簡単に作れちゃうからなあ、そこから、
しかも知識ないと疑問に持てることも少ないから、
やっぱりどうにかして、もっとエンジニアとしてやっていくってなったら、
そういうのをこう、込ん詰めてやらないといけない。
泥臭い学習をしないといけない。
だろうなあって思った。
なんだかんだ、結局その辺の基礎を学ぶほうが、
いろいろとその後の理解も深まりますし、
でも多分主流じゃない学び方になっていくんだと思います。
なんかAIとかもそれこそ、
僕もなんだろう、AIに分かんないこと聞いて深掘っていくのって、
めちゃくちゃ学習コスト低いというか、
学習効率がいいなあって思っていて、
だからAI活用して勉強の方法とか確立できれば、
すごく成長できそうな気はしますね。
そうですね、うまく使えればいいツールですからね。
うん。
というわけで、だいぶAIの話、
もうね、トレンドすぎてね、何なんでもAIに結びつけられる時代になってしまったから。
そうですね、どっかしらにフックがあるから、AIの。
そうなんだよな。
なんか考えちゃうもんなあ、このAI時代でとか、
なんかそういう、何だろうな、疑念みたいなのも結構あるしね、
AIに対するなんか、こう、違和感というか。
っていうのはあったりするんで、
なんかいろんな話がもうつながってしまうが。
まあまあ、でもつなげずに話すのが、
今後は老害化していく感じもあるから、
まあまあ、つなげて話す方が健全なのかもしれない。
じゃあ最後に、リファクタリングを学びたい人に一つだけオススメするなら、
どんな本ですか?
え、どんな本?
何、何オススメしますか?
何でもいいです。
まあまあ、でもやる気があるんであれば、
マーチンファウラーのリファクタリングとか、
ケントベックのTDDとかを社教するっていうのはやっぱいいんじゃないかとは思いますけどね。
なるほど。
やっぱ社教ですよね、まず何よりは。
社教だね。
なんか普通に読むだけだと楽だし、ぽんぽん読めて学んだ気にはなるけど、
やっぱその浅い理解にしかならないから。
ならないね。
何を読むにしても社教はするべきだと思いますね。
確かに。コードが書かれているものは社教せよっていうのは確かに。
あれみんな流し読みして分かった気になってるけど、全然分かってない可能性高い。
いやそうですね、分かった気にはなれるんですけどね。
リファクタリングとか、僕もクーリングコードとかをちゃんと社教して、
一冊時間かけて忍耐強くやっていくのがテストだと思います。
そうですね、時間がかかるのはしょうがないんで、
でもやるしかないんで、本気を出すなら、是非社教していただいて。
AI時代にこそ多分必要になってくる能力だと思うので。
そうですね、だから極力AIの補完とかも使わず、
IDの出してくるサジェストというか、みたいなのは良いと思うけど、
パイロットのタブでポンポンをかけるのはしない方がいい。
確かに。
あとちゃんと関数名とかもね、考える癖とか。
あれ昔だってさ、ねえねえってめちゃくちゃ時間かけたからなあ。
それこそクーリングコードかな、クーリングコードに名々には時間かけていいって書いてますよね、確か。
うん、書いてある。
今なんかね、こういう関数作りたいんだけどってAIに投げたらリスト出してくれるけど、
昔はこのコンテキストでどの単語がいいんだろうとか、
めっちゃ考え、だってもうGoogle翻訳しかない時代だから、
めっちゃあれに時間かけてたよなあって思う。
でも今の本当AIでいろいろと出してくれるからいいですね。
その中でもちょっとニュアンス違うんだから、こういうニュアンスでーとかってやったらまた出してくれって、
あーこれ近い近いこれ近いんだけどちょっとまだ違うみたいな。
それいいよなあ。あんだけ明々にめっちゃ時間かけてたもんなあ。
また出すにしそう。こんなところですかね。
はい、そんなところです。
はい、じゃあ終わりましょう。ありがとうございました。
ありがとうございました。
