読みやすいコードとはという話をしましょうがリーダブルコードですかリーダブルコードリーダブルコードに書いているような話をするのかもしれませんがリーダブルコードとはまた多分別の切り口かもしれないしそうじゃないかもしれないOKです近々話していたグッドコードバッドコード持続可能な開発のためのソフトウェアエンジニア的思考という本から順平が一番気になってそうだった

読みやすいコードを書くためのテクニック抽象化レイヤーの話をします具体的になってくる感じですかね以前話したインターフェースとか抽象クラスのあの辺ですかああもうまさしくまさしくまさしく別の角度からそういう話をすることによってよりああこういうことかみたいなねそういうのを

整理することができると良いなというエピソードになりますこれを聞いた後はすごい綺麗なコード書けるようになるんだねじゅんぺい君はその通りですなるということでじゅんぺいの同僚が聞いててじゅんぺいが汚いコード書いてたらこの野郎と言ってやってくださいわかりましたやってみせましょう抽象化レイヤーって何ぞやっていうところもあるんですけど

そうですね抽象化レイヤーってワードを聞いてじゅんぺん何のことかなって思います?思いますなんて思います?思います?イエスかノー抽象化レイヤーと聞いて具体的なことは書いてないそうすごいなそのまま言ったねコード的な話なんだコード的な話で言うとなんだと思う

それこそさっきのりさんが言っちゃってましたけどアブストラクトクラスとかで中身がまだ実装されてないというかオーバーあれどっちでしたっけオーバーライド違うなそういうやつってことねどっちだっけオーバーロードとオーバーライド多分オーバーライドの方が近いこれの方が近い

そういうまだ中身をメソッドを実装していく前の段階というか近からず遠からずという感じなんですがこの書籍で言っている抽象化レイヤーっていうのはそういうのも含め中身が入ってたとしても関数とかクラスとかって結局大元がいて具体的な作業をしてくれるメソッドにどんどん枝分かれしていって

端っこではめっちゃ細かいことやってて中間層ではそれを抽象化したことをやってるみたいな作りのプログラムになると思うんですけどその真ん中のやつら何かを抽象化してくれてるメソッドないしクラスとかとかを抽象化レイヤーと指してますそのうまく抽象化できることによって分かりやすいコードに

していけますよねっていうところが今日のお話なるほど割とあれですかもしかしたら人によって個人差あるっていうような感じになりますどういうことどういうこと何が抽象化の仕方が抽象化されててもいやこれは抽象化レイヤーに入らないぐらいの抽象化なんじゃないかみたいなとかってあります結構なんか曖昧そうな気がしたんですけどどんどんメソッドが細かくなっていってその

中小化レイヤーとそうじゃないとこの切れ目っていうのは結構個人差によっちゃいそうだなと思ったんですけどどうなんでしょうそうじゃないと思ってます僕ははっきりなぜならメソッドとかクラスっていろんな処理が書いてあるけど結局これらの名前ってこれって定義するじゃないですかあーはい

結局これらの名前ってこれって定義していることって抽象化なんですよねはいはいはいじゃないですかメソッド作るのも抽象化ってことですよねそうそうそうそうこういう手続きを組み合わせたらざっくり言うと入金になるよねみたいなそうそうそうそう入金ってお金を入れるよねはいはいはいっていう

のがありますねこの本の中で確かになと思ってツイッターでもツイートしたんですけどコードを書くこととは複雑な問題をより小さな問題に切り分け続けることだとうん確かにと最終的には一行になるからねそうそうそう入金しようって思ったらその入金するためには何のクラスがいるんだろうみたいなね小さな問題に切り分けていくとうんうん

ユーザーの端末で動くサーバーにメッセージを送るコードを書こうと思うと想像してくださいコードユーザーのクライアント端末というかクライアントからサーバーに対してメッセージを送るソースコードを想像してくださいソースの書き方とか言語によるかもしれないんですけど多分コネクションを準備する一行コネクション

ドットセンドメッセージコネクションクローズみたいな感じで3行で書けると思うんですよ最近の言語とかだとでもこれって抽象化されてるんですよコネクション貼ってコネクションにメッセージ送ってコネクションを閉じるってかなり抽象化されててまず文字列

