リファクタリングすると全部テストしろと言ってくる奴の矛盾2
■ このスレッドは過去ログ倉庫に格納されています
機能追加や変更した時に、全部テストしてるでしょ?
いつもやってることじゃん
前スレ
リファクタリングすると全部テストしろと言ってくるやつの矛盾
https://medaka.5ch.net/test/read.cgi/prog/1523765624/ リファクタリングしながらやると美しいコードになるけどやっぱり時間かかるな
複雑なSQLで一気にデータ持ってきて表示、編集させて、ボタン押したらこれまた複雑な更新SQLで一気にデータを更新
コードめちゃくちゃになるけど、これが一番生速度が速い 設計は遠回り
最初から最短距離見えてるんだからそうすればいい どうせ引き継ぎ用の説明書作らなきゃならないだろうに…。 >>402
設計は必須。
お前さんは書き込みする時に、カキコの影響とか考えるだろ?
それは広い意味での設計。
「設計書」と称する、実は設計書になってないゴミは要らんけどね。 設計・設計書要らない派が挙げてる仕事って、
1時間で終わるレベルのタスクなんだろうなって思う。
人と設計を共有したりしないでいいんだろうな。 だからコードで設計を共有すればいいじゃん
設計書を記述するための「プログラム言語」という専用の言語で
設計書を記述すればいいでしょう? >>410
プログラム書いて持ちよった結果
イメージが合って無くて全面書き直しになっても
直ぐに書き直せるのならそうかもな >>410
小規模ならそれもいいけど、大規模になったらそうもいかんのよ >>411
お前が言う「設計書」を書いて持ち寄った結果
イメージが合って無くて全面書き直しになるのと何が違うの?
全面書き直しが問題なら、単に早めに
レビューすればいいだけ。別の問題だろ >>413
それはプログラムと設計書の工数によって変わるだろ
プログラムより設計書の工数がえらい小さい場合は、設計書を持ち寄ってレビューするべきだし
工数がほとんど変わらないなら、最初からプログラムでレビューすればいい 設計書は長時間うんうんうなって完成させてから
レビューするもんでしょ
大規模なものなら、1ヶ月とかそれ以上かかって完成させて、
でイメージが合ってなくて全面書き直しwww 設計書は書き直すことなんてないよ
所詮絵に描いた餅なんだから
間違ってもOK。レビューなんてしない
間違いはコードでなおす >>416
いや、設計書書いたならレビューしろよw
何のために書いてんの? 建築業なら企画書→仕様書→設計書→図面→といった工程の中の
一部分であることが設計書の存在意義なんだが
この業界って仕様変更の頻度が高すぎて工程という前提条件が破綻してる
とくに下請けはプロマネのレベルが低くて無知だから何でもハイハイで
再見積もりも無しに平気で工程をまき戻していつものデスマーチ >>419
建築はしっかりしてるというような隣の芝生は青く見えるんだろうけど、
あっちもやっぱり似たようにgdgdだよ。
特に今は作業員に外国人が増えてるから意思疎通も大変だし。 建築業界に例えたらプログラマは何に相当するんだ?
○○に相当するとして、建築業界では○○に対して
ちゃんとした資料を渡してるんだろ?
だけどプログラマに対して、それと同じぐらいの内容の
資料渡してないだろ
って結論になるのが、この話題の最後になるのが目に見えてる >>421
土方だろ
だって俺ら鬼の副長じゃなくてIT土方だろ >>422
おい、先にレスしてるんだからその先を書けよ。
土方に渡す資料に
「4階建でマンションを建てます。
部屋はいくつで、階段、エレベータはここで。
詳細は全部任せます。材料とか適切なのを選んでください」
って書いてあったら、それ建築士が使えないって判断だぞ >>423
末端の土方はそれくらいの情報しか持ってなさそう
で、現場監督や棟梁には詳細な資料が渡ってると プログラマは土方に相当すると言ってのに
現場監督や棟梁に相当するって訂正かよw 将来的には絶対いいしそうしないと先がふさがるけど
当面の課題解決の理由として正当化できないせいで採用できない などと言い訳をしているところは
デスマ状態なんだろうってのがよく分かる
なぜならコード修正の見積もりには
予めリファクタリング分の工数を含めるものだからだ
その余裕も無いほどカツカツなスケジュールなら
デスマになるに決まっている 将来的に当たるかもしれない課題がある
でもそれは優先度低くてかなり先、一度後回しでいいやってなった
今回の改修は範囲狭くて緊急性たかい
今回のを理由に将来を見越した改修をしてしまうと、緊急性高いテストに関係ないモジュールまで巻き込まれてしまう
先で死ぬのが見えてるのに出口が コストカット原理主義が無くならない限りはリファクタリングの正当性を見出すのは無理だろうな
空いてる時間に今までのフィードバックをすることでよくしていくことが必要なのに空いた時間
そのものをコストとして敵対視してるのだから受け入れられることはない
空いた時間=余裕=コスト=絶対悪 になっている人が多い >>429
それならコード修正の見積もりもできないだろうね そりゃ正しいコードの姿が見えてないのに
コード書くのにどれくらいかなんて見積もりできないだろw
それか修正前のコードがどんなに汚くて
修正箇所が大きくテスト範囲も広くなろうが
修正前のコードが綺麗でわずかの修正で解決できようが
全く同じ工数で修正できるって考えてるアホかのどちらかだ 正当化できない理由は>>430
コードの正しい姿とかどっからでてきた話だ 言語やOS、ライブラリ、フレームワークなんてのは変わり続けてたり、変わらないことで
使えなくなることがあったり、使用者の習熟度が上がるなんかでも変化するから正しい
コードの姿なんてものは幻想だよ。
極端な話、変更がなければリファクタリングなんてしなくてもいいがOSバージョンアップは
ほぼ確実に数年単位で起きるしそれに対する対応としてはリファクタリングなりなんなりの
事前によくしておくというのは必要なんだよな。 >>435
え? コードを適当に修正してんの?
動けばどんなコードでもOKって人? >>436
> 使用者の習熟度が上がるなんかでも変化するから正しい
> コードの姿なんてものは幻想だよ。
コードの話をしてくれないかな?
お前が言ってるのは使用者の習熟度の話
お前が言ってるのは、正しいコードはあるが
それを使用者が理解できないって言ってるだけだろう? >>437
おまえは自分の頭にある筋道以外の話が理解できんのか >>431
テストやリファクタリングをサボって、コストカットしたと勘違いしてるのが多いけどね。 >>441
そもそもそこまでコストカットする必要はあるのかっていう話だな。
お給料=コストなんだからコストカット自体は自分の給料を減らすものとして考えなきゃ
ならないわけで、なんで自分の首を絞めることに肯定的なのかなあと。
効率化自体はかったるい作業をかったるくない作業にする自分ために必要なことだが
効率化しないと評価下げる、お前は低評価だみたいなのは違うだろうと。 資本主義の世界だと自分の成功とは他人より成果を出すことでつまり他人が失敗すること
つまり望まれてるのはお前がコケて失敗することなんだ
それでまわりが幸せになる
おまえの上司は
お前が失敗しないことを理由に地位と給与を下げ、失敗したことを理由に地位と給与を下げるだろう
成功者の側に立とうと思ったらうわべに隠された別の道を通らねばならない >>442
費用対効果って概念が抜けてる現場は多い。 >>444
だからそんなバカバカしい定量化しづらい、出来ない概念を信奉してるから
ちょっとした計算違いでどんどんドツボにはまっていくんだよ。
金は貯めたり削ったりするものじゃなくて使うものだという認識が出来てない。 減量が必要なボクサーじゃないんだから無駄なんてあっていいの、あって当たり前なの
そんな当たり前のことが分らなくなってきているから作業量が増え続けて仕事が楽に
ならないんだよ。
過労死するとかそれに近い状態が幸せなのか? どうでもいいけど、
少なくとも給料上がった分くらいは効率化しろよ?
新人雇った方がコスパ良いとか笑えないから。 われながらクラスとメソッドの名前がひどい
壊滅的な英語センスと気まぐれなルールで
日本語との対応や分類がえらいことになってる
名前かえるぐらいさせろよ 小売業者が定期的にやってる棚卸しみたいなもんだけどな リファクタリングは日々一人ひとりがやることだから
棚卸しのようにまとめてやる行事とはぜんぜん違う 正確には無能がする日課のオナニーみたいなものやけどね システム刷新の前にリファクタリング少しでもやると効果的なんだけど余計な手間だろって却下される
古い言語で書かれたゴミを新しい言語で書かれたゴミに刷新しても意味ないと思うんだけどな 定期的な整理をしないと肝心なときにぐちゃぐちゃになる
んで、緊急だっつって慌てて直してカオス化が進む
そーなる前に整理しろってそんだけの話でしょ
なんか難しいところあるか? 整理整頓するつもりで散らかし放題やから無能と呼ばれとんのやぞおまえw 整理整頓するつもりで
整理整頓してればいいだけでしょう? 整理整頓した結果が前よりマシになる保証がないことを奴隷主どもはよくわきまえている
まともな整理整頓できるぐらい理解が進んでたら
そもそも整理したいって思わないことも多い リファクタリング何ぞ不要
その頃には丸ごと作り直せ 自動テスト出来るならもうかなりキレイなコードになってるはず
リファクタリングが本当に必要なのはテスト困難な汚いコード
リファクタリングはテストと必ずセットだって常識は間違っていたのかも知れないな
テストしないでリファクタリングすることも時には必要
これをエクストリーム・リファクタリングと名付けよう
みんなこのワードを流行らしてくれ
流行ってるなら本番でも採用されるから 最初は何とかなってたのに
あれがたりないこれがたりないってプライベートメソッドが増えて
にっちもさっちも行かなくなった…
リファクタしたいけどテストできなくなったからリファクタできない 規模にもよるけど、機能の変更や追加依頼があった時にその部分だけリファクタをやってから手をつけてるなぁ
もちろんそれ込みの見積もりを出す
依頼もないのに勝手にリファクタやることはないわ なんでこんなに変わってるんですか?
工数を増やさないでください
勝手にやった分の料金返してください 本当にリファクタリングを綺麗にできるのなら、
そもそも設計が綺麗だから、リファクタリングなんて不要だろ?
まともに設計できずにぐちゃぐちゃ書いた奴が、
リファクタリングなんてできる訳が無い。 >>468
コードを修正する必要がないなら、
最初からきれいに書けるよ
実際には機能追加、変更、バグ修正などで
コードを変更する必要があるから、リファクタリングが必要なんだよ >>469
そうだね。
まともに設計できない奴はそうなるね。 まともに設計できるかどうかじゃなくて、
将来を読めるかどうかだろ?
将来大規模になるなら、大規模な設計をするし、
そうでないなら小規模な設計をする
規模に応じて適切な設計は変わるのに
最初から規模が読めるとでも? 最近は設計できない奴の言い訳がすごいな。
まともに設計できてればそんなことでリファクタリングは発生しない。 そりゃ先の先の先まで考えて
必要ないことまで設計することだろw >>474
クソコテの戯言はおいとくとしても
設計はコーディングとちゃうで?それはコーディングの話や 日本人は年末の大掃除が文化として根付いてる
なので「日々整理整頓してクリーンな状況を維持しよう」って外国人なら当たり前の感覚がどうしてもわからない
民族・文化のレベルでITが向いてないんだよね 設計を受け取ってコードを書くだけの人ほど>>472のような勘違いをする傾向が有るね
ドメインへの理解度は開発をすすめるにつれて深化する
ビジネスルールやニーズは時間経過で変化する
という2つの大前提を理解してないっぽい >>477
クソコテに反論したからと言っておまえがコーダーである事は隠せんよw もうコテも信用できない
俺だってKACのふりぐらいできる >>477
設計できない事はよく分かった。
つか、開発プロセスすらまともに理解できてないんだな。 リファクタリング出来る環境あるならテストも自動化されてるだろうに、何が問題なんだろ? テストが自動化されてる現場なんてあるわけじゃないか!
だからリファクタリングは禁止! まさか、人力でリファクタリングしといて、インターフェースは完全に互換だとかのたまうアホなん? 完全に互換です
動き違うのはもともと定義外の使い方してたからで
既存バグです
正しくなおしたわれわれのせいではない 齟齬があるのに観世互換とか、日本語が使えないのかな? リファクタリングして、コードのメンテナンス性が上がって
メンテナンスに時間がかからなくなると、時間を節約で金になるんだよな
これをわかってないやつが多い ソース付きで売り切りの開発にリファクタリングなんて不要 ソースコードがなにもないところから生まれてくるとでも思ってるのだろうか? 切り売りするにはリファクタリングされきって
綺麗な設計になってないと無理だからなぁ あ、無理っていうのは不可能って意味じゃないよ。
切り売りする時、綺麗な設計になってないと
修正が大量に必要なってコストがかかるという意味 >>494
ネットに落ちてるのはバグばかりだよwww >>495
売り切りなのに修正なんてあるはず無いだろ。
修正するとすれば、購入した顧客側の仕事だしな。 >>497
じゃあ売ってる使えないコードってことか
詐欺という仕事も、そりゃありますよねぇwwww ■ このスレッドは過去ログ倉庫に格納されています