# チャプター 1 トモとマサのボイコード ボイシーエンジニアの声と出会えるチャンネル、ボイコード このチャンネルでは、ボイシーエンジニアの日々の活動をお届けしています。 なんか、今日ちょっと歯切れ悪いかも 思い出しながら喋ってます 普段もっとなんかいけるんですけど 何かがちょっと足りないんですけど わかんないかったんで ちょっと噛み噛みですけど 始めていきます 切り捨ていきましょう 今日は平日版の技術ワードトークの回なんで 今日はちょっと僕の持ち込みで あんまり得意じゃないやつ持ち込んでしまうっていう ちょっとヤバめのあれなんですけど オブジェクト思考プログラミングをテーマにしようかなと思うんですけど 厳密にオブジェクト思考プログラミングそのものをめちゃめちゃ喋りたいというか そこら辺でよく言われてそうな設計の話をしたいみたいなのが 今日のテーマですね 大きいですね そうです 僕はそもそもそういうところをちゃんと勉強してはいないんで にわかなんですけど ただ設計の本とかでも結構似たようなこととかは 結構語られてるかなと思うんですけど 最近めちゃめちゃ思うのが よくエンジニアの中だと設計の話 ソフトウェアの設計の話とかで 単一責務の話だったりとか 単身の分離が大事だよねみたいな そういう話はめちゃめちゃよく聞くし みんななんとなくそうなんだろうなみたいなところの 合意は取れてるはずだと思ってて ただ実際コード見ると これのどこが単一の責務なんだみたいな 意外と結構あるのかなっていうか 自分自身も適当に書いてると 実はそういう いわゆる抽象的な意味で大事だって言われてたことが コードに具体的に落とそうと思ったとき 結構苦労するというか 自分も間違えて書いてたなみたいなことを 後から振り返ることを思うことがあって 今日はそんな話をしていきたいという テーマで話していきたいなと思うんですけど 最近そういうのあったりしたんですか これ微妙だったなみたいな設計として ありますね 最近なのかな まずよくあるのは データと操作がバラバラになっている みたいなのが結構あるのかなと思ってて 例えば あんまりいい例がパッと思い浮かばないんですけど 何かローカルにデータを保存したいっていうのが 特定の機能の中で何かデータを保存したいみたいなのが 仮にあってデータを取り出したり保存したり みたいな処理を含むような一連の機能があったときに 何かそのコードが型の外にはみ出るのが 型の外にはみ出る 型のメソッドとして提供されてないとか っていう実装とかは結構やっちゃうなみたいな フィールドを直接書き換えちゃうみたいなことですか フィールドっていうよりか ノラで呼び出すみたいな感じですね 型を通さずに保存したいものを保存して 読み取るとき読み取ってみたいな感じで 型のメソッドの中で本来はどこに保存するのか っていうところを書くべきなんだけど 保存するって行為だけをやらなきゃいけない 例えばiOSだとユーザーデフォルツに保存する みたいなのよくあると思うんですけど 普通にユーザーデフォルツ.sharedみたいな感じで そのまま保存するみたいな処理をベタで書いちゃう OSの仕組みみたいなのをそのまま使っちゃうみたいなこと そうですね だけどそれって1個の機能で見たときに どこに保存するのかはその型が知っていればいいというか その型の中で全ての操作が閉じてくれないと 操作がバラバラにいろんなところに出てくるじゃないですか でもちゃんと型のメソッドの中で 全ての操作が完結できるようになっていれば そのメソッドを単純に呼び出すだけで ちゃんと振る舞いが担保できるというか 他のところで読んでも同じような動きになるというか そういうのとかは結構データと操作が一致して これは今ユーザーデフォルトの話に入っちゃったんですけど 型のプロパティを書き換えるみたいな操作もそうだと思うんですけど 直接インスタンス化して何とかドットで 直接代入するとかも一応できはすると思うんですけど それを至る所でやっちゃうとやりたいことというか ちゃんとメソッドを通じて振る舞いが統一されるような形で 書けないみたいなのとかは いわゆるオブジェクト思考っぽい考え方とかで 考えた方が綺麗に書けるみたいなところとかは 昔のコードとか見てると多分僕はやってるはず 気づいたら変わったみたいな ここで何か変わってるんだけどみたいな そういうのがあったりとか あとはやっぱ責務が大きくなるみたいなのが結構あるかなと思ってて これちょっと具体的にいい例が言えるか分からないけど 例えばあるデータを外部との通信をしていて その通信をどっかログを吐きたいですみたいな感じになった時に 何とかログのサービスのユーティルみたいなのがあって そこにメソッドがバーっとたくさん生えていくみたいな 例えばAっていう外部通信で外部とのサービスのやり取りの中で こういう形式でログを吐きたいみたいなやつが いくつか増えていくと めちゃめちゃたくさんメソッドが増えていくみたいな現象とか あったりとかすると思うんですけど それって多分ログ何とかユーティルズみたいなやつが 多分責務が多くなってしまう 本来ログのサービスだったらログを送ることだけ 一定のフォーマットを受け取ってログを送るだけでいいはずなのに どういう風な形式で送りたいかっていうのは 送る側の都合が入り込んでしまうボードとかって 結構見てると普通にあるなみたいな感じだったりとかするんで でもやりたいこととしては どこどこから出てくるデータをログとして吐きたいですみたいな やりたいことベースとしては合ってるし ログを書き込むんだから ログを書きそうなところ ログのサービスの型のところで定義すべきなんじゃないかなみたいなのは 第一感というか こういうオブジェクト思考みたいなのに慣れてないと そうなったりとかするのかなみたいなところとかも 理解できるなみたいなところがあったりするんで そういうのとか その辺の基盤的なところになるとむずいっちゃむずいところは いやむずいっすね どれくらい抽象的に作れるか そうそう むずかしいなと思って 僕もざっくりと理屈としてはそういうことなんだろうなと思いつつ 最初からその設計が自力で全部パッと思い浮かぶかって言われたら そこまでではないなというか もうちょっとふわっとしたものだったんですけど 最近とかだと結構AIがあるから AIが出した行動に対して いやこれなんかちょっと違うなみたいな 物を見せられたときに 正しいか正しくないかは何となく判断はやりやすいのかなと思うんで いきなりそういう 自分で答えはいきなり出さなきゃいけないっていうほどのレベルじゃなかったとしても 最近はベースとなる考え方をある程度理解した上で AIと色々やり取りする中で行動はきれいにするみたいなのは 結構できそうだなって感覚はあって その辺の話をするとすごく長く話せそうな気がしてて いいですね 一旦次 はい行きますか # チャプター 2 はい、じゃあ なんかお話が それで言うとみたいな それで言うとみたいなのがあるっぽいんで その最後の話は モデリングみたいな話だと思うんですけど まさにその辺めちゃくちゃ最近やってて そうなんですか めっちゃやってますね 既存の概念の捉え直しみたいなことをやってて ですかね リプレイスみたいな 綺麗にしている やってて すごい面白いですね 面白いです 確かにこの概念をどう捉えるかっていうのが なんか本当になんかこう めちゃくちゃ大事だなって感じ 単になんかこうコーディングのスキルというか テクニックとしてどうこうっていうのもあると ある程度あるとは思うんですけど なんかそれ以上にその概念をしっかり整理して なんか何ですか凝縮度の高いという ちょっと曖昧な言葉を使ってしまうんですけど 凝縮度ですね あそこ凝縮度 早くシュクって言っちゃった そうですねなんかまあ なんかこう 無駄がないけど なんか必要なものがちゃんと表現されている みたいなところとか なんかその 概念と概念の関係性とかを正しく捉えるみたいな なんか最終そこができないと なんかどんなに頑張っても 綺麗に書けないんだろうなみたいな そうですね いやまじで最近は捉え方ってめっちゃ大事だな っていうのを 別のコードをレビューするときとかも思うんですけど なんか単一の観点から見るとやっぱダメだな っていうのは最近はすごい思います その表面的に捉えるというか なんか 例えばなんか新しい機能を作りますってなって これはこういうことができればいい機能だ だけで捉えちゃうと 多分大体間違ったものができると思ってて そうですよね それのなんか必要なものはなんだとか 一個一個これはなんだみたいなのをちゃんと考えていって とかなんか 何だろうな 今出てないけどこういうパターン 今は要件が出てきてないけど こういうパターンもありえるよねってなったときに この概念はそれで正しいのかみたいなことを考えるとか そういうのを考えるとすごい ちょっと最初は時間かかっちゃうんですけど まあ楽しいですね あとなんか 最近はその辺のモデルさえ作れちゃえば あとはもう勝手に絵を描いてくれるなって 一応してるとかできてると思うんで だからなんか人間がというか 今はそこを時間かけて図にさえ起こしちゃえば あとはなんとかなるかみたいな気持ちでやってますね 確かになんか何のときだったか忘れましたけど なんかそう マスさんが図を描いてるのをスラックに貼ってるのを見た覚えがあって こういうのやっぱ書くんだって思いました やっぱ多分あれを書くことによって なんかその多分プログラムを書く下地みたいなのを 多分整えてるんで 実質多分なんか自然言語だったりとか図とかで プログラミング的な何かをやってるのには ほぼ相当するのかなと思うんです なんか僕は人によると思うんですけど 僕は書きながら整理できるタイプなんで 書きながらなんか あれこれはなんだみたいなこととかもよく思いついてくるんで 書いて整理するみたいなのを結構やってますね あとはなんかこう図が描けたら 結構割と実装のイメージとかって湧くじゃないですか そうですよね あとは実装するだけみたいな感じなんで 確かにあれを書くまでが多分大変というか なんかあれができてないと ちょっと分かってるのか分かってないのかが ちょっと不安になるような感覚はあると思うんで 確かにあれぐらいちゃんと整理したれていれば なんかまぁあとは書くだけだし 関係性も全体像も多分見えてる状態で なんかこうコードを書くっていうところに あとはフォーカスできるんで そうですね 割とこの辺の力は以前よりかはだいぶ 話する気もするんですけど めっちゃついてきてる気がしますね いやぁいいですね なんかそのモデリングちゃんとやるみたいなのを いつかやりたいです いやまぁやってもらってもいいんですよ 既存コードを直してもらっても 確かにそれでいうとまぁそうですよね 確かにできますよね なんか僕もなんかだから 最近はなんかこう リファクタリングとかをたまにするというか 別にしたいと思ってやってるっていうよりかは たまたま自分が触ろうと思ったところを眺めてたら 直したくなってしまう気持ちになって やるみたいな感じののがあるんですけど その時もそこまで多分 難しいことをやってるわけではないんですけど 概念の捉え直しというか 型の切り出し方とかも全部変えたりとかする みたいなところとかは結構なんか 割と時間かかってるなっていうか 多分動くものを作るだけだったら あと秒で終わるんですけど 何も考えない 目をつくってしまえば多分終わるんですけど AIあるし特に そうですよね なんですけどなんかちゃんとあるべきに 今のコードの状態でなるべく労力をかけずに あるべきに近づけるっていうことを考えると 意外となんかやっぱり AIに丸投げするのは結構難しいな みたいなところはあったりして どの程度まで直してほしいのかとか 結構伝えたりとかしないといけなかったりとか 結構なんかやっぱり既存のコードに 引っ張られて書くというか 既存のコードありきで書かれることが 結構多いなと思うんで ここはこうじゃないとかっていうのを 延々とやり取りしていて 多分そこがなんか多分 もっとちゃんとゴールが 自分の中で描けてたら なんかもう直接それを伝えれば なんかもっとうまく 早くラリーを減らして 生成できるのかなと思いつつ そこはちょっとまだ苦手だなみたいな あとあれだと思うんですけど モデリングの素晴らしいところは なんか適当に書くっていうと 普通に書くだけ 何もあんま考えずに実装するだけだと 要件通りのものを作るのって そんな難しくないじゃないですか だけど要件外のところっていうか 例外的なところとかを どれくらいちゃんと考えられてるか みたいなのも モデリングの段階で結構 大事というか見えてくるなと思って このパターンのときはどうなるのかみたいな 考えるときに出てきて それがやっぱないと いざそれが発生したときに 結構ツギハギのコードの修正になっちゃう まあ確かに みたいなのも その辺の例外的なこととか こういうときはどうなんだ みたいなこととか 考えるとか あとはなんかさっきも言ったんですけど 要件が増えたときとかにも ちゃんとこれ対応できる概念になってるんだっけ みたいなこととか 深井・ヤンヤン 確かに そこら辺は結構難しいですよね 今作らなきゃいけないものを作るのは もう分かってる情報で作るから そんなに大変とは思わないですけど 今後どうなるっていうところも めちゃめちゃ頑張って作り込みすぎても いらないものを それこそ作ってしまったり っていうのもあると思うんですけど 概念をちゃんと独立して 独立してっていうか 考えられてたら いらないものがあんまりないと思うんですよね だからその概念として出てくるんだから それは何か起こり得るよね みたいなイメージ 深井・ヤンヤン そうですね 深井・ヤンヤン 確かに 深井・ヤンヤン みたいなのが 最近はすごいその辺を考えながらやってます 深井・ヤンヤン なるほど でも本当に最近僕が読んだ本 これちょっと前の放送か何かで 多分話したやつなんですけど にも同じような話が出てきて 最初やっぱりモデリングの話とか 絶対出てくるみたいな感じなんで 最初の方はコードをどう書くべきか みたいなところで 何だろう いろいろ多分あると思うんですけど 命名を分かりやすくしましょうよとか っていう話とかも 結局命名が分かりやすいかどうか ってちゃんとモデリングできてるかとか 結構密接に伺ってくるのかなと 曖昧な名前つけちゃうと 曖昧なモデルができて 曖昧なモデルにどんどん機能が足されていって よく分かんない何かになるんで 本当にそう ヤンヤン 本当にそう 深井・ヤンヤン だからなんかそう モデリングとか命名とかって まあなんか モデリングは別にあれかもしれないですけど 命名とかも正直 何でもいいやんっていう気持ちも ちょっと半分ありつつ でもなんかそこの名前もやっぱ こだわらないかなみたいなところの なんか曖昧というか なんかそういうのがやっぱ感じるんで ヤンヤン 僕はもうめちゃくちゃ 名前にこだわってほしいですね 深井 そうですよね ヤンヤン いやもうあれが全てぐらいだと思うんですけどね 深井 いやなんか難しいなっていうか 命名はなんか 終わりがないから これでいいかなっていう最終 なんかちょっとよく分かんない着地点に 行くこともあるんですけど ヤンヤン なんか逆にそれって もしかしたらメソッドの役割が ちょっと違うんじゃないかとか そういう気づくポイントとかにもなったりしそう なんかしっくりこないとか なんか変数名に&が出てくるぞとか 深井 確かに メソッド名めちゃめちゃ長い時とかって 何かが違うんですよね ヤンヤン 変数名&が出てきた ってことはなんか 二つ役割が一個に混ざっちゃってるんじゃないかとか 考えるきっかけにはなりますよね 深井 そうですね 割とこだわる意識でいた方が いいことは多いなって ヤンヤン あとやっぱ後から見た時に なんだこれっていうのが 引っかかりがあるのが僕はすごい嫌いなんで 深井 めっちゃ分かります ヤンヤン だから今はもうめちゃくちゃ名前にこだわってますね 深井 なるほど ヤンヤン って言っても基本的には AIが生成するんで その中でも なんだこれみたいなの突っ込むだけぐらいな感じなんで 勝手に直してくれるんですけど 深井 確かに # チャプター 3 最後にちょっと今の話で思い出したのが、めいめいのところAIのめいめい結構厳しくないですか?って あーそれはありますね。厳しいってなるときありますね。 いやそうこれなんか今自分が実装しているときに見せられてもなんかよくわかんないめいめいだったりとか あとコメント修正とかが結構手間がかかる。 日本語がなんか変な直訳になっていて、なんかあんまりこう読んだ時に何のことを言ってるのかがパッとわからない日本語が結構バーッと書かれることが多くなって そこはもうなんか自分で何やってるんだろうなーっていうなんかその 言葉直しみたいな作業をしてるんでなんかちょっと何やってんだろうなって気持ちになるんでなんかちょっとあんまり なんかコート書いてるときに比べるとちょっと複雑な気持ちなんですけど 変数、でも割と最近変数はそんなすっごいうってなることはあんまりないなー 変数はまあそうですね どっちかっていうと、たまになんか雑いめいめいしてくるときあるんで それだけなんかしっかりするようなことはこれやめろみたいな話があるんですけど コメントはめっちゃありますね。なんかまず日本語が変っていうのと あ、まずなんか文の構成として変っていうのがあるのと あと言葉のチョイスが変っていうのとか あとは、あのなんか当たり前のことをコメントしてくるのが一番うざいですね 確かに いやそれも見たらわかるやん それを書き始めたらコメントだらけでもうなんかすごい料理になっちゃうけどみたいなやつも そうなんですよね その辺割と難しいですね なんか塩梅をいい感じになんか調整するのが難しいなって思いますね 確かになんかそれを頑張らないと エンジニアが頑張らなきゃいけないんだっけっていうか まあエンジニアというか使う側が頑張らなきゃいけないんだっけっていう気持ちにもなるんで なんかいやそこはモデルがちょっと賢くなって 確かにやってくれよっていう気持ちもあるんで なんかちょっと自分もあんまりそこをなんか力入れて なんかこう直そうとかっていう感じではない 直そうというかまあそのなんかこうハーネス組んだりとかはしちゃえば思ってないですけど いやでもなんか 生成したコード見てこれ消してこれ消してとか言うのマジで不毛だなって めっちゃ発表 あのこのコメントいらないから消して消してって言って 入れまくってますね 最近はもういちいち消してってめんどくさいんで バーってワンファイル見てファイル名指定して 変なコメントだけ全部ペッて貼って消して まとめて一貫 それでもちゃんと消してくれるんで 変な消え方もしてないしまあこれでいいやみたいな いやまあそうですね確かに一回一回やるのが結構手間っちゃ手間ですからね マジでこれだけなんとかしたいなって気持ちは いやそうですね まあでもなんかいい感じにプロンプト調整できそうな気はするけど でもなんか今度指示したら欲しいコメントまでなくなってるみたいなのも全然ありそうだな いやそうですね なんかどう書くかとかも やっぱ日本語がそもそもなんか読みづらいみたいなのもあったりすると思いますし 確かに なんかコメントの業務長いですよね 長い バカみたいなのが出てきますよたまに マジかこいつ なんか平気で3行超えてくるともうなんかだんだんちょっと いやそれは無理だろうみたいな いや慣れますよね 1回すっごい生成されて 10何行以上コメントが出てきて すごいですね おい後で直そうこれ と思って1回回ししてみたいな いやそうなんかとりあえずまあ中身確認したいから とりあえずパパンと見てみたいな感じにはしますけど ちょっとやっぱあれを読む立場になった時に やっぱ人間にはきついですよね 消すタイミングが最近ちょっとムズイのかなと思ってきてて なんかAIに指示出して 例えばこのなんか ジラのストーリー完結させていただいた時に そのプルリクをちゃんと分けて出していただいてるんで こまめに出してくれるんですよね これがこのすごい長いコメントあるんですけど そのコメントが次のプルリクの作業用のコメントなのかなみたいな あるんでだからなんかそこのなんだろう 最初のプルリクでは長いのを最近許容してます まあ後で見て直せばいいかみたいなところもあるから 例えばデータベースと繋がるところとかを作っていく時に 作ってるプルリクの中でも消えてなかったら消すみたいな なるほどそういうのもあるんだろうなみたいな なんか僕は分けるときは 後続のプルリクで作業するときは それはちゃんとToDoで書かせて それ以外は普通のコメントにしてるから っていうので毎回リチギリ見てます でなんかこれ確かに後で自分もここ触るんだってことを ちゃんと把握しておいたりとか あとレビュアーとかに分かるようにしておいた方がいいなと思ったときは なんかToDoでこの後の後続でこういう修正をしますみたいなのを 簡単に書くみたいなのとかはなんかやるかなっていう感じですけど そこらへんもなんかこだわりがしたら切りないんですけど 不毛だなと気持ちもありますけど そんな感じですかね ありがとうございます 次はどの声と繋がりますか 引き続きボイスでお楽しみください