00:03
はい、7月2日、土曜日ですね。 遅刻は昨日もありました。
本日も全国的に暑くなる日が続きそうですね。 はい、おはようございます。
ひめみのきーずことくわはらです。 では本日も朝活をやっていきたいかなと思います。
はい、本日は、昨日もお話した通りですけど、
CUPID for joyful coding っていうブログ記事を 読んでいこうかなと思っております。
プログラミングに関する思想というか、設計的な考えみたいなところっぽいので、 そこの話を読んでいけたらなと思います。
割と学びになりそうな感じがしたのでね。 はい、では行っていきたいと思います。
えーっと、すいません。毎回毎回翻訳をすると時間がかかるんですけど。
ソリッドですね。大前提。 ソリッド原則の縦膜の隅を突くような巻き、軽い気持ちでこう始めた
イコノクラリズム、イコノクラズムっていうのがあるんですかね。 イコノクラズムちょっと僕よくわからないですけど。
はい、っていうのがより具体的で目に見えるものに発展していますと。 もし私がソリッドの原則を最近役に立たないと思うのであれば何に置き換えたいのでしょうか。
またどの原則でもすべてのソフトウェアに適用するのでしょうか。 また原理原則とは何を見せるのでしょうかと。
だからちょっと哲学的な話にちょっぱなからなってきてますね。 はい、まあでもこういう問いをちゃんと自分の中でやっていって、自分の中で深掘りをしていっていくとは結構良いことだと思うので、
まあこの問いはいいと思いますね。 ちょっと上からでごめんなさい。
で、私はソフトウェアには一緒に仕事をするのを楽しくなるような特質やセースがあると風に信じていますと。
しかしすべてはトレードオフの関係にあるため常に自分の文脈を考慮する必要もあります。
しかし何事もトレードオフの関係にあるので常に自分の文脈を考慮する必要がありますと。 私は私がコードで切り欠けていることの多くを支える5つの特性との選びました。
5つあれば便利なセット字ですね。
が作れますし覚えておくには十分な数ですと。この記事がこれ以上長くならないように今後の記事で書く特性について詳しく説明していきますので、これ以上包括的でないことをご容赦くださいと。
なるほどですね。なるべくこの記事でもこれ以上長くならないように包括的に書いてますけど、それぞれ1個1個の特性について具体的に深掘った話は別記事にまとめているのでそこを見てくださいということだそうですね。
はい。
げんきさんとしちゅうりさんですね。はい。おはようございます。お参加ありがとうございます。タイトルの通りですけど、Cupidって読むんですかね。ちょっと僕は全然不勉強なんですけど、という5つのプログラミングに関するフィロソフィー的なものの記事を4枚読んでます。
はい。続けていきましょう。はい。で、Cupidですけど、この5つの特性っていうのは1個1個読んでいくと1つはコンポーサブルですね。
03:07
うまくやれる。他人とうまくやれる。他とうまく連携できるみたいな方法ですね。で、2つはユニックス哲学、ユニックスフィロソフィーですね。はい。1つのことをうまくやりましょうと。
で、3つ目がプレディクトバールで予測可能ですね。はい。あなたが期待することを行う。で、4つ目はイディオマティックで感欲ですね。はい。これは自然に感じられようというところでした。
で、最後はドメインベースっていうところですね。解決領域が言語と構造において問題領域をモデル化しているかっていうところですね。この5つについて今回書いていくっていうところでした。はい。
で、えーと、前文。ちょっと前文の話がここで入ってくるんですけど、遠い昔のことだそうです。はい。見慣れないコードベースを開いてどうすればいいのかわかったことはありませんかと。
構造、名前、流れ、フローとかは明らかでどこか見覚えがあります。顔に意味がかかります。これだと思いましたねと。ほう。なんか急になんかポエマチックになりましたね。
はい。私は30年以上のキャリアの中で幸運にもこのような経験を何度もしてきました。デジタル印刷のための複雑な画像処理を行う巨大なC言語のコードベースを解読したときです。
ほほ、すごそうだな。はい。他人のコードにバグがありそれを追跡して修正することになったんですと。で、新米プログラマーだった私は恐怖と自分が素人であることを裏切ってしまうのではないかという恐怖が入り混じって、えー、入り混じってしまうような感覚を覚えていますと。
で、私のエディター、Cタグ付きのVIですね。VIか、懐かしいな。はい。は、呼び出し元のサイトから関数定義に移動することができますふうのうちに、何百ものソースファイルとヘッダーファイルからなるコードベースの中で、自分が何を見ているのか分かっていると確信しながら呼び出しの数に深く入り込んでいったんですよ。
で、私はすぐに原因を見つけましたが、これは単純なロジックエラーでした。これはすべて自動テストなしでメイクファイルを作っただけ、使っただけでした。TDDというのは私の10年近く先のことでしたし、C言語にはその種のツールはありませんでした。
いくつかのサンプル画像に対して変換を実行したときは、それらは問題なく表示されました。私は、A、バグを発見して修正できたこと、B、A、同時に厄介なサプライズをもたらせなかったことにできる限り自信を持ちました。
過去の30年間のこのヒーシャーの方のご経験だそうですね。
すごい、本当に30年前ってことでC言語をずっとやってきたってことですね。なかなか大変だったんだろうなっていうのはお察しします。
一応、僕もC言語出身なので、多少の苦労はわかりますけど、ちゃんとC言語で書かれたプロダクトだったり、そのプロジェクトのソースコードを読んだことはないので、すごそうだなと思います。
余談がさらに続くと、一応、僕がC言語でLinux kernelとかネットワーク周りとか、Linuxの設計で周りを一度チャレンジしたことがあるんですけど、まあ、難かったですね。
06:10
Linux kernelをもし読みたいのであれば、かなり古いバージョンのLinux kernelから読み始めるのをお勧めします。
あの辺だとまだソースコードもそんなに膨大になってないですし、設計周りがちょっと浅いというか荒い感じだったんですけど、その代わり、読みやすさって意味だったら昔の方が読みやすいです。
今の方がより洗練されていて、しっかり構造化もされていて、よりでも僕にとっては難しかったです。読みづらーと思いました。
頭のいい人たちの書いたコードなんだろうなっていう感じはすごくしましたね。
単純にレベルが高くてついていけなかったって感じですけど。
それくらいC言語ってやっぱり低レイヤーに近づけば近づくことが難しいなっていう感じはしましたね。
機械の心が分かる人たちなんじゃないかみたいな勝手に思ってましたね。
余談でした。
ケントさんですね。おはようございます。ご参加ありがとうございます。
記事にある通り、プログラミングのフィロソフィー的なものの記事を読んでます。
じゃあ早速読んでいきましょう。
Joyful Softwareですね。楽しいソフトウェアというところの章に入ります。
ある種のコードっていうのは作業するのが楽しいものであります。
あなたは、あなたが作業する必要があるものを見つける方法を知っています。
必要な変更を行う方法ももちろん知っています。
コードは簡単に操作でき、簡単に理解でき、簡単に推論できる。
自分の変更が過度な副作用を伴わずに望んだ効果をもたらすと確信できる。
コードに導かれ、周囲を見渡すことができる。
あなたの前に現れたプログラマというのは後から来た人のことを気にかけていたんですよということですね。
こういうコードを書きたいですね。我々もやっぱり。
理想的な原則をずっと書いている感じですね。
マーティン・ファウラーですね。彼の代表的な著作、リファクタリングの中で次のように述べています。
どんな若手でもコンピューターが理解できるコードを書くことができる。
優れたプログラマーは人間が理解できるコードを書く。
リファクタリング、マーティン・ファウラー、ケント・ベックと共に書いています。
1996年にこれを書いているというところがやっぱりすごいよなって感じですね。
なかなかでもちょっときついというか、強い言葉ですね。
どんなバカでもコンピューターが理解できるコードを書くことができて、
優れたプログラマーは人間が理解できるコードを書くと。
まあでも、グーの音も出ないくらいそうとなって思っちゃいました。
ケント・ベックもマーティン・ファウラーもこのプログラミングの世界では本当に神様的な存在ですからね。
はい、じゃあ続けましょう。
私は2000年代初頭にこの書籍を読みまして、
彼の言葉によって私のプログラミングの世界が覆されました。
良いプログラミングとは他人にも、他の人間にも理解できるようなコードを作ることだとしたら、
その人間の一人が未来の私だとしたら、それは何かを目指すもののように聞こえました。
はあ、なるほどね。
09:01
しかし、理解しやすいというのは立派な目標かもしれませんが、
それほど高いハードルではありません。
マーティンがリファクタリングについて書いたのと同じ頃、
コンピューターのパイオニアであるリチャード・P…誰だ?ガブリエル。
リチャード・P・ガブリエルさん。
うわー、引っかかりもしないな。
どなただろう。不勉強で申し訳ないですね。
はい。
というのは、コードが居住可能であるという考えについて述べています。
はい。
リチャード・P・ガブリエルさんについてのリンクも貼ってますね。
これ多分彼の公式サイトだと思いますけど。
居住性とは、ソースコードの構造と意図を理解し、快適かつ自信を持って変更することを可能にするソースコードの特性である。
はい。
ハビタビリティっていうのは、家のように住みやすい場所を作るという一言を言ってますね。
はい。
ハビタビリティとピース・ミール・グロース・ワン、パターンズ・オブ・ソフトウェアの中に空いてあるものですね。
それの引用だそうです。
ハビタビリティっていうワードが僕はちょっとわからなかったんで、これもググりますと。
それが居住性ですね。はい、失礼しました。
じゃあ続き読んでいきましょう。
これはどちらかというと目指すべき姿のような気がします。
他の人のコードを快適に、そして自信を持って変更できたらどんなに良いことでしょうかと。
そしてもし我々がコードを住みやすいものにすることができたら喜びはどんなものでしょうかと。
コードベースがあなたを喜びで満たすことは可能でしょうかという問いを投げたんですね。
もしあなたがプログラミングを仕事にしているのであれば、
コードベースをナビゲートし操作することがあなたのユーザーエクスペリエンスを決定づけます。
驚きだったり、苛立ち、恐怖、期待、無力感、希望、喜び、これらすべてを
以前のプログラマーがコードベースで行った選択のために経験することができるのです。
もしコードベースが喜びを感じることが可能だとしたら、
それぞれのコードベースは特別な雪の結晶で、
あなたの精神に与える影響は独特なものなのでしょうかと。
それとも何か喜びを生むためのものを明確にし、
私たちが触れるコードの喜びを増すための道筋を示すことができるのでしょうかという問いですね。
結構、プログラマーのフィロソフィーを語っているはずなんですけど、
僕らの体験であったり、人生についてに近いような話をされるんですね。
まあまあでも、否定する気はないし、全然共感も多いけど、
そもそも僕の期待したというか、予想していたものと全然違う話になりそうだなというので、
ちょっと驚きが今あるという感じですね。
続けていきましょう。
次のセクションですけど、プロパティオーバープリンスプルですね。
原則より特性というところですね。
ソリッドの5つの原則への対応策を練り始めたときに、
12:00
それぞれの原則をより便利で適切だと思うものに置き換えることを想定していました。
なんかすごいですね、ソリッドの原則の対応策っていうのを練ったこと今までいなかったし、
この原則全部正しいなというふうに思ってたんですけど、
彼にとってはこれをより洗練というか、新しいものを作りたかったらしいですね。
考えたこともなかったので、すげえなと思ってますけど。
しかしすぐに原則という考え方自体に問題があることに気づきました。
原則というのはルールのようなもので、それに従うか従わないかです。
これでは価値観を共有する人々の中心的集合ではなく、
ルールを守る人と守られる人の境界的集合が生まれてしまいますと。
まあ確かに言われてみればそうですね。
なるほど、中心的集合かな、みたいですね。
そこで私は従うべきルールではなく、コードの品質や特徴であるプロパティについて考え始めました。
このプロパティは向かうべき目線や中心を定義します。
コードはその中心に近づくか遠ざかるかだけであって、常に明確な方向性を持っています。
プロパティはコードを評価するためのレンズやフィルターとして使用することができ、
次に取り組むべきものを決定することができます。
Qubitのプロパティは全て相互に関連しているため、
あるプロパティを改善するために行う変更は、
他のプロパティのいくつかにプラスの効果をもたらす可能性が高いです。
なるほどね。それは良い。
確かにSolidの原則って、要は独立した5つの原則って感じがしますからね。
本当は独立しなくて全部は関係することができるんでしょうけど。
こっちのQubitの原則っていうのは、原則がプロパティですね。
っていうのは、よりそれを意識しているんですね。相互に関連しているようなものを作っているということですね。
そうしないと、そもそもそのいわゆる中心的な集合という価値をなかなか生み出せなかったのかもしれないですね。
続いていきましょう。
続いては、プロパティのプロパティですか。
ではどのようにプロパティを選択すれば良いのでしょうか。
何がプロパティの有用性を高めるのか、もしくは低めるのか。
私はQubitのプロパティに求めるプロパティの特性を3つ決めました。
それは、実用的であること、人間的であること、そして重層的であることということですね。
それを1個1個見ていくというところですね。
実用的であるためにはプロパティ以下のようなものが必要であると思っています。
1つ目ですけども、easy to articulate、表現しやすいというところですね。
いくつかの文章でそれぞれの特性を説明でき、具体的な例や反例を提示できることだと。
2つ目は評価しやすいですね。early to assessなので。
コードをレビューし議論するためのレンズとして使用でき、コードが各特性をどの程度示しているのかを簡単に判断できると。
15:08
3つ目はeasy to adapt、採用しやすいということですね。
小さなところから始めて、Cupidのどの次元に沿ってでも徐々にコードを進化させることができる。
完了することもできると。
完了がないのと同様にオールインも失敗もないということですね。
コードは常に改善ができるようになっているよということですね。
コードに完全はないということですね。
人間らしくあるためにはコードではなく人間の視点で物事を読む必要があります。
Cupidというのはそのコードと一緒に仕事をするとどんな感じがするかということであって、コードそれ自体を抽象的に記述するものではありません。
例えばエニックスの哲学である一つのことをうまくやるというのは単一責任原則、ソリッドの原則の一つですね。
のように聞こえるかもしれないですけど、前者はコードをどう使うか、後者はコードの内部そのものに関わるものですと言っています。
ここでしっかり態度が示されましたね。
基本的にCupidというのはコードと一緒に仕事をするとどんな感じがするかというのを定義した五つのプロパティだということですね。
なるほどね。
でも人間らしくあるためにコードではなく人間の視点で物事を読む必要があるというところが、そもそも立脚しているポイントが違いますよね。
人間らしくあるためにというところが重要なんですね。
でもなかなか面白いな。
こういうところに立脚した原則とかフィロソフィーってなかなか語られることって少ないと思うので、新しいというか視点が違って面白いなと思いましたね。
続いていきましょう。
回想化するためにプロパティは初心者のためのガイダンス。
これは明確にしておいた結果です。
そのガイダンスとそのソフトウェアの本質をより深く探究したいという考える経験者のためのニュアンスを提供する必要があります。
Cupidの各プロパティというのは名前と簡単な説明だけで明らかではありますが、それぞれが多くの層、次元、アプローチを体現しています。
各特性の中心を説明することができるかもしれませんが、そこに到達するための道はたくさんありますよと言っていました。
なるほどですね。
どのプロパティを選択すればいいかというところがご説明でしたね。
実用的というところと人間的というところと重層というか階層的というところですね。
実際まだ使ってないからなんとも言えないですけど、結構共感は深いなと思いましたね。
表現しやすいとか採用しやすいとか評価しやすいって、なんとなく他の原則でも出てくるものに似ている感は僕の中ではありますけどね。
ただやっぱり人がベースになっているので、人にとって表現しやすく評価しやすく採用しやすいというところがやっぱり重要なんだろうなと思いましたね。
18:05
システムにとってというよりもですね。
ソリッドの原則とかはどっちかというとシステムとかにとって素晴らしい行動というふうな視点が強そうな印象があって、その差がでかいのかなと思いました。
ここからじゃあその5つのポイントについて具体的に入っていくという感じだそうですね。
でも既に21分なので教授に終わらないことはほぼ確定ですね。
この記事5分の1なんです、今まで読んで。
教授終わらないどころか、残り無効3日ぐらいかかりそうですね。
まあまあ、気長に読んでいこうかなと思います。
じゃあいきましょう。
1つ目ですね。
コンポーサブルです。
使いやすいソフトウェアというのは使われ、使われ、そしてまた使われるようになっていくと。
とにかく使われるものがやっぱり使いやすいソフトウェアだと。
高度の可用性を高めるもしくは低くする特性はありますが、これらはいかなる保証をするためにも必要でも十分でもありません。
それぞれのケースで両側からの範例を見つけることもできるので、これらは有用なユーリスティックと考えるべきでしょう。
多ければ良いというわけではなく全てはトレードオフの関係ですというところですね。
やっぱり態度は一貫していますね。
それを少し具体的にして解説までいこうというところですね。
1つ目はスモールサーフェイスエリアというところで、表面積が小さいというところですね。
表面積という表現がなかなかコードを書く中で表面積は見たことがないので面白いな。
はい、いきましょう。
APIが狭く意思というのが分かれているコードはやっぱり学ぶべきものが少なく、失敗することも少なく、
使っている他のコードとの衝突や矛盾が起こる可能性も少ないと言っています。
APIが狭すぎると複数のAPIを一緒に使うことになり、
一般的なユースケースで正しい組み合わせというのを知ることが暗黙の了解になってしまい、
参入障壁となり得ると。
APIの流度を正しく設定することというのは見た目以上には難しいですよと。
断片的と非大化の間にちょうどいい止まりというスイートスポットがあるのですと。
これは最初から僕らは結構理解しているところですよね。
どこまで細かくするかというのはすごく大きい課題になりますよね。
小さくすればして、同時に叩くAPIの数があればあるほど、
エラーハンドリングとか、ロールバックとか、リトライ処理とかというのが
考えることがどんどん増えてくるので、細かすぎるのも大変ですけど、
かといって大きいと何回APIの責務が広がっていくし、
どうなんだろうみたいなのもやっぱりありますね。
では続いて、インテンションリビーリングということで、
意図を明らかにしましょうということですね。
意図を明らかにする行動というのは発見しやすく評価もしやすいと。
私はあなたのコンポーネントを簡単に見つけることができ、
それが私に必要なものなのかどうかというのを同じように素早く判断することができます。
私が好きなモデルの一つというのは有意性ある、
エクストリームのようなオープンソースプロジェクトから
21:02
2分のチュートリアル、もしくは10分のチュートリアル、そしてディープダイブを持つことですと。
これによって段階的に投資し、自分には向かないと判断したらすぐに切り替わることができます。
意図的に明らかにする名前をつけてクラスを書き始めると、
IDが同じ名前のインポート候補をポップアップしてきたことが何度もありました。
大抵の場合、他の誰かが同じ考えを持っていて、
似たような名前を選んだためにセレンディフティにその人のコードを見つけることができましたということですね。
これは単なる偶然ではなく、私たちは同じドメインに精通しているため、
似たような名前を選ぶ可能性が高くなったことになります。
ドメインベースのコードであれば、このような可能性がより高くなりますということですね。
これは確かにそうですね。
同じような名前をつけるところで名前バッティングするという危険性もあったりしますけど。
なるほどねってところでしたね。
誰がどのコードを書くかというところの責任分岐をしっかりするのも結構大事だと思うんですけど、
一方で確かにセレンディフティにその人のコードを見つけることができるっていうのは、
それはそれで逆に面白い体験かもしれないですね。
続いてミニマルディペンデンシーズなので最小限の依存関係ですね。
依存関係が最小限のコードっていうのは心配事が少なく、
バージョンやライブラリの非互換性の可能性も特に低くなります。
私は最初のオープンソースプロジェクトであるXJBっていうのをJavaで書いて、
ほぼいびき立つのがログ4Jのロギングフレームワークっていうのを使用しました。
同僚はこのことがライブラリとしてのログ4Jだけでなく、
特定のバージョンへの依存を生み出していることを指摘しました。
それはそう。
ロギングライブラリのような無害なものについて、
なぜ誰かが心配しなければならないのでしょうか。
そこで私たちは依存関係を取り除き、
さらにJavaの動的プロキシで楽しいことをする別のプロジェクト全体を抽出し、
それ自体も最小限の依存関係を持つようにしました。
できるのであればそれはいいと思いますね。
他人のライブラリを使うってことは、
そのライブラリの更新とかバグとか、
その辺も加味しなきゃいけないので、
そこは心配事が増えるのは仕方ないと思いますね。
どこまで依存をするかどうかっていうところは懸念はありますし、
依存するんだったらその依存ライブラリのメンテナンスチームとか、
バックという会社があるとかっていうのは結構大事だったりしますね。
更新ずっと行われてないライブラリとかを使うってことは、
そのライブラリが何か起きたときの対応は
全部自分たちがするっていうのは当たり前の話なので、
何を使うかっていうのは結構大事だったりしますね。
それを全部切り出して自分たちでやれるんであれば、
全然自分たちでやってもいいと思いますし、
なんならそのライブラリをフォークして
自分たちのリポジトリとして新たに作っても全然いいんじゃないですかね。
そのライブラリ自体がライセンスMITとかであれば別にいいですけど。
以上がコンポーザブルですね。
使いやすいソフトウェアっていうところの話でしたね。
すごく共感が多い話ばっかりでしたね。
なのでまずはこのコンポーザブルから入るのもいいんじゃないのっていう
24:02
すごい直感的に思いました。
まだあと4つ読んでないんですけど。
とてもいいフィロソフィーだなという風に感じましたね。
じゃあ続いていきましょう。
あと4分で次のUNIXフィロソフィーで終わっちゃう気がちょっとしてますが。
いきましょう。
UNIXの哲学ですね。
UNIXと私はほぼ同年代です。
ほんとにかなり歴史を歩いてきた方ですねこの方は。
私たちは共に1969年に始まり、UNIXは地球上で最も普及しているOSとなりました。
すごい1969年生まれなんですねこの方は。
だいぶご高齢な感じじゃないですか。
そしてずっとこの業界でやってきたってことですよ。
1969年生まれか。
1990年代には主要なオープンソースのLinuxとフリーBSDが普及するまで
あらゆるコンピュータハードウェアメーカーが独自のUNIXを持っていました。
最近ではクラウドとオンプレミスの両方でほとんど全てのビジネスサーバーが
Linuxという形で稼働しています。
また組み込みシステムやネットワーク機器、Mac OSやAndroid OS
さらにはマイクロソフトのWindowsオプションのサブシステムとして稼働しています。
MSもついオプションサブシステムとしてLinuxが多くなりましたからね。
ここは結構でかいニュースだと思います。
UNIXと一緒に歩いてきた体験から試験があるんですね。
まずはASimpleConsistenceモデルですね。
シンプルで一貫性のあるモデルということで。
では通信研究室で始まったニッチのオペレーティングシステムが
大学生の趣味のプロジェクトとしてコピーされ、
世界最大のオペレーティングシステムになるまでにはどのような経緯があったのでしょうか。
OSベンダーがその技術と同じくらい互いに訴訟を起こすことで有名だった時代に
その成功に商業的、法的理由があったことは間違いありませんが
その永続的な技術的魅力というのはそのシンプルで一貫した設計思想にあります。
テキストの哲学というのは上記のコンポーザビリティプロパティーで述べたように
よく一緒に動くコンポーネンツを書き、一つのことをよく行うようにという。
日本語は難しいな。
そういうふうに命令をしているということですね。
例えばlsコマンドというのはファイルやディレクトリについての詳細をリストアップしますけど
ファイルやディレクトリについては何も知りませんと。
lsはその情報をテキストで表示するためのツールに過ぎませんと。
まあそうね、確かに。
とにかく一つのことだけを行えと言っているわけですね。
中身は知らなくてもとにかくリストだけを並べろっていうのをやるのがlsなので
そういうふうにとにかくシンプルで一貫しているんですね。
そういうやることっていうのは。
27:01
同様にcatコマンドっていうのは一つまた複数のファイルの内容を表示
もしくは連結し、グリップが与えられたパターンに位置するテキストを選択し
制度っていうのはテキストパターンを置き換えるなどですね。
今全部リナックスコマンドですけど。
Unixのコマンドラインにはpipeという強力な概念があり
あるコマンドの出力を次のコマンドの入力として接続し
選択変換、フィルタリング相当などのパイプラインを作成することができます。
このpipeは選択変換、フィルタリング相当などのパイプラインを形成するものにありますと。
そもそもそのためのものですと。
これ確かにすごいですよね。
コマンド上で前の入力をそのまま使えるっていうのは
当たり前かもしれないですけど思想としては。
でもこれがあるおかげでコマンドっていうところの有用性とか便利さが
本当に強いなと思いますし、今もずっとその思想というか
僕らもそれを全然使ってますからね。
すごいなと思いますね。
これだけシンプルにすればするほどずっと先でも生きてくるような
やっぱりものになってくるんだろうなっていう感じもありますね。
先進性があった設計だっていうのはやっぱり間違いないんだろうなと思いました。
続いてというか時間が来てしまうんですけど
あとセクション1個だけなので1個だけ読んでいきましょうかね。
単一目的VS単一責任ですね。
シングルパーパスVSシングルレスポンシビリティですね。
一見するとこれは単一原則SRPのようにも見えるし
SRPのある種の解釈には重なる部分がありますと。
しかし一つのことをうまくやるというのはアウトサイドインの視点であり
具体的で明確に定義された包括的な目的を持つという性質であります。
SRPっていうのはインサイドアウトの視点であって
コードの組織化に関するものでありますと。
SRPはこの用語を作ったロバートシーマーティンの言葉を借りれば
コードっていうのは変更する理由を一つであるべきで
たった一つであるべきであるっていう風に言ってますと。
何か聞いたことある?
Wikipediaの記事の例っていうのがあって
それもちゃんとリンク貼ってるっぽいですね。
レポートを作成するモジュールですけども
レポートの内容とフォーマットっていうのは
別々のクラスもしくは別々のモジュールにするべきであると。
別々の関心事であるように考えるべきですよっていう風に書いてますねと。
例えば新しいフィールドが追加されたり
データのソースが変更されたりして
データの内容や表示方法が変わってしまうような場合ですねと。
そういう時にやっぱり分けで住み分けておくと
変更もしやすいような話ですね。
もう一つの一般的なシナリオっていうのは
UIコンポーネントで
SRPはコンポーネントのレンダリングとビジネスロジックを分離することを義務づけています。
開発者としてこれらが別々の場所に存在することで
同一のフィールドを連携させるという管理上の手間が発生しますと。
さらに大きなリスクっていうのは
コードベースが成長し一つのことをうまくやるっていうコンポーネントや
30:02
問題空間のドメインモデルに適したコンポーネントが出現した時に
より自然な関心ごとの分離が行われないように
これが早すぎる最適化になってしまう可能性があるということですね。
これはよく体験しています。
先にやっぱり僕らって
特にフロントエンドはそうかもしれないですけど
結構Atomsレベルの細かいところから作り始めて
そこからコンポーネントを組み上げていくっていう
いわゆるアトミックデザインの思想に基づいた開発をするフローが結構多いと思っていて
最初から結構こういうふうに石も分けたりとか
この辺はここで分けた方が今後扱いやすいとか
再利用しやすいとか拡張しやすいとかっていうふうに分けていくんですけど
これが早すぎる最適化になってしまう可能性ってすごくありますよね。
実際感じていて後から結局これ混ぜた方がよかったじゃんとか
分けたけど結局使ってるの一回しかなかったねみたいなのがあったりして
面倒ってなることがいっぱいあったので。
しかしやっぱり必要な時に分離する必要があると感じた時に
分離するのがやっぱりなんだかんだいいんだろうなっていう気はしますね。
ただもちろん先を見据えてこれは必ず分離する必要があるよねっていうのは
全然最初にやっていいと思うんですけど。
じゃなければまずは分離しないで
愚直に作っていってもいいのかなっていう気もしています。
同じ一つの画面でしか使わないUIコンポーネントをわざわざ分けておく必要って
正直僕もあるのかなって毎回思ったりしてますからね。
すいません余談が過ぎました。
早すぎると最適化になってしまう可能性があるような続きですね。
コードベースが大きくなるにつれて
適切なサブコンポーネントに分離する時期がきますけど
コンポーザビリティとドメインベースの構造の特性っていうのは
いつどのように構造変更を行うのかっていうのが
良い指標となるでしょうと言ってました。
後ほど読むドメインベースっていうところの指標
プロパティと最初に読んだコンポーザビリティっていうところのプロパティですね。
っていうのを構造変更するときにまた
使うっていうのがいいんじゃないかっていうところでしたね。
すいませんちょっと時間的に過ぎてしまったんですけど
こちらで以上にしたいかなと思います。
今ので一応二つ目のLinuxフィロソフィーですね。
とにかくシンプルでっていうところですね。
単一の設計思想とシンプルさっていうところが重要だったところですね。
最後のところ読んだ感じで
5つのプロパティが確かに相互に上手いこと
関連してたり連携してるんだなっていうことはよく分かりました。
なのでこれ確かに5つ全部上手いこと取り入れたら
もうちょっとプログラミングの視点というか見方が変わってくる感じはしますね。
今までのこのソリッド原則にしかり
いっぱい原則やられ格言とかあるんですけど
やっぱりあの辺と全然立脚する視点が違うので
すごく面白いなって思いましたね。
というところで今日の朝活は一旦こちらで以上にしたいと思います。
明日はまたこれの続きで
プレディクタブルに予測可能性のところから入っていきたいなと思います。
33:02
現時点でまだ記事の5分の2ぐらいですね。
なのでもう2日ぐらい続くと思うんですけど
興味ある方はごゆるいとご参加いただければと思います。
では土曜日ですね。
休日をゆるーくお過ごしいただければなと思います。
ただまあ暑いので皆さん体調だけは気をつけてくださいねというところで
じゃあ今日の朝活はこちらで以上にしたいと思います。
ご参加いただいた4人の皆さんありがとうございました。
では本日も良い休日をお過ごしください。
ではでは。
