  |
DRYやSOLIDは的を外している その原理原則を使えば幸せになれると、誰もが夢見て、挫折していく こういった言葉はほぼほぼ全てプログラミング初心者を挫折にいざなう プログラミング界...
まあ、言いたいことはわかる。目的と手段が入れ替わると。ただ、DRY と SOLID が守られているコードが良いかはともかく、守られてないコードはゴミだ。
実経験から行くと敢えてDRYを守らないパターンは稀によくある。
必然的にDRYなのか偶然DRYなのか、前者はDon't repeat yourselfだし、後者はDo repeat yourselfだ
いまなら shoud not repeat yourself かなあ。そう考えると。
稀によくある、ってどっちやねん。確かにコードの共通化は諸刃の剣だよな。変更に弱くなるし、絶対に分離しないと確信できなかったらやらないよね。
ステークホルダーが複数いたり継続的にアップデートを行うB2CやB2BのサービスだとDRYは理想論だなってなる 結局仕様や目的がガチガチに固められていて将来にわたって変更が無いと確信...
すいません、マジになるとは思わんだ。しばらく働けば、その感覚はつかめるよね。それは、そう。
エンジニアリングの特性なき人間がプログラマーやってるのが間違いだと思うのよな 理解すべきことが理解できないってそういうことよ
まぁ優秀な人材は不足するからね。アーキテクトとマネージャーは分離すべきかと。
数学とCSの素養の無い人間はそもそも採用するべきではないんだけど、業界全体が人手不足だからか採用してしまい、それに合わせた実装になってしまっているよな。
昔は専門卒や文系も多かったから、今も昔も変わらんと思うがな。
で、糞コードができあがるわけですね。日系企業あるある。
仕事で書くのであれば稼げるコードが良いコード
メンテナンス性が低すぎて、5秒でそんな修正できるだろ？ってのに1人月かかりますっていうSIerが正義みたいなこと言うな。 そんなレベルでは海外のまともなtech企業には間違っても入れ...
商用コードが直ぐに修正できるわけないやん。テストやQA、とかプロダクションにデプロイすることやフロントエンドと互換性を保つのを考えたら、それなりに時間はかかると思うよ。日...
15
