この番組は駆け出しエンジニアの順平と先輩エンジニアの海地 野里が送る駆け出しエンジニアを中級エンジニアにキャリアアップさせるラジオですということで先輩エンジニアの野里です 今日はですねその幅のボケがあったんですねそのちょっと今後の僕らのハードル上がりますよ順平さん

階段のCMあるじゃないですかそれ最初に持ってきたんかなと思いました本当に勘違いしたあれ喋ってるのじゅんぺいだけどねこの番組はノリさんそっちの方ねそんなこと置いておいて今日はですね先輩エンジニアのノリが相談を持ってきましたノリノルゼちょっと今テーマとしてはコードの共通化ですね

この共通化ってねマジでめちゃくちゃ難しいなと思ってまして難しいですねドライ原則という有名かつ強い原則があるじゃないですかDon't repeat yourselfさあ何でしたっけじゅんぺいくんあなた自身で繰り返さないドライ原則の説明してほしかったんですよね英語に引っ張られてる同じコードは

書かないようにしよう欲しい同じ知識を繰り返し書かないようにしよう知識コードに限らないですからねはいなので例えばもちろん同じコードがいろんな場所に散らばってたらまとめようっていうことにもつながるしあとそのこれ多分達人プログラマーが提唱した原則なんですけど第2版出た時にこれはめっちゃ勘違いされてしまったみたいなことを言っててあの

繰り返されるのはコードだけじゃないよっていう例えば何をしてるかを書いてるコメントはドライ原則違反だとかって言ってるんですよコメントはコードじゃないからでも

ダメだよっていう何してるかってコード読めば分かるからそれは繰り返してるよみたいな感じのことを言ってるんですねなのでいろんなものに対して言えるんですがこのドライ原則って僕エンジニアのいろんな原則の中でも上位と下位があると思っててこのドライはかなり優先されがちな

原則なんじゃないかなと思ってるんですよ強原則強い強い強いめっちゃ強い分かりやすいとこで言うと

ヤグニより強い分かりにくいからどっちも強いけどなヤグニは今関係ないこと実装今関係ないことは今考えなくていいよちょっと違うな必要なものだけを実装しましょういらないものは実装しません具体的に言うことを言うと将来こういう機能が実装されそうだからここのインターフェース作っとこうみたいなのは

やるなってことですねなぜならコードを読む人がこのインターフェースなんだって一瞬なって読んでみると中身ないやんけ読まなくていいやんけっていう感じで無駄にコードを複雑にして全員の生産性下げるからやめろよみたいなそういったニュアンスだと思ってますおまけに先回りしてやったことは10%しか使われないとかって言われてますねアジャイルの精神にも反しますね同じくらいかでもそこ

僕同じくらいだと思うノリさんほど細かくレベル分けされてないかも上中下くらいですよ上中下くらいか絶対守ればないと思ってます確かにそれはそうなレベル感はさておきドライは強い原則だと思うんですよ優先度高めって感じなんですかねなんか高い気がするしかもめちゃくちゃ分かりやすい

わかりやすいね同じような処理あったまとめなきゃっていうことに紐づきがちじゃないですかなんですけど僕はここにすごい重大なトラップがあると思ってましてパッと見同じに見えるけど実は違う処理ってあるじゃないですかありますあります

そういうのを無理してまとめがちになるというかめっちゃあるのはコーディングで言うバッドスメル不吉な匂い間違えたマーチンファウラー超リファクタリングよりコードの怪しい気配のことをバッドスメルとかコードスメルとかって言ったりするんですけど感じる時があって

関数まとめましたとまとめたけどif文で分岐してますよみたいなあるこれって分岐してるなら違うやつをまとめたから分岐したんじゃないかなってまず思うじゃないですかなんですけど例えば10行処理がありますと前半3行共通です後半4行共通です

しかし真ん中の3行違いますみたいな処理の時ってなんかパッと見全体像同じに見えるしまとめちゃって真ん中の部分だけ条件分岐すれば良いかなみたいなそういう風になり1個のメソッドにまとまりとかっていうことが起きると思うんですよこれってどっちなんだろうっていうので皆さんの現場どうしてますかっていう投げかけですねなるほどねありますよ

