キャッシュフローとリファクタリング
三昇が、キャッシュフローのための 機能、オプションのための構造
というタイトルがついてて、ちょうど 今さっきしたような話な気もします
ね。
おだしょー そうですね。今言ったやつ
ですね。
三昇 外部から見えるもの、いわゆる ユーザーが使うものをためのプログラミング
と、将来の機能開発能力向上させる いわゆる技術的負債を返却
するとか、リファクタリングして 拡張性を持たせるためのプログラミング
この2つがプログラミングの中には あるよね、ここをちょっと区別
して喋ろうね、みたいなことを 最初に言ってるそうですね。
おだしょー その続き見てみると、両者のバランス
というかリズムが、Good News Factory を作成するのだ。バランスじゃなくて
リズムやぞ、というふうに言って ますね。
三昇 要はバランスではなく、要はリズム
。
おだしょー これでもちょっと面白いですよね。
どっちを取りますか、どのくらい 取りますかっていうバランスじゃなくて
テンポよく交互にやるんだよ、みたいな ことですよね、言いたいのは。
三昇 そうそうそう
おだしょー これは確かにいいって思って。
三昇 スクラムとかでスプリント みたいなものをやるときもリズム
が大事みたいな話があったりとか したし、その習慣みたいなもの
に考えていくときに、リズムみたいな ものっていうのをとても大事にする
みたいなのがあるのかなとちょっと 思ったりしましたね。
おだしょー そうだなぁ。この章は何かどこ
ら辺が面白かったですか。快楽性 の話とかも出てくるのか。
三昇 そうですね、そうですね。ここで
構造と振る舞いの話が出てきて、 その話でリファクタリングってやつ
であったなみたいな振る舞いを 変えるみたいな。まさにリファクタリング
っていう感じがするなってちょっと 思ったりもしました。
ソフトウェアのコストの理解
おだしょー そうか、そこのニュアンス というか、誰かに言わせてたり
をするのか。
三昇 ただ単にAIがたまたまそう 訳しなきゃいけない可能性はあるんで。
おだしょー 確かに。
三昇 ちょくちょくこの本、演算子 っていう言葉が出てきて、果てな
く。
おだしょー そう、演算子が本当にピンと
こなかったんですよね。演算子 どういう使われ方してますね。演算子
三昇 どんなかだと今、振る舞い の変化の中で2行目あたりに演算子
の合理化やコスト削減のための 最適化までって書いてあって、
演算子って思ったんですけど、どう やらこれはオペレートリライアビリティ
リライアブリっていうもので運用 っていうものだったんで、多分運用
の合理化やコスト削減のための 最適化までで、多分訳してあげる
のがちょうどよさそうって感じ はありましたね。
おだしょー いやあ、分かんないよなあ、そこ
三昇 演算子だからオペレート、オペランド
オペレートみたいな、その辺かな みたいなこと思いながら読んでたん
ですけど、運用とまでは思わなかった ですね。
おだしょー そうですよね。いやあ、すごい
弁当になる。
三昇 あとはあれですかね、プログラミング
知ってる人からすると当たり前 って感じはするけど、アーキテクチャー
とかビルド&デプロイツールとか テストみたいな話が出てて、これは
多分ターゲットのために用語の 説明というか、こういうようなこと
があるんだよみたいな話が入ってる なあっていうのも思ったりしました
ね。
おだしょー そうですね。なんかでも本当に
プログラマー向けっていうよりか、 エクゼクティブとまではなくても、
全体をマネジメントしてる人でも 伝わりやすそうな概念にちゃんと
翻訳して話してる感じがします ね。
三昇 そうそう。だからアーキテクチャー
っていうのはシステム全体のロジック がどのように分割されているかっていう
ような意味合いとして紹介されて ますね。でも分かるなあって思い
ながら、そこに着目する確かにな みたいなぐらいかなあって感じ
でしたね。
おだしょー そうですね。なんかあったっけ
なあ。オペレーション演算子の運用 をオペレーションの改善とか、それ
こそCICDとかテストとかも含めて ですけど、ビルドアンドデプロイ
かとかっていうのを、設防してる ユーザーがいないっていう表現
してるか。そこにお金を払う人はいない けど、それをちゃんと仕込ん
どくことによって、ちゃんと将来の オプショナリティっていうのを確保
できるよねっていう話を踏み台 にした上で、将来のNPVっていう
のを犠牲にして、今機能を開発する のか、それともある種今の機能開発
っていうのをちょっと、さっき言った リズムっていう意味で言うと交互
にどっちか。同時にやることは難しい から交互にやりましょうっていう
ふうにケントベック言ってます けど、今は機能開発よりちょっと
落ち着いて、そっちの将来のオプショナリティ の作り込みやろうよっていうのを考える
のか的な話してて、そこはなるほど そういうふうに言うのが面白い
なって思ったりしましたね
おだしょー コード書いてる側からもデプロイ
が早いとすぐ巻き戻せると助かる し、自動化されてるとオペレーション
ミスが起きなくなるし、現場にとって もありがたいし、ユーザーにとっても
実はハッピーなんだよっていう ことでもあるんだよなっていう
でもその機能をちゃんと出す ことありきで幸せを届けるんでしょう
ってなると 最初のプリントでCICDだけ作って
まだ無理、機能は何も動かないんですよ って言われると、なるほどーって
なります
おだしょー いやでもCICDは作り できるから最初にとか自動テスト
は最初にみたいな気持ちもある けど、ユーザーの視点からすると
つまりそれは何もできてないって ことですねってなるからむずい
ねって 家建てるときはまずは土台から作
っとかないとなみたいな
いやでも一般一番過ごすの 長いのリビング家族のための部屋
なんでそこからお姉さんアスって
おだしょー リビングで住んでると床が抜ける
みたいな
そうっすね2Aドアがなさすぎる から
おだしょー 物理的なものは2Aドアはなかなか
難しいね
壁作ってないからドアいない やろって
おだしょー 酷すぎる
でその次ですかね
おだしょー 次いきますか4章がカプリング すいませんまだあの土台や設計の
結合バランスは読んでないんです けど
悪い本だって
おだしょー 4章がカプリングカプリング なぜソフトウェアのコストは高い
のかっていう話になっていて なぜ ソフトウェアはこんなに高くつく
のかっていうものを昔読んだって ことをちょっと思い出しました
けどここで言うのはやっぱ変更 コストがまだでかいっていう話を
みんなするけどなんででかくなる のっていうことを喋ってるって
感じですかね
そうですねこれギアの話が 出てきてますね
おだしょー そうですねギアを回す 時に一個回すとその繋がってる
複数のギアが全体が回りますよ っていうことになっていてそこ
は摩擦っていうものがあるので 全体を俯瞰した時には結構一つ
を動かすのに全体があるのでなかなか うまく回らんっていうような例
を出してますね ギアの場合は繋がってる部分が
分かるからいいんだけどではこれが 繋がってる部分が分からないと
したらどうですかねって問いかけ られていてそうなんよソフトウェア
ってそれなんよみたいな気持ち になりますね
でも起きてることは一緒やろう みたいな雰囲気がついていいです
よね
おだしょー それ多分ソフトウェア 開いて開発画面じゃない人にとって
伝わりやすいたというのはちょっと 思ったりしましたねギア回した
ことないんですよねって言われたら はいってなっちゃうけど
でも機械っていうフィーチャー の中にいろんなギアが入ってるん
ですよっていうのも比喩として通り そうだし本当に今動いてるここに
新しいギア取り付けるんですか みたいな反応を実は内部ではそういう
のが起きてるってことですもん ね
おだしょー そうそうここから入れる 保険があったみたいなそんな状態
ですみたいな
これ全然本題関係ないですけど ここですげえギアっていう表現と
歯車っていう表現がめちゃくちゃ 入り乱れててこういう一貫性みたいな
ところが今のAI使った翻訳の何ですか ねちょっと力のまだ足りてないところ
なのかなっていう気持ちになった りしましたね
おだしょー 確かに全然気にせず読んでた
僕も今見返してて気づいたん ですけどなんかちょいちょい頭に
入ってきづらいなって感じるところ はこういう部分なんだろうなあ
とか思ったり
おだしょー 確かに
それは完全に予算なんですけど
おだしょー でここの結局ソフトウエアのコスト
が高いのはそのギアがいろいろ とつながってるようにソフトウエア
もどれぐらい今変更入れようと思 ってることに対して欠乏しちゃ
ってるかっていうことによって コストっていうものが説明できるん
だよっていうようなことを書いて ますね
変更の難しさと比喩
おだしょー コンスタンティの透過性っていう
のが紹介されてますね
これはちなみにタイディファスト
にも書いてあったんでマジでタイディ ファストの焼き直しみたいな感じ
であるんだなっていうことをさっき ちょっとだけ読み返してて気づき
ました
おだしょー なんか見覚え悪いよなって思ったら
そっちか
でもこの話を読んで やっぱりここに変更入れると
どこに影響が及ぶか分かりません とか 影響範囲は分かるけども 大量
にずらっと参照が出てきます みたいな状態って確かに変更し
づらいよねっていうのを思って すごく直感的だし この10年ぐらい
パッケージレイヤーからパッケージ フィーチャーみたいな話とかよく
出てたけど その辺とかって結局 このカップリングを避けるために
どうやったらみんな治安を維持 できるかみたいなところのアイデア
のうちの一個だったんだろうな とか そのデカップリングするため
にマイクロサービス化しました って言ったけど データベース
が共有されていて爆発するとか 変なところで切っちゃったから
うまくいかなくて 結局三つ結合 にカップリングしちゃって 変更
のコストが大きくなっちゃいました っていうような話とかがいろいろ
出てたのも これで結構説明がつき そうだな 説明できそうだなっていう
のをちょっと読みながら思って ましたね
おだしょー これ あとゲイさんが さっき書籍名研究してたので ソフトウェア
設計の結合とバランスみたいな 話で言うと 結合っていろんな種類
があるというか 価値のある結合 とか あるよねみたいなところで
言うと さっきの話につながります けど 分かりやすい結合は分かり
やすいですよね だから結合の強度 強度っていうと
語弊あんのかな 結合はしてるけど 変更は安全にしやすいとかっていう
のもあるかなとは思ってて そっち の本とかだと侵入結合とかって
やつがあって それは何かってリフレクション 使って結合してますみたいな
つらい それはそれは最悪だよね っていう話があったりとかっていう
のと あとあれですね これはまた 本の話とは違いますけど やっぱり
最近で言うと IDEの能力がすごい 上がってリファクタリングしやす
くなる メソッドのシグニチャー 変えるぐらいだったら ある程度
相当変なマズつっぽいことしてない 限りでは そこそこ安全にいける
ねとかあるし 静的な言語とかだと よりそこら辺の安全性が担保しやすかった
りとか 静的動的関係なくテスト やって ちゃんとカバレッジ取れてる
と嬉しいよねとか そういうふう に変更のコスト下げるみたいな
のもやっぱり大事になってきます よね 構造っていうの以外にもアプローチ
できるなとか ちょっと思ったり しました
おだしょー それを この本の中では 一応 数式みたいなものが出てくる
んだけど もうちょい定量で扱える ようになって 今 結合の種類みたいな
ものもいろいろあるよねとかって あったから その辺も含めてうまい
こと定量化できると パッと知らない ソフトウェアの行動を見たとき
に やばそうな場所はどこなんだろう かとかっていうことが見えて 良さ
そうだなっていうのをちょっと思 ったりもしましたね できるのかな
できなかな 複雑度みたいな話とか もあるんで できなかないかなっていう
気もしますけど 何ていうか 十分 に借れてるから そこはそのまま
利用しみたいなのもあったりする し
おだしょー あるある いかにそこを隔離 するかみたいな感じになって
きますからね
おだしょー うん だから めちゃくちゃ 棚下ろしバッチ
とかで複雑になってる最悪ですよ 道務要件的にも複雑な上に すごい
めちゃくちゃクリティカルな処理 やってるのに 年に1回しか動かされない
みたいな でも いろんなところに結合してるから 影響を流れ込み
まくってるみたいな
おだしょー いや あるなあ あるなあ
おだしょー ありますよね
おだしょー そういうやつは処理 をコンピケして寄せておいて これ
はもう塩漬けにするみたいな そういうことやったことあるな
とか
おだしょー したい したいけど データベースが生き物
すぎて変化しとるみたいな
おだしょー そういう危ないもの といっぱいありますからね 世の中
には これが現場やって感じのもの が 天然ものってやつがこんなに
違うんだぞみたいな でも 結局 これをやらないといけない
ぐらいに ソフトウェアっていう ものがどんどん非体化してるし
大規模化してるし 複雑化してるん だよなっていうのが 50年前も同じ
ような話をしてたのかもしれない けども やっぱり人間の認知の限界
が来るまで ソフトウェアっていう のがどんどん複雑していって それ
をどうやって統治するかという か 治安を維持するか コントロール
するかみたいなところっていう のは ずっと永遠の課題なんだな
っていうのもちょっと感じました ね
うん どうするんです まあ どう するんでしょうね でも スケール
の大きいちっちゃいワールド 全て がそれな気はするんだよ 国家って
難しいよねとか 外交って難しい よねみたいな話も 多分 根は同じ
だね 根は同じって言うと スケール でかすぎるかもしれないですけど
でかるとも言ってたらしい から 複雑さっていうのは分割して
管理せよって 孫引きなんで 合ってる かとかなんですけど 結局 複雑な
ものっていう 自分一人でうまく 立ち向かえない問題っていうのは
やっぱ分割して 部分に どういう ふうにそこを分割するかってこと
に 結局 センスだったりとか 経験 を持ってるかとか そういうところ
複雑なシステムの維持
に依存はしてしまうものの やっぱり そこを分割して どうやって
対処していくかってことが ずっと 求められるんだろうなっていう
気はしますね
でも 全体は部分の総和ではない みたいなことを言ってる人もいます
からね
そうですね 部分の総和 であるっていう人もいるし 要素
還元主義者はそうだけど 非要素 還元主義者はそうじゃないぞっていう
話もあるんで なかなかこの辺は 難しさはありますね
そうで 今ちょうどこの本で 言うと デカップリング頑張ろう
ねみたいな話をして 次の章が 常習とかの話なんで いい感じに
分解しすぎないところも大事だよ ねみたいな話としてつながります
ね カップリングのB面 第5章
このB面っていうのは A面 B面っていうのは 伝わるのか
みたいなこと ちょっと思います ね
われわれはまだカセットテープ 買ってたからな
そう けども 多分 MDって何ですか って人たちがいます
からね
MDは単名だったから しゃあない かもしれない
そういうことか ただ単に ゲームハードセンス
に敗れた 負けた方と同じような 扱いかもしれない
まあいいや カップリング のB面のほうは
結束ですね
結束の話
これコヒージョンですね 原文見ると
結束と結合 何が違うん だろうって思いながら読んでました
多分 これはそういうこと だろうなって思いつつ読んでた
けど いかんせん目が滑りますね 結束と結合は文字面が
ちょっと似てるから
この本の中で結束っていう ものは 何でもかんでも分解して
くればいいよっていう話じゃなくて ある程度はまとまりが必要だよ
っていうので 結束っていうもの には二つの面があるよと 一個
は一緒に変化する要素はすべて 一緒に揃えておいておきましょう
ねと 同時に変化しなければならない 関数はすべて同じファイル内に
書いておきましょうねとか それ 以外の時間に変化する要素はすべて
別の場所にありましょうねっていう ふうなことを言ってて 多筆責任
の原則みたいな話だなってちょっと 読みながら思ったりもしてました
だから同種ですよね 多分 結束
そうだと思います 多分そうだ と思いながら
1ページ前で同種ってちゃんと 言えてたのに 何で結束にしちゃ
ったんだろうっていうのは ちょっと 残念ながら
まだ人間の仕事はあるな
人間の仕事はありますね いや でも 簡易訳入るだけでだいぶ
いいんだろうな
多分 辞書整備するだけで 多分 これだいぶ精度上がるんだろう
なって気がしますね そう考えると そうっすね そうっすね
でも 言ってることはすごい 分かるなと思いながら 結構 この
辺は意識して データベースとか は やっぱりライフサイクルみたいな
のもすごい気に振るようにしながら レビューとかの中でも こことこ
って一緒に変わるのとか こっち と この絡むとこの絡むは同時に
変わるんですかとか 違うんだったら デーブル分けませんかとか そういう
ようなことを考えたりとかもする し それは多分クラス設計とかファイル
の置き方にしてもやっぱそうだし すごい分かるなっていうのを読み
ながら思いましたね
そうですね そうっすね
なんかライフサイクル が違うものがテーブルとかに入って
ると アップデートが走って この アップデートで アップデートされる
前に何だったんだろうって言って わかんなくなったりとか
あと 塗らぶるな絡むが増えて みたりしますね
そう そう 最初は塗る で このアップデートで値がセット
されますって言われて なるほど みたいな気持ちになりながら 絡む
分けようかみたいな この絡むは ちょっと別にしましょうねみたいな
話をしたりします
そうっすね この絡む そうっすね 君はこのテーブルに座ってなくて
変更の効率化
いいでしょ
そうそう でも 結局そういう ことをやっていくことによって
変更のしやすさとか 何かを追加 するときとかに どこにあるべき
なんだっけっていうことを考え やすくなっていくから 実は結構
経済的にも効果があるんだろう なっていうことを思ったりします
ね
結束力の向上による未知的な 経済効果はソフトウェアのオプション
性を拡大するっていうふうに書いて あったりとかありますもんね
やってやるだけで変更 コストだいぶ下がるから 本当に
そうなんすよね 変更コスト を下げることでGood News Factoryは
維持されるって書いてますね
多分 こういうことを意識 せずにやはりファクタリングしたいん
ですっていうことだけで 自分が 気に食わないから 気に食わない
って言い方 ちょっと言葉が強い かもしれないけど こういう書き方
は良くないってやって ただ単に コードを書き直したりするだけ
だと 多分 業種度は別に上がらない し テーブル分割するのはデータ
ベースでリファクタリングはとても 大変なので やらないかもしれない
ですけど 結局 本来解決したい 問題って何だったんだっけとか
メンテナンス性を上げたいがために リファクタリングしたかったん
じゃないんだっけっていうところ が 結局 何の問題も解決されない
まんま こっちのファイルとこっち のファイルとこっちのファイル
見ながら 同時にこれを更新しない とぶっ壊れますみたいなことを
ずっとやり続けるみたいなことが 続いていくってなるんで この辺
は結構大事ですよね
そう考えると 今 話しかけながら 思ったのが あんまりどうしても
ネガティブっぽい言い方になっちゃ いますけど 過読性を上げるため
みたいな 過読性か 過読性って何 で言ったんですかね 過読性とは
認知不可じゃないのかみたいな なんだ 高度が頭に入ってきやすい
脳みそに収まりやすい的な話と 切り離せるような次元での変更
コスト 要するに常習性がどうな ってるかとか さっき言った変更
のライフサイクルとかデータの ライフサイクルとかっていう面
で 常習性っていう話 両面ある かなと思ってて ゲインさんの今
の話聞いてて 校舎の変更コスト に直で効くような常習性をしっかり
高めようよってリファクタリング は結構賛成しやすいのかなと思
って 逆に前者で言うと なんだ この 先にフォルスって書いてある
比較式はみたいな この技法をやめろ みたいなリファクターはそんなに
変更コストには変わらん気がする とかって話になるのかな 僕は世田谷
を好きなんですけど
結構ここは好き嫌いありそうだ なと今思いながら
まだ好みに合ってるコード のほうが直感的にコードが脳みそ
にメンタルモデルに染みてくる じゃないですか それって大事ではある
はずなんですよね じゃあ100行と 200行のメソッドどっちがやっぱり
100行のメソッドもよくないか 数百行あるメソッドってそんなに
悪くないんだっけって話をもちろん したくないので やっぱり読みやすい
コードのほうがいいじゃんと思 うんですけど
そうね 読みやすいにこした ことはないからといいますね
だって100行200行ぐらいある メソッドでそこの中の処理のうち
をプライベートメソッドに切り出した ところで そのプライベートメソッド
が再利用のためにモジュール化 くくり出されてるわけじゃなかった
としたら 別にそこって助手席は 何も変わってないどころかコード
ジャンプしなきゃいけないっていう 意味で言うと助手席はちっちゃい
レベルで下がってるじゃないですか でもそのライフサイクルとかデータ
の持ち回りとかには一切影響を 与えてないから 本当はどっちが
よかったんだっけみたいな ディープ モジュールシャドウモジュール
っていう意味で言うとみたいな 今の俺だったら分割ができる
っていうことは何かのブロック を見つけてるはずだから そこが
今度次の不責になるから それは 業習性を上げるためのファースト
ステップみたいなものなのかな っていうのはちょっと思ったり
ましましたね 確かに責任が複数あるとか
には繋がってくるか 必要な登場人物が全部揃ってる
かじゃなくて 登場人物がちゃんと 認識されてるかどうかっていう
のがA面B面がありそうか そうっすね なんか密なツッコミ
変わってないけど いやでも最近僕 メソッド
を短くできるようになってきたん でよかったですね
いいっすね 成長しました 行動がかけるよう
になってきた 最近超長いメソッドにさらに
アンパサンドって引きずに渡してる の見たりとかして頭変えたり
したんで 短いメソッドすごいいい なって思ってますね
あとあれですよね ローカル 変数が何個も出てきてる
とか怪しいなみたいなやつとかね 属色化されてないのではって
登場人物多すぎではって いや多いのはいいんだけど その
ローカル じゃあ100分ずって多い のはいいんだけど そのローカル
変数を何回も上書きしないでくれ とかね
タフな証拠 PHPには確かにコンストがない
からね TSみたいなコンストレット みたいなやつがPHPにはないから
しょうがないんだけどと思いながら でもそれはお金を生んでること
なんでそういう面ではありがたい って思いながら
代入するたびに100円 儲かってるかもしれない
それだったら喜んでこの コードをいっぱいぶん回すんだけど
確かにホワイトルール で回すときも無限に無限ワンアップ
できる
だんだん話が逸れてしまった けど カップリングのP面っていう
ところでした
次ですね6章ですか