センドで送ってますけど例えばハローサーバーみたいなメッセージを送ってたとしてそのメッセージの文字列ってそのまま送れなくて送信可能なフォーマットに変換しないといけないとパケットってやつですかあとHTTPプロトコルで送ると思うんですけどHTTPプロトコルっていろいろやることあるんですよね内部では

その辺も抽象化されてくるから書かなくていいしTCP通信だからシンアックみたいなね3wayハンドシェイク通信できるかどうかチェックしてOKって言ったらハンドシェイク握手みたいな

全然わからなくてもできるやんこれはうまいこと抽象カレイヤーを先人たちが気づいてくれたおかげで我々は読みやすいコードが書けると抽象のミルフィーユってことですかミルフィーユですね今現在のプログラミング開発プログラミング開発はそうですねはいヒコマロさんみたいなでしょプログラミング界のヒコマロだから

ノリマロさんって呼んで全部ビュッフェで例えますからねヒコマルみたいなもんですね玉手箱が我々でいうビュッフェなんですねワンパターンっていうのでこれが抽象化レイヤーだというのはまずなんとなく分かっていただけたかなと思います次に

コードをわかりやすく書くために抽象化レイヤーをどうやって活用していこうかというようなお話をさせてください前回グッドコードバッドコードの話をしたときにコードの品質高品質ってなんだっけっていうところをお話ししました今回ちょっとこの話が結構ポイントになってくるのでもう一回はちょっとおさらいしておきますお願いしますまだ聞いてないんでですよねコード品質の柱

柱1コードを読みやすくする2想定外の事態をなくすこれは驚き最小の原則的な話ですね3誤用しにくいコードを書く4コードをモジュール化する5コードを再利用汎用化しやすくする6テストしやすいコードを書き適切にテストするこんななんか

まあまあありましたけどよく聞くような話がポイントとしてありました確かに今回の抽象化レイヤーをうまく使うことによってこの中の4つに大きく関わる

この中の4つを改善できると言えますなるほどね1つ目読みやすさそれはそうだとうまいこと抽象化して読んで字のごとしみたいなメソッドを作れたらそれは読みやすいと読みやすいってことはモジュール性もいいとモジュール化もしやすいというか抽象化レイヤーを適切な流度に

ちゃんと分割してると余計なことしないそれだけやってほしいモジュール化できてモジュール化もしやすくなりますなるほどねそうすると再利用がしやすくなるとその通り再利用性と汎用化も良くなりますそうするとモジュール化がちゃんとしてるってことはテストアビリティも高いテストしやすい

なるほどねちゃんと分割されてるからテストがしやすくなるとそうですなのでこの抽象化レイヤーっていうのは非常に高品質なコードを作る上ではめちゃくちゃ大事だと言えますちなみにこのレイヤーっていうのはレイヤードアーキテクチャの中に一個層挟むとかそういう意味ではないではないなるほどではないレイヤードアーキテクチャの話はもう忘れてください忘れましたプログラミング全般のあの

関数とかクラスとかその辺全部ひっくるめてですなるほどあんだけ言ってたので具体的な話をしていきます関数クラスって言ってましたけどこの本には関数とクラスとあとインターフェースの話が書いてました時間がないので今日は関数とクラスの話をしますよく使うかなと思ってインターフェースの話にはざっくり言うとファクトリーメソッドパターンみたいな話が書いてましたけど割愛します

気になる人は読んでくださいじゃあ最初メソッド関数ですね関数の抽象化レイヤーについて意識することをつらつら話していきます普段できてるかなというのを自分に問いかけながら聞いてみてください小さくすることその通り合ってる

ちょっとその前に1個話をさせてください関数を作るときに意識すべきざっくりポイントで言うと今API作ってるわという気持ちを持つのが大事ですどういうことかというとですねWeb API作ったことありますか?NUNどっち?びっくりした何回ってきたかと思ったYESのNUN変わってますね

