バランスを崩さずに、モデルや、コードを直していくことって難しいよね - Magnolia Tech

モデル、新規に作り上げる時よりも、手を加える時に、最小の手の入れ方だとアドホック過ぎて将来の負債になる、完全過ぎると工数が爆発して今できなくなる 一方で元のモデルも決して悪くない さて、そんな時どうする？という問いかけに答えられるか？って話ですよ— magnoliak🍧 (@magnolia_k_) 2023年2月10日 この話、要はバランスで終わらせても良くないので、事後評価をどうするかってところを定型化するのかなぁって思ってる— magnoliak🍧 (@magnolia_k_) 2023年2月10日 おそらく教科書的には、抽象度がキープされるように修正しましょう、元の設計者の意図を踏まえて修正しましょう、依存関係のレイヤーが崩れないように修正しましょうって話になると思うんだけど、一方で修正しないといけない”難しくて複雑な”要件が目の前に有り、それを実現することを考えるだけでも設計

[turanukimaru]

綺麗に直せないならそれはクソコードだとっとと直せ。怖いのは手を入れるべきとこが間違ってるからだ。クソコードを書くのが怖いなら多態にしろ。元の設計が正しければ、元のコードには一行も触れずに機能追加できる

[asuka0801]

経験上事業内容や提供顧客の変化で大抵モデルはbreaking changeを余儀なくされるので綺麗なコードを壊して安定したらまたリファクタリングで綺麗なコードに書き直すというサイクルが回っている感じ。

[takahashim]

そんな場合なら、多少歪になっても極力元のモデル・コードに依存しないような形で追加するところから始めつつ、もうこれしかないという変更方針を見つけたら統合する、という作戦もありそう

[tattyu]

安定してるDRYじゃない超クソコードに機能追加しないといけないのを経験したら綺麗なコードマジで羨ましいと思うよ。

[dorapon2000]

“この話、要はバランスで終わらせても良くないので、事後評価をどうするかってところを定型化するのかなぁって思ってる”

[ledsun]

恐れに打ち勝つ話なので、問題を小さくする。スタイル修正みたいな、9割9分壊れなさそうな、小さい修正を入れてくのがいいと思います。そのうち何か見えてくるので、そしたら、覚悟を決めて本格的に手を入れる。

[ikkitang1211]

わかる…