ありますよあるあるあるあるあるっていうのは考えある考えある考えあるでかいや考えないなないなんかちなみにじゅんぺいだったらもしメソッドが今2個ありますとさっき言ったみたいな感じで終わりと始まりは一致してるんだけど真ん中にちょっと違うのがあるよってなったときどうするはいそれをですねまあちょっと

2ヶ月前ぐらいにまとめたなっていう記憶があってまとめてる?まとめたんですよでも確かに今のりさんの話を聞いたらうんという気持ちもしてきました果たして良かったのかでも特に言われなかったので現場ではレビュープロジェクト出してまとめない方がいいとかっていうのはなかったんで一応チームとしてはOKではあったのかなっていうのでうん

ちなみに俺これ答え持ってなくてマジで答え知りたいでも答えは言ってないとは思うじゅんぺんはでもとりあえずまとめたと僕はもうまとめました中に不文ぶち込んだと2個似てるのがあるからやだなと思ってなりましたねなるほどね

一度このままカイチのも聞いていいですかじゃあ僕はまあ本当に教科書みたいなことしか言えないんですけどクリーンアーキテクチャーはやっぱり今年読んだのでクリーンアーキテクチャーの考えに染まってますとなので基本的にはロール使う人のロールが同じなのであればまとめるしそうじゃないなら同じ処理でもまとめないそのif文でどう分かれてるかによるなっていう感じですねうんうんうん

もっと言うと産業でメソッド化するのかな物によっては将来によりますけどねちなみに異風文ってどんな感じで分かれるんですかね超絶難問出していいですかこれはいやごめんこれ難問じゃないかもしれない逆にいいかもしれないんですけど

検索機能を浮かべてください検索も検索でスーモとかみたいな検索いろんなパターンで検索できる間取りとか家賃の価格とか駅の距離とか

でそれの検索をするメソッドを実行しましょうと実装しましょうとでコントローラーから検索を呼び出すユースケースみたいなところのメソッドでまず渡す今持ってるパラメータ渡すじゃないですかはい絞り込み条件ってやつですねはい

例えばこのパラメーターがあったらこれをするこのパラメーターがあったらこれをするみたいなF文を使って一個の検索というメソッドにまとめるのかそれともパラメーターのパターンに応じてメソッドを分けるのかパラメーターのパターンに応じてメソッドを分けるは多分しないしないよね組み合わせばかりする俺も作ってる間にそう思ってたそうですよねこれ簡単なんじゃないかなってなっちゃってたわそういうことですね

でもif文パラメータとして持たせてこのパラメータを持ってるときはこれをやるみたいにするのかな結局データベースにクエリ投げるだけじゃないですかそのクエリを入れてデータベースクラスにクエリ持たせてボーンって投げて帰ってきたのも返すんでしょうねじゃあごめん組み合わせ爆発しないパターンで行こう検索がありますフリーワード検索と

値段だけで検索できるの2パターンしかないそれぞれは同時にできない同時にできない名前だけ検索したら名前だけで検索されるし価格帯で検索したら価格帯だけで検索されるそれは僕分けますね分ける同時にできないですもんねなるほど同時にできればまとめる同時にできればまとめるかもしれない同じ人だなって思う

なるほどなるほどじゃあやっぱ結局誰が使ってるかみたいなのが大事なのかいやーでも僕は今そうですただその解釈が合ってるかもわかんないですけどね僕はそう解釈してますロールって結局さじ加減じゃないですかどういうロールかなんて多分正しいのはあるかもしれないですけどさじ加減だと思うのでユーザーって括るかフリーワード検索したい人って括るかはあるじゃないですかあるね絶対ね

最強の問題思いついたかもしれない会員がいますともう一人非会員がいますと会員にしか見れない何かがある商品がある商品名検索しかできないなんですけど