ウェブAPI作るときって誰かに呼び出されるのを想定してインプットがこれでアウトプットがこれですっていう感じで設計して作るじゃないですか関数も同じことが言えるんですよねインプットがこれでこれを返す関数だとそうすると自然にできることがあっていい感じの名前をつけるのはしやすくなると思うんですよインプットがこうでアウトプットがこうだってのが明確になってるとユーザーの

初期パスワードを発行する初期パスワード文字列を返すメソッドだと思ったらクリエイトイニシャルパスワードとかパスワードを作るだけですか文字列を作るだけパスワードって言わなくていいのかなランダム文字列を何文字のランダム文字列を生成するメソッドなのかもしれないですけどねまあとかとかまあまあまあまあっていうのができるようになるわけですよそういうインプットアウトプット意識するとそれめっちゃ大事っていうのを

大前提大前提で小さいことを考えていくと森さんがさっき言ってた小さく作るこれはめっちゃ大事単一責任じゃないですけど1メソッド1個のことしかするなとこれが読みやすいコードの近道です次にその関数で守るべきことを聞いた上でとある関数をちょっと

音声で提供してみますプログラムのコードをとんでもないチャレンジですこれはプログラミングコードを聞いて理解して超短くないとえーっとですね25行くらいありますね長っ25行僕がそれをうまく抽象化して伝えますOKです抽象化レイヤーがここにあった多くのことをやりすぎている関数の話をしますバッドパターンですねまずバッドパターン

そうですね悪い関数って長くて何やってるか分かんないよってなるじゃないですか読んでてそうなるじゃないですかつまりコードに書いてることそのまま読んでも長くて何やってるか分かんないよって思うはずなんですよそのコーディングのリファクタリングのやり方としてもありますよねコードに一つのメソッドに書いてあるものを音読してみて何言ってるか分かんないわってなったらそれはリファクタリングのポイントがあるっていう

コードスメルですかコードスメルコードの匂いっていうのでそういうやり方もあるので今コードでやってることを音読してみます多分何言ってるか分かりませんが分かっちゃったらごめんな分かっちゃったらごめんなさいじゃあいきますよどういうメソッドかは言っていいかな乗り物がスクラップされてるか

確認してそうでないならスクラップされてるならオーナーアドレスにスクラップヤード廃棄場のアドレスを入れるもうすでに多いもんねそうじゃないスクラップされてない場合は

直近で購入した日付車を購入した日付を見て買われてなかったら車の販売場所のアドレス住所買われてたら購入者の住所を入れる購入者の住所がヌルだったらヌルを返すでこれらの処理が全部終わってたら車の持ち主宛に手紙を送るこれはあの

何言ってるかわからんとわかっちゃいました?わかっちゃいましたギリわかってきたわかっちゃったか日本語でやっぱ来てるんで確かにプログラミングゲーム語もそんぐらいになるさいずれでもちょっと条件複雑すぎるなとは思いましたいいですねその観点

その観点なんですよ入れ子でif文書いてました入れ子でif文書いてましたelseの中にif文がありましたこれはねすごいのりさんやっぱすごいですねプログラミングも頭の中で走ってたもう頭の中で走ってました最初ずっとメソッド名がこれなのかなと思いながら聞いてたんですけどあのマジでおっしゃる通りでif elseのelseの中にif elseがあってでそのif else最初の上段のif elseを突破した最後にif文があってうん

ガード説とかないですよね一番下にガード説であるべきものがあるみたいなプログラミングコードだったんですけどこれは長くてダメですと小さく作って単一のタスクを行うように作らなきゃダメだというのでじゃあちょっと小さくしてみたプログラムをまた喋ってみますねまず最初車の持ち主のアドレスを取得します

持ち主のアドレスがヌルだったらヌルを返します持ち主のアドレスが入ってたら持ち主のアドレスに手紙を送ります持ち主のアドレスを取得する部分は別の関数に切り出してますなので最初に言った3つアドレスを取得アドレスがヌルだったらヌルを返すそうじゃなかったら持ち主の住所に手紙を送るこれだけなんかいろいろなくなってないですかえっとですね

