ではですね本日は開発をするようになってすごい思ったことがあるんですけどアプリケーションのソースコードを見た時にこのアプリケーションってどういう思想で作られてるんだろうっていうのを理解するのってすごい大事だなと思ったんですよ大事そうだけど正直そこまでできてないかもしれないてかできてないまあ

僕もできてるかできてないかで言われると怪しい部分があるんですけど ただこれについては結構研修の時もたまに説明してたなっていうのがありましてちょっと今日はですねデザインパターンのうちの1個の話をしていこうかなと思ってます デザインパターンとは

世の中によく現れる問題を解決するためのパターンですねそれに名前を付けたものというようなイメージです思想みたいなものですかね方針というか

パターンって解決テンプレ解決テンプレって感じかなデザインパターンって実は有名なやつだとゴフと呼ばれているギャングオブフォーゴフって呼ばれている人たちの23個のデザインパターンが一番有名なんですけどそれをヘッドファーストデザインパターンで見ましたねそうなんです今回紹介するデザインパターンはそことはまた別のデザインパターンになります

なるほど今日紹介するのはリポジトリパターンちょっと履修してないですねそもそもなんですけどデザインパターンは

どのレイヤーの話なのかというとソースコードとかのレイヤーの話っていう認識であってますかその認識ですコードを綺麗に書くというかめっちゃそれためのTipsですねそういうことですこのリポジタリーパターンちょっとさっきじゅんぺい君とかいち君まだ見たことないっていう風に言ってたと思うんですけど僕意外とこれ見かけるんですよPHP会話で流行ってんのかな

ペチパーペチパー界隈でもしかしたら流行ってるかもしれないこのリポジトリパターンというのはですね出典は謎なんですけどとりあえずこの本に出てきたよっていうのはまず1個目はねパターンオブエンタープライズアプリケーションアーキテクチャーっていうねマーチン・ファウラーさんというねリファクタリングっていう本で有名な人がそれよりも前に書いてるのかな結構ゴツめのいろんなこう

エンタープライズアプリケーション企業内で使うアプリケーションのパターン集みたいなアーキテクチャのその中でその中のソースコードでこういうの使えますよみたいなパターンの一個として紹介されてたりとか

あとはエリック・エバンスのドメイン駆動設計ですね有名な本あれ実は結構ねいろんなパターン紹介してくれてるんですけどこういう風にアーキテクチャ作っていきますよみたいなのも実は結構あるんですよはいはいはい

クリーンアーキテクチャを混ぜていい?クリーンアーキテクチャって実際読んだらあんまり具体的じゃないというかクリーンなアーキテクチャってこういう原則があるよねみたいな原則集みたいなイメージなんですけどDDDドメイン駆動設計はですね結構具体的にこういうパターンこういうパターンみたいなのがありますへ

その中の一個にリポジトリパターンが出てきますね なので結構このドメイン駆動設計とか意識して作ってるアプリケーションとかだとよくこのリポジトリパターン使われてたりするので ちょっとどんなものなのかっていうのとこれ結構ね勘違いされやすいというかなんか間違った使い方されやすいなっていう印象もあるので その辺を回避する方法っていうのをですね

言っていこうかなと思います何卒お願いしますということでまずリポジトリというのはですね日本語でどういう意味でしょうじゅんぺいくん今海外に興味があって英語を勉強している可能性があるじゅんぺいくんやめてくださいそうだな考えたことなかったリポジトリ

GitHubのリポジトリとかって言うよねイメージですけどフォルダごとに分けられてるみたいなイメージはやっぱありますよねリポジトリごとみたいななんで半分来てるよ50点取ったんでカイツさんにパスちなみに僕もマジで分かんないんですけどめっちゃ適当なこと言うんですけどブランチが生えるんでミキとかうーん