会員が検索した場合と非会員が検索した場合で見つかるアイテムが違うケース分ける分ける絶対分けるこれはもう明確に使ってる人が違うからしかも非会員だけ更新するケースが絶対にあるからそうですね多分ロールを分けるのは答えでそっちだけ変えるケースがあるかっていうのが多分本当に明確な基準なんでしょうねただそれを想像するのが難しいから

ロールによって変えるってクリーンアーキティスが言ってるんだろうなと思いますなるほどなるほどじゃあちょっともう少し踏み込んでいいですかいいですよまとめた場合とまとめなかった場合のメリットデメリットについてなんですけどはいはいはい例えばデータベースからデータを取得する部分を考えてほしいんですけどはい取得した時に取れる必要なパラメータって画面によって結構違ったりするじゃないですか例えば商品情報とかだったらさ

商品の詳細ページに表示するときの情報と一覧ページに表示するときの情報ってボリューム全然違うじゃないですか1商品あたりに使う情報みたいなやつってそういうのがいろんなページで発生するよみたいな例えば特集ページとか記事ページとかがあってそこに埋め込む場合とかいろんなパターンが発生するケースその場合の取得用のメソッドどうするかっていうのめっちゃむずいなと思ってて

まとめすぎるとFindっていうメソッドができてそこにとんでもない量の引数を渡さなきゃいけなくなる気がするんですよかといって分けるとFind by IDFind by 違う ID

ファインド4何々ページファインドwithなんちゃらみたいな感じのいろんなファインドのバリエーションが発生して今度はメソッドがどういう分け方してるのっていうのが意味わかんなくなるみたいなこのトレードオフめちゃくちゃむずいなって思うんですよねどう思いますかじゅんぺいさん

今の感じの想定だったらまあでも僕は分けるなって思いますねファインドがいっぱいできるやつでもなぜかと言われてもまとめるととんでもない関数になるじゃないですかファインドがそれは分けてファインドの関数がいっぱいできるより見づらいんじゃないかなっていう気はしたので

その場合だったらそういう考えで分けますねなるほど僕カイチなんですけど改めて自己紹介しちゃいましたねカイチだと思った正直データベース触る周りめちゃめちゃやってきたわけじゃないんでちょっと自信はないんですけどファインドでいいんじゃないって今は思ってますまとめる方でいいんじゃないかなと思います例えばクエリとか入れるにしても多分パラメータを

なんかのクラスに入れるのかなでボカーンって渡してそれを頑張って処理して終わるマッパーで叩かせるってことですよねそれでいいんじゃないかなコードはシンプルなはずその方がなんか処理めっちゃ大変だったりすることありますかね

あるよどういうケースですかファインドまとめたときのめっちゃ大変なケースで言うとパラメータ渡されたときと渡されてないときとかの組み合わせがめちゃくちゃ多いので中のif文がとんでもないことになってそのメソッドの使い方が分かんなくなるんですよ例えばですよORマッパー触るじゃないORマッパーでDB叩く想定だとしてORマッパーってだいたいテーブル名とあとまあ

検索条件みたいなやつこの形でORマッパーに渡してねって決まってるじゃないですかそれを渡す側で作ってファインドに渡すだけそうなんですけどそれがめっちゃボリューム増すじゃないですかそうするとパラメータ何を渡すとどう動くかっていうのはその長いファインドメソッドを読まないと分かんなくなって使う時に何を渡していいかが分かんなくなってくるんですよね

だってちょっと書きたいなということで今戻ってまいりました図に書いた結果ファインドを一個にまとめたらすごい複雑になることが今判明しつつ僕が理解しましたやっとすいませんねちょっと聞いてる皆さん分かってたかもしれないんですけど僕だけ分かってなかったんでそうなると解説必要だよね多分

そうかもしれない今回のファインドはだから呼び出し側によって例えばカラム使いたいカラムも変わってくるしどういうウェア条件にするかっていうのも変わってくるしどのテーブルと結合したいかっていうのも変わってきますとで順番とかねサブクエリいるのかいらないのかとかそういうところとかもめっちゃ関わってくるんで結構複雑なパラメータ渡しになる可能性もあるうんうんうん本当にDB経験少なくて申し訳ないんですけどはい

