リファクタリングをただのコード修正と思ってる人へ
■ このスレッドは過去ログ倉庫に格納されています
テストも書かないでリファクタリングとかうけるｗ Eclipseのリファクタリングは名前変更もリファクタリングのひとつなんだよなあ リファクタリングは結果ではない。 本当のリファクタリングを知ると、 >クラス内部で別のクラスを生成しない（必要な場合は外部から渡す） リファクタリングがしたいと思ったとき、 正直名前変更くらいしか使ってないな、それでも相当便利だが >>8 XXXはXXXXXであるべき、なんてXXは全くもってXXXだ。 >>1 ごめんなさい。取り乱しました。 このスレッドは天才チンパンジー「アイちゃん」が リ略をただのコード修正だと思わないでよ え…あぅ……わ、私そんなんじゃないのに… なんか決まりがあって、そうしないとダメだって言ってるような頭固い人間がプログラムしてるのが間違いだろ。 >>12 リファクタリングって流行らないね。 ウェブアプリの場合、同じ問題が >>26 >>27 社長に今なにやってる？と聞かれてリファクタリングしてます、と答えたら リファクタリングがなんなのか、メリットとデメリットについてなど >>30 理解させるには分かりやすいたとえが必要だと思う。 そもそも本当に１階にも手を入れないと倒れるのか？ 理解のないシステム 会社はそれだよね。腐ったシステムを抱え続けると将来的にどれだけのコストになるかわかってない。 リファクタリングの重要性のわからん上司にどうわかってもらうかでずっと悩んでいたが、 リファクタリングしていると、仕事を押し付けてくる奴がいてうぜーよー。 >>39 >38 組み込みスクリプトってLuaとかあるし普通じゃね、と思ったら >>45 リファクタリングなんてやって意味があると思ってる奴は消防 共通処理をまとめるだけがリファクタリングではないし、 >>50 どこの幼房かしらんが、 >>53 >>54 >>54 >>55-56 素直に継承するとか、デコレータパターンとか >>57 >>60 結局>>49 =>>52 =>>54 =>>57 =>>61 が何言いたいのかわからん。 >だが、現実は絶対にcase Aを入れる >>49 はコーダーのレベルにすら達することの出来なかった落ちこぼれ 元々>>49 が意味不明なこと言っているのが原因だろ。 >>49 =>>68 が具体的なコード出せ。そうしたら反論してやる。 >>69 >>70 >>49 を読んで意味が分かるのは池沼のおまえだけだ。 >>71 >>49 はリファクタリングの前にオブジェクト指向を勉強したほうがよい よくわかってないプログラマとか 文字列は切り分けたほうがいいよ >>77 こりゃまた、もの凄い珍説が飛び出したもんだ。 「必ずしも分かり易い名前を付けてくれるとは限らない」 >>81 >>82 >>83 いや俺の脳みそ云々の問題でなく、矛盾してるんだってば >>85 >>83 での「だとすれば」がどういう意味もってるのかわからない グローバル変数を使わなければ管理が要らないなら >>89 >>91 >>92 >>93 #define 使うな、までは同意できたんだがなあ… リファクタリングなんて、簡単な概念でしょ。 >>99 高速化は変更の具体例として挙げているだけで、 >>101 >>103 >>103 ＞インターフェースが変わりますって他の開発者への通知が >>108 おお、Javaがやってる方法じゃん DeprecatedやObsoleteは そう。どの言語でもやってる。 「なんかこう、俺とは一段以上下のレベルの奴しか見当たらんよなｗ」(キリッ >>112 めんどくさいからコードに対する変更はもう全部リファクタリングでいいよ >>109 JavaのPGやってるけど やっぱり目的が意味不明 >>119 >>120 時間と共に増大する複雑性への対処では。 果てしなく続くメンテナンスと機能追加を前提として 何いってるのかさっぱりわからない >>122 >>123 >>125 >>127 余計なもんなんかいれない。 >>129 >>130 >>129 >>132 >>132 >>135 >>136 >>136 >>137 この表現でわからないならデザパタ使うと出てくるゴミクラスなんか全部該当すると思う >>139 >>141 デザパタでぽこぽこ生まれるゴミクラス問題は http://www.norvig.com/design-patterns/ >>143 他の言語では作る必要の無いクラスを作らされたら 他の言語では、定義する必要がない型を >>148 うん。だからそれは、インターフェースを守った きっちりしてるというのはどういう意味だ？ >>152 >>153 >>154 このように、言語によって >>156 ただなぁ， 世に存在するうちの設計書で, 仕様書は役に立たないがテストの手順書はとても役に立つな 仕様書とソース・プログラムの挙動が不一致ならバグ認定、即修正 >>160 >>134 うちのプロジェクトjavaソースだけでついに1万個を超えた >>163 javaでもすでに10年物のソースコードとかあるからな リファクタリングとか、 >>166 ＞リファクタリングとか、 > 「既存の動きに影響を与えない方法を使ってコードを修正すること」 >>169 ユーザーインターフェースかわんなきゃリファクタリングと言ってみるtest > 仕様をリファクター 仕様変更にまで手をいれない修正だったら俺はする意味ないと思うけどね 試験とか全部やり直しになるけどそこまでコードに重心置けないです >>174-175 >>176 単純なシチュエーションだと、今動いているものがあって >>179 >>177 仕様書を大雑把に >>182 リファクタリングの価値は 寧ろそうやって放置されたコードのメンテナンスの際にESP能力を発揮しながらリファクタリングして日銭稼いでますが何か。 >>184 >>186 >>187 >>186 >>188 >>189 http://www.os.cis.iwate-u.ac.jp/wikky/wikky.cgi?%E7%AC%AC2%E7%AB%A0%EF%BC%9A%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%E3%81%AE%E5%8E%9F%E5%89%87 >>192 >>193 >>191 重複の除去が有効とか書いてあるじゃん 別にいいじゃん >>199 ちなみに >>198 は >>200 >>202 >>203 >>204 うちは少数精鋭なんで（使えない奴はやめさせられる） >>205 >>207 重複コードを作ると、納期が延びます。 >>209 >>210 >>211 数字を出しさえすればそれが全てだと思い込んでいることはよく判った。 >>213 >>210 >>213 >>216 正面から反論できないときは人格攻撃になるんですね >>219 >>220 トレードオフ考えてやるんだから トレードオフはコードをまとめる話だろ？ 汚いコード >>225 >>224 >>227 >>228 最高 綺麗で動く >>232 使用がバッチィからコードもバッチイって発想はないのか？ 仕様が汚いと動かすのが難しい >>234 コードを綺麗/汚いで語るから話がおかしくなるんじゃないか。 >>236 もちろん設計の問題とコードの綺麗/汚いは関係ありますが？ >>238 >>238 >>240 関数、クラスの仕様は変わっても 設計を仕様と見なしたら aとかbとかわけのわからん変数名を I/F変更を伴うかどうかっていう観点じゃないの 結局、 >>248 >>249 >>250 >>251 >>248 がえらそうに宣言してるから>>248 に決めてもらうか (この人たち、なんで今さらこんな議論をしてるんだろう) そうか、リファクタリング本を読んでるのは俺だけだったか >>255 そういう手合いはおそらくよんですらいない 改修が必要になったときに初めて リファクタリングを身に付けるとコードレベルでの設計力が上がりますか？ 設計力は下がります 設計力あがるだろ >>49-52 で結論は出てる オナニー？ 自己満足と言いたいのかもしれないが。 密に結合した処理を処理を疎になるようにするとか >クラス内部で別のクラスを生成しない >>4 のこの話って完全にはDIでも使わなきゃ無理だけど、 言葉の揚げ足取りに終始しててウザいだけのスレになっちゃってるなｗ 大規模アプリには VB6で幾度となく機能追加が行われたコードをぼんやり眺めてると >>272 趣味でやるならすごく楽しい。一人でやるのなら絶対リファクタリングしてる。 リファクタリング本はかなり勉強になったな。 リファクタリング中にバグが見つかっても修正しちゃいけないんですか？ 好きにすれば？どうせ個人でやってんだろ 業務でリファクタリングの時は、バグの種類にもよるけど基本的にはそのまま。 バグを見つけるためにリファクタリングをすることはあるが リファクタリングとは 上を納得というか安心させるための無駄検証にコストを掛けた後だと >>282 でも実は一発目無計画で作ってリファクタリングするのが一番品質がいい 一発目無計画っていうのがありえなさすぎ。 >>287 神ならざる身で限界を知りつつも最善を目指す手法ではないか 考え方の違いなんだよね。この業界に「ボーイスカウトの規則」っていう言葉があるらしい。 http://qiita.com/hirokidaichi/items/d6c473d8011bd9330e63 そういう自己満足だけの身勝手な修正が一番たちが悪いんだよ >>292 >>293 コードがスパゲティになってしまって、 今どきスパゲティコードなど、そうそうお目にかかるもんじゃない リファクタリングするもしないも、そのソフトの特性や現場事情があんだから、 >>296 リファクタリングする前のコードを保存しておいて >>300 >>288 最近ソフトウェアが壊れていくプロセスってのが クソコード書いて、次は誰かがもっといいコード書くだろうからそれマネしようとか思ってたら >>305 仕様書が別になってたらどんなに処理が似てても別にするなあ 似てる処理を共通化できないのは設計がきちんと出来てない証拠 いやあるよ。 >>309 >>310 >>311 >>311 func1(){ >>312 >>315 >>316 人間は細胞でできているだろ 共通化するときの決まりの一つとして、 >>317 経験的にforの内部、ifの内部は関数にまとめると都合よいことが多い >>320 >>323 共有化するには物事を抽象化するセンスが問われるから、 クロージャｗメタプログラミングｗ 自分の経験上、>>328 みたいにプログラミング言語の機能の話を 自分と同じドカタ仕事してる奴以外は 自分の経験上、リファクタリングしたがる奴は例外なく低スキル。 アホSEがExcel仕様書の罫線を二重罫線に書き換えて ２重罫線を大事にする客だって多いわ。 工数改善の見通しが数字で説明できるならともかく 受託開発やってるところと 受託なんてドカタを人月で売って稼ぐビジネスモデルなんだから、 >>340 >>341 自社サービスで食っていけてるってだけで圧倒的な成果だろうな SEが設計してコーダがコード書くってスタイルと SEの設計が日本語プログラミングになってるからな。 >>346 リファクタリングは1にも2にも自分のためにやるものだ >>346 リファクタリング否定派は技術力に乏しく低脳という風潮 どう考えてもすぐリファクタする方が低脳だろｗ >>352 >>353 そんな奴、実際には見た事無いが >>354 コードオナニストは、常にコード以外の観点が欠けているのが特徴。 >>356 > 散々テストしたはずなのに客先に持ってったら動きが変わってて >>359 >>360 >>359 完璧なテストとか言う以前に、 >>358 のケースなんてコードがマージされるはずない） Excelで書かれたチェックリスト片手に手動でテストして >>336 仕様変更でもバグ修正でもいいが、 ネストが揃ってないとか空行が多いとか 変数定義の位置を移動したりスペースを除去したり 失敗例をあげてリファクタリングは糞って言ってるの最高に滑稽。 リファクタリングが糞なんじゃないよ >>371 新人はリファクタしたがっていかん 技術レベルの低い人ってのは初心者に近くて 生理整頓した状態を維持しながら仕事しろよｗ >>375 リファクタリング本を一回読んだとき何を感じるかだよな。 クソコードを普通のコードに直す作業をあんまりリファクタと呼びたくないｗ リリースした後でバージョンアップのついでにやるもんだろ ボーイスカウトの法則といって、 規模が小さいうちは手抜きで簡単なコードを書くだろ？ 権限のない末端PGが現場の手続き無視してユニットテストのないコードを >>383 最初から厳密に書けばいいんだよ 人間誰しも、最初は初心者で >>386 大体最初からある程度ちゃんとしたプログラムも書けないやつに 関数の中身やprivateな関数のインターフェースを修正するようなリファクタリングと、 初心者にオススメなのは、派生開発でコードを読むときに、動作確認をテストで書くことかな。これはとっつきやすい。 リファクタリングするなっていってる奴がいるけどさ、 >>390 >>390 当たり前のことを当たり前に理解してそれを前提としている人と、 ウォーターフォールだったり、詳細設計書で日本語プログラミングしたりしてるとこと うまくいかないんじゃなくて どうしても自分が書いたコードを書きなおしたい人がいるようだけど 前向きって新しいコードを書くってこと？ >>397 みたいな事言ってると、拡張を繰り返すうちにコードが保守不能なカオスになって 全部捨てて作り直しだーまで追い詰めるって馬鹿だと思う。 >>400 >>403 よくある設計とコーディングっていう役割分担からしてくるっとる。 「前向き」って言ってる奴が、 もう最近ガチガチの詳細設計やるとこって殆ど無いだろ 一応UMLでシーケンス図とクラスとPublicメソッドだけはきっちり作ってるな >>409 >>411 まあありがちやねｗ >>953 Ａ社に発注して作らせた大規模なソフトを、 リファクタリングはアートですよ。 わかる、わかるぜ〜 やべえ。 他人のコードだと思って、何の前情報もない状態でコードを読み リファクタリングの誤用 ちんこの振る舞いを保持したまま変化させる、もちろん性的な意味で。 インタフェースの変更はリファクタリングか http://capsctrl.que.jp/kdmsnr/wiki/bliki/?IsChangingInterfacesRefactoring http://capsctrl.que.jp/kdmsnr/wiki/bliki/?IsFixingAnUnknownBugRefactoring http://capsctrl.que.jp/kdmsnr/wiki/bliki/?IsOptimizationRefactoring http://capsctrl.que.jp/kdmsnr/wiki/bliki/?IsDeclarationOrderingRefactoring あれもこれも取り入れた「オブジェクト指向」とまるっきり同じパターンだな すべてリファクタリングの結果発生する作業だろ。 OpenSSLがリファクタリングされまくっているな >>429 客の要件はそのままプログラムにできるけど、 >>433 最適化じゃないんだよ バグも含めて機能そのままで、構造だけ変える（良くするつもり）ができるっていうのが結構単純な 別に胡散臭いとは思わないが、真に受けちゃったバカが「リファクタリング最強！」とか言い出すのはかなりうざい。 >>436 なんだ、自分で自白してるじゃんかｗ ダメなコードは直すことでよくできる >>440 リファクタリングを知らない人は、 デザパタ信者みたいなのが暴走して悪評を広めてるんだろう その悪評を鵜呑みにしているのが 流石に数学の定理と同等か言い過ぎだろ。 >>446 >>446 いや、普通に恥ずかしいでしょ？ ぶっ壊して同じ結果が得られるように作り直すこととの違いを教えてください。 イチから作り直したい病と 機能やクラスを抽出するのだって破壊を伴うんじゃないの。 >>451 >>453 http://d.hatena.ne.jp/asakichy/20100607/1275877997 >>453 が言ってる、 >>452 も少し勘違いしているね。 >>456 リファクタリングの「関数の抽出」をやったら >>459 つまり途中で一回ぶっ壊して同じ結果が得られるように作り直すわけね リファクタリングがゲシュタルト崩壊しそうなスレだ。 >>461 http://d.hatena.ne.jp/asakichy/20100607/1275877997 >>464 >>459 の操作で一回ぶっ壊れてるじゃん 慌てずリファクタリングの公式に沿って変更すれば副作用は一切ない。 >>465 ちなみに、リファクタリングブラウザを使えばもっと簡単に行える。 >>467 まあ俺ぐらいリファクタリングに精通すると、最初からリファクタリング後の最終形になるように最初からコーディングできちゃうわけで、あえてリファクタリングを意識しなくていいわけなんだけどね。 >>469 >>470 >>471 今更ながら>>1 が言っていたことって正しいんだなって思った。 >>473 リファクタリングの「関数のインライン化」をやったら ID:kUSteVkT必死すぎだなｗ ID:kUSteVkTアは書いたコードが要件を満たせなかったら 一日中スレに張り付いてる ID:9UWhhSIJ に必死過ぎと言われてもな… やっと要件といったねｗ >>482 >>454-456 ) 絶対に壊れない奥義は秘中の秘で リファクタリングってどのタイミングでやる事を想定してるのかな やりたい時がやるべき時なんだよ。 だからそんなタイミングなんて実際存在しないよねって話をしてるのに >>487 >>483 http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism >>486 >>490 >>489 IDEのリファクタリングのメニューから選べる機械的にできる変換のみを >>446 >>493 リファクタリング前と後で同じテストが通ればOK派と、 >>1 ３行で言うと 隠された4行目は >>500 また俺の会社すげえ自慢か なんで力量がはっきりしてない人のソースレビューもせずに、 リファクタリングが工程になのであればら、彼の知っている開発手法はそもそもTDDに向いてないので、その前提でTDDの話なんてできないと思うのです リバースエンジニアリングが難しいのと同じで、 >>504 >>508 自分よがりなんて書いてる奴は、他人に読みやすい文章になるような注意力に欠けた >>511 うむ http://www.weblio.jp/content/%E8%87%AA%E5%88%86%E3%82%88%E3%81%8C%E3%82%8A >>516 要求仕様の変更に追随するために設計を変えていくのがリファクタだ 他人が作ったものをメンテする時は つーかリファクタリングとか言いにくいから修正でいいじゃん リファクタリングを定義しようぜ >>500 に対して>>503 の返しするということは、>>500 の話が論が正しいことを>>503 が認めているということ。 誰でもできることでないなら、実現は夢物語ということだ 工程を確保して >>524 >javaで10ステップ >>485 リファクタリングしない人は 全部埋めてやったぞ ＜＜リファクタリングとは＞＞ >>534 問題ないのに直すのは明らかに無駄な労力だろ >>531 >>536 まあ理論的に完璧なリファクタリング手法を使っても テストやりました。バグが見つかりました。 違うね。 >>542 開発段階ですでにスケジュールオーバーしてる現場だらけなのに机上の空論w >>544 リファクタリングすら必要ないほどの腕のいい奴を最初から揃えれば良くね？ 他人のソースコードの解読は新規作成より時間がかかるケースが多々。 >>548-549 仕様変更っていうのは避けられないものだし、 >>552 >>550 リファクタリングは有能が無能の尻を拭く作業ではなく自分の尻を拭く作業だ >>556 >>555 >>555 エクストリームプログラミングから全否定かよ。 バグを仕込んでしまう可能性があるのが致命的 他人の尻を拭くハメになったとき、リファクタリングが可能である唯一の条件は、 >>559 恐怖駆動開発だな。 http://www.hanselman.com/blog/FearDrivenDevelopmentFDD.aspx >>557 りファクタリングって言うのは、オブジェクト指向の言語（これが大前提）で、 一度客に納入してさあ、次に改修の仕事がきたときにリファクタリングしていたから工数が減っていたとしてもなんのメリットもないんだよな。むしろ工数が少なきゃ金が取れない。リファクタリングした分取ったら水増し請求だ。 それと、テストという概念は個人がスクリプトやツール類を書く場合には絶対に生まれてこない発想で、 リファクタリングは工数水増しの手段ではない。 もし>>567 が客側の意見であれば、失敗したプロジェクトや案件とは縁を切って >>563 http://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0_ (%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0) >>566 必要なのはコードのリファクタリングではなく 言い換えると、ソースコードをリファクタリング出来るように > チームメンバのリファクタリングである 例えばバグが多く、しかも非常にメンテしにくい糞コードがあったとする >>576 ホント現実をみてないな >>579 > コードを読みやすくする？直す？どーやってなおすんだよ正しい仕様不明なのに >>581 開発手法が根本からおかしい >>580 >>584 >>582 うちのソースコードはほとんどが綺麗だから この板はガセネタをもとにした煽り合いのスレしかないみたいだな >>585 >>590 クソソース1万ステップ読まなくていいようにするためにリファクタリングするんじゃないか マーチン・フラウアーのリファクタリング本てruby版とjava版て言語が違うだけで内容は重複してるの？ >>589 >>593 >>454 ででてるリンク先の一覧が内容の比較として使えるよ。 >>596 Aさんがリファクタリングしました。 普通は、 Class レイザラモンFoo Extends Object >>598 >>599 個人の知識の違いによってソースの見え方が違うからな 知識って・・・そんなの一機能5分もあれば それに、知らないなら何をやっているか おれはやらな〜いw アホみたいな話だが結局>>598 が真理だよな。 リファクタリングはただのコード修正と思ってもらってかまわない リファクタリングするよ派はここでなにしてんの？しないよ派とじゃれあってるのが楽しいの？ >>607 >>1 が考えるようなことは誰もが考えてる。 >>598 の意見が正しい。 >>1 はしのごのいうなら、リファクタリング後の形になるプログラミング言語を生み出せ。 >612 > 何を持ってリファクタリングといいたいのかわからないが >>423 , >>426 あたりを読むといいよ。 http://capsctrl.que.jp/kdmsnr/wiki/bliki/?IsChangingInterfacesRefactoring http://capsctrl.que.jp/kdmsnr/wiki/bliki/?IsFixingAnUnknownBugRefactoring http://capsctrl.que.jp/kdmsnr/wiki/bliki/?IsOptimizationRefactoring http://capsctrl.que.jp/kdmsnr/wiki/bliki/?IsDeclarationOrderingRefactoring >>614 を見ればわかるけど、 >>613 >>615 このスレも http://kanae.2ch.net/test/read.cgi/prog/1411354584/ >>5 >>5 >>617 >>614 を見ればわかるけど、 まだ無職が語るの？ しかし、この超売り手市場なのに就職出来ないって、相当無能なんだな いやぁ馬鹿スレを止めてくれてありがたい え？ という妄想を書く人って、 リファクタリング良さそうなんだけど、いろいろ疑問点があります テストケースは全部通さないと駄目だよ インタフェースを作り替えたらテストも必要 >>628 >>629 ただ、そのテストのメンテナンス、テストを減らしたり、改善したり、 http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview43.html >>632 テストできない・しづらいインタフェースを作ったらあかん >>627 >>637 世の中に汚いコードが溢れてるってことだなｗ 設計がまずかったり場当たり的に組んでしまったりして >>648 >>640 >>643 >>644 >>645 >>646 >>642 >>642 世の中なんでも使い捨てで楽な方に向かってるのに >>650 >>651 再利用って考え方がそもそもコストが高いんだよ 再利用のコストに関しては単純に何回再利用するかで変わってくるから、 >>654 >>655 再利用前提で作ろうとしてる時点で余計なコトスがかかっとるわい 再利用性や拡張性というのは、将来のことだから仕様外。 再利用と考えるからいけない。 >>660 本当の意味での再利用？ >>660 >>661 全く修正しないで使うのが再利用。 流用元から流用先がどこにどれだけあるかは基本的に分からない。 頑張って同じ機能がすでにあるか探して、 >>661 ,660 どのタイミングでやったら工数に影響を与えずにできるの? みんな、言い負かされないようにリファクタリングを定義してるから、本当の目的がなんなのかぼやけちゃってるよね。 >>673 大抵の趣味人はリファクタリングなんかせずに垂れ流しだろ あとwikiから ユニットが再編成されたコードの外的な振る舞いをテストする うちの会社の糞プロジェクトはリファクタしてことでバグ生んで大炎上してたな >>680 >>682 >>683 >>684 分子構造が再構築された全ての細胞の働きがもとそれと１つも変わらないならそれは再構築前と同じ生物になるのではないか >>684 >>678 に書いてある「外的な振る舞い」というのは >>687 >>688 >>690 >>691 >>692 >>687 で >>692 レベル低くて結構だが ID:pecoNgwzがすごい小さい世界で生きていることだけはよくわかる >>691 っていう勘違いをここまで堂々と話してるところが2chだなぁと感じる >>691 >>692 >>701 >>692 >>703 >>705 勘違いさせたならすまんが、俺は別にリファクタリングにシステムテストとかが必要ないなんて思ってない。その一つとは別人。 リファクタにE2Eテストがいらないというのはある意味ただしいんだよ リファクタリングの責任範囲はユニットテスト迄でシステムテストとかは機能の変更、追加、向上なんかの範囲だと思うけどね >>708 >>709 >>711 >>712 >>713 >>706 >>710 >>713 >>709 >>716 >>718 >>719 >>716 >>715 ID:6yEMM6pR がまともなリファクタリングを語るのはもうギャグにしか見えない >>722 >>717 >>724 >>725 >>726 >>728 >>720 >>730 ←自分のオナニーが認められないから根本的な設計思想の変更までリファクタリングだと言いだす極端すぎるバカｗ バカをチンカス野郎と言い換えても 「外部からみた振る舞いを変えずに内部の設計を変更すること」がリファクタリング >>734 >>735 >>739 >>740 ゴミが書いたテストコードなんて使えるわけなかろう >>740 ←TDDもリファクタリングも分かってないゴミwこういうのがリファクタオナニストw リファクタリング前提の開発なんて小規模開発以外はやるものじゃないね それを言うならプロトタイピングだろw >>746 >>749 >>747 >>750 現状それなりに動いているけど > 将来性を考慮しての改善するのがリファクタリングでしょ >>751 >>754 ちなみに、TDDでは最初にテストコードを書いて http://www.atmarkit.co.jp/ait/articles/1403/05/news035.html#025 それてないじゃん？ｗ うーんww >>760 >>753 リファクタリングに開発規模は関係ない 規模が大きい開発はクソコーダーがクソコードを量産してくるから俺様が随時コードを書き換えてやる >>764 本当に大規模開発やったことあるのか？ >>767 >>769 話を戻すと開発中にそんな状況になるのを俺はリファクタリングとは言わん >>750 から何度も言ってるからだけなんだがねw そもそもファクタリングとは？ じゃあ逆に聞くけど設計から変えてUTのコードがそのまま使えるケースってどんなの？w 別にリファクタリングは個別のユニットテストに影響ないレベルとは限らないでしょ。 結論から言えば概念としてのリファクタリングは否定しないが、 >>775 >>749 だから選択も糞もないくやらないといけない状況でそれをリファクタリングとはいわねーって プロジェクトの開始時にリファクタリングの見積も出してね だからまずファクタリングの定義からしようか 機能要件を満たすため オブジェクト指向でシステム開発するなら、リファクタリングは必須です。 >>771 とりあえず動くものを新規で作って書き換える場合か、すでに動いているもので、修正が入りまくって汚くなったものを整理するくらいしかない。 >>762 >>777 >>749 だから選択も糞もないくやらないといけない状況でそれをリファクタリングとはいわねーって >>749 で設計に問題があるときはどうするのか聞いた。 >>750 で >>778 >>776 >>784 >>790 >>753 には while とか for の話は >>791 YAGNIの話？ ほんまやね。レス辿って明らかにおかしいのを見つけたがら言ったけどそれforのレスにかすりもしなかったわ。すまん。 下手に勘違いされると困るから補足しておくと、 読まなきゃ汚いと思わないんだから、矛盾してるような気がするけど。 > 読まなきゃ汚いと思わないんだから >>797 汚いから直すってのもリファクタリングと呼ぶと思うけど、 >>802 >>801 リファクタリングを行うタイミングを間違ってるんだよね >>806 >>805 >>807 > Red/Green/Refactor 通りの順番 1.機能追加前にテスト書く >>815 最近、特定のフラグ変数に関するif文の山をswitch構文に清書し直したんだけど、これってリファクタリング？ >>816 >>817 >>817 >>817 >>818 >>816 が言ってるのは、Red→Greenでやる内容は * Green 現実にはこの5. テストに通っただけの状態で 駄目だこりゃ。なんでそういう手順がリファクタリングなのか？ Refactorとリファクタリングが同じ意味の言葉だってのが伝わってないのかも知れないな あ、はい間違えました このスレってそもそも特定のリファクタリング作業のスレッドか。話がかみ合わないわけだ。 誰が特定のリファクタリング作業の話をしてるんだ？ TDDの例出したからTDDに限定した話だって勘違いしてるんでしょ >>829 定義から定まってないからなリファクタリングって 殆どの用語は定義なんか定まってないよ ソースを組んだときと今とでチンコのポジションを若干変更した 特定の統合開発環境のリファクタリング機能をリファクタリングだと言ってるやつはいなくなったなw 俺の中では変数名の変更=リファクタリング 俺の中では、マーチン ファウラーのリファクタリング本（古い方）に あるスコープの中で外部から見た仕様を変えずに内部の設計を変えるのがリファクタリング 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 ■ このスレッドは過去ログ倉庫に格納されています