ちょっと遠のいたかもしれない遠のいたフォルダとかそういう区画を分けてるところはニュアンスあってて実はこれ保管庫って意味があるんですよGitHubもソースコードごとに保管してるよねみたいなそれの保管庫だよねって意味でリポジトリって言ってると思うんですけどこのリポジトリパターンはですねドメインオブジェクトの永続化と再構築の責務を持った

そんな役割を持ったクラスでございますじゃあその各クラスを整理するために一個抽象的なやつ置いておくというかそういうオブジェクトクラスを格納しておくようクラスを作っておくということですね整理してそうすることで

クローンとかみんなできてすぐ構築できるよねみたいなうんとねいや多分ね違うかも違うんですよねまずちょっと今の説明はあえて難しく言ってるんではいちょっと疑問を持った感じ出してもらっていいですかすいません

それによって何が解決されるのかまだよく分かってないですなるほどねOKめっちゃそれをさっきの特に一般的に永続化と再構築って言われるんですけどこれが非常に難しい言葉を使い上がってこの野郎と思ってるんですけど簡単に言うと永続化っていうのはデータベースに保存するとか要は一回処理がリクエストから始まってレスポンスで終わるじゃないですかでも

でもその後も情報が残ってるよねっていう状態を作ることを永続化一般的にはデータベース保存したりとかS3に保存したりとか保存先はさておきいろんなところに保存できるよねと再構築っていうのはそこに保存したやつを取り出してもう一回使える状態に戻すよっていうやつで基本的にはそのセキュームを持ったやつなのでデザインパターンゴフのデザインパターンで言うとちょっとファクトリーに近いかもしれないですねうんうんうん

あれをもうちょい限定的にしたみたいな感じでファクトリーっていうのはクラスを作るクラスみたいなここの深掘りはちょっとあんましないとこ別エピソードで話してましたかね怪しい怪しいですけどこの保存するところと取り出すところを抽象化しましたよっていうのがこのリポジトリパターンでなんとね今日はこれをですね

これで例えたらめっちゃわかりやすいんじゃないかなっていうのがあるんですよなんかヘッドファーストに戦いに行ってる感じでいいですねビュッフェファーストで例えていただきたいです出たなるほど今回はですね普通のホテルのビュッフェの会場をイメージしてほしいなと思ってますマジで料理いっぱい並んでてお客さんやってきて食べますよみたいなただ今回はですねお客さん登場しませんなんとなんと

今回はビュッフェ会場を作るっていうところをちょっとリポジトリパターン当てはめて 紹介していこうかなという感じですねまずビュッフェを作り方っていうところでなかなかビュッフェで働いた経験のある僕じゃないと言えないところだなと思うので紹介していきましょうまずビュッフェというのはですね必ずですね

会場がありますとテーブル側だいたいテーブルは固定で置いてありますはい

そこの台に料理並べて作るんですけど並べていくにあたってチャーフィンという銀色のやつ出てきた食べ物の皿をセットするための台みたいなのを並べていって洋食コーナーは洋食コーナー和食コーナーには和食のものを置いていくみたいなそれぞれの料理を取れるように

スプーンとか大きいスプーンとかビュッフェでしか見ない大きいスプーンとか長い箸とかそういうのを適切なところに置いていってドリンクを最後補充して電気つけてオープンって感じで開くわけですねそれを作ってるメンバーが社員さんが規模によるんですけど2,3名とあと地元のアルバイトが3人ぐらいとリゾートバイトのアルバイトが4人ぐらいみたいな

その情報いらないですか?いらないですいらないんかいらない関係ある関係ある社員と地元のバイトと地元のバイトがいるんですねそうなんです今回はちょっと特殊ビュッフェなんですけど特殊ビュッフェというかちょっと特殊に感じない可能性あるんですけどスタッフの分業がものすごく進んだビュッフェ会場の作り方というところをやっていこうかなと思っています

さっきいろんな人出てきたじゃないですかあの人たちみんな大体全体の作業を薄く広がって特に分業せずに各々作っていくんですよなんですけど今回はスタッフの分業がめっちゃ進んでます分業って進んでないもんなんですね本当はまず社員さん一人しかいないですありそうありそうこの社員さんも会場マネージャー