例えばですけど1回に叩くからそんなに複雑になるってこともないんですね分けて叩けばもっとシンプルに叩けるとかでもないんですね分けて叩くとシンプルになるけどメソッド数が増えてクラス全体で見たときに複雑になるかもっていうこのトレードオフなるほどじゃあそうかユースケースごとにそのファインド分けるか全部一緒にするかか

なるほどねこれがね絶対答えないしプロジェクトによって違うんだろうなって思ってるんですけどもしかして別の角度の解決策あるのかっていう気配も感じつつでそんなに複雑なアプリ作りたくないなって

設計でどうにかできないのかなもうすでにある時点のあるものはしょうがないんでそれはそれはもう本当にどうにかするしかないっていうかパワーでやるしかないいやでもなんかメソッド分けるの泥沼に行くしかないんだけどないやそうなんだよね分けても泥沼混ぜても泥沼っていう

泥沼サンドイッチが混ぜたら泥沼が悪化することはなさそうじゃないですか泥沼のままいきそうじゃないですかメソッド分けたらさらに泥沼になってきそうじゃないですかそんなことねえか分けた先で泥沼化してきたらもう終わりだと思うまあまあうん

複数人で一人で作っていけばいいと思います一人で作ってるんだったらあとはコーディングルールというか規則ポリシーこういう順番でメソッド並べるとかこうやったらこう切るとか明々規則こうするみたいな決まってたら分けるのありだと思いますけどそれが浸透してないと終わると思いますそうだよねだってもうさそれでいろんなメソッド分けてじゃあ1000行とかなりましたってなった時によしじゃあここのテーブルから取得を

お! 鮮魚ある! えっ? これ既存で使えるやつないかな? 探す探す探す探す30分後 なかった っつって書くみたいなことが起きるんだよねそうそうそう 書く ぐるりく あった みたいなあった? いや これここにあります みたいなあるんかい! こう使えばいけますみたいなどういうことやねん! そしてそんなの把握してない人も生まれてくるんで同じやつが何個もできるみたいな うんうんうんうん

っていうのをちょっと想像して分けた先に希望はないんじゃないかって思ったんですけどまあでもそんな無限に成長するわけじゃないと思うんで判断ですねいやーそうだよね俺分けたくない分けるプロジェクト行きたくないあそういうことねいやいやいやいやありません

ありますそういうプロジェクトはですね 見ませんね本当にマジでこんなにキャリアを積んでて rdb 触ることあるんですけどそういう検索とか複雑なシステム 複雑なテーブルを扱うのってほぼないんで01しか結構やったことないからな 嫌だなぁと思いましたなるほどね

混ぜるも分けるも怖いな悩ましいでも結局企業の需要があるのはそういうのを扱える人だと思うんで僕はちゃんと勉強しようって改めて思いました本当にそこを少しマシにする

考えとしてあるんですけどまず基本分けた方がいいんじゃないかなと思ってるんですよ今どっちかっていうと分けた上であんま分けすぎない方がいいんじゃないかなっていう気持ちがあるんで例えばこのページとこのページで使うカラム違うけど

大幅に違わないならある程度まとめちゃっていいんじゃないかなっていう多少無駄なデータ生まれるけど今ってPCとかそもそも使ってるデバイスも高性能じゃないですかって考えたらそんなめっちゃ細部の最適化するよりはコードの複雑化を防いだ方がメリットがあるんじゃないかなみたいな気持ちで望むのがいいのかなっていうのが今のところの落とし所なんですよね割と

僕も経験上そんなにパフォーマンスを求められるものって作ってこなかったんですよなんでそういう風に捨てることが多いですシンプルにして行動だからある程度パフォーマンスを削りに行くのはありかなっていう気がしてますねなるほどなるほどっすねパフォーマンスシビアっていやいや全然そっち考えたことないですけどまとめ

