ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくるやつの矛盾

>>2
責任とって辞めます。

>>664
Jenkinsは至るところで使われてるけど50行以上のメソッドなんていくらでもある事実

>>147
だからデグレは複雑なコードのまま変更するほうが
リスク高いんですってばw

>>447
すごーい君は国語辞典たくさん持ってるフレンズなんだね

関数の中のロジックの一部を他の関数に切り出して、カバレッジ100%のユニットテストで元のテストの
外部的振る舞いが変わってないことを確認して満足してた奴がリファクタリング起因の障害を発生させてたわw

意味不明

結局リファクタの成否は
客を丸め込んでデグレのリスクを飲ませられるかにかかってる気がしてきた

バージョンアップとかスピードアップとかなんかこじつけて
リファクタでデグレたら原因も無理やりそこに倒す

英検1級レベルに満たない奴はローマ字でコードを書け

もしかしてプライベートメソッドのテストをしてるとかかな？ｗ
それユニットテストじゃない

ユニットテストはモジュールのインターフェースのテストだから
変わりまくることはあり得ない。

もしモジュールのインターフェースという概念がなくて、
単に長いから関数にまとめましたみたいな、
なんでかしらないけど、この関数テストしづらいです。
なんてことをしてるのならそいつの問題

株式会社トップクラス

体力がなくて単純工すらできないごみクズがIT技術者(笑)になる日本では
コストメリットどころかリスクしかない。

>>595
リリース前も後も管理するのは当たり前

お前ら自分のことは棚にあげてるけど、スーパープログラマから見たらバカとお前らのレベル差なんて誤差みたいなもんやろ

糞コードいつか破綻するのはわかってるのに
そのまま売りまっくて最終的には極悪に肥大したクソコードのリファクタリングしろという
まずその事実を知っていて売り続けた開発部長やら上層の誰かに責任取らせろやハゲが

>>401
ミスった本人がミスだと言ってるわけですからミスですよ
いいやお前はミスターだとかそんな寒いこと言おうとしてるんですか？
やめてください

付加価値ゼロのコードを
何万行書こうとも
付加価値ゼロだからね

Eclipseなら最初から統合環境が整備されてるみたいな言い方だな。

>>101
あと仕様変更がないってことだろうね。

仕様変更があれば、少なからず設計を変更することになるから

コードがださいからリファクタしたい
気が滅入る

>>120
リファクタだけの問題じゃないが、リファクタも修正のうち
修正する以上人間がやらかすリスクはある

だったら修正は極力限定されているほうがいいだろ

>次修正する時、また改修時間（読む時間）がかかりますよね？
そしてリファクタ最大の問題
コードの読みやすさや理解しやすさは人の主観に大きく依存する

else取っ払ってタプル戻り値の関数に変えようとするやつもいるんだぞ

リファクタ後に修正したほうがテスト工数が削減できるとか、規約が新たにできたから合わせるとか
なにかしら明白な理由がないと

日々コードの形が変わっていくのをイメージできない初心者はIDDDでも読んでみたらー

>>47
そんな入門書の1章に書いてあるような話はいいよ、面白くないから

>>556
> リファクタの途中よりリファクタの前と後で結果が変わらないことを保証してほしいんだけど

だからリファクタの前＝コミットログの修正前
リファクタの後＝コミットログの修正後だろ？

リファクタの前のテストコードを変更せずに
リファクタの後でもそのまま通れば
変わってないことが証明できる。

あー、これ↓を言っておかないとダメなんだろうなｗ
結果が変わってないと証明された後、
使われてないと判明したコードは削除できる

リファクタリングの存在を否定できないと
困る人がいるんですよｗ

だから
リファクタリングなんぞ不要

数年後には業務変化の見直しと現在業務の確認のために、システムをまるごと作り直すから

>>186
> リファクタリングに時間がかかるって主張だよな？

なんでそう何度も曲解するの？
わざとだよね？

時間がかかるのは、コードの修正。
リファクタリングしなくても時間がかかる

入門レベルの奴でも上から目線になれるから張り切ってんのか

