バックエンドの設計で直したほうが良いコード9選

バックエンド兼インフラエンジニアのrevenue-hackです！ 今回は今までバックエンドエンジニア10年くらいやってきて、「これはまずいなー」と思ったコードについて紹介していきます。 ↓記事はこちらに移しました！↓

[fai_fx]

“見ればわかることをコメントに書く必要はないですね。。。”…見て分かるのは今だけ。

[superchibita]

20年前の記事感ある。

[hatest]

「fatする」がルー大柴の声で再生されるので、最後に「togetherしようぜ！」で締めるといいと思う

[versatile]

たしかに古いイメージの記事だけど、結局現場で動いてるコードってこういう内容をガンガンはらんでるよねぇ。

[tamanecoplus]

/* ここを直すと動かなくなるから弄るな！ */

[shikiarai]

いまだに人類はここ。新しい人も増えるからいつまでもここ

[daira4000]

昔から言われてるよねーって感じ。普遍的よね。

[raamen07]

フロントエンドで直すのではなくバックエンドで直した方がいいこと ではなかった

[uchiten]

今日！エラーを握りつぶされたコードのせいで！大変な目にあった！！

[n314]

utilはfatしてもいい派かなあ。ハッシュ化は無し、バリデーションではないoptional型的な空文字チェックは有りかな。表示用の日付整形とかDB用に配列を整理するとかのIO境界でよく使う。

[sigwyg]

古来から言われるリストだけど、UtilとかCommon誰にも使われない問題と、エラーは発生した箇所で投げるべき、てのは特に同意。

[NOV1975]

色々と納得できない。ここに書かれてるような問題が起きるのはそれなりの規模のシステムだろうから共通系の設計と管理が核心。コメントは設計書と即座に対照できるためのものを当たり前でも書いておくべき

[twotiger]

fatする？変な言葉

[kmaebashi]

utilは太ってもよいのでは。その中で、ちゃんと分類整理されていれば。

[mookie]

突っ込む気で読んだけど、おっしゃる通りです。反省しています。確かに命名は命なので魂を込めたい

[ultimatebreak]

人間の脳は設計の最適化に向いていないのが良くわかるね

[tettekete37564]

バックエンド関係なくね？言っていることは経験が浅かったり、人的・時間的リソースが十分でないとやってしまいがちな奴なのでその通りなのだけど。

[yarumato]

“バックエンド10年。困ったらときの関数置き場になるutilは作るのをやめよう。 状態管理するクラスにsetter導入すると変更して良いという意図を伝える実装に。ドメインモデル(Class)はルールも書いてカプセル化”

[homarara]

chatGPTがもうちょい進化して「リファクタリングして」「テスト書いて」で済むようになるまで粘る。

[osamu0329]

> 偶然同じようなコードになったからと言って共通化するのではなく… ほんとそれ。utilも下手に外部から利用されると不要な依存関係の原因になる

[dlive1]

バックエンドの良くない設計「困ったらときの関数置き場になっているutil」⇒そもそもutilを作るのをやめ「状態を管理するクラスにgetter, setter導入」「責務を複数持ちすぎクラス」

[nharuki]

あーーーあるあるあるある！！utilブクブク肥えるのちょーわかる！ある程度膨らんできたら切り出すようにしないとアカン

[nunulk]

「コントローラーにデータ取得処理も実装している」のは別に問題なくて、往々にしてデータ取得のロジックの詳細が記述されてしまうのが問題だけど、例示されてるコードは問題ないように思う

[sakuro]

「fatしてくる」という不思議な表現 (意味は分かる)

[mayumayu_nimolove]

秘伝のタレとか抱え込みすぎクラスとか面白い