細分化してかつ一部はまとめてるってことですもんねなんかそうなんですよね基本僕もその細分化していく現場しか当たってないですけど一部まとめてるとこの基本ここでは1メソッドで一つのことじゃなくてこうやってまとめることもあるんかってなって割となんか見なきゃいけなくなるというか他のメソッドも

修正するときにっていう気持ちもありつつも分かるなっていう気持ちですなるほどねそういう問題だよね分かるなってなるやつですよねだからやっぱ明確なあれはないんだよなない

僕としては一つにまとめちゃうと泥沼化は防げるかもしれないですけど沼の深さは深まるなと思って底なしになっちゃう方が俺はちょっときついかなって気がしちゃいましたねちなみにコーディングするときテーブル定義見てコーディングするじゃないですか普通やっぱりどのテーブルに結合するとかどういう順番に並べるとか

別にDB叩くクラスを呼び出す側が頑張って考えて渡すじゃやっぱダメなんですかねでも見つけすごくないのかDBのテーブル変更した時にそこに影響が出るのが望ましくないのかあれじゃないですかねどっちかっていうと使い方を知ってなきゃいけないっていう知識の漏れが発生するみたいなそうですね確かにあの

よく言われるクリーンアーキテクチャでこうってこうだよねの原則には反してる気がするなDBの中身を上側外側が知ってしまっているじゃあ分けるべきかさっきのアクターの考え方で言うとそもそも使うページが違うなら分けた方がいいよねそれはそうですね分ける

分けるか分けるなんか基本分けた方がいい気がしてきたなうん分ける気がしてきましたうん

同じページで複雑な場合は多少沼になってもまとめた方がいいような気もするアクターが同じならそれはそうですねただやっぱりアクターが違う場合はこっちのページでこの表示なくなったからって消した時に他のページが被弾するっていう確かに有名なミノクドウさんのツイートみたいなことが起きちゃうんでその場合ってユースケース図のそもそもあれが違う

アクターでまとめればいいのかユースケース違うけどアクター同じ場合ってどうするんだろうでもそれはまた別のもの言ってる意味わかりますよユースケース違う時点でなんじゃないですかでもいやそんなことないかアクターが同じだけどユースケースが違う場合はでも普通分かれてるべきですよねなんか分けてた方がいい気がするなだってそれ違うことやってるんですもんねそうだねだからそれアクター同じと言わないのかもしれないそうかもしれないうん

アクターのユーザーみたいなもんですね誰が使ってるかみたいなユースケースがどう使ってるかみたいなこういう取り留められない議論をするという会話僕は楽しいですでもなんか喋ってて整理されてきましただんだんそうですねやっぱりクリーンアーキテクチャは偉大という結論そうだねクリーンアーキテクチャと言ってるのはクリーンアーキテクチャと呼ばれているクリーンなアーキテクチャはこうでねっていうわけじゃなくて本ね

本を指してますクリーンアーキテクチャという本は偉大ですね偉大だなあれクリーンアーキテクチャって言うと怒られるんだよ界隈にクリーンアーキテクチャっていうかソリッド原則が偉大なのかもしれない思うにインターフェース逆転の原則ってことさっきのアクターが違う云々ってソリッド原則のSシングルレスポンシビリティプリンシポじゃないですか単一責任

確かにソリッド原則だソリッド原則がすごい気がするゆるっとエンディングトークみたいになっちゃうんですけどリポジトリパターンもやったじゃないですかちょっと前ですけどねいろいろ世の中にいろんなワードあると思うんですけど結局ソリッド原則なんじゃないかなっていうところありますよね確かに最近僕も継続的デリバリーのソフトウェア工学っていう本読んでますけどいろいろすごい役立つ面白いこと書いてるんですけど結局ソリッド原則なんじゃないかなっていう

ところでソリッド原則ってすごいキャッチでこれはこうこれはこうっていう風に言われてますけどあんなじゃ足んないんですよ説明全然それをなんかうまく補足してくれてる本が世の中いっぱいあるっていう感じなんじゃないかなってなるほどね