会場どう作るかっていうところに責務があるとそしてアルバイトアルバイトも契約形態変えましたリポジトリにしましたどういうこと契約形態リポジトリリポジトリになりましたこのアルバイトの人たちは保管庫保管庫保管庫になったんですね保管庫っていう意味なんですけどリポジトリパターンは

これは後でいいやこのビュッフェはシンプルにしてコストを抑えるために和食と洋食の2つで攻めてますアルバイトにはそれぞれ役割が

分担されてまして半分は和食リポジトリという役割を持ってますもう片方は洋食リポジトリという役割を持ってますこの人たちはそれぞれ和食のコーナーを作ることと和食のコーナーを片付けることができるんです逆に洋食の人は洋食コーナーを作ることと片付けることができますよという状況になっておりますはいはい

でこれをするとですね何が嬉しいかというと実はこのリポジトリの子たちはねあんまりちゃんと自発的に動けないんですよその自分の作業は分かってるけど自分で動いてこう動くってことはできないとつまり素結合つまり素結合それはそうなのかまあでもはい一旦はいとしましょうはいはい

つまり疎結合な状態になっておりますとなので必ずマネージャーが指示しないといけないですねでも実はマネージャーも

普通の職場だったらマネージャーって全部把握してる人がやるから分かんないことだったらマネージャーに聞いて教えてもらうんですけどなんとこのマネージャーは裏方のこと何も知りません会場最終的にこうなってたらいいよねっていうのは知ってるんだけど料理どっから取ってきてんのとかそういう細かいこと何も知らないんですよこのリポジトリパターンというのはですね

そういうどこに保存してどういう手順で出してきて何の料理の近くには何のスプーンというか何の取るための

なんだあれ食器トングトングどういうの置いたらいいとかっていう情報全部アルバイトが持ってるわけですよそうするとマネージャーっていうのはそこの作り方を知らなくてもそのリポジトリに対して指示を出せば要ははいじゃあ和食出してっていう命令を出すだけで和食コーナーが完成しますと次は洋食リポジトリにはいじゃあ洋食出してっていう命令を出すだけで洋食が

養殖コーナーが完成しますとつまりクライアント要はマネージャーですねそのリポジトリを使う側から見たときにめっちゃシンプルにその中にある本当は複雑なロジックっていうのをマネージャー知ることなく会場を作ることができるんですよこれがリポジトリパターンですつまりマネージャーが無能でもちゃんと作ることができると

質問いいですか今話を聞いていると普通そうじゃないかという気持ちになってくるんですがというのも例えばGoogle検索でクライアントが検索するじゃないですか鶏肉その鶏肉を検索するためにGoogleの方では複雑な処理をやっているけど鶏肉って検索する人は別にそういうの知らなくていいじゃないですか多分全てのプログラムはそうなっていると思うんですけどリポジトリパターン

だからそうなってるっていうのは何が違うんですかリポジトリパターンっていうのは要するにそういうどういうセッティングをするかっていう細かいルールっていうのをマネージャーから隠してるっていうのが結構ミソで要はその料理じゃあルールが変わったとしますちょっともう今回和食だけにフォーカスしていいですかはい面倒くさいんでいいですよで和食の厨房の位置が変わりましたとってなったら本当だったらもし

それが役割分担進んでないビュッフェだったら全員がそのことを知らないといけないわけですねなんですけどもしその分業進んでる今回のビュッフェだった場合は和食リポジトリの子たちがその状況を知っていればそれを使っているマネージャー側は何も気にしなくていいとそれがあれか他とどう違うのってことかソリッド原則と言ってることが一緒そう同じだと思います

違いで言うとその再構築する部分と取り出す部分っていうのは複雑化しやすいからそこを抽象化するといいよねっていうのがリポジトリパターンなんでそれをそこのレイヤーに当ててるっていうのがリポジトリパターンの特徴みたいなイメージかなそうするとインターフェースクラスみたいなものをリポジトリクラスと名前を付けていれば

