00:07
はい、9月16日金曜日。 地獄は朝9時を回りました。
えー、1週間の終わりの金曜日ですね。 ちょっとテンションは上がらないですけれども、頑張っていきましょう。
はい、おはようございます。 ひめめめのkeethです。
では、本日の朝活を始めていきたいかなと思います。
はい、今日はですね、昨日宣言していた通り、タイトルの記事ですね。
ソフトウェア設計についてtwada技術顧問と話してみた。
フィロソフィー用のソフトウェアデザインを ベースにっていうところで、
いわしさんという方ですね、が書かれた板。
まあまあその社内勉強会がそもそもあって、 NTTコミュニケーションズのそこでですね、
社内勉強会があって、そこのスライドのリンクも 貼られてるんですけど、そこのもうちょっと
記事化したというか、それを言語化したものっていうのが この記事になりますね。
はい、では早速読んでいきたいかなと思います。
で、いきましょう。 初めにスタンフォード大学のジョン…
アウターホールという教授ですかね。
ちょっと名前読み方あってわからないですけど、
アウターホール教授が執筆された
アフィロソフィーオブデザインソフトウェアデザイン
まあ以下、APOSDですね、と略しますと。
という書籍をご存知でしょうか。
書籍のタイトルと直訳すると、 ソフトウェア設計の哲学となります。
書籍の内容はまさにソフトウェア設計について 扱っていますと。
本書籍をベースにアフィロソフィーオブソフトウェアデザインを
30分でザッと理解するというお題で
社内ランチ勉強会が開かれました。
本執筆者、本記事の執筆者であるいわせが発表者であり、
勉強会収録に関わるとおりです。
スライドの4ページに記載したとおり、
本書籍はアウターホール教授の 意見が強く反映されており、
ソフトウェアエンジニアであれば 議論を呼ぶ箇所があります。
実際、勉強会の実況スラックでは、
これはどうなんだろうといった 疑問が挙がっていましたと。
一応、スライド4ページ目のことを見ますと、
ゴールを目指して話すことということで、
書籍の概要、全22章から20章のトピックを ざっくりとってきますと。
注意点、面積というのはあれですけど。
本記事では、その勉強会で挙がっていた疑問について、
ティーワダコモンと話した内容を紹介していきます。
各社の皆様のソフトウェア設計に関する知見の拡大が 記事のゴールだというふうにおっしゃっています。
なお、事前の面積が言ってあります。
対話の起点はAPOSDですが、
途中からソフトウェア開発全般のトピックに 発生していきます。
APOSDから外れてソフトウェア設計全般のトピックを 発生していたなという気持ちで読んでいただければと思います。
さて、以降は大きく二部構成となります。
前半ではAPOSDでの主張、 概要というのを紹介します。
後半を読むためのペースラインを合わせるのが狙いです。
スピーカーデックの資料をお読みの場合は 飛ばしていただいて構いません。
03:01
後半は本題となるティーワダコモンとの議論パートです。
では早速いってみましょうということでした。
APOSDの概要ですね、まずは。
これの主題というのはいわゆる複雑性です。
この複雑性はソフトウェアの構造に関するものであり、
システムの理解や修正を難しくするものになります。
システムの理解や修正が容易であれば、
そのシステムは複雑ではないということになります。
仮にどんな大規模なシステムだったとしても、
理解や修正が容易であれば、
APOSDの定義では複雑ではないシステムになります。
複雑性が増大すると以下の3つが起こります。
1つ、チェンジアンプリフィケーションですね。
変更の増大です。
2つ目がコグニティブロード、認知的負荷が上がる。
3つ目、アンノーン・アンノーンズですね。
未知の未知というものが発生するそうです。
例えば一見単純に見えても、
変更箇所が多い場合が変更の増大としますと、
また覚えるべきAPIや気にしないといけない変数が多いといった場合は
認知的負荷の増大になります。
さらにあるタスクを完了させたいとして、
何を変更すればいいかわからない状態が未知の未知となります。
今回の書籍ではその未知の未知が3つの中で最悪と述べられています。
なぜならば、何らかの変更を加えてもバグが出るまで発見できないためですと。
このような複雑性はどこから生まれてきてしまうのでしょうか。
今回の書籍ではその要因として、
ディペンデンシー、過去依存性とオブスキュリティですね。
不明瞭性の2点が挙げられています。
例えば何らかのモジュールを操作する場合に、
1つのモジュールで完結できない場合は依存性がある状態になります。
またコードが読み解かないとわからない場合は不明瞭性がある状態となります。
一例としてタイムという変数があった場合、
単位などの補足がなければどのように利化していいかわかりません。
秒か分からないし、分からないし、
そもそも時間軸はどこですか、JSTですか、UCTですかみたいなのが結構あったりするので。
また単純に時計的な時間かもしれないし、
例えば何かを計測している途中のタイムスタンプの時間かもしれないし、
タイムという変数だけだと全然わからないですよね。
この複雑性にソフトエンジニアはどのように立ち向かえばよいのでしょうか。
POSDではその方法として以下に点が挙げられています。
一つは複雑性の排除、例えば特別なケースを排除すると。
もう一つは複雑性の隠蔽だと言っていますね。
例えば何回の部分が見えなくても使えるようにカプセル化しましょうと。
書斎記ではこの1と2を中心に全22章でより具体的に説明されています。
詳細は現状に移るとして、ここから一部のトピックについて
技術コモンのT和田さんと議論していきますというところで本題に入っていきましょう。
06:04
技術コモンとAPOSD、書籍ですね、について話してみましたよということです。
行きましょう。小クラス主義と大クラス主義というふうにまず言っております。
APOSDでは4章の中で以下のソースコードが記載されています。
これ多分Javaのコードかな。
一応音読ですけどそんな感じですね。
ファイルインプットストリームというクラスのスペースにファイルストリームという変数で
newのファイルインプットストリームでファイルネームというのを引きずりに受け取ってインスタンスを作っています。
続いてBufferedInputStreamというクラスでBufferedStreamというインスタンス変数を作っておいて
newのBufferedInputStreamでファイルストリームという変数を受け取ります。
インスタンスを作りました。
3つ目にオブジェクトインプットストリームクラスのオブジェクトストリームという変数を定義しておいて
その中にもnewのオブジェクトインプットストリームでBufferedStreamを変数に受けています。
インスタンスを作りましたみたいなソースコードが記載されたそうですね。
やりたいのはファイルを開いてシリアライズ化されたオブジェクトを読み込むことです。
クラス設計としてはGang of 4のデザインパターンでいうところのデコレーターパターンが活用されています。
実家として小さいクラスを組み合わせて実装を進めるコードにはなっていますけど
本件を勉強会で話していた際にスラックでT和田氏からもコメントが上がっています。
著者は小クラス主義に異を唱えているんですよね。
T和田氏はここについて疑問があったんですね。
これについて以下で深掘りしていきます。
ここからいわしさんとT和田さんのやりとりが続きます。
小クラス主義ってことは大クラス主義がありますか?
小クラス主義と大クラス主義があります。
私のこれまでの言語キャリアから考えると小クラス主義の代表はJavaで
大クラス主義の代表はRubyですと封印されます。
なるほど。僕はあんまりRubyとJavaをがっつり使ってプロジェクトに入ったことがないので
そうなんやって感じですね。
小クラス主義の例としてJavaの先ほどのファイルIOが分かりやすいですね。
大クラス主義におけるRubyの例としてはアレとかストリングのクラスに
多くの機能や責務っていうのがありますよね。
少ないクラスがそれぞれ多くの機能を持つ必然的にクラスが大きくなりますと。
そりゃそうだよね。
続いていわしさんですね。
このあたりは今回の書籍APOSDの主張とどう関連がありますかというところですけど
次は和田さんですね。
APOSDの著者が述べているのはディープモジュールが良いということですよね。
ディープモジュール、深いモジュールとはインターフェースが狭くて実装が深いことです。
09:01
反対にシャローモジュール、浅いモジュールですね。
というのはインターフェースが広い代わりに実装が浅いことを意味します。
いわゆる公開されているインターフェースっていうのが結構広いよね。
その代わりに一個一個は小さく浅くっていうところですね。
これ自体は小クラス主義とも大クラス主義ともちょっと違います。
ただ小クラス主義は必然的にシャローなモジュールに近づきがちですというふうにおっしゃられています。
これはなんとなくイメージできますよね。
で、いわしさんです。
シャローモジュールのようにIFが広いのを避けたいのは認知負荷の増大でしょうか?
というところに対して和田さんはそうですと。
よく似た機能がいくつもあってその中から選ばないといけない。
利用者としては認知的負荷が高いというふうにおっしゃってますね。
よく似ていてちょっとずつ機能が違うクラスがたくさんあり、
その中から選んで使ってくださいみたいなパターンはありますよね。
あるいはよく似ていてちょっとずつ違うメソッドがあるというパターン。
これも認知的負荷が高いですよねというふうに和田さんはおっしゃられていますと。
まあでもそうかもね。
よく似ていてちょっとずつ違うメソッドがあるというパターン。
これもまあ認知負荷が高いのは確かにそうかもですね。
和田さんと僕聞いてて思ったのは今のフロントエンドのフレームワークと結構似てるなと思いました。
リアクトとかビューとかもそうですけど基本的にはエコシステムに依存するじゃないですか。
いろんなものを他にいろんな外部ライブラリとかに頼りつつ作りたいものをどんどん実現していくと。
ありますけど一方でアンゲラっていうのは今回でいうとこの大きいクラス、大クラスに近い感覚があって、
アンゲラそのものにいろんなモジュールがあったりとか機能っていうのは全て内包されていて、
外部ライブラリに依存することであんまなかったんですよね。
なので僕アンゲラで開発したときは基本的に公式ドキュメントからの海ですね。
公式ドキュメントの海から欲しい機能ってないかなっていうのをざーっと調べつつ、
あったっていうので使うことが多かったので。
本当の意味でちゃんとフレームワークはやっぱりアンゲラだなって今思っているんですけど。
もちろんネクストとかナクストもあったりするのでそういう包括したフレームワークが出てきて、
元と違う可能性は。
そいつらは確かに大クラスと言えるんですけど、
単体のビューとかリアクトっていう意味でいくと小クラスの感覚だなっていうふうに巻き入れて、
似てるなと思ったというそういうだけなんですけどね。
それでいくと和田さんは小クラスに疑問があるというのでやっぱりちゃんと大きいからですので、
和田さんはアンゲラ派のような人っていうふうに僕は勝手に思いました。
はい、まあいいや。戻ります。
Javaの設計思想に行きましょうついて。
岩瀬さんは小クラス主義にも一定のメリットがあるのかと思います。
例えばJavaの元々の設計思想だと何を意識されていたでしょうかっていうのを聞かれてますと。
和田さんが述べられてますけど、
これから述べる課題っていうのは最近のJavaでは解決されていますが、
一応歴史からお話しますと。
元々のJavaの設計の背景にあったのは、
全ての状況を破綻なく扱える設計を提供しようという価値観でした。
例えば巨大ファイルを広げようとすると、
まあアウトオブメモリになりますよねと。
まあなり得ますよねと。
12:00
だから例えばArrayとかListにファイルの全行を簡単に読み込むのは
意図的にできないようにしていましたと。
言語レベルできないようにして防いでたんだ。
それよりはどのような場合でも適切に動く汎用的な組み合わせを提供しています。
例えばインプットストリームを開いて、
インプットストリームリーダーでキャラレベルに変換をして、
バッファードリーダーでバッファリングするという例のコードになりますと。
これは理屈はわかるんだけどめんどくさいよねとか、
正しいけど面倒だよねという話にはようはなるんですねと。
まあまあまあ面倒くさがりというのはエンジニアとしての一つの良い機質ですからね。
ちなみにこの問題はJavaの進化とともにだんだん解決されていって、
現在では単純な問題は短く解決できるようになりましたと。
この正しさと面倒くささの問題に対して、
Rubyも大蔵主義の観点から一応アプローチをしていますということですね。
続いてRubyの設計例ですね。
UTCオフセクトってやつです。
Rubyの標準ライブラリの設計者はMatzさんを中心に何人かいます。
その中の一人の田中哲さんですね。
AKRっていうふうにネットでのアカウント名を持っているそうですね。
田中さんは正しさと使いやすさの関係をとても敏感に考えていますと。
正しいやり方が簡単でないとみんな正しいやり方を使ってくれない。
だから正しいやり方が最も簡単であるべきというAPA設計をしたんです。
いいですね。この思想は僕かなり今共感を覚えましたね。
結局使ってくれなければそのツールそのものに価値は結局生まれないですからね。
簡単だけど若干間違っているコードと正しいけどすごく面倒なコードがあるときに
人は簡単だけど若干間違っているコードに引き寄せられがちですね。
その点、経例はUTCからの時差の求め方ですね。
時刻処理というのは正確にやろうとするとかなり面倒な部分がありますと。
うん、わかる。めちゃめちゃわかる。
具体的にはうる秒があると1秒ずれるとかですね。
この部分を正しく実装しようとすると2行だったものが8行ぐらいになるわけですね。
すると誤差があっても簡単な方に返し通っていきますと。
そんなとき田中さんはRubyのタイムクラスにUTCオフセットというのを定義して
正しいけど面倒なやり方を1回のメソッドを呼び出しで済むように設計をしました。
タイムクラスのUTCオフセットがメソッドを呼び出す方が明らかに短くてかつ正しいやり方というわけです。
一番正しいやり方が一番短くて簡単であるべきという考え方によって
正しい方向に利用者を誘導する設計をしたわけですと。
このあたりの詳細はAPIデザインケーススタディ
Rubyの実例から学ぶ問題迅速したデザインと普遍の考え方という
これは記事のリンクですね。
これは書籍か。
APIデザインケーススタディという書籍がありますね。
技術評論者から出版されている書籍でした。
これにも載っていますので興味ある人は見てみてください。
続いて良いインターフェースとはというセクションに入りますと。
15:04
実は同じ趣旨の内容がプログラマーが知るべき97のことの1つにも載っています。
ちなみにプログラマーが知るべき97のことという超有名な書籍ですよ。
これ今オンラインで読めるようになりましたね。
しかも無料で読めるようになったという。
本当に誰でも読めるようになったというので
ちゃんと読みたい方はネットで調べてみていただくといいと思いますし
この記事にもリンクが貼られているので
今読んでいる記事のリンクをあらためてシェアします。
一応この中にも載っています。
良いインターフェースとは次の2つの条件を満たすインターフェースのことですよというふうに仰ってました。
1つ目が正しく使用する方が操作ミスをするよりは簡単ですよねという。
2つ目が誤った使い方をする方が困難ですというふうに仰ってますね。
良いインターフェースだと誤った使い方をする方が難しいと。
正しい使用をする方が操作ミスをするよりは簡単ですと。
使う側の人にそういうふうな促しというか
良くも悪くも制約を付するような感じですね。
このような考え方に照らし合わせると
小クラス主義で利用者に適切な組み合わせ方や
責務の選び方を委ねるのもなかなか難しいなという話になります。
もちろん優は安く行う形という話でもあります。
続いて岩瀬さんが言ってますけど
なるほど確かに設計の最も難しいポイントですねと。
1つのことを実現するために1つの正しいやり方があるというのは
シンプルでとても素晴らしいと思うんですが
現実として1つのことを実現するために複数のやり方がある例というのは
これまでどのようなものがあったんでしょうかという問いを投げられています。
ここでまた和田さんが回答されてますけど
古典的でありますがプログラミング作法という書籍ですね。
僕ずっとTUDOに残っている書籍ですね。
結構おすすめだというふうにいろんな方が言われたので読んでみたいんですけど
ここから1つ紹介をしますと。
この中ではC言語ですね。Cの標準ライブラリが紹介されています。
例えばOutput Streamに一文字書き込む場合に
Put CとかF Put C、F Print F、F Writeがありますね。
懐かしいですね。そんな関数ありましたね。
僕一応C出身なので。
大学の頃にC言語から入ったというのもありますけど。
懐かしいですね。
言わせたんですけど、確かに利用者は結構混乱しますよねと。
Output Streamに一文字書き込む場合に4つのメソッドが一応存在します。
ライブラリを作るなりビジネスロジックを作る場合には
そういう設計を避けるのが大事ということですよねということでした。
和田さんもまた続けてますけど。
例えばプログラミング作法から引用しますと
少なくともどうしても関数を増やさなければならない明確な根拠が生まれるまでは
広いインターフェースよりも狭いインターフェースの方が望ましいと。
一つのことだけ実行し、それをうまく実行すること。
可能だからというだけでインターフェースに追加してはならないし
問題があるのは実装の方なのにインターフェースに手直しをしないことだと。
18:00
例えば速度面で有利なMemcpyと安全面で有利なMemmoveがあるよりも
常に安全に利用でき、できれば高速に動作する関数が一種類存在する方というのがいいですよねと。
速度面のオプションと安全面のオプションが2つあって
どっちを使うみたいなトレードオフみたいな設計にするよりも
できれば一発の関数でやれた方がいいですよねって。
それはもちろんそうだよねってなりますけど。
というところでした。
続いて、似た機能でちょっと違うものの実装でどうします?というお話に移ってきます。
では少し話を戻して、似た機能でちょっと動作が違う場合というのは
現実の開発現場でよく出会う例かと思いますと。
これってどうすればいいんでしょうか?というのがまたイワシさんの問いですね。
また和田さんの回答ですけど、例えば動作をオプションで変えるかどうか等で悩むことになりますよねと。
今回の書籍でも言及されています。
この点は私だったらリファクタリングをしていきますと。
じゃあそのリファクタリングの方向性は?っていうイワシさんの問いに対して
和田さんはこう回答しますと。
基本戦略としてはよく似ていて、ちょっとずつ違う箇所があるときに
ちょっとずつ違う部分をくくり出していきます。
そうすると完全に一致する部分とそれぞれ違う部分にどんどん分かれていきますよと。
完全に一致する部分は外部に注視して共通ができます。
昔は親クラスに注視して継承による差分プログラミングをしていた時期がありましたが
現代では推奨されません。
オブジェクトを組み合わせ共通部分を移情していきますよと。
その際にインターフェースを広げないようにバリエーションを追加するのにポリモフィズムを使います。
ここは書籍の調査力とはちょっと流派が違うかもしれませんねというふうにおっしゃっています。
では続いてポリモフィズムの箇所の実装イメージをもう少し具体的にお話しいただくとどうなりますかという問いが投げられました。
ここに関してですと、まずよく似ていてちょっとずつ違う部分で共通を抽出すると
その共通部分の大部分というのは利用者が直接触らない部分に移動します。
共通部分の多くは利用者に露出していないので設計はある程度自由になります。
次に新しいバージョンが増えるときにそれをどう扱うかという話になります。
1つ目のユースケース、2つ目のユースケース、3つ目のユースケースで似たような抽象が見て取れるのであれば
その共通部分との界面にインターフェースを導入して汎用的な実装として組み合わせられるようにします。
リファクタリングは結果的にドメインモデリングに近づいていきますよと。
まあ言われりゃそうだよね。
かつ必要性とかできるなってなってからやるのがいい話ですね。
最初からそういうような設計にしないっていうところが聞いてていいなと思いましたね。
これは共通部分の抽出とは違うってことですかっていうところですね。
問いが投げられてまして、これいい問いだな。
じゃあ具体例を出しますよと。
例えば私が開発していたとある学内システムというのがありますと。
最初はあるレポートを出すという要件が一つあって、機能は一枚岩で作られていましたと。
21:02
しばらくして新たな連絡先が出てきて、ちょっとずつ要件が違うレポートを出す必要が増えてきました。
4つぐらい例出されてますけど。
学生向けはその学生だけの情報が出ます。
教員向けレポートならクラス全員の情報が出ます。
担当クラスの教員向けに全情報を出すが、担当外の教員が見る場合はいくつかの情報がマスクされると。
4つ目で、今後は連携している他大学の教員もレポートが見えるようになる予定。
その際にはさらに情報がマスクされると。
こんな感じの必要性が出てきたよということですね。
このようによく似ているけどちょっとずつ違う要件というのが出てくると。
単純にやるならば、if文で条件分岐します。
閲覧するユーザーも引数で渡すとかですね。
これは確かにほぼ脳芯に近いようなやり方ですね。
一般ユーザーと管理者ロールで分けるべきケースとかですよね。
新しいロジックが入るたびにif文が増えることになります。
ただ、リファクタリングしていくと次のような気づきがあります。
例えば、何を見せる、見せないというロジックはデータレベルの認可、データ視認性のロジックになっているわけです。
リファクタリングしていく中で完全に同じ部分と違う部分を寄せる、もしくは集めていくと
違う部分というのは代替においてこのようなロジックであることに気づきました。
そうなると何をやればいいかというとユーザーが誰かではなくて
レポートの元データの抽出機能とコンテクストごとに異なるデータのフィルターがあって
その2つの組み合わせで動けば要件を満たせるという話になります。
まあ確かになるほどね。
例えばログインユーザーがその授業の担当教員の場合は全部見えるフィルターを渡します。
フィルターの中身は実質的にはヌルオブジェクトパターンでいいわけですね。
学生だったら、担任以外だったら、学外だったらという形で
各々のフィルターインジスタンスを作れるようにします。
ギャングオブフォーのストラテジーパターンというやつですね。
それを状況に応じて共通のレポーターに渡せばいいわけです。
学生の場合は全員検索してからフィルターするよりも
そもそも自分のデータだけを抽出する方がもちろん効率が良いので
まずは動くもののパフォーマンス改善の余地が大きいバージョンでリリースし
後にデータ抽出部分のフィルタリングを含んだ複合的なインターフェースになりましたということですね。
続いての問いで、Javaで実装するならフィルターのインターフェースを定義することになりますか?
ですけど、和田さんもJavaではそんな感じですねと。
このレポートの場合はいくつかのユースケースがありますが
そうして何を見せるか見せないかのロジックの差異が多かったので
ロジックの差異を表現したクラスを作って渡していく。
そうすることでレポート機能のコードはほぼ変更なく
新たなフィルタリングが提供できます。
例えば今後は連携している他の大学の教員もレポートが見えるようになり
その時はマスクする項目がさらに増える予定です。
この場合も他大学の教員用のストラテジークラスを用意すればいいことになります。
これは継承に頼ると出てこないレベルの抽象なんですと。
継承でやるならアブストラクトレポーターっていうのが出てきて
24:02
if 文が抽象メソッドになっててアナウメする実装になるでしょうと。
具省クラスにアナウメ部分を実装してフィルタリングするわけですね。
つまり親クラスが抽出を行いサブクラスでフィルタリングをする。
この方向性だとデータ抽出とデータレベルの認可が異なることに気づきにくいと。
これはサブンクラスに近い考え方ですねと。
言語語法パターンで言えばテンプレートメソッドパターンに近いですねと。
ちなみにそのテンプレートメソッドパターンって現代だと筋が悪いんでしょうかという問いですけど
和田さんは筋が良いのは現代ではあまりありませんが
処理の順序を示すパターンですよね。
例えばユニットテストにありますよねと。
テスト前のセットアップとかテスト後のティアラウンドとかですよねと。
ただそれもやっぱりテンプレートメソッドパターンが必須というわけではありません。
例えばオブザーバーパターンでも実装できますよねと。
現代においてはそもそも継承をあまり使わなくなってきていますというような別の観点もあります。
続いてですね、書籍の内容で継承を考えていこうと。
なるほど、この辺でもう一度その書籍に戻りたいんですが
その書籍で述べられていた次の3つの複雑性から招かれる事象と継承の関連は何でしょうかと。
その3つっていうのは1つ。変更の増大、2つ目が認知的負荷、3つ目が未知の未知ってやつですね。
これに関して継承の関連ってどういうことでしょうかと。
和田さんも回答しますけど、継承っていうのは親クラスとの間に強い依存関係が生まれますよね。
継承の使い方を誤ってしまうとその継承の階層が深くなります。
また書類を読み解くときにサブクラスを読んで次に親クラスを読んで
親の中身を見たと思ったらまたサブクラスでオーバライドされていたみたいな不可解さを持つことがありますとなる行動です。
この書籍では複雑性の要因っていうのは次の2つが挙がってましたねと。
複雑性の要因は1つ依存性と2つ不明瞭性ですというふうに仰ってました。
まさにこの2つに繋がるわけですねと。
不明瞭性で言えば行動の距離が遠くなりますからねということですね。
そういうわけです。
というわけで最近出てきたプログラミング言語では継承という概念がないことも増えてきて
継承ベースのテクニックっていうのが推奨されなくなってきたっていうのが背景にあるよってことでした。
というわけで一応最後終わりにというところにもう来ちゃうんですけど時間もそろそろ迫ってきますからね。
本記事では前半でその書籍の概要を紹介して後半で小クラス主義、大クラス主義、インターフェース設計、
リファクタリングによるドメイン中枢といった内容の対話を紹介してきました。
実は後半の内容ですね、対話内容は全体の内容のうち半分程度しか記事に起こせていませんと。
半分だけでも非常に多いかもっていうのもありましたけど
本記事が好評でしたら後半パートや続編を検討していますので
Twitterでフィードバックいただけましたらありがたいですというところで締められていました。
いやー良かったですね。
ちなみに今回の記事には筆者の方はあるですね。
深堀FMっていうポッドキャストもやられているので
27:00
もしもし興味ある方は全然見てみて聞いていただくといいと思います。
かなりエンジニアに特化したような内容で参考になるなという感じですね。
なので深堀FMも興味があったら聞いてみてくださいというところでした。
僕は結構読んでてすごく共感となるほどなって思うことが多かったんですけど皆さんいかがでしょうかね。
僕フロントエンドの人間なのであまりこういう設計レベルの話ってほとんどしないんですけど
改めてこういうのを聞くとバックエンドって楽しそうだなってちょっと思いましたっていう
全然記事とは関係ない感想を述べるんですけど。
最近はもうそういう感じなんですがそもそも継承を使わないっていう流れになってきたんですね。
それすら知らなかったのでいろいろ新しい情報を得られてよっぽど楽しかったと思いますので
この記事またTwitterでこの後シェアしますので
皆さんの方でも見ていってどんな風な感想を使っているのか
皆さん自身で考えていただければいいのかなと思いました。
はい、じゃあこちらで朝方終了したいと思います。
今日もご参加いただいたたくさんの人、大変にありがとうございました。
金曜日ですね、1週間の終わりというところできっちり仕事を終えて
ハナキンを優雅に過ごしていただければなと思います。
では終了します。お疲れ様でした。