ソリッド原則で言うとねあの本がいいらしいですよアジャイル開発の奥義みたいなやつ俺が好きそうな本ですね好きそうどっちかっていうとクリーンコードの分厚い版みたいな感じだと思う読みたい本他にもいっぱいあるからな分厚すぎて買ってませんそんなに700、800ぐらいあるんじゃないかなヘッドファーストぐらいですねヘッドファーストより厚く見えた

ヘッドファーストも俺豆腐だなと思ったんだけどなあれうまそうね豆腐しかもアジャイル開発のおぎゃ何たって白いんでもっと豆腐です求めてないわ別に豆腐のめっちゃ豆腐じゃあ物理本欲しくなっちゃうな豆腐置くタイプの豆腐いつの本だろう

ちょっとタイトル微妙に違う可能性があるんですけどアジャイルソフトウェア開発の奥義アジャイルソフトウェア開発の奥義ですねロバート・シマチン2008年の本ちょっと古いですねオブジェクト思考開発の真髄と巧みの技なんで多分僕は読みたいなこれ普通にこれ名著と言われてますよ読んでみようかなアダス

これは手出したいなちょっと酔い上がるかわかんないけどちなみに何ページありました600本高っ6000円もするの683ページですね683ページ1ページ10円重っ確かにいやでもそのくらいの価値はありますよね普通に本ってねありがとうございます

ノリさんの話が人とならなくちゃので取り留めもない議論でしたがありがとうございましたお便りを読ませていただきますラジオネームめんぺきさんからのお便りですめんぺきさんありがとうございます何度目かですよね聞き覚えある感想からいきます感想を読んでいただいてありがとうございましたまたGitの簡単な使い方という雑な質問を取り上げてもらいとても恐縮です

じゅんぺいさんおすすめのVSコードの拡張機能Gitグラフを少し触ってみましたとてもわかりやすくGitの基本的な使い方に早く慣れることができそうですグッジョブよかったじゅんぺいメンターありがとうございます英語の話題が上がっていましたが個人的には薬袋先生の基本文法から学ぶ英語リーディングドック本、等本が長いスパンで勉強できるには

するにはいい本だと思ってますゴリゴリに文法の仕組みからいく本なので拒否感を覚える人は多そうですがこれからも面白いポッドキャストを聞けるとこれからも面白いポッドキャストを続けていただけると嬉しいです頑張ってくださいありがとうございます薬袋先生薬袋薬袋薬袋はなんか

怖いよちょっとはいというのでちょっとポッドキャストで話してほしいことAIがこの1年ずっと話題ですがエンジニアの方の環境や開発するサービスはどれくらい大きく変わってくるんでしょうか変わっているんでしょうかはいというのでまあ分かりやすいところにいきましょうか開発するサービス変わってますかっていうはいじゃあカイチからいくんですけどはい

開発するサービス大きくは変わってないですがただPOCとかトレアルとか世の中で生成AI入れてみたいとか会社さんが増えてるのでクラウドかなベッドロックとかあとAzureで言うと何ですかベッドロックってラグAzure AI Search FunctionAI SearchとかAI Search

ちょっと怪しいんだよ生成AIを使ったアプリを作って各企業さんのスラックなのか分かんないけどねチャットボットに入れるのか分かんないけどそういうのに入れるとかあとはデモアプリを作って展示会で出すみたいなねそういうのは増えてきてるなと思いますただビジネスとしてめちゃめちゃ確立してるかっていうとまだもうちょっとかなっていう気がするんでそこのところは

もうちょっとかなとは思いますがただ各種パブリッククラウドがLLM利用できるように利用しやすいようにサービス出したりめちゃめちゃアップデートかけてるんでそこはだんだん触るようになってくるんだかなと個人的には思ってますっていうのが開発するサービス観点の勝手に思ってることなるほどね作ってるサービスというか使ってるツールがどんどんAI化されてってるなっていう感覚がめっちゃ強いっすねうんうん