やることをリポジトリパターンって呼ぶみたいなイメージなんですかね 具体例に移りましょうかはいはいでこれじゃあまずどうやって作るのっていうのでまずそのソースコードの構成から見ていこうと思うんですけど 僕がね結構これはわかりやすいなと思ったリポジトリパターンの使い方がありましてはいはいじゃあどうしようかな ちょっと

厳密なDDDの流れで言うとあまりにもリポジトリを細かく分けすぎてるんであれなんですけどちょっと理解しやすいようにめっちゃシンプルなリポジトリでいきますね画像を保存します画像を保存するためのリポジトリなんでイメージリポジトリっていうのを作りましょうかってなった時にまずはインターフェースを作ります今回は保存と取り出しができればいいんでセーブメソッドと

ゲットメソッドの2つのメソッドを実装しましょうっていうインターフェースを作りますとそうなったら今回セーブだけに特化していくんですけどセーブメソッドってことは引数で画像を渡してリターンはどうしようかなトゥルーかフォルスにしようかな保存できたらトゥルーが返ってきて失敗したらフォルスが返ってきますよとっていうシンプルなインターフェースを作りますインターフェースってそれだけじゃ動かないんでそのインターフェースを実装したクラスが必要ですよねはい

実はこれ本番だとAmazonのS3に画像を保存するんですけどローカル環境でS3使うのはちょっとなって感じなのでローカルではどうしようかなファイルで保存しますディレクトリの中にで

あとは環境変数を使ってですねもし環境変数がローカルだったときはファイルに保存する方の実装クラスをインスタンス化させてもしローカルじゃない本番だった場合はS3に保存するっていう処理を変えた実装クラスをインスタンス化するというかバインドするっていう感じで作りますとそうすることによって何が嬉しいかというとですねまずセーブメソッドの中に

条件分岐がいらなくなるんですね要はセーブメソッドで今までインターフェース作らずに1個のクラスとかでやってしまうとセーブメソッドの中にもしローカルだったらこういう処理して違ったらこういう処理しますよみたいなことを書くとそれをゲットメソッドにも書かなきゃいけないんですよってなって条件分岐がめっちゃ増えてだろくなるんですけどインターフェース作って分離させることによって1個1個の実装クラスはすごいシンプルになると全部で4つですかね

セーブとゲットを合わせるとローカルのディレクトリに保存する場合とS3の場合とっていうのがセーブとゲットで2個ずつあったのがインターフェース使うことで全部で4つのクラスみたいに基本リポジトリは保存と取り出しの両方セットで持ってるんで1個のクラスに2個のメソッドあるみたいなイメージになってる

すいませんはい待ってくださいインターフェースは一つインターフェースは一つでその下に環境化で変わるクラスが一つずつその他にはセーブとゲットが書いてあるあるともしこれを一個のクラスでやってると各メソッドの中に条件分岐があったのがインターフェースで区切ることによって各実装の中は分岐のないシンプルな処理になりますよとはい

そしてそれを使う側のクライアント要はコントローラーでいいかなコントローラーから使ってるとしましょうとそうするとコントローラーから見ればどっちも同じインターフェースを継承してるんでセーブっていうメソッドを読んでイメージを渡すっていうことが分かってればいいとうんわおシンプルなんか説明足りてない気がする質問いいですかはい普通のDDDの本読んでてうん

ソリッド原則にのっとってインターフェース作って画像クラス作った場合も同じような構成になる気がしてセーブとゲットがあるみたいなそういう構成をリポジトリパターンって呼んでるってことなんですかソリッド原則でいうとあれはソリッド原則にのっとってると思いますねリポジトリパターンは本当にシンプルイコール例えばですけど

それこそファクトリーパターンとか分かりやすくインスタンス作る用のクラス作ったりするじゃないですか分かりやすくリポジトリパターンって