さっき言ってた乗り物がスクラップされてるかどうかを確認してスクラップされてたらオーナーアドレスにスクラップヤード廃棄場のアドレスを入れるとかスクラップされてなかった場合に直近で購入した日付を見て買われてなかったら車販売場の住所買われてたら購入者の住所を入れるってつらつら言いましたけどこれって要するに

車の持ち主の住所を取得するっていう処理なんですよね車の持ち主は3パターンでプヤードか持ち主か車の販売店そのロジックがこの手紙を送るっていうメソッドに入ってたことによってそっちが主役みたいになってたんですけどなるほどね

それは別のことだとなるほど要するに住所を取得するだけっていう風に抽象化するとやりたかったのは住所を取得して手紙を送ることだねっていうのが分かりやすくなるよねっていうのがなるほど手紙を送る実際のメソッドのところでどこに送るかの条件分岐を含ませておけばいいとそうですそうですそうですそうです

しゅんぺいくんが置いてかれてますわかってますわかってますわかってると思います言ってみて言ってみて一番大事なのは住所を取得して手紙を送ることなんですけどその住所を送る住所を取得するのに3種類ぐらいの条件分岐があるんですよねあって

手紙を送るのは購入者だけなのでそこだけで一個作っちゃって他の残り二つもまた別々で作ればいいっていう話なんですかねちょっと違うちょっとわからなかったなんかちょっと違ったかもしれない手紙はどこも送るんですよね結局手紙はスクラップ場にもお店にも送ってるそうだねヌヌじゃなかったら送る

はいなるほどそしたら3カ所3カ所くらい俺的にはメソッド作ってそれぞれそれぞれの場所の住所を取得して手紙を送るっていうのに切り分けるえっと手紙を送るメソッドの引数に住所を入れればよくないそれでそう言ってたってこと言ってないよね言ってなかったですそうそうそうそうなりますねメソッド3つではなくメソッド3つではなくはい

そうですね抽象されたわけだ今までここに送るメソッドとここに送るメソッドとここに送るメソッドってのがあったけど送るメソッドになったわけだそうですねでも送るメソッドは最初からありましたすいませんただこれはちょっと分かりづらいんでしょうがないですここでもう一個伝えたいことがさっき言ってたオーナーアドレスを取得するメソッドが外に切り出されましたと

一緒に手紙送る一つの関数の中に全部ひっくるめられたのが住所を判定する住所を探す外だけ切り分けられて別にいますとこうするといいことがあるんですよのりさんは言わないでくださいじゅんぺいこの関数を外に出すことによってコードの品質が上がるんですよそれは何でしょうか最初に言ってたことを思い出して

切り分けることによって何ができるようになる4つとも良さげな気がしますけど1番はテストを書きやすくなるそれもあるけどそれも1個いいよ2つ目読みやすくなるその通り3つ目汎用的になるなんで必要な時にそれだけ呼び出して

知って利用できる無駄な例えば例えば例えば例えば手紙を送るじゃないパターンの時にそこの住所の人に何かしたい時にそのメソッドを持ってきて呼び出して住所を取得するだけっていう処理をかけ素晴らしいそれを言ってほしかったそうなんですよ今までの作りだと

こういう作りになってしまっていると他の例えばお手紙を送るんじゃなくて他に何があるかなお中元送るじゃあお中元送る

お中元送るメソッドがあったとしてその住所の判定をまたお中元送るメソッドの中で書かなきゃいけなかったんですよそれがリファクタリング後に外部に切り出されることによってその住所を見つけ出すメソッドを再利用できる再利用性が上がる後で作る人も楽になるっていうそんないいことがあるよっていうなるほど

順平言ってくれたやつも全部メリットとしては反映される気はするけどね読みやすくなるしテスタビリティも高くなりますね場合分けが減るんですよね手紙のメソッドの中であともう一個なんだっけモジュール化されてますもんねなのでこれらのポイントを抽象化によって正しい抽象化によって品質上がるわなんとなく体験できたかなと思います以上が関数の話です関数

続いてクラスの話ですクラスですがクラスの理想的な大きさって知ってますか何行とか何行とかっていう話どうぞ300え?え?ってやり合わないでください2人で顔見合わせて38行この本では一般的にっていう書き方はされてたんですけど300行以内って言われてるらしいです