DBからデータを取り出してブラウザに返す仕事なんて、専門教育を受けてない文系でもこなしてるという事実

TDDってさ
組織的にガチガチにやるもんじゃなくて
設計者の間で守るべき密やかな秘密程度で
やったほうが良い気がすんのね。

トレードオフって何と何のトレードオフなんだろう？

最初から短い関数で書けばいいと思うけど、
関数を長くすることで、何のメリットがあるの？

>>368
妄想と現実の区別がつかない状態がこれです

>>641
それは当然だけど、50行とか平気で超えてるようなコードを書く人たちに
現実ってものを突きつけたいと思ってね。

>>40
修正許可与えてるなら、どんな修正をしたとしても
許されるはずだけど？

改修準備
調査分析
自動テスト作成
負債返済
利便性向上

少なくともこの5種のリファクタリングを日常的に行う
改修前のリファクタリングしか知らないならまだまだだね

>>614
（奴隷度）トップクラス

素人というやつは童貞だ
イカ臭いプログラム書いてろ
と言ってるようなもの

リファクタリング対象だな
対称でも対照でもなくて

>>396
意味を理解していようといまいと変換ミスは起こるものですよ

>>553
> 開発中の日々形を変えるコードに対してガチガチのテストを書くなって言ってんだけど、

テスト＝仕様を元に決まるものなはずだけど、
仕様が日々変わりまくるのか？

ならそっちが問題だなｗ

最前線なのに過去形とゆう矛盾wバカw

> が、ちゃんとリファクタリングとそれ以外は明確に別れる必要もある。

どういう意味で言ってるのか知らんが、これを読めばわかると思う

Martin Fowler氏によるリファクタリングのワークフロー
https://www.infoq.com/jp/news/2014/03/fowler-workflows-refactoring

> 機能を追加するとき
> バグを修正するとき
> コードレビューと共に
> Fowler氏は「二つの帽子」の比喩を引きあわせて、プログラミングのタスクをこなす際の、
> 新しい機能の追加（ファンクションの帽子をかぶること）と、
> コードの品質向上（リファクタリングの帽子をかぶること）について説明している。
> そして、「プログラミング中は、頻繁に、ことによると数分毎に2つの帽子を
> 取り替えることになるだろう。しかし、一度にかぶれる帽子はどちらか1つだけだ。」と彼は述べている。

一つのタスクの中でこれらは混ざるが、同時に二つを行うことはない。
その意味で明確に分かれるといってるのならそれはそのとおり

もう少し具体的に言えば、ある機能実装のブランチがあって
そのブランチの中でこれらは混ざることはあるが、コミットは別れている

>>302
ググらないとわからないならお前がにわかです

将来の改修や拡張の方向性がわからないのにんあことできるわけないだろ！

>>539
ユニットテストが壊れない程度のリファクタリング、つまり関数レベルのリファクタリングしかしない人にはわからないかも

>>569
外から見た時の動きが変わってなければ良い。
そして外から見た時の動きが変わってないが、
（テストコード以外で）使われていないメソッドを作ることは可能
そしたら使われてないコードは安全に消せる。

こういう話をしてます。

そもそも設計書からしてそんなに大量のメソッド作成するように書いてるのか？
設計書に書いた処理とソースの処理を一致させないと説明が面倒だろ

複雑なコードは壊すのがこわいからリファクタできない
簡単なコードは意味がないからリファクタできない

>>775
おまえも単価安い十天王の一角やんか

>>457
使用例は
意味がはっきりわかったときに「意味明瞭だ」と言うんだよ
これが使用例です、普通というのはあなたの日常では使いませんという
意味ですよね、それはあなたの語彙が足りてないから使えてないだけで
このスレであなたは新たな語彙を獲得したんだから、是非使っていって欲しい
と僕は思うわけです

>>290
テストファーストの手順の中に含まれるものだって話をしてるんだから
テストファースト＝リファクタリングなわけないでしょｗ
お前の日本語の理解力の問題だ

>>525
> 手動でもテストコードはあるんだが？

なら手動でバグを見つけられなかったことでは？
まあ手動によるテストは信頼性が低いからね

テストファーストはリファクタリングじゃないですよ