普通に書いたらそうなるんじゃねっていう役割をリポジトリクラスが持ってる気がしてて超ドキソのやつをリポジトリパターンと呼ぶっていう理解でやってますなるほどねこれをすることによってどこに保存するかとか関係なく呼び出し側のコードはメソッドを呼ぶだけでそれが保存されるってことが保証されるんで非常にねクリーンなコードになるというのですと

僕がちょっとこれをやっててハマりがちな罠っていうのがいくつかあるなと思ってたんで最後アンチパターン紹介していいですかもう一個質問いいですかリポジトリって何で言うんですかねイメージがあんまり分からなくて多分クライアント側からするとどこに保存されるかとかを全部抽象化しててこのメソッド読んだら保存できるこのメソッド読んだら取り出せるっていうのだけが分かるんで実装保管庫ってそういうもんじゃないですかなんか

あーなんか突っ込むとにかく突っ込んだりするかそうそうそうそうなるほどなるほどあーなるほどねでそれでなおかつデータを扱ってるものだよっていうのを明示的に言うためにポジトリってつけてるみたいなイメージなのかそうそうそうそうはいはいはいありがとうございます理解できましたなんとかなんとかパターンリポジトリパターンから例えばファクトリーパターンが生えてる派生したみたいな感じになってくるんですかね

生えてんのかな別大元の何とかパターンの考え方なのかなって気がしてリポジトリパターンが大元で言うと多分ねゴフのパターンで言うとストラテジーパターンと全く同じことをやってると思いますねストラテジーパターンもインターフェース作って状況に応じて切り替えれるようにしようねみたいなパターンなんですけどそれを保存と再構築の部分に作ったよっていうことによってリポジトリと呼ばれてるみたいな

単純に近いかもしれないなるほどストラテジーだとストラテジーもストラテジーはさっき言ったリポジトリパターンあるじゃないですかあれの保存と再構築にフォーカスが当たってないバージョンだと思うなるほどそうすると確かにリポジトリパターンって呼ぶのをイメージできた気がしますちょっと具体的な目的になってるというかありがとうございますではなんですね

トラップアンチパターンこれは結構リポジトリパターンにあるあるなんですけどインターフェース作ってるのでまず保管と保管先どこでもいいって言ったじゃないですかなのでインターフェースの中に絶対に保管先の情報が返ってくるようなことをやっちゃいけないなと思ってるんですよ例えばめっちゃあるあるなのはAPI叩くときですね

そのリポジトリの先がデータベースでもAPIでもどっちでもいいわけなんでリポジトリの中でAPIを使ってデータ取ってきてるケースもあるんですよその時にAPIのレスポンスそのまま返しちゃうと例えばステータスコードとかなんかこれ明らかにAPIから返ってきたよねみたいな形のデータを返してるケースこれはねあの

ファイルの構成としては合ってるんですけど役割がうまく分離できてないなっていうケースですね質問いいですか例えばですけど先ほど商用環境ではAWSのS3というストレージに保存するみたいな話がありましたけどS3の保存先URLを返さない方がいいって言ってるってことですかそうそうそうそう例えばS3だったらパスだけにするとかねはいはいはいでもパスは返してもいい

パスはいいんじゃないかなめっちゃ丁寧にやるならファイルのオブジェクトにして返すみたいなケースはあり得るかなと思いますけどねそれはすごいですねただ実際のウェブアプリケーションだとクライアントからURL叩いてねっていうケースはあると思うんでそこを厳密にやりすぎるのはあんま良くないことが起きるケースもあるかもユースケースによるっていうイメージなんですねリポジトリはあくまで保存をする

脳を責任無にしているそう保存と再構築そっかで何か取得したかったらもう一回ゲット叩いてねそうゲットで教えるからうんっていう考え方そうですうんうん