順平くんドンピシャですドンピシャじゃんまあでもこれあくまで行数が目安なんですけど他にもなんか行集度とかね関心の分離とかっていうのがあるらしいんですが行集度は聞いたことありますか関係あるものがどれだけちゃんとまとまってるかという指標ですそういう指標指標なんですかよくあるのだと工業種の素結合って言いますよねインコードってそう

素結合はモジュールとモジュール同士があんまり依存してないこと要はだからAのモジュール変更した時にBもA変わっちゃったから変えなきゃっていうのは良くないですよとそれで影響出にくいのが素結合工業集っていうのはそのAのモジュールの中に関係あるものがちゃんと集まってるかどうかみたいな

本当はAのモジュール1個でまとめれるのにそれがAとA'で分かれてたりするとちょっと凝集度低いよねみたいな感じですねもう1個何か出したっけ関心の分離関心を分離することですもう1回言いますかそこじゃないです何に対する関心

の話ですかまあ分かりやすいかどうかはさておき特にフロントとかでよく使われているのは見た目とビジネスロジックをちゃんと分離させようみたいなのとかはよく考えて作られてますねあとはあれじゃないですかMVCとかも要はそうじゃないですかうん

MVCモデルのフレームワークありますよねあれってモデルにビジネスロジック集めてコントローラーにアプリケーションロジック集めてビューに見た目のロジック集めてるわけじゃないですかああいう風に関心ごとごとに分離してるよねみたいななるほど関心の分離と言うんですね言いますねありがとうございますこの関心の分離はむずいどこが何の関心ってなる

それこそ個人差ありそうな気がしましたけどでもそういうのがあるんですねありがとうございますその辺の行数とか行集度とか関心の分離っていうのがクラスの大きさとか分け方として重要なポイントになると言われておりましたで

クラスについてもさっきの関数と同じで読みやすくてモジュール化しやすくて再利用性があってテストしやすいというのが非常に重要だと言えますここでさっきと同じ流れででけえクラスを見ましょうでけえクラスを見ていきますでけえクラスを見ていくんですがでけえクラスは結構でけえんじゃないか

でけえクラスを頑張って説明しますやばいね関数の日じゃないまずクラス名テキストサマライザークラスというテキストサマライザー文章をようやくしそうなクラスになってます文章をサマライズする伝えれるかわかりませんがでかいクラスを文章で伝えていきます関数よりは300行超えってことですか300行は超えてないんですが

今回伝えたいのってでけえクラスだと不便で適切なクラスだと便利そうだなっていうのを伝えたいんですよそれを音声で伝えれるかはチャレンジですチャレンジですはいいきますそんなに難しくないですクラスはまずテキストサマライザークラスは一つのメンバーがありますメンバーサマライズテキストですね

サマライズテキストは引数にテキストを入れて文章を段落に分割して文章の文字列の重要度のスコアを計算するっていう流れを踏んでいくようなものになってますメンバーファンクションですかメンバーファンクション文章を段落に分割するステップ2の文章を段落に分割するっていうところでは段落の最初を見つけるのと段落の最後を見つけるっていう

2つのメソッドを使いながら1つの段落を判定してどんどん配列に入れていくっていうようなものになっています文章の文字列の重要度のスカーを計算するという最後のステップ3のものについてはそれらのプライベートメソッドで重要な名詞動詞形容詞をそれぞれ見つけたりとかそれぞれの重要度のスカーをつけるっていうようなメソッドがついていますなるほど形態素解析ってやつですか

具体的なコードは書いてないんですよてんてんてんてんてんてんてんてんてんてんてんまあでも複雑なロジックみたいな書き方されてますなるほどね確かにむずそうこれって一つのことをやってるクラスでしょうか一つのことを一つの複数やってるんですかねえ

僕は多分仕事でやっててクラスは一つのことしかやっちゃいけないなって思いながら仕事をしていてこれを作ったりこれを見たりして一つのことやってるなって思っちゃいますでもこれは人によっては一つの文章を要約する作業しかしてないと言えるかもしれないという抽象化をできてしまうかもしれないかもしれませんけどパースとスコアリングを両方やってるかもしれないとも言えるかもしれないそうなんですよ

