00:05
きんじょうひでき
そうですね。続きのところに行きますか。
じゃあ、またげいえいさんの気になるところに乗っかろうと思いますけど。
げんえい
はい。じゃあ、14章の設計とデバッグの関係をしめりたいなと思っていて、
これすごい気になっていて、これ何かっていうと、
設計をちゃんとしないからバグが生まれて、ひたすらデバッグをしないといけなくなるんだ
っていうことを言ってるんですよね。
デバッグにかけてる時間がプロジェクトの全体何パーセントですか?
みたいなことをちゃんと考えたことある?みたいなことを言われて、
確かに、みたいな気持ちになったんですよね。
で、一方で、なのでもうちょっと本当にちゃんと設計しなさいと。
これでちゃんと設計しなさいっていうのは、
この辺は実際その時に考えればいいからっていって、後回しにしないとか、
どういうインターフェースなのかみたいなことまでしっかり考え抜きましょうみたいなことが書かれていて、
それは一方わかるなって思いながら一方で、
でも我々やっぱり実際書いてみたらその場で見つかる問題っていっぱいあるよねって思ったりしているので、
設計にどれぐらい時間をかけますかって言われたときに、
今だったら、金城さんだったらどれぐらい時間かけるっていう風にちょっと聞いてみたいなって思ったりしました。
きんじょうひでき
なるほど、僕今ゲインさんの後ろで分かる分かるって思って聞いてた気なんですけど、
なるほど、今、ファーストぐらいを守ってたのか俺をみたいな気持ちになりました。
げんえい
ボールこっちに来るんかいって思ってますね。
具体的に何パーセントとかっていうことではなく、設計ってどんな風に普段やってます?みたいなぐらいの感じですかね。
きんじょうひでき
どうなんかね、ここまで見えてきたら多分いけるやろって思うところまでっていう感じなんだけど。
げんえい
自信がつくところまでみたいな感じ?
きんじょうひでき
作ってみないと分からないなではあるので、
そうですね、やばい設計を真面目にやってないんですねってのがすごいロテってしまう。
分かんないですね。
げんえい
ケースバイケース。
ケースバイケース。データベースの設計はちゃんとすると思うんですよ。
きんじょうひでき
データベースの設計してくると、大体どういうデータの流れかな、物理的なデータの流れってのが分かるようになるので、
そうするとインフラ的なアーキテクチャのレベルが見えてきますよね。
03:00
きんじょうひでき
ここは非同期で突っ込んで、分かればってやらせるかとか、
ここは案外同期でやらなきゃいけない圧が強いから、
変にバッとか流さないでオンラインでそのまま処理したいかとか。
オンラインで処理しようかなとか、非同期の別のミドルウェアとか使って処理しようかなっていうのが見えてくると、
大体オニオンアーキテクチャ的な、
ここは多分ドライバー像みたいなものが見え隠れするなとか、
ここは多分切り離すな、交換するかもなみたいな感じになっていって、
このぐらいで良くないですか?ダメかな?
げんえい
自分もそんな感じだなと思いながら聞いてましたね。
きんじょうひでき
どのくらい事前設計とか予防コストに費やすことで、
全体の調子に合わせますか?みたいな、そこらへんまでの分析はしたことないんですけど、
いわゆる外部失敗コストみたいな言われ方をする、
リリースした後に実際にエラーとか欠陥が生まれてしまって、
固着対応とか、修正対応とかっていうのが入って、
どのくらいのコストがかかりましたか?みたいな話で言うと、
管理会計的な目線で、
作業の分類によって、保守系の作業にかかったらこっち側の分類とか、
そういう区分けというか、労務管理じゃないんですけど、稼働管理を前にしてたことがあって、
馬鹿にならないな、削りたいな、みたいなのは、
肌勘もそうだし、素敵な実感としても覚えたことがありますね。
そこから先はまた組織論とか別の話にアプローチになってくるんですけど、
そういう意味で言うと、どのくらい事前設計予防コストから抑えて、
どのくらいのリターンを獲得しにいこうか、みたいな話は、
ちょっと経ってきたことがあるなって思いながら今話を聞いています。
げんえい
たぶんこれの本が書かれた当時と今だと、作るコストがだいぶ違うと思っていて。
きんじょうひでき
ゲームチェンジだったのは本当にCICDの前なんですよね。
そこは絶対違うなと。
げんえい
あと、レイルズってものが出てきたじゃないですか。
きんじょうひでき
そうなんですよ。
げんえい
10分、15分でブログを作るぞみたいな時代がやってきて、
言った中で、もちろん今近所さんが言ってくれたくらいの設計はするものの、
そこから先の実際に動くものを見ながらフィードバックをもらって作っていく、
06:03
げんえい
みたいな価値観みたいなのは、この本の時代と今では全然ちょっと違うよなと思っていて、
この設計にどれくらい時間をかけますかっていうことの意味合いが全然変わっちゃったかなっていうのはちょっと読みながら思っていて、
もしかしたらそもそもレイルズGでコマンドを打って生成して実際動かしてみるっていうことこそが
設計になってしまったっていうこともあり得るかもしれないし、
何も考えてなかったら本当にバータリ的にテーブルを作っていって、
いやなんか全然石化されてなくて、こっちを更新したらあっちも更新しないとね、みたいなことが起きてたりとかするので、
一概にレイルズが出てきたから設計フェーズっていうのはもうちょっと省略されて、
ずっとやってますっていうことではないと思う。
なんかちょっとそういう時代背景的なところはあるなって思ったりとか、
あとさっき金城さん結構でかい規模で言ってくれたけども、もっと何ていうか抽象度が高いではなく、
詳細よりなところでもやっぱりAPIのリクエストとレスポンスのインターフェーズどうしますかって、
多分最初に決めたり設計したりとかいうところもあるだろうし、
じゃあどのクラスにどう持たせますかとか、
その辺とかっていうのはもうどちらかというと動かしながらやってった方が分かりやすいよねみたいな部分も多少あるのかなって思ったり、
ながら読んでいましたね。
きんじょうひでき
あと本当にね、公営的な話になりますけど、ただAPI変えた時にクライアントが実装する人が別にいるんだったらやっぱり事前にイメージツリーアセットしておきたいよねとか、
げんえい
そうですね。
きんじょうひでき
自分でフルタックでエンドとエンドで書き回すんだったら、なんかへへへって言いながら書いて直ってみたいな感じでやったりとか。
げんえい
あとグラフQLみたいなものが出てきて、別にAPIの方は修正がいらないっすみたいなことも起きてたりとかするし、
この辺は別にないデータは返ってこないので、足さないといけないとかもちろんあれですけど、
もうちょっと柔軟性みたいなところも出てきたりとかして、だいぶ時代は変わったなみたいなことを思ったりとか。
あとは一方で風外をいっぱい出して、仕事を増やして、コンスプリントはいっぱいポイント消化しましたってなってるけど、お前それ風外チケットばっかじゃんみたいなこととかも一方であるので、
設計って難しいなっていうか、いう気持ちになったりとかもしました。
きんじょうひでき
ちょっとまた話に変わっちゃいますけど、さっき言ったストーリーポイントとか、バックログの見積もりみたいな話で言うと、あれもありますよね。
09:02
きんじょうひでき
作業ボリュームに関して、実装コストに関してポイントで表現するのか、本当に生み出し得る、期待できるアウトカムに関してポイントをつけるのかみたいな、
もう一段階アウトみたいな話がある気もして、アウトカムみたいな目線で言うと、風外対応とか補修調査みたいな話は、ちょっとアウトカムが明確に変わってくるなとかって話が。
そうですね。
そういう世界観があるなっていうのは頭では分かっている。
げんえい
なかなかアウトカムまでは難しいですからね。
きんじょうひでき
難しいですね。より熟練というかレベルアップが求められる感じがしますよね。
げんえい
ユーザーのことを知らないと、これが実装されると何が嬉しいんですかってなって、議論が終わったらアウトカムのこと話せないですからね。
やっぱり来るので精一杯だと、そこまで頭が回らないっていうのはしょうがないことでもあったりするし。
きんじょうひでき
どこまでケーパビリティが必要でこういうことができるのが当たり前ですみたいなパドルが上がるにつれて、やっぱりついていける人が限られちゃったりするので、それってスケーラブルなチームだっけみたいな感じとかあったり。
げんえい
だからやっぱり採用だったりとか、さっきの適材適所に人を管理しましょうみたいな話に結局つながってくるんですよね。
きんじょうひでき
そうですね。
抜け漏れがあったりとか、バグみたいなエラーみたいなものはある程度我慢して涙を拭いてやっていくしかないかなっていう気はするんですけど、
だからこその気づきやすさとか担保するために、オブザーバビリティって最低限このレベルを満たしてやっていきましょうよとか、
あともいざっていう時にここはえいって変えられるように変更用衛星をちゃんと保っておきましょうみたいな。
最近設計って大事なのはこっちじゃないかなっていう感じがあるんですよね。
2wayドアをゴリゴリに打ったてまくっておければOKみたいな。
読みづらい頃は困るんですけど、いざっていう時にあんまり自分の残りヒットポイントとか残機を減らさずにいけるんであれば、いってそれでいいかなみたいな。
げんえい
めっちゃわかりますね。
最近そういうことばっか考えてますね。
いざという時に外せるなとか、スコップアウトさせて出せればいいかなとか。
もちろんこれはすごく妥協してですけどね。
何でもかんでもスコップアウトすればいいと思ってるって思われるとちょっとあれなんですけど。
結局これって本質的な価値じゃないやつとかをいかに簡単にコードから外せるかみたいな。
12:00
げんえい
ユーザーが一番やりたいことと、これはアドオンでついてるものをいかに外せるかとか、さっきのオブザーバビリティの端も結局不具合はどうしても出ちゃうと思うんで。
我々は別にロケットを作ってるわけじゃないんで。
もちろん不具合出るのは良くないんだけども、修理系なので、修理系というよりは単純にエラーがあった後に修正してまたデプロイすればいいようなものを作っているんで。
そうするとエラーが飛んできた時にパッと直せるかどうかってことの方が勝負になるので。
そこのエラーメッセージを工夫したりとか、ちゃんとスタックトレースが見えた時に自分たちがどこを直せばいいのかってことが分かるような設計になっているとか。
やっぱりそっちの方が大事っていうことは結構思ったりしますね。
きんじょうひでき
そうなんですよね。だいたいエラーが起こるとかバグの原因になるのって、インピーダンスミスマットとかって言われるような、入力と出力っていう一番外側の点Xと点Yがあった中で、
その中で色々変換する場所、翻訳が必要になる場所っていうのがあって、翻訳間違いが一番壊れやすいなっていう気がするんですよね。
壊れやすいところを守りましょうって、それクリーンアーキテクターだみたいな感じがついて、おのずとレイヤーが分かれてくるみたいな感じがついて。
結局ね、綺麗なコードとかかっけいコードって喜ぶのは我々だけでしかないので、中でコードをいじくり回ってる人だけが得られる豪華得点みたいなものだと思っていて。
その我々ですら、やっぱりバグが起きた時にすぐにパッて直して、社内の人もユーザーも大にっこりみたいな方が、どっちを選びますかって言われたら、仕事が楽な方がいいかって感じなので。
そういう意味で言うと、直しやすい、気づきやすい、直しやすい。
もっと言うと、我々に対して、内部に対しては気づきやすい、バレやすい。ユーザーに対しては、起きても直っちゃうからバレづらいみたいな感じになっていけばいいんじゃないかな。
やるのが設計って品質を高める声だと思うんで、品質って仕事を楽にしてアート感を増やすっていうところだと思うと、何々パターンが綺麗か模範的な効果的な例みたいなのは良いかみたいな、そこを考えるのみと無駄だなみたいな感じがする。
なので、それでさっき話した事前設計に行き当たりばったりになりがちな感は、反省も込みで僕はありますね。
げんえい
多分今の話って結局運用まで全部やったことがあると、色々見えてくるみたいな話でもあったりしますけどね。
15:03
きんじょうひでき
エターデューは生き様だっていう話が流れてきます。
げんえい
だから、じゃあこのバックエンドのPHPを一生懸命書いてるだけだとなかなか気付けなかったりとか、運用は別のチームがやってますとか、
世の中にあるじゃないですか、運用と新機械が分かれてるとか、デフトワークスが分かれてる系の話とかあったりするんで、
そういうことを理解するために一気通貫で色々やってみないとねっていうことを思ったりとか。
きんじょうひでき
実際にそこの、なるほど、世界から見るとこういう風になってるのかみたいなところが気付くと、やっぱり楽しいと伝わりますね。
進撃の巨人とかも壁の外がなぜあるのか分かってから本番みたいな。
僕が2月のPP Conference関西で、アプリケーションエンジニアこそ関係だよねっていう発表をしたのね。
げんえい
あれ会場で聞いてましたけど。
きんじょうひでき
それよそれってこの辺に来ない状態だから見てました。
げんえい
結局その設計をサボって雑にイフ文を追加するみたいなことをした結果、被害をこむるのはやっぱ自分たちだし、
そのイフ文を頑張って読み解いて、なんかこの時はこうなんでとかっていって値をひたすら上書きしながら、
なんかこう複雑なパターンを作っていって、生涯復帰までの時間を長くしちゃうとかに繋がっていくんで、
設計ってある程度頑張ってやらないといけないし、でも一方で書いてみないとわからないこともあるしっていう感じで、
なんていうかこの辺のトレードオフ感というか、
リリース急がされるとバータリ的な対応で一旦イフ文で回避とかっていって、
きんじょうひでき
後でリファクタリングって書いてあるんだけど一生リファクタリングされないみたいなことになったりとかして、
げんえい
その時のトゥーズコメントにぶち当たってあーはーって気持ちになるとか、そういうこといっぱいあるんだろうなと思いながら。
きんじょうひでき
たまにね、古代文書みたいなトゥーズコメントありますからね。
げんえい
お前このトゥーズいつからあんねんこれみたいなトゥーズありますか?
きんじょうひでき
まあでもね、自信がないところとかは本当はテストで担当したりとかしてほしいですよね。
必ずしもメソッド単位の単体テストである必要はないと思うので、
もうちょい長めのライフサイクルというか、結合テストとかもっと大きいテストとかでもいいと思います。
げんえい
あとは究極的にはプライベートのファンクションにテストを書くなんて話ありますけど、
18:02
げんえい
どうしても自信がないんだったら書いたらいいんじゃないって思うし、
まあもちろんね、それをパブリックに変えるとか、クラスを移動するとかっていう風にした方がもっといいっていうのはあるかもしれないですけど、
目の前の問題を一旦解くときにはテストを書いて、その後にまたリファクタリングしてそのテストを引き継ぎながら、
もっとケースを増やすとか、いろいろ多分必要は出てくると思うんで、それ育ちていくみたいなとか、
そういうのは全然ありだなと思ったりもするし、
この辺とかはいいプラクティスはあるものの、その場でいいものを選んでいって、
アンチパターンとされているものも取り入れながらやっても結構いいだろうなって思ったりとかしますね。
きんじょうひでき
アンチパターンは当初の理想みたいなのが失われて、アンチパターンになるみたいに嫌味をするみたいな感じがあると思うので、
定例コメントとかを別に長期間放置されなければ別にアンチパターンじゃないわけじゃなくか、
げんえい
そう、そう、そう。
きんじょうひでき
そういう結果になっているようなものよくある悪いあるあるだよねみたいな、
になって初めてアンチパターンを本番みたいな感じがするんで、
うん。
うん、なるほどなあ。
14章そんなに面白いそうだったんですね。
げんえい
いや俺はもう、そうですね、この14章は結構面白いなと思って、やっぱデバッグ、
その無駄をやっぱ減らしたいじゃないですか、仕事の中の。
で、やっぱその無駄ってなんだろうって思ったら、自分で仕事を増やしていることって無駄だと思うので、
それをじゃあ減らすってどうやったらできるかなってことを読みながら考えてて、
経営でどれくらいそれが減らせるかなとか、やっぱ不具合を出さないようにするってどうやったらいいのかなとか、
それってやっぱテストを書くことだよねとか、ユーザーがどう使うかを知っているからこそユースケースが分かって、
このケースをテストを書いておけば、仮にバグがあってもユーザーが踏まないバグは別にいいわけじゃないですか、ある意味では。
きんじょうひでき
そうですね、そうですね。
げんえい
なので、結局ちゃんと担保したいことなんだっけとかってことが分かってないと設計もできなくて、
設計ができないから不具合が増えたりとか、無駄な仕事が増えていったりとか、
期待した通りに動かないからデバッグをブレーキポイントを張って頑張って、
いくつバッグでステップ実行しないといけないとか、いう風になっていくのかなって思ったりとかして、
この章はすごい好きだなと思いながら読んでました。
きんじょうひでき
いいですね。やっぱり他人を見てるところが違うから意見交換すると面白いですね。
げんえい
そうですね。