もちろんテストファーストをしないならリファクタリングはしないってことじゃないよ。
先に実装しても、その後テストコードを書いて、それが通るのを維持しながら
ソースコードを読みやすくする。これもリファクタリング

>>134
で？結局リファクタやると具体的に何がいいんだっけ？
色々話してるとメリットが全く見えなくなっちゃう

>>600
変更中で清書する前のコードならpushしねえよ

> ちゃんと設計できてないから改修する度にいちいち事前のリファクタリングが必要になるんだろうな

そりゃリファクタリングの必要がない場合にはリファクタリングしませんよｗ

前提として、リファクタリングの必要があるコードだって
ちゃんと書きましょうか？ そうすればもっとわかりやすくなりますね。

・リファクタリングをしない場合
1. ちゃんとした設計になっていない
2. そのままで無理やりバッファサイズを増やす
3. やってることが意味不明。変更に自信が持てない。コードレビューも大変。
4. 変更で問題が出やすい。そのたびに意味不明なコードと格闘する。
5. 関連箇所の試験して完了。

・リファクタリングをする場合
1. ちゃんとした設計になっていない
2. 設計を修正する（リファクタリング）
3. ちゃんとした設計に自然な形でバッファサイズを増やす
4. やってることが明確。変更に自信が持てる。コードレビューも簡単。
5. 変更に問題が出にくい。仮に出たとしてもちゃんとした設計になってるのですぐに修正できる
6. 関連箇所の試験して完了。

リファクタリングしたことで1工程増えたように見えますが、
ちゃんとした設計になってないものを無理やり修正した複雑なコードは
バグが出やすく、修正も大変になって時間がかかります。
それはわかるでしょう？

>>84
触らなければテストもしなくていい
プロは余計なコードも書かないし、余計なテストもしない

テストしないでコード整理するのも時には必要
あまりにも悲惨なコードに短時間で多数の機能を追加しなきゃならん時とかね
多少のミスは割り切ってリファクタリングして機能追加して全体を手動テストして納品する
俺はこれをエクストリームリファクタリングと呼んでる
厳密なリファクタリング信者からすると気持ちわるいかもしれないが生産性は高い

>>62
自動試験してレビュー通ったらシステムインしてサービス開始すんの？

>>757
それテストじゃなくて別の問題だよね

それなｗ

あと、リファクタリングするとお前責任取れるのかとか言ってくるが
機能修正でバグった時の責任はリファクタリングじゃないんだから
全部あんたがとれよって言うと顔真っ赤になるｗ

>>517
それは仕様がすべて文章化されていればな
実際はそんなこと不可能だし
変更した以上デグレは覚悟しなければならない

コードの優劣は、そのコードが生み出す経済的価値によって決まる
ただ綺麗なコードより汚くても利益を生むコードの方が価値がある
大して価値のないコードを一生懸命リファクタリングしてる奴には、そんなゴミ捨てて意味のあるコードを書けと言いたいね

つーかさ、誰も100%納得がいくまで
リファクタリングしろなんていってないんだよ。
修正する所、どちらにしろテストが必要な所
関係がある所を、少しづつやればいい。

時間がかかるっていうのは、それはいつも手遅れの
コードばかりだって自覚有るからじゃねーの？

WFとアジャイルとでも違うし
リファクタリングできる設計になってるの？
も大きな要素だが

動いているなら弄るなよは永遠の真理

正確に言えばコードの修正を始めるまでの
コードを解析している時間だな

たった一行の修正なのにこんなにするんですか！？って
言われるぐらいの費用になるのは、”コードのタイピング”には
含まれない部分がたくさんある

異世界に転生して洋食屋に行きたい

関数レベルのリファクタリングしか語れないレベルだということはお察し

リファクタリングが有効かどうか？
検証してやるよ。コスト？そりゃ当然かかるよ

ここで嫌がる会社が多い

重要なのは、失敗するかもしれないがやってみよう
という考えが通じる会社かどうかなんだろうな

個人的にそういうやり方をやってるってだけで
テストファーストとリファクタリングは根本的に異なり
完全に独立して成り立つものですよ