この単一に分けるってめちゃくちゃ難しくてその勘どころがなんとなく分かるようになると良いなという話をします全エンジニアが悩んでる声が聞こえるエンジニアの声が聞こえるその能力は結構強いぞどこにでも求められるまず

このクラスいけてないところをつらつら並べていきますねこのクラス見たときに文章から段落への分割とか重要な名詞とか形容詞とかの抽出とか重要度のスコア計算とかよくわからないことがいっぱい入っててクラス全体としてサマライズしてるのかもしれないけど中身を理解するのはちょっとカロリーいりそうだなって思ってたし

あとはどういう時に何が呼び出されるかが分かりづらいような書き方がされてて今ちょっと音声で僕が整理しながら伝えたからあんまり分かんなかったかもしれないですけど急に段落の最後を見つけるっていうメソッドだけポンってあった時に書いてあるわけなんですけどこれ何から呼び出されるのかっていうのは多分読んでて分かりづらい確かにそれがプライベートメソッドで一個だけポツンってあるわけですよねそうそうそうそうこれはなんかちょっと良くないよねってこの本では言ってますねうんうんうん

あとは2つ目コードがそんなにモジュール化されてない例えばですよ新しい重要度のスコア計算の仕組みを入れたいなと思ったとき機械学習とかにしましょうか機械学習ベースで重要度のスコア計算を入れるような仕組みを入れたいなと思ったときに今ちょっとそこだけ入れ替えれるような作りになってないよねって言ってますクラス内に

文章の重要度を判定するメソッドがそのままバコーンって入ってるんですけどそれを外に出しとけばそこだけ入れ替える作りにもできるよねって言ってましたクラスの中に含めればいいんじゃないかってそういうわけではない?いやいいえじゃあそれが2つ目3つ目再利用性低いよねっていうのでさっきじゅんぺん感想でやった話にちょっと似てるんですけど他の人が

文章中にどんだけ段落があるか数える機能が欲しいなと他の何かで思ったときにそれを再利用できないと今プライベートメソッドになっているのでそれが再利用しづらいよねっていうことを書いてましたすいませんさっき文章を段落に分割するのプライベートメソッドですって言い忘れてましたねすいません言い忘れてたんですけど基本的にプライベートメソッドですこのクラスの中のメソッドは全部はい

なので他の人が利用しづらいような形になってるねっていうのが悪いクラスの例として言ってましたなるほどプライベートメソッドなのも見抜いてたんですねはいっていうのでこれをどうやって解決しましょうかというので依存性を注入しましょうというのはディペンデンシーインジェクションですかすごいどんどんワード入れるとどんどん出てくる依存性注入ですね

小さな問題を解決するためにそれぞれの分離されたクラスはテキストサマライザークラスのコンストラクターにパラメータとして渡しましょうというのがあって依存性注入というのは僕もそんなにオブジェクト思考詳しくないのでまた外れだったら修正してほしいんですけど他のクラスなのかな他のクラスを利用する手続きみたいなものですよね

ですさっき言ってた段落探すやつとか文章の中の重要なやつを見つけるやつらを別のクラスにしちゃってその別のクラスの段落分けるやつと文章の重要度を見つけるやつをテキストサマライザーで呼び出して使うようにするとよりモジュール性が上がるというのが依存性チューニングをするというところで言ってたことです

さっきの大きすぎるクラスで比較した概念ごとにちゃんと一つのクラスを作ったリファクタリングされた例を音声で見てみましょうさっきのは本当に一つのことやってますかっていう問いかけがありましたがのりさんからはそうじゃないんじゃないかってのもありましたけど一つのことだけをやったクラスはどうなってるかいきますねテキストサマライザークラスですこれに依存性注入をしますと

注入するクラスとしてはパラグラフファインダー段落見つけるクラステキストインポータンススコアラー文章中の大事なやつを抜き出すやつこれらを注入します注入注入してテキストサマライザー君のコンストラクター

