マジックナンバーと定数化の課題
はい、いつまじラジオを始めます。
ちょっとテンション低いな。
はい、えーと、
今日は僕の持ち込み会です。
お願いします。 はい。
えーとですね、とある
Xの投稿やら、記事やら
を持ってきまして
えーと。 わかった。
絶対当たんないけど。
イーロンマスクが
6年後にiPhoneがなくなるって言ってる話。
いや、知らないです。 知らない。
その話は興味あるけどちょっと置いといて。
えーと、珍しく
技術の話を持ってきました。
はい。
で、えーと、まあその
背景として、まあとある人が
言っていた話が
マジックナンバーを
定数に置き換える際に
定数だけが定義された
ファイルやクラス作るの
むしろ快悪では。
っていう話をしていて。
まあまだちょっとあんまピンときてなかったんですけど。
まあでも
よくあると思うんですよね。ファイルにまとめる
とか定数っていう。まあ別に
珍しい処理じゃないというか。
まあそれに対して言語化
してくれましたっていうのも
その人が話していて。
で、そんな言語化された
言葉が
見かけ上の読みやすさは
向上するが、判断に必要な情報量は
減っていない。むしろ
名前の妥当性を検証する手間が
増えているっていう風に
言語化していますと。
この時点でちょっと
僕まだ分かってなくて
なんかピンとくるものがありました。
見かけ上の読みやすさは
向上するが、判断に必要な情報量は
減っていない。むしろ名前の
妥当性を検証する手間が増えている。
どうなんだろう。
それって分かんない。
諸説あるというか
いろいろ考えさせられるけど。
確かに定数を
1個の場所にまとめるってことは
この1個の場所の名前が
まず第一必要になるのと
で
プラス
じゃあこれって
マジックナンバーとどっちがいいかって
分かんないけど
定数には名前があってそれが文脈に
沿っていれば
分かりやすいとは思うけど
1つのファイルに突っ込んでる時点で
使う場所との
関係性が薄くなってくるから
ある意味で分かりづらいのかもな
とか思ったりした。
いい話です。
おおむねそういう話です。
ちなみに今日の話は
一旦AIがある時代のことを
忘れて
AIがなかった時の
AIあるからこうだよねっていう話は一切なしです。
大丈夫。AIではあんまり開発してないから。
まだ昔の状態のままだと。
一旦参考として
出る前提のコードとして
イフ文ですと
リトライカウント大なり3
3
3っていうところがマジックナンバー
ですよね。
例えばイフリトライカウント大なり
定数で
マックスリトライカウント
意味としては分かりやすくなって
はいますよね。
マジックナンバーがリトライできる
マックスのカウントが
マックスのカウントだなっていうところ
ですが
これによって2つのことを指していますと
1つ目が
マックスリトライカウントっていう
ネガティブな話として
その名前を
見てもなんで3なのか
とか
これって変えていい値なのかとか
何を根拠に決まった
値なのかっていうのは
書かれてはいない。
定数がどっかにまとめられておいてある
うちの1個なんで。
リテラルが
名前に変わっただけで
読み手が判断に使う情報は何も増えていない。
ちょっと名前分かりやすかった
っていうだけだよっていう主張と
もう1つが
定数が
コンスタンツ
クラスのような別の場所に集約されると
その名前が
実体に合っているかを確かめるために
定義元にジャンプして
値を見に行く往復が発生するの。
そりゃそう。
なんで、リトライカウント第3であれば
その場で完結した確認に
ひと手間挟まりますよねみたいな。
飛んでいって値を確認するみたいな。
で、名前が
値の意味を取り違えていれば
むしろ誤解を招く可能性も
ありますよねみたいな。
っていうことの2つありますよ
っていう話で
さっきユウヤラさんも言ってましたけど
定数を集めたファイルっていうのは
値が使われる文脈から切り離されちゃってるよね
っていう話ですね。
Enumとデータ抽象の概念
ここなら納得できますよね。
これまであったけどこの後も
僕は納得感あるんですけど
その次の対策として挙げられてるのが
イーナム。列挙型とか呼ばれるんですね。
さっきのリトライカウントとちょっと分かりづらいんで
今度あたかってる例としては
ステータス何々
何々
それに123ってくるみたいな。
っていうのはありがちな定数かなって思うんですけど
こいつをイーナムに置き換えて
オーダーステータスイーナム
ってなって
発送待ちとか
注文
準備中とか色々あると思うんですけど
置き換えますと。
ただそうなった時に
あくまでこれ今イーナムが定義されてるだけの状態。
例えばじゃあ
この注文ってどういう状態だったら
キャンセルできるの?
っていうなった時に
イフ文にそのイーナムの
何とかもしくは何とか
だったらキャンセルみたいな
イフ文とその中身が書かれる
みたいなことがあると思うんですけど
そうすると
キャンセルに関する書類書きたい時って
このイフ文が
色んな場所に出ちゃうよねみたいな。
ここから分かることが
イーナムにしたとしても
根本的な解決にはなってないよね
っていう話ですね。
ただのイントから定数
イーナムと
行ったとしても
あくまで名前付けの延長でしかないよね
っていう主張ですね。
ここまで大丈夫ですか?
大丈夫です。
違和感なくここまで来ているかと思います。
その次いくと
ここから
DDDとか
触れてきた人たちは
よく聞く話になってくると思うんですけど
使う側の関心は
振る舞いであって
値ではない。
さっきの注文の
1とか2とか3とかじゃなくて
キャンセルの話で
例えるとキャンセルできるかどうかが
知りたいんであって
値が何かを知りたいわけじゃないよねっていう
話ですね。
オーダーとかだったら
order.cancancel
書類を呼び出すと
その注文がキャンセルできるんだったら
true返ってくるし
そうじゃなければfalse返ってくると。
さっきのorder.
オーダーの中だけで
関係する話。
僕ちょっとあんま馴染みなかったんですが
こういうのデータ抽象って
言うらしいんですね。
聞いたことあります?データ抽象って。
僕はどっちかというとカプセルか
そっちの言葉は知ってるけど
データ抽象っていう言葉自体はそんなに
聞き馴染みがなかったんですよね。
データ抽象は
それは
あれなのかな。
あんま聞いたことないな。
うーん。
使わんな。
データ抽象っていうのが要するに
詳細を隠して
必要な情報だけ見せるみたいなものを
データ抽象って言うらしいですね。
でも
なんかでも可視性の
話でしょ。
まあそうですね。
どこまで見してどこは隠すのか
っていうところですね。
それをクラスの話なのに
データに絞ったって話なのか
よくわかんないな。
クラスでカプセルかとか
可視性を見せたいものだけ
パブリックにする
っていう話で
だから
ここは関数は触れてないってことはデータだけに
触れてるって意味でしたよね。
データ抽象ってことは。
まあだからデータの
状態とかそういうところを
見せず
具体ですね。
ステータスって言ったら。
を見せずに
キャンセルできるできないっていう抽象だけ
出しますよっていう
意味だと捉えてはいます。
中身がどうかっていう
だから中身
今の状態がどうこうではなくて
キャンセルしたいから
キャンセルするけど
ってことですね。
そうですね。だからなんか別の言葉だと
なんだっけな。テルドンとアスクみたいな
言葉もあって
命令しろ
聞くなみたいな。だから今のステータスどうですか
って聞くんじゃなくてキャンセルできるの
っていうまあこれは命令と
あれですが真っ白みたいな
となんか似た話なのかな
と思ったりも。それは当然そう
な気がする。
でちょっとまたENUMの話に戻るんですけど
定数化とかENUM化
自体っていうのは何も隠蔽
してないよねと。
使う側に解釈を委ねている。
なんで
どんなにENUMにつけたとしても
最終的な判断っていうのは使う側
を行うということで
これはデータ抽象ではないよねっていう話ですね
定数とかENUMとか
あと
よくある話として
定数化すると変更の
箇所を一箇所で済むようになるよね
っていう話もよく聞く話だと思うんですよね。
これに対しても
一つ話があって
これも局所化
定数化されるのは値そのもの
例えば1を2に変えるとか
そういう値だけ
で
そこにいろんな処理が
いろいろ呼び出している
場合とかだと
変更内容によっては書き換え直す
とか呼び出し方変えるとか
変更をして回る
可能性もあると
定数化っていうのは
値の変更を局所化
するのに対して
データ抽象は
値の使い方まで局所化する
なんでどう使う
値が
さっきのキャンキャンする
みたいな処理があった場合に
使い方
内部の
詳細とか分からずとも
使えますよっていう話
っぽい感じで書いてますね
なんでこの辺とかは
DDDとかの
ドメインモデル
ところとかは
よくこういう話があるかなって思います
理想と現実のコーディング設計
テンポよくいってしまって
もう3分の2ぐらい終わってます
やっぱねこれね
書きながら思ったんですけど
そうだよねってなるなって思って
この台本作ってたんですけど
やっぱそんな感じですよね
でもあのぶっちゃけ
それは
理想では
あるんで
今の話一番最初にやった
定数の話とか
ENUMの話と
3つ目のやった状態の話っていうのは
状態は
確かに
ステートマシンで
オートマトン
有機
ステータスが
移動することの
関数型だと結構
使われるんだけど
次にいけるかどうかっていうのを
なんか持ってるみたいな
一つのモデルというか
モジュールみたいな形を
持ってるみたいなのがあるんだけど
その話と
状態を持たない
ENUMも
あるわけじゃない
状態を持たないENUM
要するに状態に
移動できる移動できないみたいな
判断を必要としない
ものっていうのも単純にある
わけじゃない
定数とかENUMと
状態の話が
もしかしたらもっと細かく書いてあるのかもしれないけど
全部ごっちゃになって
使われ方ごっちゃになってるような気が
しなくもない
っていうのが一つあって
それこそENUMで定義
ENUMっていうのがものがあるってことは
ENUMとして使いたい場面がある
でENUM
共通のENUMがいろんなところで
使われるなら共通の場所に
持っていけばいいしっていう話で
たぶん今回のは
そういうのをはしょるために
そういうふうな記載になってるんだけど
使い方適材適所で
定数も
定数って僕が思うには
コンスを一箇所に
全部置くのはあんまり良くないとは
俺も思うんだけど
でも
よりコードをエレガントに
したい場合に
マックスリトライとか何も伝えてないから
ダメだけど
理由
何の値なのこのっていうのをちゃんと
意味付けがしてて
文章として読めるような
コードになってるのであれば定数として
置いてその値を保持しとくっていうのは
いいと思っていて
マジックナンバーは
なんでこれが
最初に言ってたけどなんでこれが4
なのとかは伝え
伝えれてないし
でも
まずその4っていう値は
状態とはまた切り離して話さないといけない
ものだと思うから
だから多分
定数も使う場面はあると思うんで
そこだけは
状態と
コード内
一つのファイル内だけでエレガントに見せたい
時の定数の使い方と
いろんなところで
同じenumを使いたい
使い回したいっていうモチベーション
かつ状態がない
みたいな時にはenumを
共通の場所に定義するっていうのもあり得る
みたいなのだけは
分けて考えないといけないだろうなと
そうですね
あと例えば消費税みたいな
明らかに概念が1個しかないような
かつ変更の
メリットを受けられそうなのとかは
どこにあってもいいというか
例えばタックスみたいな
感じでバレオブジェクトみたいな感じで
表現するのかなDDDだったら
消費税を加算する
っていう
ロジックがどこかに包まれたり
するのかな
あとは
その辺に置かれるのかな
その辺に置かれるんじゃない
タックスありなしでタックスが
タックスもしかしたら変えたい時も
あるかもしれないし
場所によっては
軽減税率とかも入ってきますし
そうそう
タックスフリーとかも
入ってくるかもしれないしみたいな
そうですね
そのまま
逸れたまま話すんですけど
結構マジックナンバーに厳しい人
とかもいるじゃないですか
いるね
どこからマジックナンバーを
定数にするんだろうな
っていうのは思っていて
例えばその
サマーキャンペーンみたいな
メソッドがあったとして
引き続きプライスとかを渡す
としますと
でサマーキャンペーンの
処理はここにしかありませんと
サマーキャンペーンはこれが
呼び出されますと必ず
ってなった時にプライス
かける
0.9とか
あった場合これって1割引きになってわかるじゃないですか
そうなった時にこの
0.9定数にした方がいいのか
って思うわけですよ
僕は別にしなくていいと思うんですよこれって
なんかもう自明だからこの
0.9は何を指しているのか
でも多分中にはこれを定数に
してっていう人もいると思うんですよ
マジックナンバーだから
これどっち派ですか
えっと
まずサマーキャンペーン
に
サマーキャンペーン
って言ってるから
それ以上抽象化するんなら
多分話は
もしかしたら変わってくる
可能性はあるけど
もう少し抽象にすると
キャンペーンとか
キャンペーンで
なんかサマー
引き継ぎサマーとかウィンターとか入れたら
変わるとか
そういうのは多分ないと思うから
サマーキャンペーンっていうのが
存在が1つだけなのであれば
別に
持たなくてもいいとは
思うけどね
だから僕もそう思ってますと
で
これをどんどん
どっかのタイミングで
マジックナンバー定数に変えよう
っていうタイミングが多分あるじゃないですか
サマーキャンペーンの
割引ディスカウントってことで
今
サマーキャンペーンっていう
自明なものを出しましたけど
ちょっとずつ全然別概念で
ちょっとずつ
自明じゃなくなっていくグラデーションがある
と思っていて
どっかのタイミングで定数になる
みたいなの多分あると思うんですよね
ちょっとあの具体例全然考えてきてないんですけど
定数って
今そのサマーキャンペーンだけで考えると
定数にしようが
ないかなとか思ったりとか
あーそうですねサマーキャンペーンはそうだと
そう
でも
最近書いてないからな
あんま思い出せないな
でも意味を
ぶっちゃけた話だから
なんで4なのとか
なんで0.9なの
とかに回答できる
ものを
使うべき
だから
この文脈だと
サマーキャンペーンは
1割引きなんだ
で負に落ちるけど
それ以外で
今関数名と
その0.9で察しがつく
けど
察しがつかないときに
定数にするべきなんだと思う
まあそうですね
なんかいい例ないかな
その例が思い浮かばないけど
なんで
たださっきのいいよねリトライ回数
とかってなんでこのリトライ回数
なのってなるじゃん
文脈によって変わるから
し3にした理由とか
4にした理由が絶対あるはず
適当にしてたらだめじゃん
妥当性がないといけないから
その妥当性を説明する必要あるよね
でもその妥当性って
コードで絶対読めとれないから
コメントがつく場所な気がするんですよね
そこって
えでも
なんかコードで表現できんのかな
それを表現するんじゃない
難しいけどな
だから理由を説明できてればいいんだよ
なぜか
なんでこれなのみたいな
なんでこうなってるのとか
例えばさ
いくらまではとか
千円まではとか
五千円までは
みたいな
五千以降使ったら
一万円までは
重量課金だけど
一万円超えたら低額になりますよ
みたいな
じゃあなんで一万円なのとか
なんか
なぜに答えるわけではないけど
なんだろうな
なんだろうな
わかんないな
大抵コメントで補足されるケースが
多い気も
コードで表現
できそうっすか
フライス
なんかいいのありそうだけど
なんかいいのありそうですけど
だからその五百とか値に
名前がついてるもの
なんじゃない
わかりますよ
わかるけど全然例が出せ
だから
さっきの例だと
ここから低額
ですっていう
名前
にするのかな
でもそれも結局
じゃあなんでここから低額ですが
一万円なのか
っていう説明にはなってないですよね
説明にはなってないね
コメント書くしかないとやっぱ
社長が言ってたとか
でもここから低額
なのかすらわからないかもね
一万円だと
何をしてるのか
コード見ればもしかしたらわかるかもしれないけど
F文の中を読むか
F文だけ見ればわかるかの違いって感じですかね
だから低額
どちらかというと重量課金上限値
みたいな名前になるのかな
したら表現できてる
感じなんじゃない
そこになぜはたぶんもしかしたら難しいけど
なぜそれが
この値に決まってるのかは
わかんないけど事業的判断だから
よく言うのが
ワットじゃなくてホワイを書けってやつねコメントは
そうですね
ライブラリとデータ抽象の境界
でちょっとまた戻って
戻るか
どこまで言ってたか
さっきは
使う側の関心を振る舞いであって
値ではないみたいな話をいろいろとしましたと
オーダードットキャンキャンセルとか
でライブラリーの
イーナムみたいなのも
世の中には存在しますが
例えば
httpステータスコードとか
イーナムとか
になったりするかなと
定数だったりすることもあるかもしれませんが
じゃあそれは
基本的にバットリクエストとか
ノットファウンドとかあって
そこに振舞いがついてること
ほぼほぼないと思うんですよ
ただ定義されてるだけ
でそこだけ聞くと
データ抽象に反してる設計だなっていう風に
判断しようと思えばできる
ただこれは
あくまで
ライブラリーがこのバットリクエストとか
ノットファウンドをどう使われるかを
知らないからこういう設計になっていると
なんで
それをもとに何をするか判断するのは
ライブラリーを使う側が
バットリクエストだったら
何々とかっていうことを決めると
なんで
ライブラリーが使い方を知らないから
あくまでここはデータの
定義をしているだけですと
なんで
この使う側がその判断をする
クラス数などを一個定義して
その
ステータスイコール
バットリクエストみたいな
そこを一箇所書くための
クラスとかを用意して
使う側はそのクラスを呼び出す
みたいな
そのバットリクエストとか具体的なのは
そのクラスの
奥の方に隠されているというか
いいようなイメージですかね
直接それを使う
バットリクエストとかを
使うのではなくて
バットリクエストだったらどうする
バットリクエストだったらどうする
っていう
これしたいですって聞いたときに
今のステータスが
バットリクエストだから
できませんよとか返ってくるような
っていう風に
するみたいな
ライブラリと実際に使いたい
ところの間に一個挟むみたいな
イメージですね
これをすることで
データ抽象
が作れますと
データ抽象を作るのはライブラリの
仕事じゃなくてそれを使う側の
仕事ですよみたいな
最後の一番ピンとこなった
え?
ステータスコードだから良くないのかな
ほうほうほう
ステータスコードってライブラリって感じが
しないんだよね
でもまあ
そうなんですよね
イーナムではあるけど
ライブラリに付随して
くる
http系のやつらに
付いてくる部分で
受け取ったリクエスト
なんで
リクエスト.
ステータスみたいな
僕が
バックエンド脳で考えちゃってるから
バックエンドで実装するときってさ
ステータスコードを
ライブラリに頼るっていうよりも
ステータスコードを自分たちで決める側に
いるじゃん
決める側っていうと?
ステータスコードを最終的にはどういうステータスコードで
終了しましたっていうのを
バックエンド側の実装として
クライアントに返すじゃん
クライアントとしては確かにステータスコードって
そういう使い方するんだろうな
って思うんだけど
逆に
バックエンドの例で考えるなら
マインスケールとかの
エラーコードとか
あれはもう完全に
その後それを見て
我々どう処理するか
っていうのは
あるけど
いい例ですね
そっちの方がいい例
それは確かにそうかもしれない
バックエンド側だとそっちの方が
イメージが強くて
ステータスコードは自分たちで作るものだから
クライアント側だともしかしたら
ステータスコードの方が分かりやすいかもしれない
バックエンドのアプリが
クライアントになってる人の方が分かりやすい
ってイメージですかね
そうだねクライアント側だとそのステータスコードを見て
何かをするわけだから
そっちが
いいと思います
バックエンドサイド
なんで
だから
例えば
デプリケーションで
IDの重複が来た場合の
処理だとか
どういうことになるんだ
4000
2020
とか
そういう
だいたいの
マイスケのライブラリー5とかだと
ちゃんと名前つけてくれてる
何のエラーの
つけてくれてるから
それで
それを見て
500万台を返すのは当たり前
500万台返したり
例えば
これを無視してもいいみたいなのもあるかもしれないから
そういうのを無視したりとか
自分たちが決めるっていう話だよね
そうですね
なんで例えば
超ざっくりですけど
エラーですか
って聞いた時にステータスコードが
500何本かだったら
エラーですよって返してくれるとか
そのエラーですけど
エラーですかの中身が
これまでは例えば
なんだろうな
デュプリケートはエラーとして
なかったんだけどデュプリケートもエラー
として考えるようになりましたって
なった時はその中身にそれを追加するだけで
呼び出し側には影響ないみたいな
まあ全然話それるけど
重複をエラーに
するパターンってどういうパターンなんだろう
重複エラーって
既に作られてますよのエラーってことだもんね
うん
それをクライアントに返す時って
エラーで返す方が多いんじゃないですか
作ろうと思ったけど
もう既に作られてましたよ
っていうエラーになるんですか
あそうかそれで作られてましたよ
でユーザーはあもうできてるんだ
じゃあ検索しに行こうっていうアクションになる
ってことか
まあそんなとかかな
クライアントの実装で
流送信されてたとかだったらちょっとわかんないけど
まあそんなイメージかな
まあそうだね
そうなるか
うん
まあとか
外部キー制約でエラーが発生しましたって
なった時に
もうそれ作りの問題やんって思うんだけど
まあそれはもうシステムエラー
返すしかない
そりゃシステムエラーだね
ユーザーに促す行動ないからね
まあとかとか
そういうのを隠蔽してあげようね
っていうのがデータ抽象だし
データ抽象できない
ライブラリー側はデータ抽象として
定義できないから
その具体的な値を
ユーザー側に見せている
っていうここのが判断軸ですね
その人が判断できるんだったら
データ抽象にするべきだし
判断できないのであれば
値を返してあげる
っていう話ですと
でもうこれ最後
結論に入っていくんですが
マジックナンバーに
名前を付けて終わりではないよ
っていう話と
あと値を振る舞いの内側に隠して
データ抽象まで
進めましょうと
逆に言えばマジックナンバー
とかベタ書きされた
ステータス比較みたいな
があればそれはドメインの概念が
埋もれている証拠になり得ると
反射的に
点数に置き換えるんじゃなくて
そこにどんな概念が
隠れているかと
ここいいですね
あんまり?
いやそうです
その通りではあるんです
あと1秒
でその概念が
隠れている証拠その行為が
ドメインモデリングですよという風に
結論付けて終わりました
AI時代の開発とエンジニアの役割
何か
納得はしてます
ただ
書かないことには伝わってはいかない
と思うんで
書かないことには伝わっていかない
なんだろうな
それを書かれてて
負に落ちるんだけど
実際にするのは相当難しいよね
ここの難しさって何があるかって
技術力じゃ解決できない
何かがあって
ドメインって言ってるぐらいだから
振る舞いを閉じ込めなさい
意味を概念に
閉じ込めなさいっていうのって
なんだろう
概念を切り出す上で
業務を知らないといけなかったり
そのドメインについて詳しくなる
必要があって
だから本当に
本当の意味でドメインモデリングを
するんだって
言ってできる人って
そうそういないし
技術だけあったら逆に
よしDDD使おうって言って
ドメイン全く知らないのにDDD使ったら
まってへんってこのものができる
切り過ぎたりとか
だから
それをやるのは
正しいんだけど
その前提にはもっとたくさんある
よなっていう
それはそう
でもこの記事それまで話したら
全然別の話になっちゃうから
みんなさこの記事
そういう短くてコンパクトに収まってる
記事だけを見て
気になって手を出したりするんだよね
まあまあそういうもんですよ
それで手を出した時に
最後に嫌な思いするのは
レビューだから
まあ程々に
いやでもやっぱ
DDDとか学んでる時って楽しかったじゃないですか
楽しい
楽しいんだけどやっぱね
無理は分かってないと
作れんね
しかもさ
それって前提としてあるのが
だいたい全部分かってますよ
想定というか
どの部分を
ドメインの部分とか
だから切り出し方も
分かるけどさ
実際の開発の現場ってさ
自分が対応する
範囲しかさ
知識ってついていかないじゃない
しかもそれも手も動かさない
抵抗で動かしながら
待ってくれないじゃん
じゃあ俺がその100%ドメイン
100%覚えることはないけど
70%覚えるまで待ってとか言えないじゃん
だって市場に
いつ投下するかって早い方が良かったりとか
時期間とか後期とかあるから
だったらやっぱり覚えながら
技術も身につけて
とかってやっていくと
まあ局所的な
局所最適解を
なるべく避けつつも
なってる部分は出てくる
まあこれを塞いだったりするんだけどさ
だから
完璧にやるっていうのは
ほぼほぼ無理があるんだけど
でも逆に
どんなに頑張っても
やっぱり局所最適解になっちゃうよね
っていうのを受け止めた上で
できる限りの
最善を尽くすとか
未来に向けて開かれてる状態
変更に開かれてる状態を
意識するとかっていうのが
やっぱ大事になってくるんだろうな
まあそうですね
DDD勉強した直後って
なんだろうな
DDDもがっつり適応
そのモデルの設計を適応する方が
後々嬉しい部分もあれば
そんなにここに頑張らなくていいよね
っていう場所もあるわけじゃないですか
ただその頑張らなくていい場所も
やりたくなっちゃうじゃないですか
まあ
僕はあの
割とここを本当に
事前にやるってことを
学び始めてた時は
どうだったんだろうな
でもファットになったら
切り出すとか
それを本当に徹底してるから
手間だけどね
もしかしたらこうなるかもしれないから
事前にっていうのはいいけど
でもその最終形が訪れるかどうかも
わかんないじゃん
優先度が変わったりとかして
そのまま放置されたりすることだってあるから
そういうのも
いついかなる時も
今予定してる通りに
物事が進むとは限らない
っていうところで
今の仕様とか今の設計とか
やるべきことのスコープの中で
最小限の実装にとどめる
っていうのはすごく意識してるかな
いやでもやっぱね
これこうなるだろうな
と思ってやっちゃうわけですよ
それを本当問うようにしてるね
自分に
いやあと
経験側最内は
ちゃんと自分知ってますよって
アピールがてらやっちゃうところもあるわけですよ
あれでも突っ込まれたら
突っ込まれたら回答できないでしょ
いやだからこうだと
将来的に
だからこうしましたって言って
でもって言って論破されて
はいわかりましたって直すわけですよ
そういうこと?
あれ1セットなんだ
やっぱあの
多少ないとも自分って
この辺勉強してますっていうのをアピールした
気持ちもありますから
しょうがないですそれは
絶対言うもんな
その判断も
難しいですからね
その人なりに
1回のプロリーグの中で
すでにファットになってきたなって感じることも
あるじゃないですか
そうなった時に
ファットだと思って
切り出したつもりだったのに
これはまだこんなことしなくていいんじゃない
っていうレビューを受けることも
あるでしょうから
そういうケースもありますから
一概には言えません
いやでも懐かしいな
今そんな実装もしてないもんな
久しぶりに話したなこういう話
なかなかね
AIのせいでっていうのもあるし
そうだねないで
何をどこに置くとか
話さないもんね
確かに
いやー
今こういう会話どこ行っても
どこ行っても嘘だけど
なかなかしてないですからね誰も
いやー寂しい時代やん
だからねなんか構造
これどうするかって
設計の議論してる時間って楽しいじゃないですか
それが今や
あんまり機会がないですからね
それってどっちなんだよね
機会が
本当に機会がなくなってるのか
機会がなくなったと
錯覚してるのかだとどっちなんだろうね
いやないん
じゃないかなやっぱ
AIが出してきた
ものをレビューすることはあるものの
とりあえずやっぱり
自分の中で
完結させてしまう
そのレビューとかも
だからその設計に対して
誰かと議論する機会っていうのは
まあもちろん減っているとは
思いますけどね
でも他社レビューはそういうことになるんじゃないの
他社からのレビューって
そういう話にならないの
最近レビューもしてないから
わかんないんだけど
僕は
バックエンドの人間で
今うち
僕が触ってるAPIって
比較的シンプルだから
そういう設計思想では
そもそもないっていうのもあるから
そこではあんま起きにくいのと
あと僕は
クライアント側の
知見がだいぶないので
言われるがまま
ああなるほど
そうなんですね
もしかしたら知っている人は知っているのかな
とはいえなんか
昔に比べて
言われたら
議論するのも
面倒なのもあるし
言われたものに正当性があるなと
そのまま入ってて直すし
っていう機会の方が
多い気はしますけどね
まあ議論
した方がいいと思うけどね
まあまあそうなんですけどね
でも議論するって大変だから
アーキテクチャ
設計周りとかは
なんか突っ込んだりはするけどね
今でも話聞いたりとか
まあ今
コードも多くなってきて
既存のコードに沿った設計にする
っていうのが基本スタイルだから
あんまりそういう
根本的な設計部分に突っ込みとか
そろそろ入ってないとは思うんですよね
だからAIが
その既存のコードを見て
同じような実装はしてくれますし
大きくそれることはないから基本的に
既存の
コードもそんなにいいとは言えないからな
まあまあそうですね
まあでも大きくは
外さないというか
実装は
そうか
新しいことをする方がやっぱりリスクだと
思ってしまっているところもあるでしょうから
それは良くないね
とは言え
そこそこまたコードも大きく複雑になってきているから
なかなかね
でもそこでさ
それでよしってしてたら
成長止まっちゃうよね
それ以上の知識とか
例えば今の議論
さっきやってたような議論
どこに置く問題とか
じゃあこの
さっきのクラスにするのか
関数のまま置いとくのか
とか
新しい概念切り出すのかとか
ファットになってきたし
全体的にみたいな
話ができないから
そういうのが養われないと結構
拡張性が結構厳しくなってくるんだろうな
とか
だから趣味で
議論する分にはいいんですけど
やっぱ今AIが出てきているから
一生懸命議論していても
虚しいんですよ
でも結局AI側とかなっちゃうから
AIっす
開発
今の開発の現場だと
何を議論するの
開発の過程で
いや
そうですね
バックエンドとかだったら
クエリのところとか
こうした方がいいんじゃないとか
あと
既存
これも議論というよりは
既存こうしてるから
こっちに合わせてねとか
そのぐらいな
気はしますね
クライアント側はあんま
わかんないですけど
レビューがボトルネックになる
時代ではある
でも新規開発とかは
最近気づいたんだけど
新規開発とかは話したかもしれないけど
やっぱAI
いいよねって思っているんだけど
とある人が
今もうレビューすら
しないと
人間でも見ない
AIがレビューしてそれが勝手にマージされるみたい
まだリリースされてないんで
一般販売されてないものなんだけど
プロダクトだけど
マジかって思って
それ大丈夫なんて思ったけど
新規開発って考えてみれば
最初は意気込んで
品質品質って言ってるけど
結局時間なくて
何もかもが削られて
あと残ったのは実装だけみたいになる
ことを考えると
今はAIが設計書も残してくれて
テストも書いてくれて
一応のレビューもしてて
確かに新規開発においては
人間が寄ってたか
いろんな人間を投入して
思想も何もなくなって
塞いもたまりまくったけど
何とかリリースできて
動くものができた
よりももしかしたら
AIでやってたほうがいいのかもしれないな
って思ったのと
結局その時作った人が
残り続ける可能性も低い
大体そうじゃん
新規開発っていっぱいいろんな人投入して
その後は
ドメインを理解してくれる人たちだけが
残って開発をするっていうのが
常だから
確かにそう考えると
新規開発は本当に理にかなってるな
って思ったね
エンジニアは何を楽しめばいいんでしょうか
確かに
それできても結局
実際に
作ったものが使われなければ
意味がない
使うように
できるのはやっぱり
そのプロダクトを知ってる人しか
いないと思うんだよね
結局何かを
作るんだったら
そのことに
何の問題を解決しようと
してるのかな
この何の問題と
その問題の外を取り巻く
ドメインっていうもの自体を
知った上でやっぱり
グロースしていく
成長させていくっていうのを
できないと
ある意味でそれができれば
いろんな業界にでも通ずるものがあると思うんで
エンジニアとしてはやっぱりここを楽しんで
いくしかないんじゃないのかなって思うけど
リリース前
だと
ユーザーの反応もないし
ただ
こなしてるだけというか
リリースに向けて
まあでもそれは
イメージするしかないんじゃない
ワクワクする
作っててワクワクするときって
これができたらどう
どういう効果があるんだろうみたいな
のを無双して
夢見てワクワクしながら
作るわけで
あとはこれ作れたら
俺すげえっていう
自己満足をしたいがために作ってる
場合もあるし
まあそうっすね
AI使ってはいるものの
むちゃくちゃ使ってるわけではない
と思うんですよね
AIをめっちゃ使ってる人たちと比べて
もっといいやり方が
あって
それをする楽しさ
みたいなのもあるのかもしれないですけどね
まだ気づいていない
AIの使い
使う楽しさみたいな
すでにあるプロダクトかつ
意思決定の連続で
今見たら合理性がない
意思決定みたいな
のとかもあるわけじゃない
そういうのも
その当時に
おいては正しかった
正しいと思われた
決定なわけで
それを今見て
拡張バイアスみたいな
って言うけど今過去を見て
過去に対しては
いやこれ当然こうするでしょう
みたいな
っていうバイアスって人って
かかるんじゃない
AIもかかるのかもしれないし
こういうある意味での
エラーみたいな
歴史の中のエラーみたいなのを
今見たらエラーみたいなものを
どう吸収させるかが
わからない限りは
今の正当な
歴史を通ってきての
開発をAIに任せるって
難しいよなとか
そこ
コードだけじゃ読み取れないことって
たくさんあるから
そこをAIがどう
カバーするんだろうな
みたいな
将来的にすべてAIがやるようになるってことは
そこすらカバーできてる状態
っていうことだと思うんで
なかなかイメージしづらいんだよな
だからゼロから
作ってみて
っていうのが
いいのかもしれないけど
結局
使えるもの
カバーになるかどうかって
ドメインの
知識と
結局保守していかないといけない
わけじゃない
プロダクト売って
使ってもらったり
実際に無償で使ってもらうってなったら
その製品がダメだ
バグが多いとか
毎回リリースごとに変な感じに修正される
ってなったときに
そうならないように
今まで保護してきたのは人間だし
そこの担保っていうのは
確実に必要だなと思うんだけど
そういう観点だとやっぱり
AI時代だと
QAが
やっぱ大事なんじゃないかな
とか思ったりするけど
そうですね
まだ今んとこだってないけど
全員QAになるんかなって
思いながら
AIの発展の最初の頃見てました
そうだから
どれだけ
アプリケーションアーキテクチャの部分が
軽視されるのか
っていうのは分かんないんだけど
アプリケーションの中身が
どうなっていようと
別に修正が困難でないのであれば
今までは
読むっていう行為を人間がするから
構造化きれいにしといた方がいいよね
とか
変更の変更範囲が広いとか
変更漏れが発生するから
一応ちゃんと
ユーティリティとかまとめたりとか
あとはまあ
依存の向きとか調整したりとか
っていうのをしてきたけど
もしも
それがいらないんなら
QAに
どれだけ特化するかに
よってくるっていう話
いやでもテストを完璧に
かけるんだったら中身見なくて
いいと思うんですよね
そうだね
まあ
それだけ思えば
その未来自体も遠くなさそうな
気がするんだよ
ただ解決能力ってあるじゃん
うん
AIに任せます
AIが出てきた行動を
QAに通します
でもなんかバグがあります
ってなった時に
多分手動のテスト
自体は人間でもすると思うんだよね
難しいテストもあると思うので
そういうのを人間がやった時に
じゃあもう一回AIに任せます
またまだバグってます
止められなくなっちゃう
未来は来そうだよなって思っていて
止められなくなるっていうと
要するに原因を正確に
判定で見つけられずに
局所的な修正を
繰り返しし続ける
みたいな時に
そこに技術力が
必要だった場合
に解決できなくなる
未来がもしかしたらあるかもしれないよね
ない気がしてるんだよな
テストが完璧に
あるという前提だったらないと思ってる
テストが完璧って
だから
全ての機能を
網羅的に
やってるってことだよね
それは結局
もしも状態っていうものがあった時に
そこまで網羅
するテストって
作れないんじゃねって
俺は思って
バグが起こりやすいのはこういうところ
状態がこうだった時に
こう振る舞うんですよが
分かってない時に
バグとして検知されちゃうとか
計算処理とかも
事実付きになってたり
繋がってたりする時に
1回目がこうで
2回目がこうで3回目がこうの時は
こういう計算になりますみたいな
もう
テストで全部やれるかって
言われたら多分無理
やれるようになっちゃうんじゃないかって
思ってるんだよな
やれるのかな
データの準備と
テスト本気で書きまくれば
いけるかもしれないけど
むっちゃ
テスト得意なAIとか出てきて
この処理だったら
状態がこのパターンあるんで
全パターンだと
何百がありますで
このパターン漏れてますよとか言ってくれるやつが
いるんじゃないかみたいな
って思ってる将来的に
そうするとそれを一個一個
埋めていくまたAIもいて
それ埋めていけば
真のカブレッジ100みたいな
なって
そしたらこのテスト全部通してね
って言えば実装されるみたいな
中身ぐちゃぐちゃかもしれないけど
っていうのは可能性するとあるのかな
って思ってる
なるほどね
CIの時間とかバカ長そうだけど
そうCI
時間長そうだなって思うのと
時にシステムって
矛盾を払う
というか
なんかそれこそ
本来はこうあるべきだけど
こうした方がいい
ユーザー的には嬉しい
謎にみたいな状況ってあると思う
そういうのをどうやって
拾っていくかみたいなのも
テスト
機械的なテストって
そういう
矛盾みたいなのが苦手じゃない
そういうの絶対システムを
作っていく上では発生してくる
からそれをどうやって
拾っていくかっていうのは
課題になりそうだなって気がした
その違和感にも
気づいて
答えは持ってないけど違和感を気づいて
ヒアリングしてくれたりはしそうな気がする
それおかしいよ
なんか
ここちょっと
こうだったらこうじゃない
でもこうなってる
できそうだけど
メンテもむずそうだよな
どうするんだろうな
技術力いらないってことになるからね
そうなっちゃう
コーディングとかそっち系の
技術力はいらなくなっちゃうんだろうな
とは思いますね
依然としてシステムをどう作るか
アーキテクチャ部分も必要になってくる
とは思うけど
それ
なくなったらどうやって人は成長するんだろう
エンジニア
AIの使い方が上手であることが
技術力ですよ
失われた
技術になっていくってことね
コーディング
コーディングを
開始したことがあるエンジニアは
寂しいですねやっぱ正直
いやー確かにね
そこまで
でもまだ
世の中には
いろんなドメインに課題がたくさんあるのは
間違いないから
それを俺らエンジニアリング
でプロダクトなり
システムなりで置き換えていく
っていうのはたぶん続くとは
思うんだけど
その営みに対して
どこのスキルが
一番になるのかっていう
AIを使う
ものなのか
それとも課題を特定して
作るものを決める能力なのか
どっちも
だと思うけど
はい
ここで以上
話すのが長くなるんでそろそろ終わろうかな
はい
もう切りないね
じゃあ終わります
急に終わりましたが
ありがとうございました