オーバーエンジニアリングしないために心がけていること - $shibayu36->blog;

オーバーエンジニアリングしてしまうという悩みがあって困っている、そのうち必要になるのではないかという気持ちになって無駄に抽象化して頑健にしてしまう。じゃあ素朴にやればいいのかというと、例えばDBスキーマみたいな要素は素朴になってはならないという難しさもある— Windymelt💀(めるくん)🚀❤️‍🔥 (@windymelt) 2024年9月12日 上のツイートを見かけたので、自分は何を心がけているか書いてみる。 結論 プロダクト方針的に起こりそうな未来を想像する 想像した未来が起こったとして、どのような実装になりうるかをざっくり考える その上で、その未来が起こったときに「詰む」ことがなさそうな一番シンプルな設計にする 前提: あらゆる未来の変更に強い抽象化はない 設計を考えていて複数案を出すと、結局トレードオフが存在することがわかる。案Aを選択すると、こっちの未来には対応しやすいが

[shiba_yu36]

プロダクト方針など情報を集めて確率高そうな未来を想像して、詰まないようにYAGNIするという話です

[hjmk]

こねくり回した設計になってて逆に身動きとれん時とかあるのでわかるわ。愚直な実装になってる方が後々リファクタリングしやすかったりする。

[nakag0711]

結局アーキテクチャの設計は未来予測なので難しいところ。まったく予測しない行動も期待値が低い

[xlc]

素晴らしいアイデアが出たらリファクタリングする、ぐらいの気持ちでまずは現状を受け入れないとプロジェクトが完成しない。

[syu-m-5151]

目指せ、最高のジャストエンジニアリング！！！

[Windymelt]

めちゃくちゃ参考になる!!! ありがとうございます。

[onk]

最終責任時点をできるかぎり遅らせる、だけ考えておけば良い。

[einherjar]

“プロダクト方針的に起こりそうな未来を想像する 想像した未来が起こったとして、どのような実装になりうるかをざっくり考える その上で、その未来が起こったときに「詰む」ことがなさそうな一番シンプルな設計にす

[s-nanagi]

アーキテクチャ設計や永続化層の設計など変更しにくいものは予測に基づいた方が将来の費用を抑えられる目算が高いことが多い。変更しやすいならYAGNI優先だが、妥当性の判断には結局はプロダクトへの理解が必要。

[door-s-dev]

オーバーエンジニアリングが具体的にどんなことの事指してるのか分からずなんとも

[naoH]

粗探しした結果物事が複雑化し結果的に低評価となる実例を見てしまった大家

[iseebi]

聞いて、感じて、考えて

[soybeancucumber]

日本のスタートアップのソフトウェアエンジニアはオーバーエンジニアリングしてやるぜ系が多いイメージしかない。技術は目的

[otihateten3510]

心掛けてる時点で多分オーバーエンジニアリグはしてると周りから思われてそう。一番むずいのはチーム間連携だよね

[chiroruxx]

最近は未来予測しないで、リファクタやリアーキを短く終わらせる方法を探したい気持ち。

[jiro68]

アプリはどうとでもなるがデータのモデリングはミスるとDB/APIに影響甚大で結構大変。フレームワークのORMとかに依存させないのが良いように思うが、それもサービス/データの想定寿命次第。

[Eiichiro]

今は名前しか登録がないけど、いずれ設定値が増えそうな項目をテーブルに分けておくとか。1対1想定だけど、もしかしたら1対N対応に分けておくとか。ただし初手でn対nのテーブル構造はつくらない。あたりかなぁ。

[cl-gaku]

自社ならええんやが問題は客のもん

[kuwayoshi]

想像していることは案外起こらない。起きてないのに考えすぎはムダ。

[yuno001]

将来は将来考えれば良くて、現在はシンプルにするのが良い以上のことはないのでは。

[n_231]

不確実な将来予想によって作るものの正当性が変化するので、レビューとかで意見衝突しがちなんだよな〜

[NOV1975]

正規化しすぎ問題みたいな話か

[w_bonbon]

つまる所YAGNIに帰って来る話なきが

[wwolf]

オーバーエンジニアリングぽくなってる所は意図を文書化してもらえると助かる