例えばAPIの場合だったら本番だったらAPI叩くけどローカルだったらハードコーディングしたJSONデータ返すよみたいなことをするとするじゃないですかでもそうなるとJSONの時点でちょっとAPI感じちゃうっていうのもありますし例えばそのハードコードしてる中になんて言うんでしょう

レスポンスのさhttpのところの情報も入っちゃってるみたいなっていうことをやってしまうとリポジトリパターンとしてちょっとうまく責務の分離ができてない状態になってしまうそれするとどんなデメリットがあるかっていう話なんですけどそれを使ってる側でまずこれAPIの形で返ってくるからデータだけ取り出すっていう処理をその中でやんなきゃいけないそうですね

しかもそれ汎用性めちゃなくて例えばAPIから取っていくの遅いからデータベースを例えば夜のうちに連携しておいてデータベースから取るようにしましたって変えた時にAPIの形になってるとそれを使ってるコードも変えなきゃいけなくなるんですよねなんですけどそういうのをリポジトリの中に閉じ込めておけるとどういう保存のされ方であれ同じデータで返せるんでクライアントが全く変えなくて済むっていううんうんうん

リポジトリパターンのアンチパターンその1変えてるデータに保存先を匂わせる情報が入っちゃってるむずむずむずって思ってるのはやっぱそうですよねファイルのオブジェクトというかファイルの中身を変えしたくなりますね保存先関係なくしたいんですもんねでもあんまり画像とかはそんな厳密にやりすぎなくていいかなとは思ってます

やっぱりパスとか返したくなるのかファイルパスならいいんじゃないURLならいいんじゃない別にそうなんですねURLなら大丈夫かも結局それがURLとして後で使われるってことが保証されてればそれは大丈夫かもだから保証されなきゃいけないんですねそうですよねURLが

一番妥協点としてはあるかもしれないなって思いますね確かにそうねURLだったらS3のURLであれ自分のサイトのURLであれ結局同じ使い方が後でできるんでURLで大丈夫かもありがとうございますいずれにせよバインドされない保存先にバインドされない

締め付けられないというか限定されないというかそういう情報しか返してはダメということですねそうですアンチパターンその2めっちゃモデルに引っ張られて作っちゃうどういうことですかこれ特に多分レールズとかララベルとかああいうフレームワークでやった時にあるあるなんですけどテーブルごとに作るじゃないですかモデルとかってそれに引っ張られてテーブルごとにリポジトリ作っちゃうみたいな

っていうのはあんまり良くないと言われててこのリポジトリはどういう単位で作ればいいかっていうと例えばさっきの商品の話するなら商品と商品と商品カテゴリーと

他にもいろんな商品コメントみたいないろんなテーブルから取ってきたデータを複合して1個の商品という概念として扱ってますよみたいな状況が多いと思うんですよそれを各テーブルに分解させて保存するっていうのは保存と再構築のところの話なのでそれをそもそもファイルごとに分けて作るってなるとそれを使ってる側で今度考えなきゃいけないじゃないですかどのリポジトリを使うかみたいなのを

ってなったらそれはちょっとリポジトリの責任が使う側の方に行っちゃってるよねっていうのが起きやすいんですけどこのアンチパターンはめっちゃあるあるですね結局リポジトリに引っ張られてモデルの個数に引っ張られて作っちゃうみたいなそれはユースケースごとにリポジトリを作るべきってことなんですか理想はそうですかねめっちゃ厳密な話をすると

ドメイン駆動設計に集約っていう概念があるんですけどそれごとに作るのがいいと言われてるんですがその集約を説明しようとするとこっから1話作れてしまう可能性があるのでどのぐらいの理解でいればいいですかね概念概念ごとにあるのがいいと思うさっき言った商品っていう概念があったらそれのリポジトリが1個あるみたいな商品

概要と商品詳細それぞれあるみたいなイメージですかね商品一覧でバーって出てくるぐらいの情報量も必要だし商品ページに飛んだ後に表示される詳細情報を含んだやつそれぞれリポジトリがあるみたいなそこはね難しい話になるわうわ難しいんですか気になって