具体例ありますか最近だと大体のツールAIチャットついてないですか例えばVSコードのフォークしたバージョンみたいなやつなんて名前だっけなカーソルですねカーソルっていうと日本語発音っぽいんであれなんですけどカーソルっていうエディターがあってこれはAI搭載の最強エディターと噂ですね

VSコードからフォークしてるらしいGitHubコパイロットと何が違うんですか使ってないから分かんない確かにそうですねそれ間違いない

ターミナルでワープとかって紹介しましたっけ一応もう一回お願いしますラスト製のMacで使えるターミナルでワープってのがあるんですけど僕は最近ワープを使っていてそうなんですか使ってる理由はかっこいいからなんですけどそれもチャットついてますねAIの本当にチャットGPTみたいな感じでターミナル触ってるときにこれどうするんだっけってなったらそこのチャットの欄開いて

こうこうこうなんですけどどうなんですかって日本語で送ったら絶対英語で返ってくるみたいなこの前腹立ったのはJSの質問したんですよ英語の説明コードの実例英語の締めの言葉みたいなのがあって日本語でお願いしますって言ったら説明全部吹っ飛んでコメントアウトのとこだけ日本語になってていやそこじゃないっすみたいな

のがありましたねそれ裏側何なんですかねGPTチャットGPTだとなんかそういう感じで返してこない気がするでもまあ変なプランプター入ってたらでもなるかも確かに前後とかになりますなります一応1日100件っていう制限があるんですよチャットのなるほどでもなんかそんな感じでツールにAI搭載されてなんかもう検索エンジンいかなくても答えが分かる時代になってきたなってのは思いますねそれは分かるうん

僕も結構勉強とかに使いますねキャッチアップとかね前もちょっと出したリアクトとかのフックとかそういう概念がよく分かんない時とかねフックって関数なんですか要するになんでフックで分けてるんですかとかはいはいはい

そういうのを鬼詰めするとより理解が深まるんですよねGPTをねそういう使い方とかしやすいGoogleよりそれで言うとあと最近呼ばないのがGitHubワークスペースコパイロットワークスペース何それ今GitHubコパイロットってあるじゃないですかあれはコードの自動保管とか生成とかレビューとかしてくれるやつなんですけどちょっと

僕もツイッターで見たぐらいなんで正しいところは一時情報確認してほしいんですが

コパイロットワークスベースのこれから提供予定なんですけど1周から仕様を作成してブレイクダウンして実装計画作ってコード生成してビルドしてエラーが出たらコード修正してくれるんですよえちょっと待って全部やってない?開発者いらなくなっちゃったはいなんで開発者だから今の話だと既にあるソースコードがあってそれに対して1周を書いたらそこからコード修正して

デプロイしてくれるっていうすごくすぎない?デプロイまで行くの?デプロイ来ないかビルドかビルドまでしてくれるでもビルドしたらだってそんな後CICDでデプロイするだけなんでそうだよねこっちチェックしてこれでOKそうだねってなったらあとはもうって感じ?そうですそうですじゃあもう一周立てるだけでいいじゃんそうえぇ

っていうのが2024年にコパイロットワークスペースっていうのをGitHubが出すよって言ったんで最近そうなんだとんでもない世界来たなこれマジでエンジニアどうなっちゃうんだろう分かる本当にコパイロットもあいつ言うて絶対的にこれが正しいってのは思ってないんでコパイロットが軌道に乗れるような良いコードベースを作るとかあとは良い問いを立てるんですかね

確かにそうね課題設定課題設定力が求められるエンジニアにも今までも変わらず求められてたスキルだし中級と上級の境目がそこなんじゃないかと思いますけどだから初級駆け出しはもう駆け出しの仕事が減るんでしょうねでも駆け出しの人は欲しいんで絶対エンジニアは絶対必要なんで

ただその駆け出しでやってたただテストコードを書くとかなんかそういう仕事が減るんでしょうね求人減るんじゃなくて多分より難しい仕事を求められるようになる気がするなんかフリーランスになるハードルとか上がりそうだななんかそうなるとあそうですかなんかそんな気しないですかフリーランスの仕事があんま分かってないですけどテスターのフリーランスやるなら確かにそれはハードル上がりそうねめっちゃできる人じゃないとフリーランスできないみたいなあー確かに状態になりそうな気がするそれはそうかもうん