これはなんて言えばいいのかなコンストラクターとしか言えないですかねコンストラクターはインスタンス化するときに動くメソッドクラス作ったときに動くやつクラス作ったじゃないですねクラス呼び出したときにインスタンス化したときにそこでさっきのパラグラフファインダーとテキストインポータンススコアラーがこのテキストサマライザークラスの中の

コンストラクターとしか言えないのかメンバー変数かメンバー変数もしくはプロパティに入れられますなのでテキストサマライザー.パラグラフファインダーパラグラフファインダーが呼べるようになりますっていうような状態でこのテキストサマライザーを呼び出したときに呼び出したじゃないですねインスタンス化したときに勝手に

パラグラフファインダーとかテキストインポータンススコアラーのインスタンスを作ってくれるようにコーディングしておきますこうするとですねいざ使ってみようと思ったときにテキストサマライザーをインスタンス化するだけでパラグラフファインダーもテキストインポータンススコアラーも呼び出せちゃうよっていうテキストサマライザーが完成しますなるほどテキストサマライザーにクラス名

どれですかパラグラフファインダー文章を探す機能とスコアリングする機能を持たせるみたいなイメージですよねそうですねこれで単一責任になっていて段落探すクラスが別にいて文章を探すクラスが別にいてそれらを活用しながらテキストをサマライズするやつが一ついるなるほど三つに分かれたわけですコントロールしてくれるわけですねコントロールしてくれるテキストサマライザーさんが

こうするとねテキストインポータンススコアラーをAIベースにしたいと思った時にねそれ入れ替えるだけでいいですしねモジュール性も上がってそれぞれ分かれているのでテストもしやすいとしかも他のクラスで文章を探してってなった時になんとかファインダーを使い回せるとそうですね

今回のポイントとしては関数もそうなんですけど一つのことでいろいろやりすぎると他の人がそれを再利用できなくて大変になるから分けとこねっていうのが抽象化レイヤーの学びになりますそうですねじゃあ最後にまとめです抽象化レイヤーとは何でしたかミルフィーユだよえ?抽象化のミルフィーユダメな残り方してる例えがダメな残り方してる

抽象化レイヤーはですね抽象化するレイヤーを指していて関数とかクラスってそうだよね結局っていうので末端末端って言えばいいのかなそのコード一行一行を抽象化していく逆に具体化していくのがコーディングなんですけどユーザー作りたいと思ったらユーザー作るためには何したらいいかな最初のユーザーIDなんだか割り出してDBに書き込んで

とかとかってコーディングなんですけど細かい作業を要するにこれだよねっていうのを読みやすいように分割していく管理しやすいように分割していく再利用しやすいように分割していくのが抽象化そのメソッドとかクラスをレイヤーと読んでいるのが抽象化レイヤーですありがとうございます今日の話を聞いてじゅんぺいくんじゃあ明日からのコーディング何を変えていくんでしょうか明日からのコーディングはグッ

一体的な何をやりたいのかっていうのを考えてそれになんて言うんでしょう無駄な部分を含めないように抽象化レイヤーを書いていく一つのことしかやらせないってポイントになると思うのではい

出来上がったコードを音読してみて何言ってるかわからないと言ったらリファクトリングするみたいなのはぜひ実践していただきたいなと思いますとにかく関数を小さく書くとノリジーノリジーの言葉です

というわけでグッドコードバッドコードの第2章の内容をできるだけざっくりまとめて話してみました関数のはうまくやってクラス数のは若干グだったんですけどもこれは今後の学びとしてよりいい感じに話せるように頑張っていきますでは抽象化して読みやすいコードを書いていきましょうアブストラクション頑張りますバイバイ

こんばんは7時のニュースですまずは立てこもり事件の速報です現場のノリさんこちら現場のノリさんですたった今立てこもっている犯人が人質と一緒に出てきました何か言ってるみたいですこいつを解放しようしければグーグルフォームへのお便りを受けた番組への質問や話してほしいことをお待ちしております

どうやらお便りを要求しているようですまた犯人は先ほどからしきりにスポティファイアップルポッドキャストでの高評価や感想のツイートも欲しがっています現場からは以上です詳しくは説明欄を見てとのことでした中継ありがとうございました本日のニュースは以上ですまた次回の番組でお会いしましょうさようなら