気になっちゃうかどうしようもないその辺はマジで設計判断だと思っててマジでシンプルに作るなら商品っていう概念がありますとコントローラーから次このページはその商品の中のこの情報を使うよみたいなのを表示用にデータを整えるクラスを作った方がいいかもしれないただそれだと

一気に無駄なデータ取りすぎてパフォーマンス落ちるよねってケースは絶対あると思うんですよそうなったら概念的には1個だけどパフォーマンス上の都合から2個に分けるみたいなことをすると思いますなるほどありがとうございます分かるように説明していただいてありがとうございますなるほどなっていうのでこの2個が結構間違って使われやすいなっていう

印象があったのでリポジトリがいっぱい増えたらまず危険リポジトリ書くときにあれこれってリポジトリ書くときのコツなんですけどデータベースで取れたときでもAPAで取れたときでも

使う側のコード変わらないかどうかで考えながら作るとね作りやすいんですよね差し替えても大丈夫かどうかみたいなダメだったらきっと何かがおかしい大丈夫だったらうまくカプセル化できてる設計できてるって思っていいと思いますねはい

いやーその観点で開発なかなかしてこなかったんでこれからははいそうですねその置き換え可能かみたいなところを意識していきたいところですね置き換え可能かどうかってなんかあんま実際はやんないじゃないですかそんなデータベースも変わるよなんてことってそんなないと思うんですけど変えれるようにして作っておくと使う側が綺麗になるよっていうのがあるんでそうですよねうん

インターフェースの先は変わっても大丈夫かどうかっていう観点はリポジトリパターンに限らずインターフェース作って設計するなら考えるといいかもしれないですね確かに限らずっていう今回はねビュッフェどこ行ったんだってぐらい激ムズの話になったんですけどリポジトリパターン結構よく出てきやすいんじゃないかなと思うので一個知っておくと書くときに

これ責務漏れてるとか判断できるんじゃないかなと思いますのでぜひビューフェのことを思い出してこれは和食だから下に小さい小座を敷かないといけないとか和食だから箸を置かなきゃいけないとかそういう責務をリポジトリに持たせて使うマネージャーは無能でも大丈夫なようにしましょうそういうパターンでございましたありがとうございますまさしく

会社ってそういうもんですよねって思います会社リポジトリ部長は多分詳細よく知らないけどこういうサービス例えば金融の何々銀行向けのこういうシステム作るぞって部長が言ってどうやって作るとかそれを作るためのパソコンの使い方とかは部長さん知らないけど各課とかチームがリポジトリとしてちょっとすいません

セーブもゲットもしてないんですけどストラテジーパターンに近いけど使う場所の問題なんでみたいな感じなんですねそうですねありがとうございましたという抽象化のお話でございましたはいありがとうございました久しぶりに重めでしたねちょっと重めでしたね

でもわかりましたわかりやすかったですありがとうございました締めちゃって大丈夫ですか?大丈夫ですSNSでフィードバック募集してますのでこんなリポジトリやったよっていう報告お待ちしてます一般的なのかどうかも知りたいですねどんくらい普及してるんだろうみたいな知らず知らずのうちにリポジトリつけるのか命名しなきゃダメですもんねそうね

あとはポッドキャストの説明欄にGoogleフォームのURLがありますのでそちらから番組への質問要望をお願いしますこんなパターンも解説してほしいとかがあったらねお願いしますじゃあお待ちしてますあとは各種ポッドキャストフォームでのフォロー高評価お待ちしてますので押してない方はぜひともお願いしますお願いしますありがとうございましたではまた次回バイバイ

日本のエンジニアは使うアプリが多すぎる事実ヒマプロの使用アプリ平均数38.6個レイキャストならアプリの即起動過去のコピー履歴を引き出せるウィンドウのリサイズなどこれ一つで作業効率アップしかも料金無料今すぐレイキャストで検索