それはそうかもあとはうまく使えればいいんじゃないですかねAIを結局うまく使うには難しいスキルが必要ですね確かにっていうのが最近のトレンドっぽいとんでもないのが来たなまた

楽しみどうなるんでしょうね確かにコパイロットも結構ねテンション上がったけどねいまだにだからちゃんと課金してますもんコパイロットとチャットGPT本当に後悔してない俺が持ってるサブスクの中で一番高いけど高いでしょ20ドルですよそんなのなくないですかチャットGPT月20ドルです

でもまあそんぐらいは元取ってるなって思ってます勉強のためとかが主かなあとお話し相手昨日とか僕あの少子化の問題についてディスカッションしました気になったんでそうなんだ日本の未来をその辺もちゃんとねチャットGPTはうざがらず付き合ってくれるんでそれは僕すごい楽しいはいまあなのでうん

ここ最近で言うと結構大きく変わってると思いますそうなんだそれで言うとねただコードを書くっていう時代が結構長かったと思うんですけどそれが変わるわけですからね大きいんじゃないかなAIがこの1年ずっと話題ですが他に話し足りないことはないですか個人でサイト作るってなった時に結構画像問題があるなって思ってたんですよ僕

自分でブログ作ろうってなった時にかっこいい画像使いたいけどかっこいい画像だいたい有料だけどこれから立てるブログに対してそんな有料のかっこいい画像を買うのはちょっとなみたいなのがあるから結局フリー素材を使って他のサイトと似たような写真のラインナップになるみたいなのが個人サイトあるあるだったと思うんですけど画像生成系のAIとかでも割とそういうのとか使ってる人多くなってんじゃないかなと思いますけどね

どうなんでしょうねなんかダリ使うことはあるんですけどダリで作ったやつダリで作ったなって感じしませんなんかわかりますまあ確かに上手いことやったらいい感じになるかもしれないですけどねあと写実的にしなきゃいいんじゃないかなそれはあるかも結局映える画像を作るっていう頭がないとできないわ普通に

なんかネットのバナー広告とかもさAIで作った素材ですみたいなやつ多すぎない?多い多い合理的っすよね絶対そっちの方がビジネス的にはいいはず効果は分かんないですねどうなんでしょうねなんか多すぎて埋もれちゃう感じあるけどな言うてパターン違うって言ってもなんか知らんけど分かるじゃんそうですね分かるそこは伸びしろかもねうんうんうん

でも確かに本当にね今までできなかったことができるようになるのは本当にいいことなんでねうまいこと使えば使いたいなとっていうのとそんな世の中でも生き残れるエンジニアにしていくなりたい我々のポリシーではあると思うんでねリスナーの皆さんと一緒に生き残れましょう生き残れましょうサバイブニシンカップヌードルみたいなねごめんCMあんま見ないけどうん

あったんだろうなどうせあったっすよなんか宇宙みたいなアニメのイメージそれでした終わりますめんぴきさんお手入れありがとうございましたまたお願いしますではハッシュタグひまじんプログラマーでSNSでフィードバック募集してますので今日話した内容についてのフィードバックお待ちしてます確かにうちではこうやってますとか今日の内容じゃなくてもこういうの悩んでるんすよみたいなの欲しいですね欲しいね

あとは説明欄から番組のお便りをGoogleフォームから募集してますのでそちらにお気軽に番組の要望質問コメントなんでもお願いしますどしどし読んじゃうよ各種ポッドキャストプラットフォームでのフォロー高評価もお待ちしてます高評価じゃなくてフォロー数もっといきますよ僕ら待ってますよ待ってます

ノリさんありがとうございました結局最初のノリさんの話もコパイロット自体生き抜くためのスキルなんで普通にねなので生き残りましょうではまた次回バイバイ