リファクタリングをただのコード修正と思ってる人へ

1デフォルトの名無しさん2010/05/29(土) 17:25:56

テストも書かないでリファクタリングとかうけるｗ

まずな、リファクタリングでは機能追加・修正は行わない。
動作はまったく同じでコードをきれいに書き換えること。

書き換えるといっても、これなら同じ動きだろ？って推測でやってはいけない。

まずテストを書く。ユニットテストをできるように、
単一のクラスでインスタンスを作る。

汚いコードなのだからたいていは依存関係のせいで単一ではクラスが生成できない
それを生成するために、クラスの動作を書き換える。
といっても元のコードは修正しない。継承やプリプロセッサを使って
依存関係を断ち切るために既存のコードを上書きする。
どうしてもそれが不可能な場合には、決められた手順で最小のコード修正を行う

そうやって既存のクラスのユニットテストを行う。
それでやっとリファクタリングが行える。
既存のクラスのユニットテストを通るように新たなコードに修正、
もしくは新規作成して置き換える。

この手順と考え方を守ってないのはリファクタリングではない。

で？

2デフォルトの名無しさん2010/05/29(土) 17:27:43

Eclipseのリファクタリングは名前変更もリファクタリングのひとつなんだよなあ

3デフォルトの名無しさん2010/05/29(土) 17:33:05

リファクタリングは結果ではない。
プロセスだ。やり方だ。

コードがきれいになったからリファクタリングをしたと
思うのは間違いだ。

バグを入れないのは当たり前だが、コードの動作を変えずに
決められたた手順をもちい、クラス間の依存関係を減らすことで
ユニットテストできるようにする作業がリファクタリングだ。
テストコードが増えてなければ、それはコードを書き直しただけで
リファクタリングとは呼ばない。

リファクタリングブラウザとは、このリファクタリング作業を簡単にするための
ツールであり、リファクタリングブラウザの機能を使った作業（名前変更など）そのものは
リファクタリングではない。

4デフォルトの名無しさん2010/05/29(土) 17:41:18

本当のリファクタリングを知ると、
新たな設計方針にたどり着ける。

テストしやすい設計。
クラスを単独で生成できるように
依存関係（クラスが別のクラスを使用するなど）が
少ない設計。

publicメソッドの引数には、なるべくクラスを使わない。
クラス内部で別のクラスを生成しない（必要な場合は外部から渡す）

5デフォルトの名無しさん2010/05/29(土) 17:59:47

>クラス内部で別のクラスを生成しない（必要な場合は外部から渡す）
全部main(String [] arg)で作るんですねわかりま…

6デフォルトの名無しさん2010/05/29(土) 18:00:34

宇宙飛行士様が来たぞ

7デフォルトの名無しさん2010/05/29(土) 18:07:01

リファクタリングがしたいと思ったとき、
こういう考えの流れになっていないとだめ

リファクタリングしたい
　↓
リファクタリングするにはユニットテストコードが必要
　↓
既存のコードを（なるべく）修正せずにテストするにはどうするか。
　↓
（依存関係が無ければ簡単にテストコードを書けるが、たいていはそのままではテストコードかけないので）
既存のコード・クラスをどうやって他のコード・クラスとの依存関係から分離させるか。

この分離が一番大変な作業。
分離させることに成功したらあとは簡単。
ユニットテストを書いてコードを修正すればよい。

8デフォルトの名無しさん2010/05/29(土) 18:17:41

正直名前変更くらいしか使ってないな、それでも相当便利だが

9デフォルトの名無しさん2010/05/29(土) 18:24:16

>>8
名前変更（リファクタリングブラウザの機能）というのは、
例えて言うのなら小説を書く（リファクタリング）ときの文房具（リファクタリングブラウザ）と
同じ関係だよ。

文房具を使って文字を書いたり、消しゴムで消したりという作業は、
小説を書くための道具を使っているわけだが、
本質的には小説を書く行為そのものではない。

10デフォルトの名無しさん2010/05/29(土) 23:54:35

XXXはXXXXXであるべき、なんてXXは全くもってXXXだ。

11デフォルトの名無しさん2010/05/30(日) 00:14:58

>>1
その通りです。
何か嫌がらせされてる気がする。

12112010/05/30(日) 00:52:51

ごめんなさい。取り乱しました。
ソフトウェアテストで良い本ありませんか。

13デフォルトの名無しさん2010/05/30(日) 02:51:03

>>12
レガシーコード改善ガイド

14デフォルトの名無しさん2010/05/30(日) 10:13:00

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

15デフォルトの名無しさん2010/05/30(日) 18:16:22

>>14
だと思った
>>1の一行目で分かった

16デフォルトの名無しさん2010/05/30(日) 19:47:36

リ略をただのコード修正だと思わないでよ
コーダの思いがこもってるんだからあ

17デフォルトの名無しさん2010/05/30(日) 22:16:42

どおりで重いと思った

18デフォルトの名無しさん2010/05/30(日) 22:34:43

>>16
釘宮風にたのむ

19デフォルトの名無しさん2010/05/30(日) 22:44:12

ばーかばーか

20112010/05/31(月) 06:09:05

>>13
ありがとうございます。
本見てみます。

21デフォルトの名無しさん2010/05/31(月) 21:06:25

>>19
チルノのパーフェクト算数教室？

22デフォルトの名無しさん2010/06/01(火) 01:55:41

え…あぅ……わ、私そんなんじゃないのに…
これは、コード修正じゃなくてりふぁくたりんぐなんだから！
ちゃんと勉強してから出直しなさい！
なによ……わざわざしてあげるんだから…何か言いなさいよ！
あっ、べ、別にアンタのためにやるんじゃないんだから、
勘違いしないでよね！ばーかばーか！

23デフォルトの名無しさん2010/06/01(火) 12:35:24

なんか決まりがあって、そうしないとダメだって言ってるような頭固い人間がプログラムしてるのが間違いだろ。
目的に即してれば、細かいことは違ったって問題ないのに、それは手順としてあーだーこーだ・・・みっともない。

24デフォルトの名無しさん2010/06/04(金) 19:59:43

>>12
遅レスですまん

ファウラーの「リファクタリング」は必読
「パターン指向リファクタリング入門」はオススメ
あと、関連してデザインパターン関連の本を読んでおくといいかも

25デフォルトの名無しさん2010/06/19(土) 17:52:31

リファクタリングって流行らないね。
そもそもリファクタリングするために必要なユニットテスト技術も未熟だからか。
日本は技術レベルが低いよ。

愚痴はここまでにして、データベースのフィールドってリファクタリングするのに
厄介だよね。ただの文字列だと名前変更に追尾できない。

それはO/Rマッパー使ってもそうだけど、データベース関連はリファクタリングを念頭に置くと、
SQLとデータベースからクラスとして自動生成したほうがいいのかもしれない。
このクラス（仮にDBCLASSとする)ではデータベースのフィールドが一メソッド（プロパティ）になる。
これはビジネスロジックを書くいわゆるモデルではなく、データベースの構造をあらわすだけのクラス。

DBCLASSのプロパティを変更しても、DBCLASS内部でアクセスしているデータベースのフィールド名は変わらない。
逆にアクセス先のデータベースのフィールド名を変えると、DBCLASS内部でアクセスする
データベースのフィールド名も自動的に変わる。

26デフォルトの名無しさん2010/06/19(土) 17:56:15

ウェブアプリの場合、同じ問題が
フォームのクエリー名にも当てはまるんだよな。

要はデータではなく、意味がある名前であるキーを
ただの文字列として扱うのはやめようということ。

フォームのクエリー名を変更したら、
自動的にコードの名前に反映させたい。（逆もあり）
そのためのコードの生成機能が必要だよ。

27デフォルトの名無しさん2010/06/19(土) 18:14:03

>>26
いまだにフォームの設定かいたら、その部分のコードが自動生成されないの？
みんなふつうにやってるとおもったんだが気のせいであったか。

28デフォルトの名無しさん2010/06/19(土) 18:22:48

>>27
何の話？
自動生成されたとしても、それを文字列で扱っていたらだめだよ。
ようはリファクタリングブラウザで、それがキーとして認識されるような形になってほしい。
リファクタリングだけじゃなくて、コード補完もできるようになるから間違いが減るしね。
コンパイル時点でのエラー検出もおこなえるようになる。

29デフォルトの名無しさん2010/06/19(土) 22:20:10

社長に今なにやってる？と聞かれてリファクタリングしてます、と答えたら
いつも波風が立つのはなぜだろう

30デフォルトの名無しさん2010/06/19(土) 22:24:56

リファクタリングがなんなのか、メリットとデメリットについてなど
理解してないからだろ

こういう成功例を見せながら地道に説得していくしかないんじゃないの？
http://ascii.jp/elem/000/000/497/497905/

31デフォルトの名無しさん2010/06/19(土) 23:08:32

>>30
いい記事だった。
そこの社長ぐらい、うちんとこの社長も柔軟な頭だったらいいんだがなあ

32デフォルトの名無しさん2010/06/20(日) 02:34:06

理解させるには分かりやすいたとえが必要だと思う。
例えば平屋を拡張して2階、3階と増やしていったら、
1階にも手に入れないと、いつか倒壊しますよね?とか。

33デフォルトの名無しさん2010/06/20(日) 06:23:44

一階に手を入れたら倒壊しちゃいました、とか

34デフォルトの名無しさん2010/06/20(日) 15:29:28

そもそも本当に１階にも手を入れないと倒れるのか？
やってみたら意外と倒壊しないんじゃないの？、とか

35デフォルトの名無しさん2010/06/20(日) 18:34:34

理解のないシステム会社はそれだよね。腐ったシステムを抱え続けると将来的にどれだけのコストになるかわかってない。
だから目先のコスト増に怯えて将来の飛躍の芽を摘んでしまう。

36デフォルトの名無しさん2010/06/20(日) 20:56:47

リファクタリングの重要性のわからん上司にどうわかってもらうかでずっと悩んでいたが、
理解のない人にはリファクタリングしているとはあえて言わないのも手だと
Ruby版リファクタ本に書いてあって目から鱗だったわ

37デフォルトの名無しさん2010/06/23(水) 13:48:44

Rubyの場合結局Cで作り直すんだよな

38デフォルトの名無しさん2010/06/24(木) 08:19:11

そんな分野でそもそもruby使うのがおかしい。

39デフォルトの名無しさん2010/06/27(日) 21:52:39

リファクタリングしていると、仕事を押し付けてくる奴がいてうぜーよー。
どうもそいつはリファクタリングしている=暇そうにしていると思っているっぽい。

40デフォルトの名無しさん2010/06/27(日) 22:30:05

仕事を交代してやればいい

41デフォルトの名無しさん2010/06/27(日) 22:31:35

リファクタリングの決断
http://www.infoq.com/jp/news/2010/06/decision-to-refactor

42デフォルトの名無しさん2010/06/28(月) 02:42:24

>>39
>リファクタリングしている=暇そうにしていると思っているっぽい。

正解だから困る

43デフォルトの名無しさん2010/06/29(火) 21:31:04

>38
組み込み向け「軽量Ruby」と「Rubyチップ」、福岡県が経産省の事業で開発へ
http://itpro.nikkeibp.co.jp/article/NEWS/20100628/349693/?ST=oss

的外れな提示だったらすまそ。

44デフォルトの名無しさん2010/06/30(水) 14:19:54

組み込みにスクリプト言語とな？ｗ

45デフォルトの名無しさん2010/06/30(水) 15:22:41

組み込みスクリプトってLuaとかあるし普通じゃね、と思ったら
組み込み機器のほうの話なのか

46デフォルトの名無しさん2010/07/01(木) 01:28:43

組み込みJavaと同じ運命をたどる

47デフォルトの名無しさん2010/07/01(木) 09:36:51

>>45
いちおうLuaはヤマハのルータなんかにも使われているぽい。

48デフォルトの名無しさん2010/09/15(水) 19:43:18

大規模なリファクタリングを行う方法
http://www.infoq.com/jp/news/2010/09/large-scale-refactoring

49デフォルトの名無しさん2011/06/01(水) 22:25:20.30

リファクタリングなんてやって意味があると思ってる奴は消防

Ａ～Ｚまであるクラスの共通処理をＰクラスとして纏めたとするわな
したら、ＰクラスをいじるたびにＡ～Ｚまでの影響範囲を調べなあかんのやで

仮にＡにしか関係しないＰに入ってしまった共通処理を弄るのだって
一度結合したらはがしてＡクラス特有の処理としてＰクラスからＡクラスを避ける処理なんて
結構、邪魔な処理になるで

それでもＰとしてまとめてしまったらＡ～Ｚまでサポートしていかなあかんのやで
リファクタリング、結構、だが、誰がこの未来を予測できる？

Ａ～Ｚまでの共通処理が走ってるＰクラスを蹴飛ばしてＰＡクラスを新しく作って
Ａ－ＰＡ、Ｂ～Ｚ－Ｐの関係を新しくぶった切るような切込みはできんやろ？
せいぜいＰの処理にcase Aを入れるような修正が精一杯やないか？

今後を考えてリファクタリングなんてする意味があるんか？

50デフォルトの名無しさん2011/06/01(水) 22:28:19.38

共通処理をまとめるだけがリファクタリングではないし、
自動テストが伴わないものはリファクタリングとは呼ばない。

51デフォルトの名無しさん2011/06/01(水) 22:28:23.13

>>1

52デフォルトの名無しさん2011/06/01(水) 22:38:24.11

>>50
いや、上で書いたのはあくまで例だよ
上の例は処理をまとめることによって明らかに構造が汚くなってるよね？
この先もまとめたＰクラスにＡ～Ｚへのどれかの追加が入るたびに
case B、case C・・・と追加されていくだろうね
そのときＰクラスを消滅する選択肢は誰か選べるんだろか？

こーゆーのってさ、その時点ででは確定しなくね？
じゃ、リファクタリングってなんのためにするの？

って根本的なところに目を向けたときに次の開発をしやすくするためでしょ？

したら、その仕様書もなしでリファクタリングをするってことは
仕様書もないのにプログラムの構造を「俺が好き」なだけの構造にただ意味もなく
書き換えてるだけのマスターベーションなんだよ

53デフォルトの名無しさん2011/06/01(水) 23:55:42.31

どこの幼房かしらんが、
case B、case Cとなるようなまとめ方はアフォがやるものだろ。
それはリファクタリング以前の問題。

54デフォルトの名無しさん2011/06/02(木) 06:38:02.16

>>53
ほうほう、それじゃ上記の例でＰの共通部分にＡのみに変更がかかったらどう修正する気？

55デフォルトの名無しさん2011/06/02(木) 08:30:37.53

>>54
Aが自前で実装すればいいんじゃね
それか、Pが取る引数を工夫して柔軟な対応ができるようにする

56デフォルトの名無しさん2011/06/02(木) 08:38:55.65

>>54
Aが自前で実装するように戻す。
あとそういうのは例えばStrategyパターンを使うべきで、共通化するものじゃない。
それすら分からないなら幼房。

57デフォルトの名無しさん2011/06/02(木) 21:05:01.86

>>55-56
>Aが自前で実装
だが、現実は絶対にcase Aを入れる
自分のソース見てみろ
今回は俺が逃げ道塞いだから自前で実装って言っただけだろ？ｗ
正気に戻ればＰクラスなんてつくらねーんだけどな

58デフォルトの名無しさん2011/06/02(木) 22:24:39.31

>>57
ガキみたいなこと言うなよ池沼

59デフォルトの名無しさん2011/06/02(木) 22:30:46.12

素直に継承するとか、デコレータパターンとか
ほかに影響に与えずに拡張なんていくらでもやりようがあると思うよ

60デフォルトの名無しさん2011/06/03(金) 04:53:30.73

>>57
いや、その場面でcaseとか、既にそういう実装だった場合を除いてしないと思うが…

61デフォルトの名無しさん2011/06/03(金) 06:40:24.29

>>60
違うな
大抵の場合、外部とのやりとりをＡ～Ｚまでまとめない一心でＰクラスで作ってしまうから
Ａだけ切り離してもインターフェースがＰを通しているのでＰにＡへの変更を吸収してもらうほかないって感じになってるはず
じゃないとまとめたうまみないしねｗ

62デフォルトの名無しさん2011/06/03(金) 08:28:45.65

>>61
おまえは統失か。

63デフォルトの名無しさん2011/06/03(金) 08:32:19.79

結局>>49=>>52=>>54=>>57=>>61が何言いたいのかわからん。
1+1は？と聞かれてみんなが2と答えたら、田んぼの田だやーい間違った間違ったと
はしゃぐ鼻水垂らしたガキにしか見えないんだが。

64デフォルトの名無しさん2011/06/03(金) 12:43:00.66

>>63
せめて反論しろよ(笑)

65デフォルトの名無しさん2011/06/03(金) 20:59:55.04

>だが、現実は絶対にcase Aを入れる
>変更を吸収してもらうほかないって感じになってるはず
想像と主観だけ。

66デフォルトの名無しさん2011/06/03(金) 22:24:10.95

>>36
でFA

67デフォルトの名無しさん2011/06/03(金) 22:29:04.53

>>49はコーダーのレベルにすら達することの出来なかった落ちこぼれ
自分が何が分かってないかすらわかってない

68デフォルトの名無しさん2011/06/03(金) 22:47:12.11

>>67
具体的な反論よろしく

69デフォルトの名無しさん2011/06/03(金) 23:03:07.11

元々>>49が意味不明なこと言っているのが原因だろ。
>>49=>>68が具体的なコード出せ。そうしたら反論してやる。
まあ、コーダー未満の池沼だから出せないだろうが。

70デフォルトの名無しさん2011/06/03(金) 23:41:04.87

>>69
わかってないのは君だけじゃないの？
無駄だってわかりつつやるとお金もらえるからみんなやってるだけだよ
「なんのためにするリファクタリングなのか？」
って考えたらすぐに自分のやってることの無意味さに気がつくはず
現状の設計とマッチしてないから合わせるならわかるけど
それは開発段階で気がつくただの不具合だよね？

将来どうするのか？もわからないのにどうしてコードに手を入れられるの？
仕様書無しでコードに手をいれるのはダメだダメだあれほど言ってたのになんでこういうオナニーは好きにやっちゃうの？
目的がわからないのに最適（？）なコードなんてわかるわけないじゃない
なんのためのリファクタリングなの？
すべてがおかしい、でもお金になるし偉い人もやってるからやる
ただ、それだけのもんだよこれは

71デフォルトの名無しさん2011/06/03(金) 23:56:03.20

>>70
やあ幼房。>>49を読んで意味が分かるのは池沼のおまえだけだ。

72デフォルトの名無しさん2011/06/04(土) 00:49:50.56

>>71
うっとおしいからやめろよ
変な言葉も聞きなれない横文字も使ってないし誰でもわかる内容だ
内容の意味がわからないのは経験が浅いからだろ

73デフォルトの名無しさん2011/06/04(土) 06:49:03.11

＞うっとおしいからやめろよ
日本語でOK。

74デフォルトの名無しさん2011/06/04(土) 20:32:27.75

>>49はリファクタリングの前にオブジェクト指向を勉強したほうがよい

75デフォルトの名無しさん2011/06/04(土) 21:55:36.94

よくわかってないプログラマとか
プログラム中で使用する文字列をすべてヘッダで#define切っちゃうのとかよくいる
使うその場に直接書いたほうがいいことに気がつくのはいつのことだろうか？

76デフォルトの名無しさん2011/06/04(土) 22:44:23.36

文字列は切り分けたほうがいいよ
聞きかじりで行儀の良いとされる作りにしようとして
多重定義したり実際の文字列探すまでが長かったりする
くそみたいな所が多すぎるからそう感じるんだろ

77デフォルトの名無しさん2011/06/04(土) 22:51:42.66

>>75
根拠は？

78デフォルトの名無しさん2011/06/04(土) 23:04:54.02

>>77
意味がねぇからさ
ソースをみた瞬間に文字列が直接書いてあればその時点で意味がわかる
それを#defineきったら今度は命名した奴のセンスに丸投げすることになる
それが必ずしもわかりいい名前をつけてくれるとは限らない
また、複数個所でこの文字列を使うことがあったとして・・・いや・・・ないだろ？ｗ
あるならなにかおかしいんだｗ

文字列の場合、数値とはちょっと違う事情があってこういう定数を#defineを切るのはあまり意味ない

79デフォルトの名無しさん2011/06/04(土) 23:07:46.71

また、数値の場合も俺は#defineを切る意味がないと思ってる
こんなこというとすぐに頭に血を上らせてソースでいきなり出てきた数値の意味が～云々で怒るやつがいるが
俺はそうじゃなくてソースを読んで出てきた数値がわかるようなソースを書くべきだと思ってる

ちゃんとインスタンスの生成箇所をしっかり制御すればそもそもプログラム全域に一つの値が
複数使いまわされることなどほとんどない（はず）
数値計算（3.1415・・・）ですら特定のファイルにまとまる

しかし、プロジェクトにグローバルインスタンスホルダー（大域変数セット）などあると俺の言ってることは全く理解不能だと思う

80デフォルトの名無しさん2011/06/05(日) 00:50:06.75

こりゃまた、もの凄い珍説が飛び出したもんだ。
責務やカプセル化の話と、可読性とはイコールではないだろーに。
自分の説の論理的な飛躍に気づけないのか？

81デフォルトの名無しさん2011/06/05(日) 07:21:48.46

「必ずしも分かり易い名前を付けてくれるとは限らない」
「ちゃんとインスタンスの制御をしっかりすれば複数箇所に出てくることはほとんどない」

まともな名前すら付けられん人間が「しっかりとしたインスタンスの制御」なんてやると思うかい？

82デフォルトの名無しさん2011/06/05(日) 07:49:17.22

>>81
インスタンスの管理なんてやる必要があるのはグローバル変数使ってるからだろ？

83デフォルトの名無しさん2011/06/05(日) 07:54:59.13

>>82
だとすれば

＞ちゃんとインスタンスの生成箇所をしっかり制御すればそもそもプログラム全域に一つの値が
＞複数使いまわされることなどほとんどない（はず）

ってのはグローバル変数使ってる前提なのか

84デフォルトの名無しさん2011/06/05(日) 08:21:32.31

>>83
なんでそうなるの？
いままでグローバル変数にばっかたよってるからそういう脳みそしかないんでしょ？

85デフォルトの名無しさん2011/06/05(日) 09:03:52.51

いや俺の脳みそ云々の問題でなく、矛盾してるんだってば
管理が要らないのか要るのか、どっちなのさ

86デフォルトの名無しさん2011/06/05(日) 09:31:51.48

>>85
それとグローバル変数がどうして関係あると思ったの？

87デフォルトの名無しさん2011/06/05(日) 09:39:59.44

>>86
それは>>82に言ってよ

88デフォルトの名無しさん2011/06/05(日) 09:43:54.09

>>83での「だとすれば」がどういう意味もってるのかわからない
なにが「だとすれば」なの？
馬鹿だからグローバル使うしか方法わからないだけじゃない？
いままでプログラム組んでてこの程度ってすごくみじめ

89デフォルトの名無しさん2011/06/05(日) 10:04:45.71

グローバル変数を使わなければ管理が要らないなら
何故にインスタンスの制御とかの話になったの？
要らないんでしょ？

90デフォルトの名無しさん2011/06/05(日) 12:27:20.48

>>89
グローバル変数使わなければね
俺の言ってることなにか矛盾してる？

91デフォルトの名無しさん2011/06/05(日) 12:35:52.01

>>90
「何故」と理由を聞いてるのだが

92デフォルトの名無しさん2011/06/05(日) 12:53:18.34

>>91
あんまり気にしなくていいよ
「ちゃんとインスタンスの生成箇所をしっかり制御すれば」＝「グローバル変数なんて使うほどお馬鹿じゃなければ」
って意味だからｗ

93デフォルトの名無しさん2011/06/05(日) 14:26:48.94

>>92
ちょっと待て、たかがグローバル変数を使わないだけのことを
「ちゃんとインスタンスの生成箇所をしっかり制御」
なんて仰々しく書いてたのか

94デフォルトの名無しさん2011/06/05(日) 14:28:38.99

>>93
仰々しく書いたつもりはないけど
君にはできないことだよねｗ

95デフォルトの名無しさん2011/06/05(日) 15:03:32.48

>>94
何故そう思った？

96デフォルトの名無しさん2011/10/09(日) 01:02:25.28

ああげ

97デフォルトの名無しさん2011/10/09(日) 04:44:50.43

#define 使うな、までは同意できたんだがなあ…

98デフォルトの名無しさん2011/10/09(日) 12:05:06.67

リファクタリングとリエンジニアリングの関係は？

99デフォルトの名無しさん2011/10/09(日) 18:39:07.21

リファクタリングなんて、簡単な概念でしょ。

たとえば、多角形を表示するプログラムがあったとする。
それは実際は三角形を表示するプログラムを反復実行してるとする。

三角形を表示するプログラムは、線を表示するプログラムを反復実行してるとする。

線を表示するプログラムは、点を表示するプログラムを反復実行してるとする。

すると、
点を表示するプログラムを、高速に書き換えれば、
これに依存した全てのプログラムが、その内容を変更しなくとも、高速化する。

ってのがリファクタリング。
これのポイントは、修正したのは点を表示するプログラムだけで、それ以外は一切変更していないのに、他も高速化できること。
このためには、インターフェースを極力保ったままで、中身だけを変更することが重要になる。
これがリファクタリングと、普通のコード修正との違い。

100デフォルトの名無しさん2011/10/09(日) 18:57:05.08

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?IsOptimizationRefactoring

101デフォルトの名無しさん2011/10/09(日) 19:57:12.25

>>99
近いが微妙にはずれている。

リファクタリングと高速化は無関係。
リファクタリングした結果、高速化することもあれば
（他にメリットがあるならば）逆に遅くなることもある

インターフェースも変えないこともあれば変えることもある。
リファクタリング本にもしっかり、「インターフェースを変えるリファクタリング」が載っている。

リファクタリングの目的はアプリ全体の動きを変えずに、ソースコードを綺麗に改善すること。
ただこの目的を達成するために、適当に修正するのとリファクタリングとでは違うものがある。
それはリファクタリングはちゃんとした手順でやるものだということ、
この手順に従うことが、修正とリファクタリングの違い。

どういった手順があるかは、リファクタリング本に書いてある。
この手順に従って修正することでバグを入れずに修正することが可能になる。

102デフォルトの名無しさん2011/10/09(日) 23:20:59.42

高速化は変更の具体例として挙げているだけで、
高速化がリファクタリングだとは言っていないだろ。

103デフォルトの名無しさん2011/10/09(日) 23:59:37.52

>>101
I/F変えたら機能変更だろ。
リファクタリングの範囲をどこまで取るかであって
その範囲で内部I/Fは変わることがある。

手順がどーのだって、効果的な手法がそうだってだけで、
ある作業がリファクタリングかどうかの判断に手順は関係ない。

104デフォルトの名無しさん2011/10/10(月) 00:31:27.92

>>103
> I/F変えたら機能変更だろ。
え？そんな事言ってもなぁ。
インターフェースを変えるリファクタリングはたくさんある。

メソッドの移動、クラスのインライン化、メソッド名の変更
引数の追加、引数オブジェクトの導入、メソッドの隠蔽
メソッドの引き上げ、階層の平坦化、継承の分割、他

リファクタリングの目的は、高速化という今すぐに効果があるメリットのためではなく、
過去にその場しのぎで対応したコードの修正とか、設計上まずいコードの修正とか
過去の負債、将来への投資として行うものだよ。

設計がまずい＝インターフェースがまずいってことはよくある話で、
コードを改善するためには、インターフェースを変えなければいけないということも当然ある。

105デフォルトの名無しさん2011/10/10(月) 00:40:22.19

なんでこいつら10年前の議論してるの？

106デフォルトの名無しさん2011/10/10(月) 00:53:59.26

したらいけないの？

107デフォルトの名無しさん2011/10/10(月) 01:04:25.82

>>103
> I/F変えたら機能変更だろ。

インターフェースが機能になってるのは
ライブラリぐらいなもんだろ。

システム（アプリ）の動作さえ変えなければ
リファクタリングでインターフェース変えたっていいんだよ。。

インターフェースが変わりますって他の開発者への通知が
必要なことがあるかもしれないが、それは、通知すればいいだけの話。

それが世界中巻き込んで大変なことになろうが、
社内の一部だけしか関係ない小さなものだろうが、
「やってはいけないこと」ではない。

108デフォルトの名無しさん2011/10/10(月) 12:55:38.15

＞インターフェースが変わりますって他の開発者への通知が
＞必要なことがあるかもしれないが、それは、通知すればいいだけの話。

幸せな環境だ・・・

109デフォルトの名無しさん2011/10/10(月) 15:07:45.53

>>108
かわいそうな環境の人？ｗ

そういう場合に、古い関数を
DeprecatedやObsoleteと書いて
リファクタリングする方法もあるよ

110デフォルトの名無しさん2011/10/10(月) 15:29:15.75

おお、Javaがやってる方法じゃん
Java PGは可哀想な子だからな

111デフォルトの名無しさん2011/10/10(月) 15:31:03.21

DeprecatedやObsoleteは
どの言語でもやってることだろ。

なんかこう、俺とは一段以上下のレベルの
奴しか見当たらんよなｗ

112デフォルトの名無しさん2011/10/10(月) 15:49:03.28

そう。どの言語でもやってる。
何故ならインターフェースなどそう簡単に変更できないからだ。

それなのに
> 必要なことがあるかもしれないが、それは、通知すればいいだけの話。
のような事を書くほど低レベルのPGはJava PGだけだと予想して釣ってみたが、
やっぱりその通りだったねw

113デフォルトの名無しさん2011/10/10(月) 15:55:41.96

「なんかこう、俺とは一段以上下のレベルの奴しか見当たらんよなｗ」(キリッ

114デフォルトの名無しさん2011/10/10(月) 16:24:50.97

>>112
意味がわからんｗ

インターフェースが簡単に変更できないからって、
絶対に変更できないわけじゃないだろ。

お前頭が硬すぎじゃね？

115デフォルトの名無しさん2011/10/10(月) 16:48:43.88

めんどくさいからコードに対する変更はもう全部リファクタリングでいいよ

1161082011/10/10(月) 19:15:25.35

>>109
若干かわいそうな環境かも。

機能毎に縦割りでリーダーが立ってて
「こっちは機能追加が進んでて人居ない」とか
「影響が大きい」とか言われて
とてもじゃないが変えられない。

それでも自担当の部分だけでもリファクタリングする工数が
貰えるだけマシなのかも知れんけどね。

117デフォルトの名無しさん2011/10/10(月) 21:13:00.47

JavaのPGやってるけど
privateメソッドを修正するだけでもJAVADOCの修正とかユニットテストが更新されるからって
チーム内でそれを拒む人いるんだよなー
ってか、お前が俺のソースコピペして、俺がその責任背負わなくなくなるのが嫌なんだろｗｗｗどうせｗｗｗ

118デフォルトの名無しさん2011/10/25(火) 13:23:05.69

リファクタリング中は考えることを止めよう
http://www.infoq.com/jp/news/2011/10/thinking-and-refactoring

119デフォルトの名無しさん2011/10/29(土) 00:57:02.72

やっぱり目的が意味不明
設計ミスならリファクタリングという形で手を出すべきじゃないし
汎用性の向上にしても次の開発やバージョンアップの仕様書があってこその修正だ

単純にリファクタリングってのが何を目的としてるのかどの文献を読んでもまったく意味不明

120デフォルトの名無しさん2011/10/29(土) 03:24:37.60

>>119
でっていう

教えてほしいならそう言えよｗ
そうでないのなら、やり方はひとつじゃないんだし、お前の好きなようにやれば？

121デフォルトの名無しさん2011/10/29(土) 05:48:50.42

>>120
じゃあ、質問だけど
これは何を目的とした作業なの？

122デフォルトの名無しさん2011/10/29(土) 11:34:19.34

時間と共に増大する複雑性への対処では。

書いたソースが自分たちのものになるのかで大きく価値が異なると思う。
複雑性が増すと修正にかかる工数が増えるけど、それを良しとするか悪しとするか。

123デフォルトの名無しさん2011/10/29(土) 18:57:08.38

果てしなく続くメンテナンスと機能追加を前提として
それぞれのモジュールの精度を高めるために必要な準備作業

じゃないかな

124デフォルトの名無しさん2011/10/29(土) 22:48:37.21

何いってるのかさっぱりわからない
じゃ、質問をかえる
その作業いつ終わるの？

125デフォルトの名無しさん2011/10/29(土) 23:05:14.32

>>122
>時間と共に増大する複雑性への対処では。
何？複雑性って？
仕様とコードが乖離してるの？
そもそも仕様や設計がまずいの？
仕様や設計はバッチリなのにコードだけ綺麗にしようとしてる？（場面がまったく浮かばないけど）

>>123
精度？よくわからないけど
精度が高い状態と低い状態があって
それを判断する手段があるって言ってる？
高い状態はどうなってて、低い状態はどうなってるってのを説明してほしいんだけど？

126デフォルトの名無しさん2011/10/29(土) 23:30:50.35

効果も含めて微ファクタリング

127デフォルトの名無しさん2011/10/30(日) 00:00:06.96

>>125
仕様が変わることによって設計がそぐわなくなったときの対処についてはどう考えているの？

仕様や設計がまずいといえばそれまでだけど、
完璧な仕様や設計は期待できないでしょ

128デフォルトの名無しさん2011/10/30(日) 00:12:36.90

最初から間違えなければいい。

129デフォルトの名無しさん2011/10/30(日) 01:44:30.53

>>127
んー
それをコードにいれちゃうのはなんかちがうなーって思う
だって説明として仕様や設計に入ってもいないクラスが
自分の考える汎用性のためだけに入ってるってことでしょ？

まあ、昔の俺ならそういうコードいいと思ったけど

最近はこういう見切り発進みたいなコードをちっともいいと思わなくなった
むしろ余計なもん入れちゃうのってどうよ？って思う

130デフォルトの名無しさん2011/10/30(日) 02:01:00.62

余計なもんなんかいれない。

”必要だから” 入れてる。

131デフォルトの名無しさん2011/10/30(日) 02:32:58.38

>>129
自分の考えるよりよいコードを実現するためのひとつの手段がリファクタリングなのであって、
お前がリファクタリングは不要と考えるならそれはそれでいいんじゃね
リファクタリングしなくていいよ

132デフォルトの名無しさん2011/10/30(日) 09:42:26.14

>>130
でもそれって仕様書にないよね？
どうやって説明するの？
これまで派遣やってきたけど
そういうの許してる大手なんてみたことないけど

133デフォルトの名無しさん2011/10/30(日) 11:29:33.88

>>129
見切り発進と思うのなら、修正した方が良いと思った内容を提案してみては。

受け入れるかは組織なり人なりタイミングによると思うけど、
少なくともうちだったら、そういう提案してくれる人は歓迎するけどなあ。
その人の持つ技術力の評価や信頼にも繋がるし。

134デフォルトの名無しさん2011/10/30(日) 11:55:22.16

>>132
大手なんて10年は遅れてるじゃん
ゴミコード量産の現場でリファクタリングしようなんて、俺だって思わないな
メンテする奴が死ねばいい

135デフォルトの名無しさん2011/10/30(日) 12:08:51.05

>>132
じゃあ聞くが、お前の所の仕様書には、
ifやforやローカル変数名が書いてあるのか？

使用する命令はそれ以外のものは
一切使ったらいけないと書いてあるのか？

136デフォルトの名無しさん2011/10/31(月) 03:11:52.86

>>135
そんな話はしてないじゃん
でもこっちの場合はそういう制御文にとどまらないもんができちゃうよね？
必要のないクラスだったり関数だったり

137デフォルトの名無しさん2011/10/31(月) 12:33:30.90

>>136
なんか勘違いしてね？
必要ないものってなんのこと言ってんの？

138デフォルトの名無しさん2011/10/31(月) 21:45:02.67

>>136
世の中に必要なクラス・関数を網羅した
仕様書なんて無いよ。

139デフォルトの名無しさん2011/11/01(火) 00:54:41.88

>>137
仕様と関係ないソース
汎用性のために入れましたって言うんでしょ？

140デフォルトの名無しさん2011/11/01(火) 00:57:56.17

この表現でわからないならデザパタ使うと出てくるゴミクラスなんか全部該当すると思う

141デフォルトの名無しさん2011/11/01(火) 06:03:18.76

>>139
仕様と関係ない関数は不要なので、コードはすべてmainの中に書いてくださいね

142デフォルトの名無しさん2011/11/01(火) 07:41:02.59

>>141
いくらなんでもそれは話が飛びすぎてて馬鹿っぽい

143デフォルトの名無しさん2011/11/01(火) 08:04:06.10

デザパタでぽこぽこ生まれるゴミクラス問題は
特定の言語に固有の問題であって、リファクタリングの問題じゃなくね？
http://www.norvig.com/design-patterns/

144デフォルトの名無しさん2011/11/01(火) 20:58:54.49

>>143
リファクタリングは保守の一つなのだから、
コードを修正するならば言語に関係なく発生する問題。

リファクタリングとデザパタは
特定の言語固有とか言う以前に、全く関係ない話題。

ついでにデザパタで作るのはゴミクラスではなく必要なクラス。

145デフォルトの名無しさん2011/11/01(火) 21:19:29.93

>>142
よう、レガシー

146デフォルトの名無しさん2011/11/01(火) 21:21:02.73

Sir! FUTURE!!

147デフォルトの名無しさん2011/11/01(火) 22:09:32.23

他の言語では作る必要の無いクラスを作らされたら
ゴミクラスと言いたくもなるわい

148デフォルトの名無しさん2011/11/01(火) 22:12:41.23

>>147
たとえばどんなの？

149デフォルトの名無しさん2011/11/01(火) 22:14:56.95

他の言語では、定義する必要がない型を
定義しても、ゴミ定義とは言わないだろ。

単に、エラーを見つけやすい方法で書くか、
短いコードだから省略して書くかの違いでしか無い。

150デフォルトの名無しさん2011/11/01(火) 22:26:33.69

>>148
Strategyパターンはファーストクラスの関数があれば
クラスを作る必要は無いな

151デフォルトの名無しさん2011/11/01(火) 22:28:50.74

うん。だからそれは、インターフェースを守った
きっちりとしたアプリを作るかどうかの違い。

152デフォルトの名無しさん2011/11/01(火) 22:36:13.61

きっちりしてるというのはどういう意味だ？
静的型検査という意味なら勘違いも甚だしいぞ

153デフォルトの名無しさん2011/11/01(火) 22:41:00.77

>>152
コード上に、インターフェースがちゃんと表現されているという意味。
インターフェースを守らない、間違ったコードは組み込めないという意味でもある。

154デフォルトの名無しさん2011/11/01(火) 23:28:25.82

>>150
ファーストクラスの関数がなかったら？

155デフォルトの名無しさん2011/11/01(火) 23:53:30.12

>>153
だから、それは静的型検査という意味じゃないのか？

>>154
無名クラスがあれば代用可能
無名クラスも無い？あきらめろ

156デフォルトの名無しさん2011/11/02(水) 00:43:25.84

このように、言語によって
クラスが必要かどうかは違ってくるというのに、
設計書と呼ばれるものに、そこまでちゃんとクラスを書いているのか？
普通は書かないだろ。

だから、設計書と呼ばれているものは、実は設計書ではない。
コードこそが設計書そのものなんだ。

157デフォルトの名無しさん2011/11/02(水) 07:35:25.31

>>156
>だから、設計書と呼ばれているものは、実は設計書ではない。
>コードこそが設計書そのものなんだ。

そりゃ違うだろ
設計書と呼ばれてるものも設計書
ただ、粒度が異なるだけ

158デフォルトの名無しさん2011/11/02(水) 21:53:07.67

ただなぁ，世に存在するうちの設計書で,
なぜこれが必要か
といった，設計ポリシーとともに書かれているものは，ごく稀

で，最後には
ソース読め
状態になると思ってるんだ

159デフォルトの名無しさん2011/11/03(木) 01:04:35.79

仕様書は役に立たないがテストの手順書はとても役に立つな
なにをやるための機能なのか一発でわかる

対して仕様書は嘘、間違い、抜け、バージョン違い、勘違い
更新忘れ、認識間違いばっかりになってほとんど役に立たない

仕様書いらなくね？
っていうかテスト手順書でよくね？

ちなみにおそらくテスト手順書は仕様書を見て作られてはいないだろうな
やってみて「ふーん・・・これだろ？これが仕様だろ？な？」的な感じだと思う

160デフォルトの名無しさん2011/11/03(木) 11:16:22.26

仕様書とソース・プログラムの挙動が不一致ならバグ認定、即修正

っていうレベルのもの以外は仕様書に書くな！！！！

161デフォルトの名無しさん2011/11/03(木) 19:08:42.55

>>160
ショートカットとか本当にどうでもいいもののリスト作ってるひまあったら他のことやれよな

162デフォルトの名無しさん2011/11/04(金) 00:04:28.66

>>134
> ゴミコード量産の現場でリファクタリングしようなんて、俺だって思わないな

なんかすごくよくわかる。発注しまくりでゴミコード量産しまくりで身動きが取れないわ

163デフォルトの名無しさん2011/11/04(金) 20:57:42.11

うちのプロジェクトjavaソースだけでついに1万個を超えた

リファクタとかいうレベルじゃねーだろ

164デフォルトの名無しさん2011/11/04(金) 22:40:52.09

>>163
すごいな
まんこの部分だけ強調して三回ぐらいは口にしたいよね

165デフォルトの名無しさん2011/11/06(日) 10:59:30.75

javaでもすでに10年物のソースコードとかあるからな

166uy2011/11/06(日) 16:44:42.65

リファクタリングとか、
１０万行のソースコードがあったとして、
その１０万行のソースコードを、読んだってレベルじゃなくて、そうとう熟知した状態で
１人で行わなきゃならない
ていうか、それできるレベルなら、多分最初から書き直したほうが綺麗に書ける

まぁそれは理想で
ＳＥ共のいってるりファクタリングは機能ごとに、ちょこっとずつ最適化していく程度のものを言ってるよね
自分の能力でソースコード全体を見渡せる範囲で何とかするリファクタリング

なんていうか、それはね
まず木で作られた線路を、途中から鉄にして、さらに途中から銅にしたようなもので、本当に器用に継ぎ接ぎをしてるだけ
その継ぎ接ぎ部分はとてもシビアになるし、バグが出ても特定不可能で、
「よくわかんないけど、○○にすると落ちるから☆☆にしといてｗｗｗｗｗｗｗｗｗｗｗｗｗっうぇｗｗｗｗなんで落ちてんのｗｗｗっうぇｗｗｗｗ」みたいな状況にもなりかねない
ソース全体を見渡しているわけでもないリファクタリング作業なんてのは、あまりやりすぎると
ゼロから書き直す以上の労力をいつの間にか注いでいる事にもなりかねないので
最低限以上はやっちゃいけない

167デフォルトの名無しさん2011/11/06(日) 16:52:16.13

>>166
お前は、ただのコード修正をリファクタリングと言ってるだけだね。

リファクタリングは単なる「コード修正」とは違うもの。
リファクタリングは「既存の動きに影響を与えない方法を使ってコードを修正すること」

既存の動きに影響を与えない方法ってのがあるんだよ。
これを使わないとリファクタリングにはならない。
行き当たりばったりの思いつき修正とはわけが違う。
論理的に考えぬかれた体系化されたテクニック。
それカタログ化して解説した本が、世の中にでてるリファクタリング本

168デフォルトの名無しさん2011/11/06(日) 17:24:22.30

＞リファクタリングとか、
＞１０万行のソースコードがあったとして、
＞その１０万行のソースコードを、読んだってレベルじゃなくて、そうとう熟知した状態で
＞１人で行わなきゃならない
＞ていうか、それできるレベルなら、多分最初から書き直したほうが綺麗に書ける

とてもじゃないが、まともに教育を受けた人間の書いた日本語には見えない。

169デフォルトの名無しさん2011/11/06(日) 21:45:33.79

> 「既存の動きに影響を与えない方法を使ってコードを修正すること」
ここで仕様をリファクターする必要を考慮しないのがリファクタリング厨

170デフォルトの名無しさん2011/11/06(日) 22:13:45.01

>>169
リファクタリングは仕様を変えないのが原則です。

仕様を変えたほうがいいこともあるが、
それは修正であってリファクタリングではありません。

あたまがわるーい。

171デフォルトの名無しさん2011/11/06(日) 22:17:40.89

ユーザーインターフェースかわんなきゃリファクタリングと言ってみるtest

172デフォルトの名無しさん2011/11/06(日) 23:12:56.73

>>170
ちゃんと読め。

173デフォルトの名無しさん2011/11/07(月) 02:11:07.98

> 仕様をリファクター
はぁ？
んなもんリファクタリングじゃあなーいと言ってやれ。ドキュメントをリファクタリングしちゃるとか言ってる奴、それもリファクタリングじゃねーぞコラ。そういうのは、リストラクチャリング（再構築）というのだッ。

174デフォルトの名無しさん2011/11/07(月) 06:29:39.93

仕様変更にまで手をいれない修正だったら俺はする意味ないと思うけどね
いいと思ってるのは自分だけっていう典型だと思う

175デフォルトの名無しさん2011/11/07(月) 22:24:06.07

試験とか全部やり直しになるけどそこまでコードに重心置けないです
しかも動作は変わらないとかね

176デフォルトの名無しさん2011/11/07(月) 22:56:57.01

>>174-175
あんたたちに言いたいことは、全て本の最初に、
それは違うよって書いてあります。

つまり、そのレスはFAQで答えがバッチリ出てるので、
今更議論するような話ではないです。

177デフォルトの名無しさん2011/11/08(火) 00:14:11.06

>>176
とかいって逃げたいから自分の言葉で説明しないで本に書いてあるとか言ってるんでしょ？
わかるよ
説明できない人ってみんなそうだもの
あんたもいっしょ

残念だけどここ本質なのよね
そもそもリファクタリングっていう行動自体意味がわからない
将来どう変わるか？の仕様もないのに汎用性？
何に対していってるの？あれほど仕様書に重点をおいてるのに
なんでコードレベルでソフトウェアの方向性がわかるの？
それと何度もいうけど全体の工数からいったら実装なんてすげー短い期間なのに
リファクタリングなんてしなくていいんだよ
馬鹿かよ
設計や仕様決めに時間割いたほうがいいの、わかった？御馬鹿ちゃん？
人件費みたって派遣ＰＧと正社員様様と比べて比較になるわけねーだろ

そんな糞みたいな脳みそしかないんだったら技術者なんてやめちゃえばいいのに

178デフォルトの名無しさん2011/11/08(火) 01:14:10.32

>>177
コンプレックス刺激されすぎｗ

179デフォルトの名無しさん2011/11/08(火) 01:17:58.36

単純なシチュエーションだと、今動いているものがあって
それに仕様変更や機能追加をする"前"にリファクタリングしたり

えーちょっと何やってんのか分からなぁ～いって時に、リファクタリングして今の動きを確認したりする鴨

さすがに何も用事が無いのにリファクタリングはしないぞw

180デフォルトの名無しさん2011/11/08(火) 06:35:51.23

>>179
ローカルのＨＤＤの中で勝手にやってろレベルだなｗ

181デフォルトの名無しさん2011/11/08(火) 08:17:23.29

>>177
どうしたの？
したくないならしなくていいんだよ？

別にお前のコードのことなんて知らないし

182デフォルトの名無しさん2011/11/08(火) 12:07:50.87

仕様書を大雑把に

・機能仕様書：ユーザの観点からシステムがどのように動くか記述する
・技術仕様書：プログラムの内部実装について記述する

に分けたとき、機能仕様書を変更しないのがリファクタリング
技術仕様書は変更する必要がある

と、俺は解釈してるんだけど

183デフォルトの名無しさん2011/11/08(火) 22:53:38.54

>>182
そんな金になんない仕事やったらダメだよ
仕様どおりには動いているんだ
よほど現実からかけ離れた組み方でない限りはそんなところにお金を入れてはダメだ

184デフォルトの名無しさん2011/11/09(水) 00:34:09.76

リファクタリングの価値は
リファクタリングしたことによる将来のメンテナンスコストの低減分だと思うから、
純粋なリファクタリングをする意味ってあると思うけどね。

まあ、少なくとも、作ったコードを客に出すのが仕事の人は、
リファクタリングの価値を見出すのは難しいだろうね。
お客が腐ったコードをメンテナンスし続ける費用を負担してくれる限り、
工数がかかる方が、お金になるだろうから。

185デフォルトの名無しさん2011/11/09(水) 01:07:17.87

寧ろそうやって放置されたコードのメンテナンスの際にESP能力を発揮しながらリファクタリングして日銭稼いでますが何か。

186デフォルトの名無しさん2011/11/09(水) 22:25:08.24

>>184
でもドングリの背比べじゃない？
仕様にまで踏み込めないレベルの修正でなんか変わるの？
同じ人、もしくは似たようなレベルの人がやんでしょ？

187デフォルトの名無しさん2011/11/09(水) 23:19:04.89

>>186
同じようなレベルの人がやったら対して変わらんだろうね。
時間がなくて小手先で直したのを時間が取れる時にまともに直すとかかしら。

あほなプログラマが書いた動くけどわけわらんプログラムを
レビューで突き返したりするのもリファクタリングになると思うけど、放置するの？

188デフォルトの名無しさん2011/11/10(木) 00:11:30.20

>>187
でも設計レベルではなにも変わらないんしょ？
アホだろうがどうだろうが違いがでるレベルにならんのとちゃうか？

189デフォルトの名無しさん2011/11/10(木) 02:48:37.98

>>186
> 仕様にまで踏み込めないレベルの修正でなんか変わるの？

お前コード書いたことないだろ？

190デフォルトの名無しさん2011/11/10(木) 02:49:24.36

>>188
お前の言う「設計レベル」ってどういうことだ？

コードには設計があるのは知ってるよな？
それは機能のことじゃないぞ。

191デフォルトの名無しさん2011/11/10(木) 06:19:17.82

>>189
あるけど
そこでそんなに違いが出るとは思えないんだよね
大手もそう考えるから（いや実際そうなんだろう）ＰＧは派遣ばかりなわけだしね

192デフォルトの名無しさん2011/11/10(木) 22:10:19.47

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

2.1 リファクタリングの歴史

リファクタリングの先駆け：1980年代以降Smalltalkの仕事をしていたWard CunninghamとKent Beckの2人

Smalltalkはリファクタリングに特に向いている環境

コンパイル、リンク、実行のサイクルが短く、コードを気軽に書き換えることができる

彼ら2人の考えはSmalltalk文化にリファクタリングの概念を定着させた

筆者「リファクタリング？そこまで重要ではないよ」→Kentと同じプロジェクトに携わり、
Kentのリファクタリングを目の当たりにする→ソフトウェアの生産性、品質に明らかな違いが…→筆者「！！」

上の経験からリファクタリングを重要視するようになった

193デフォルトの名無しさん2011/11/10(木) 23:19:30.99

>>192
そのストーリーって重要な部分なの？ｗ
しかもそんな馬鹿みたいな長文書いて大事な要点がちっとも書いてないじゃん

>ソフトウェアの生産性、品質に明らかな違いが…
明らかに大事なのってこの部分の詳細だろ

何がよくて品質がどうよくなったのか？

だろ？
お前の国語の能力低すぎてリファクタリングまで怪しくなるわｗ

194デフォルトの名無しさん2011/11/11(金) 21:19:14.97

>>193
そういう文句はオリジナルを書いた奴に言え。

195デフォルトの名無しさん2011/11/11(金) 23:32:49.89

自分の言葉で語れない奴はカス

196デフォルトの名無しさん2011/11/11(金) 23:58:46.50

お前のセリフに説得力はない

197デフォルトの名無しさん2011/11/12(土) 01:34:54.40

>>191
違いを理解できない能力なだけじゃないの？

198デフォルトの名無しさん2011/11/16(水) 20:57:29.42

重複の除去が有効とか書いてあるじゃん

前にやった仕事で、ほんの一部を除いて同一の機能を持つモジュール２つが
別々の人によってそれぞれ実装されてて
目玉飛び出そうになったのを思い出した

199デフォルトの名無しさん2011/11/16(水) 21:30:50.10

別にいいじゃん
その２つをくっつけることで後に呼び出し先Ａの機能を修正したいだけなのに
その機能がわざわざまとめられてるために
もう一つの呼び出し先Ｂのソースまで洗わないといけなくなるかもしんないだろ

まとめるのは必ずしも正解ではない

200デフォルトの名無しさん2011/11/16(水) 22:33:28.29

>>199
必ずしも正解ではないのは正しいけど
同じような修正が必要になったときに片方の修正が忘れられることの方が多いと思われ
共通で使われてるメソッドの参照元を調べることより
クラスもメソッドも違うけど実は中身が同じでなければならなかったのを探すほうが大変な気が

分ける理由がないうちは一緒にしといて
必要になったら分ける方のが正しいと思う

201デフォルトの名無しさん2011/11/17(木) 01:17:42.75

ちなみに >>198 は
その両方を移植する仕事だった

「工数儲けた」と思ってたら
両者をソース読んで同一機能であることを確認した上で
一つにすりあわせて、その承認もらう羽目になったとさ

当然まともな設計書なんてありゃしないし

202デフォルトの名無しさん2011/11/17(木) 22:48:38.78

>>200
いや、お前の言ってることはGoogleやAppleでは正しいだろうな
だが、日本の工業製品ではＮＧ

もちろんいいたいことはわかるけど
それじゃ見積もりがとれないこの１点でＮＧ

色々な大手でたくさんのプロジェクトが走っていて
共通ライブラリなんて生まれないっつか生まれても消滅してしまう理由はここにある

修正の影響範囲が巨大すぎて見積もれない
また、修正時に全員が同じタイミングで対応できない
これも大きな問題だ
こっち動かなくなるのに「直したよ～」とかメールくれられても困るだろ？
そっちに手がまわらないのにリリース前に真ライブラリでバグってリリース失敗であぼんとか話にならない

修正した本人は「いいんですーこれが本来あるべき姿なんです～」って主張しようと
修正するほうは「糞が・・・」って思うっしょ？
まあ、ＭＳの出荷するもんにみんなが愚痴をこぼす瞬間だと思うけど

203デフォルトの名無しさん2011/11/17(木) 22:50:23.01

>>202
で、その壁を超えられる所が勝ち組で
超えられないところはどんどんブラック会社化するわけだ。

仕事、つまらないだろう？ｗ

204デフォルトの名無しさん2011/11/17(木) 22:55:03.81

>>203
でもいくらもないっしょ？
日本のＩＴって進化に失敗してて紙業務を電子化したような仕事のほうが多いよね？
韓国にもすっかり抜かれちゃったみたいで国内全員でｼｮﾎﾞｰﾝって感じじゃない？
研究開発分野と本当に極一部だけだろうね
まあ、いまそういう開発してても日本じゃいつ紙業務の電子化ＩＴにまわされるかわからないから
勝ち組って意味でいうと海外脱出組が勝ち組だろうね

205デフォルトの名無しさん2011/11/17(木) 22:58:57.20

>>204
ごめんな。

うち自社で作ったウェブサービス提供する会社なんだわ
HTML5系とかそっち系。

選ぶ会社の時点で勝ち負けが決まるよね。
仕事、つまらないだろう？ｗ

206デフォルトの名無しさん2011/11/17(木) 23:01:51.10

うちは少数精鋭なんで（使えない奴はやめさせられる）
同じコードをいくつも書くとかそんな無駄なことやってられないんだよね。

テストも人海戦術で同じことを何度もやるとか、時間的に無理だし、
もちろん手動テストは極力減らすので、変更したって
影響があるならすぐ分かる。

207デフォルトの名無しさん2011/11/17(木) 23:02:59.45

>>205
ウェブ系なんて工業製品とかわんねーけどな
あんなん汎用性見越して組む必要あるかね？

寿命が短いからどう組んでもどうとでも動くが正解だろ？
納期まで早い方が真
お前の世界こそプログラムを綺麗にまとめて褒める奴１人もいないと思うがな

208デフォルトの名無しさん2011/11/17(木) 23:38:17.66

>>207
汎用性見越して組むとか言ってないんだが。

無駄にある重複コードをまとめると言ってるだけ。

209デフォルトの名無しさん2011/11/17(木) 23:39:39.61

重複コードを作ると、納期が延びます。

修正があると、重複コードの分
修正量が増えます。

少しの修正であっちこっち修正して、
あっちこっちテストして納期伸ばしてるのは誰ですか？ｗ

210デフォルトの名無しさん2011/11/18(金) 00:57:17.23

>>209
それって何箇所？
１０箇所？２０箇所？程度なら貼ったほうが速いよね？
思いっきりまとめあげられてて難しい仕組みに頭ひねってソース解読しなきゃいけないぐらいだったら
単純コピーで貼ってあってくれたほうがまだソース読みやすいよね

っていうか件数が１００件いかない程度のコピペならお前が便所に席を立った間にやっておいてやるよ
この程度の件数だったらどう組んでも変わらない

211デフォルトの名無しさん2011/11/18(金) 01:28:11.79

>>210
お前適性ないんじゃね？

ぶっちゃけ、仕事楽しくないでしょ？

212デフォルトの名無しさん2011/11/18(金) 01:48:53.37

自分でやるんじゃなくて他人にやらせるんだろ

213デフォルトの名無しさん2011/11/18(金) 06:57:57.33

>>211
いや、楽しいよ
お前みたいな対象物のメリットとデメリットも判断できんようなの出し抜いて数字上げるのが何よりの快感だわ(笑)
結局、技術の上部だけしかすくえないひとって何も見えてないんだよね
新しいってだけである意味パニック状態になってる自分がなにより見えてない

214デフォルトの名無しさん2011/11/18(金) 07:32:36.75

数字を出しさえすればそれが全てだと思い込んでいることはよく判った。
さぞかし楽しい人生だろうねぇ。

215デフォルトの名無しさん2011/11/18(金) 11:48:05.79

>>213
お前性格屈折してるな
そうとういじめられたな

216デフォルトの名無しさん2011/11/18(金) 12:54:07.46

>>210
> 思いっきりまとめあげられてて難しい仕組みに頭ひねってソース解読しなきゃいけないぐらいだったら
> 単純コピーで貼ってあってくれたほうがまだソース読みやすいよね

申し訳ありません
ifとforしか理解できない人もいるということを忘れていました
リファクタリングの過程でデザインパターンを適用してしまったことをお許しください

217デフォルトの名無しさん2011/11/18(金) 12:59:02.53

>>213
コピペもできるしリファクタリングもできる俺がそれを言うならまだわかるけど、
お前はコピペしかできないんだからさ、取捨選択の上でコピペを採用したみたいな言い方はやめてよ
もっともらしい後付けをしたところで、お前のカードはコピペしかないわけで

218デフォルトの名無しさん2011/11/18(金) 12:59:57.09

>>216
forすら理解してないかもよ
100回ループ廻すくらいならコピペするって言い出しかねん

219デフォルトの名無しさん2011/11/18(金) 15:50:01.61

正面から反論できないときは人格攻撃になるんですね
その時点で白旗あげてるっていうかなんていうか

220デフォルトの名無しさん2011/11/18(金) 19:16:21.49

>>219
だってー
低レベルな人を教育してあげる気なんて毛頭ないですしー

221デフォルトの名無しさん2011/11/18(金) 23:06:02.19

>>220
でも自分のやってることの説明できないってのは問題じゃない？
結局トレードオフの問題であって
やればやるほどとかどんな場面でもってわけじゃないってとこは否定できないわけでしょ
じゃあ、君のやり方は正しいの？また、他の人と差がでるのは何が決め手なの？
ってのは結局のところどこでも求められると思うんだけどね
それが説明できないなら君に用のある人なんていないと思うんだよね
みんな暇じゃないから(笑)

222デフォルトの名無しさん2011/11/19(土) 16:25:48.92

へえ

223デフォルトの名無しさん2011/11/19(土) 16:38:24.26

トレードオフ考えてやるんだから
やっぱりリファクタリングは必要ってことね

リファクタリング全否定って人はいるのかしら

224デフォルトの名無しさん2011/11/19(土) 17:14:49.53

トレードオフはコードをまとめる話だろ？
リファクタリングはまったく必要ないよ
そもそも意味わからないもん
次の仕様が決まってる中でのコード修正ならわかるけど
次になんの予定もないのに何に向けてどう修正してるのかまったく理解できない
その修正はいいの？悪いの？
オナニーで終わってない？

これらを判断できる材料すらわからない
単に金をドブに捨ててるだけだと思う

225デフォルトの名無しさん2011/11/19(土) 17:30:26.36

汚いコード
ゴミ溜めが如くきったない部屋で過ごしてもなーんにも問題無い
↑
↓
チリ一つも落ちていないようなクリーンルームじゃないと過ごせない
綺麗なコード

って話だろ？何事もほどほどにしとけって事だよ

226デフォルトの名無しさん2011/11/19(土) 17:33:20.81

>>225
人の話を良く聞かないで進めちゃって失敗するほうじゃない？

227デフォルトの名無しさん2011/11/19(土) 18:59:16.42

>>224
キミがそのコードをずっとメンテナンスする責任者だとして、
どこかのプログラマが明らかにまとめるべきところまとめてこなかったり、
分けるべきところをを無理やりまとめてきたりした場合、
正しく動くという理由でそのままにしておくのかい？

228デフォルトの名無しさん2011/11/19(土) 19:28:32.54

>>227
作るときに設計書にあわせてもらいます
ソースだけ弄るってことはしません

229デフォルトの名無しさん2011/11/19(土) 19:33:14.80

ソース＝設計書だろ?

230デフォルトの名無しさん2011/11/19(土) 19:47:12.13

>>229
底辺乙

231デフォルトの名無しさん2011/11/19(土) 19:51:09.79

>>228
要するに仕様は変えずに設計を変えるんだろ
リファクタリングじゃないか

232デフォルトの名無しさん2011/11/19(土) 20:14:22.32

最高綺麗で動く
↑　汚いが動く
↓　綺麗で動かない
最低汚くて動かない

一番下のは捨ててよし
[動く／動かない] と [綺麗／汚い] の相関関係だお

汚いけど動くのは、綺麗だが動かないものより価値がある。
でも綺麗で動かないのを動くにしやすいし、
汚いけど動くものも、後で何か変更するにあたって、動くのを保ちつつ綺麗にしておくと直しやすい。
「綺麗にする」のがリファクタリング。動かないものを動くようにすることとはイコールではない。関係はあるけど。

233デフォルトの名無しさん2011/11/19(土) 20:27:15.16

>>232 使用がバッチィからコードもバッチイって発想はないのか？

2342322011/11/19(土) 20:45:33.70

仕様が汚いと動かすのが難しい
↑
↓
綺麗な仕様は動かしやすい
って関係はあると思うけど、コードと仕様は直接関係しないんじゃねの？

235デフォルトの名無しさん2011/11/19(土) 20:55:13.83

>>234
汚い仕様を何とか動かすために、汚い姑息なコードを大量に入れてる
例なら山ほどあるよ

236デフォルトの名無しさん2011/11/19(土) 21:31:39.15

コードを綺麗/汚いで語るから話がおかしくなるんじゃないか。
リファクタリングって大なり小なり設計の問題の修正のことだと思うんだが。
オレがずれてるのか。

237デフォルトの名無しさん2011/11/19(土) 21:34:18.54

>>236
おれもそう思うよ. 仕様も設計の内だとも思うけど...

238デフォルトの名無しさん2011/11/19(土) 21:49:35.63

もちろん設計の問題とコードの綺麗/汚いは関係ありますが？

最初にきちんと設計をしたつもりでも、実装段階では想定したとおりに行かなかったり、抜けがあったりすることはよくあることです。
実際に書いているうちにいろいろ思いつくこともあります。ちょこっと例外的な処理を付け加えて、を繰り返し、コードは汚くなっていきます。
そうしてソースがスパゲッティ化し、メンテ不能のソースとなっていきます。

そうならないようにするためにリファクタリングがあります。
リファクタリングとは、仕様を変えることなく、ソースコードを改造することをいいます。
汚いソースコードでもプログラムは動きますが、メンテナンスするのは大変です。
汚いソースコードと綺麗なソースコードではメンテのしやすさが全く違います。
なのできるだけ綺麗なソースを書くように心がけ、汚くなったら速やかに書き直すことです。
後々のことを考えて、わかりやすいソースに直します。

239デフォルトの名無しさん2011/11/19(土) 22:15:38.43

>>238
> そうならないようにするためにリファクタリングがあります。

そうならないように設計を見直す方が先じゃないか?

小手先でどれだけいじっても, 汚い設計は汚いソースを
再生産するだけじゃないのか?

それだったら, 設計をリファクターすべきだ

ぶっちゃけ, ユーザーインターフェースが変わらなきゃ
仕様の範囲内だ

240デフォルトの名無しさん2011/11/19(土) 23:03:54.10

>>238
コピペはいらんよ。

汚い綺麗で語るとコードの可読性ばかりを問題にしてるように感じるって話。
だからリファクタリングがいらないとか言う奴がいるんじゃないの。

コードが綺麗であっても設計上の問題が存在することは当然あるよね。

コードの綺麗/汚いは設計の一部しか示していないと思うし、
その修正はリファクタリングの一部でしかないと思う。

241デフォルトの名無しさん2011/11/20(日) 07:43:51.29

>>240
したらただの仕様変更だよねそれって
まあ、名称にこだわる必要もないけど

242デフォルトの名無しさん2011/11/20(日) 08:21:15.92

関数、クラスの仕様は変わっても
システム全体の仕様は変わりません。

なので仕様変更にはあたりません。

243デフォルトの名無しさん2011/11/20(日) 08:21:59.02

設計変更と仕様変更は別の話といえばよかったか。

244デフォルトの名無しさん2011/11/20(日) 12:07:12.15

設計を仕様と見なしたら
仕様変更を伴わないコード変更って存在するのか？

245デフォルトの名無しさん2011/11/20(日) 12:08:20.66

aとかbとかわけのわからん変数名を
意味がある変数名に変更するとか。

246デフォルトの名無しさん2011/11/20(日) 13:09:50.85

I/F変更を伴うかどうかっていう観点じゃないの

ユーザに見える部分とか
担当者の異なるモジュール間とか

247デフォルトの名無しさん2011/11/20(日) 17:10:54.61

オリンパスコーディング

248デフォルトの名無しさん2011/11/20(日) 17:46:34.19

結局、
外から見た目の振る舞いが変わるか/変わらないかがポイントで、
外から見た目の振る舞い＝仕様であって
内部構造≒設計は、リファクタリングの対象
って事でおｋ？

249デフォルトの名無しさん2011/11/20(日) 18:02:36.08

>>248
個人的にはソレが正しいと思うけど
そう思ってない人がいる予感。
241とか

250デフォルトの名無しさん2011/11/20(日) 18:50:26.97

>>249
じゃあ、リファクタリングってのは設計変更までを指すってことでいい？
何やんだかさっぱりわからないけど

251デフォルトの名無しさん2011/11/20(日) 18:53:49.64

>>250
設計の範囲を定義しろ。
話はそれからだ。

252デフォルトの名無しさん2011/11/20(日) 21:17:25.23

>>251
そっちにまかせる
>>248がえらそうに宣言してるから>>248に決めてもらうか

253デフォルトの名無しさん2011/11/21(月) 09:59:01.46

(この人たち、なんで今さらこんな議論をしてるんだろう)

254デフォルトの名無しさん2011/11/21(月) 22:35:10.04

最初からずっとこのスレにいるのは
お前だけだよｗ

255デフォルトの名無しさん2011/11/22(火) 10:39:05.00

そうか、リファクタリング本を読んでるのは俺だけだったか

256デフォルトの名無しさん2011/11/23(水) 00:32:21.88

>>255
本の受け売りじゃなくて中身をちゃんと理解しろよ

257デフォルトの名無しさん2011/11/23(水) 01:19:14.75

そういう手合いはおそらくよんですらいない
買っただけ

258デフォルトの名無しさん2012/02/07(火) 13:45:03.37

改修が必要になったときに初めて
その場で interface をでっちあげて、その後、クラスお取替え

これでいい気がしてきた

259デフォルトの名無しさん2012/02/07(火) 20:02:48.59

それでいい

260デフォルトの名無しさん2012/03/24(土) 14:35:39.62

リファクタリングを身に付けるとコードレベルでの設計力が上がりますか？

261デフォルトの名無しさん2012/03/24(土) 16:05:22.68

設計力は下がります
でも組んだ後の問題に対する対応力は上がります

262デフォルトの名無しさん2012/03/24(土) 17:35:34.20

>>261
何故、設計力は下がるのですか？

263デフォルトの名無しさん2012/03/24(土) 21:11:33.51

設計力あがるだろ

正しい設計のコードに
変化させるのがリファクタリングだ。

264デフォルトの名無しさん2012/03/24(土) 21:36:47.86

>>49-52で結論は出てる
リファクタリングはオナニー
好きにやればいい
公開オナニー好きでも床オナ好きでもその方法を誰も咎めることはできない

265デフォルトの名無しさん2012/03/24(土) 21:51:30.52

オナニー？　自己満足と言いたいのかもしれないが。
仕事でやるのなら自己満足じゃないぞ。
みんなの満足。

266デフォルトの名無しさん2012/03/24(土) 22:21:58.07

みんなでオナニー

267デフォルトの名無しさん2012/03/25(日) 12:10:02.63

分散マスタベーション

268デフォルトの名無しさん2012/04/22(日) 22:43:46.10

密に結合した処理を処理を疎になるようにするとか
処理が対象になるようにシーケンス直すとか
って意味があるリファクタリングだと思うけど
こういうのはリファクタリングっていわんの？

269デフォルトの名無しさん2012/08/05(日) 00:31:39.26

>クラス内部で別のクラスを生成しない
>>4のこの話って完全にはDIでも使わなきゃ無理だけど、
FactoryMethodで解決できるよね。

>publicメソッドの引数には、なるべくクラスを使わない。
完全抽象化クラスに類するもの限定ってなら正しいけど、
intや文字列型だけってのは無いよね。スタブ渡せば済む話だし。

270デフォルトの名無しさん2012/08/05(日) 01:11:40.91

言葉の揚げ足取りに終始しててウザいだけのスレになっちゃってるなｗ

271デフォルトの名無しさん2012/10/14(日) 16:17:10.72

大規模アプリには
必ずリファクタリングが必要。
開発工程の一つに加えていいレベル。

272デフォルトの名無しさん2012/10/15(月) 15:52:21.57

VB6で幾度となく機能追加が行われたコードをぼんやり眺めてると
リファクタリング？何それおいしいの？
という気分になってくる。

273デフォルトの名無しさん2012/10/16(火) 18:14:20.05

>>272
そういうコードこそ、リファクタリングが楽しいんじゃないの？

2742722012/10/16(火) 18:35:14.51

趣味でやるならすごく楽しい。一人でやるのなら絶対リファクタリングしてる。
けど仕事となると時間が取れない。
さらなる機能追加と他言語への移植作業用のドキュメントが優先になってまつorz
移植作業前にリファクタリングできたら解読も楽だろうになあ。
そんなことより成果物（ドキュメント）が優先だってさ。しゃーねーや。

275 忍法帖【Lv=40,xxxPT】(0+0：5) 2013/07/11(木) NY:AN:NY.AN

refakuta

276デフォルトの名無しさん2013/07/11(木) NY:AN:NY.AN

リファク太

277 ◆unko./w.Osri 2014/01/10(金) 07:46:54.18

リファクトスタンダード

278デフォルトの名無しさん2014/01/21(火) 23:03:30.89

リファクタリング本はかなり勉強になったな。
ぐちゃぐちゃなコードしか書けなかったのが、リファクタリングしまくってたら
最初からオブジェクト指向やらデザインパターンやらを考慮したコードが書けるようになってた。

279デフォルトの名無しさん2014/07/25(金) 01:44:17.80ID:S+8bjftN

リファクタリング中にバグが見つかっても修正しちゃいけないんですか？
振る舞いが変わるわけだし。
リファクタリング原理主義者の方の意見が聞きたいです。

280デフォルトの名無しさん2014/07/25(金) 07:34:43.94ID:FDyePLlK

好きにすれば？どうせ個人でやってんだろ
一人ならほんと楽しいよねリファクタ。

業務でリファクタなんかできねーよ
リリースしてから何年も動いてるパッケージに手入れられるわけないだろ！

281デフォルトの名無しさん2014/07/25(金) 10:51:25.65ID:nHudeAGx

業務でリファクタリングの時は、バグの種類にもよるけど基本的にはそのまま。
勿論、リファクタリング後に修正することを見越してリファクタリングすることになる。
実は、バグを見つける為にリファクタリングすることもあるので、「できねーよ」で済まない場合もあるのよ。

282デフォルトの名無しさん2014/07/25(金) 11:26:11.42ID:PjU5XzSY

バグを見つけるためにリファクタリングをすることはあるが
改修はリファクタリング前のコードに対して行うことになるなぁ

283デフォルトの名無しさん2014/07/25(金) 12:21:15.76ID:CQdwbNpj

リファクタリングとは
テストの合格を維持したままの
コードの修正でしょ

284デフォルトの名無しさん2014/07/25(金) 12:41:48.16ID:mmV7Js8i

上を納得というか安心させるための無駄検証にコストを掛けた後だと
いじくれないというのはわかる

だがサブシステムを小分けして
その範囲内で裁量をもたせられるようにしてないのはアカン

285デフォルトの名無しさん2014/07/25(金) 13:58:36.59ID:fPj1ZcPi

>>282
> 改修はリファクタリング前のコードに対して行うことになるなぁ

それって人件費を無駄に捨ててるじゃないか？
会社に損害与えてるよ。
プロ意識無いのかね？

286デフォルトの名無しさん2014/07/25(金) 20:12:11.75ID:zPq/iOJh

リファクタリングしたがる人とは仕事したくないよね

287デフォルトの名無しさん2014/07/25(金) 20:12:41.10ID:Fz0v1PBn

でも実は一発目無計画で作ってリファクタリングするのが一番品質がいい

288デフォルトの名無しさん2014/07/25(金) 21:18:52.98ID:JraUdqnP

一発目無計画っていうのがありえなさすぎ。
趣味のプログラミングだろそれは。

289デフォルトの名無しさん2014/07/25(金) 22:15:52.25ID:Xbv85is1

>>287
それは全然不思議じゃないね。
下書きだと思えばいい。

一発で書くよりも、下書きして全体を理解してから
清書する。

290デフォルトの名無しさん2014/07/25(金) 23:03:10.49ID:mmV7Js8i

神ならざる身で限界を知りつつも最善を目指す手法ではないか

291デフォルトの名無しさん2014/07/25(金) 23:24:21.34ID:oKdTZN9u

考え方の違いなんだよね。この業界に「ボーイスカウトの規則」っていう言葉があるらしい。

http://qiita.com/hirokidaichi/items/d6c473d8011bd9330e63
> ボーイスカウトが、来る前よりも帰った後の方が山をきれいにしておくことにちなんだ規則。
> ソフトウェア開発においては「モジュールをチェックインする際には、必ずチェックアウト時よりも美しくする」ことを意味する。

リファクタリングしない人って、ただ動けばいい、コードが怖くて触れない。
他の部分はいじらないですませようとしちゃう。

修正しない部分なら見て見ぬふりもいいが、修正するなら、
そのまわりを綺麗にしろと。

それが出来ない人は、バグも多いんだよ。してシンプルにしてないから。
複雑なものはバグが多い。複雑だからコードを理解していない。
理解してないからバグが出る。当たり前の話。

292デフォルトの名無しさん2014/07/25(金) 23:31:13.15ID:zPq/iOJh

そういう自己満足だけの身勝手な修正が一番たちが悪いんだよ

293デフォルトの名無しさん2014/07/25(金) 23:33:03.76ID:oKdTZN9u

>>292
なんでですか？

まずきれいなコードのほうが、メンテナンス性が高くなり
バグが減り、開発コストも下がります。

ここは、否定しませんよね？

じゃあ、最終目標は「修正」するべきであってます。

あなたは、まったく筋違いの否定をしているのでは？

294デフォルトの名無しさん2014/07/25(金) 23:42:25.29ID:zPq/iOJh

>>293
そもそも前提が間違ってる。
きれいなコードって何だ？お前のオナニーだろ？
コード修正したいなら、きちんと設計のレビューを受けてチームの了承得てからにしろ。

295デフォルトの名無しさん2014/07/26(土) 00:11:53.24ID:NIQWGSzg

コードがスパゲティになってしまって、
簡単な機能追加ですら2週間もかかるようになってしまってた
（しかも、テストを繰り返しても正しさに自身が持てなかった）のが、
3週間ほど時間をかけてリファクタリングした結果
簡単な機能追加なら1時間もかからず行えるようになりました

296デフォルトの名無しさん2014/07/26(土) 01:29:58.80ID:b/ARCjIF

今どきスパゲティコードなど、そうそうお目にかかるもんじゃない

297デフォルトの名無しさん2014/07/26(土) 02:28:53.78ID:+7Kb6odc

リファクタリングするもしないも、そのソフトの特性や現場事情があんだから、
まずそういう情報がないとなんとも言えねーだろ。
共通して言えるのは独断で判断するなってことだよ。

298デフォルトの名無しさん2014/07/26(土) 08:38:26.34ID:NIQWGSzg

>>296
ちゃんとリファクタリングするようになったからね

299デフォルトの名無しさん2014/07/26(土) 09:05:17.83ID:EislOxX9

設計の手法が確立してきたからだろｗ

300デフォルトの名無しさん2014/07/26(土) 09:15:20.20ID:HnYXSVS2

リファクタリングする前のコードを保存しておいて
リファクタリングしてテストに合格したら
前のコードを消去すれば安全だよ

301デフォルトの名無しさん2014/07/26(土) 09:33:49.93ID:NIQWGSzg

>>300
マトモなバージョン管理システムとBTSは導入済み前提でしょうよ
でなきゃリファクタリングなんて無理

302デフォルトの名無しさん2014/07/26(土) 11:28:39.87ID:lCiymgo1

>>288
神が降りてきて、わぁぁぁぁぁってプログラム書く手が動くような事あるだろ？

303デフォルトの名無しさん2014/07/26(土) 11:34:58.07ID:EislOxX9

業務ではないなｗ

304デフォルトの名無しさん2014/07/26(土) 13:52:30.19ID:F6Vf17wA

最近ソフトウェアが壊れていくプロセスってのが
わかりだしてきたよ。

いくつかパターンがあってね、名前でもつけて
近いうちに何処かで発表したいかなって思ってる。

たとえばモノマネパターン。
周りにあるコードを真似て書こうとするパターン。

このような関数があったとする。
function foo(name) {
　var funcTable = {
　　func1: functioni() {・・・},
　　func2: functioni() {・・・},
　　func3: functioni() {・・・},
　};
　funcTable[name]();
}

それを真似してこんなコードを書く
function bar() {
　var name = 'func1';

　var funcTable = {
　　func1: functioni() {・・・},
　};
　funcTable[name]();
}

もし0からコードを書かせたらこんなアホなコードを書くわけがないのに、
なぜか周りにあるコードを真似して書こうとする。

305デフォルトの名無しさん2014/07/26(土) 15:29:59.33ID:EislOxX9

クソコード書いて、次は誰かがもっといいコード書くだろうからそれマネしようとか思ってたら
俺のクソがプロジェクト中にコピペされて救いようがなくなってたことならある

306デフォルトの名無しさん2014/07/26(土) 23:32:58.38ID:F6Vf17wA

>>305
それそれ、誰もが知ってるコピペパターンｗ

できれば最初からクソコード書くなって話でもあるが、
それは仕方ない。誰でも成長するものなのだから＝後の自分はもっと綺麗に書ける。
なのに、昔の初心者のコードを真似る奴が多い多い。

それやってると、初心者のコードをありがたがって参考にしてどうするの？ｗ

話それたけど、本来はコピペするなら再利用できる形にリファクタリングして
それを呼び出さないといけない。そしてこれは絶対にやるべきリファクタリングの一つ。

ただし、無関係な処理なのに形が似ている（しかしわずかに違う）のを
無理やり共通化して複雑化させるパターンもあるので注意。

そういう場合でもコードはなるべくシンプルになるようにしなくちゃいけないのだが、
モノマネパターンの通り、なぜか同じ形を真似ようとする。
できないわけじゃないのに真似をする。何も考えてないのかねって思う。

307デフォルトの名無しさん2014/07/27(日) 02:21:16.13ID:xgsJlmZ9

仕様書が別になってたらどんなに処理が似てても別にするなあ

308デフォルトの名無しさん2014/07/27(日) 09:42:53.89ID:r3KMo0jq

似てる処理を共通化できないのは設計がきちんと出来てない証拠
仕樣的に別物とか関係ない

309デフォルトの名無しさん2014/07/27(日) 09:55:49.81ID:xgsJlmZ9

いやあるよ。
だいたい仕様変更が入ったときって、仕様書の画面毎とかだかし、
テストも仕様書毎につくるから、共通化してもテストの工数あんま減らんし。
修正になった仕様書の枚数と、手をいれる工数が一致してるとすごく客に説明しやすい。

>似てる処理を共通化できないのは
断じて違う。「似てる処理」を共通化するんじゃない。部品を共通化するんだ。
このへん誤解してなんど泣いたことか。
おまえのその考え方はスパゲッティまっしぐら。

310デフォルトの名無しさん2014/07/27(日) 09:59:56.78ID:EfhXqtXt

>>309
どんな考えでもいいけど何かしらの共通化がされてたら
> 修正になった仕様書の枚数と、手をいれる工数が一致
これは成立しないぞ
まず自分の矛盾に気付くのが先のようだ。

311デフォルトの名無しさん2014/07/27(日) 10:34:57.72ID:xgsJlmZ9

>>310
青いのう
部品を共通化するって考え方が徹底してれば、だいたいの場合は一致するもんだ。

もちろん客に説明するより少ない工数で済むならそれでいいよ？
問題は、「似てる処理」を共通化してると、工数が仕様書の改修量よりずっと膨らむことがあるってことなんだ。
ささいな修正が全体に影響してテストが膨らんだり、結局コピペで新たにクラス作らなくちゃいけなくなったりな

うん、これも共通化してるなら何でも同じとか言われそうだな
現実のブツ無しだと説明が難しいが…

312デフォルトの名無しさん2014/07/27(日) 10:58:40.58ID:EfhXqtXt

>>311
説明が難しいのはお前が「部品」とかいうオレオレ言語使って自己満足してるからだ。
ワケの分からん独自理論開発するまえに基本をしっかり勉強しろ。

313デフォルトの名無しさん2014/07/27(日) 11:02:04.82ID:M1h0x0Bb

>>311
甘いのう
残念ながら今時の設計者の中にはコードを全く書けないやつが少なからず居る
よって、共通化なんて幻想に過ぎぬわwww

314デフォルトの名無しさん2014/07/27(日) 11:19:32.95ID:aZ1TYiI9

func1(){
a b c d
}
↓
func0{
a b
}

func11(){
func0() c d
}

func12()
func0() e f
}
上のような共通化は似てる処理と部品どっちが主張しているんだ？

315デフォルトの名無しさん2014/07/27(日) 11:22:29.85ID:xgsJlmZ9

>>312
独自理論じゃないよ！みんなそう言ってるよ！
お前こそ本読んで知った気になってるだけだろ！頭でっかちめ

確かに、だいたい初心者向けの本には同じ処理を共通化すべしとか適当に書いてあるから、
実際の経験がないと理解しづらい部分ではある。

316デフォルトの名無しさん2014/07/27(日) 13:06:38.84ID:oB6jVO7Z

>>315
「部品」で意味してるのは何なんですか？

317デフォルトの名無しさん2014/07/27(日) 14:19:58.36ID:xgsJlmZ9

>>316
ごめん。一般的じゃなかった。
「機能」って読み替えて。

318デフォルトの名無しさん2014/07/27(日) 14:22:31.05ID:5m0dj4Xz

人間は細胞でできているだろ
プログラムも細胞で作れば上手くいく
俺の独自理論だけど

319デフォルトの名無しさん2014/07/27(日) 14:35:22.28ID:b6NTPR2W

うだうだ言わずに 60兆個の細胞を持ってこい

320デフォルトの名無しさん2014/07/27(日) 15:03:56.50ID:kK8gelhu

共通化するときの決まりの一つとして、
全く同じコードの時に共通化するのであって
似ているコードを共通化してはいけない。

似ているコードをむりゃリ共通化しようとすると、
引数で処理を分岐することになる。
aが渡されればAの処理を、
bが渡されればBの処理をみたいに。

引数で分岐しだすとアウトだな。

321デフォルトの名無しさん2014/07/27(日) 15:10:03.90ID:oB6jVO7Z

>>317
あーなるほど
わざわざありがとうございます

322デフォルトの名無しさん2014/07/27(日) 18:36:01.67ID:b6NTPR2W

経験的にforの内部、ifの内部は関数にまとめると都合よいことが多い
そして気が付くと xxhelper, xximpl, xxsub といった関数であふれるｗ

323デフォルトの名無しさん2014/07/27(日) 22:38:54.70ID:j6qWMrth

>>320
似ている理由を吟味するのがリファクタリングだろ。
似ている理由を吟味した結果、同じことをちょっと違った実装しているだけと気付けば問題なく共通化できる。

324デフォルトの名無しさん2014/07/28(月) 00:24:14.35ID:PUM3vemV

>>323
設計段階で、最初から同じものだと分かってるものでさえのちのち弊害出てくるのに。
後付けでコード眺めて似てるじゃんとか思っただけのもんがまともに共通化できるわけないだろうが

325デフォルトの名無しさん2014/07/28(月) 09:35:31.93ID:DND3Jclf

それを吟味するってことだろ。JK

326デフォルトの名無しさん2014/07/28(月) 19:34:15.48ID:dU5jf/g6

コードの字面で共通化とか言ってたらそら失敗するわ

327デフォルトの名無しさん2014/07/28(月) 22:31:59.96ID:ZMdkhV+Q

共有化するには物事を抽象化するセンスが問われるから、
低能が共有化しようとして失敗するのは良く分かるよ

それに、言語によってはクロージャやメタプログラミングが無かったり
有っても扱い難かったりして、実現可能な抽象化が限られるケースもある

328デフォルトの名無しさん2014/07/28(月) 23:39:29.31ID:PUM3vemV

クロージャｗメタプログラミングｗ
どんだけ狭い視点で話してんだよ
それかなにか、お前は世界中で使われるライブラリの設計者かなにかか？ｗ

お前のコードとか会社に出たら即ゴミ箱行きだよｗｗ
ただの帳票出力で得意げにtemplate使ってんじゃねえｗｗｗｗ後引き継ぐ奴の身になれ
死ね。くさかどああｋｊｓｄふぁｊ；ｆじゃ死ねええええ

329デフォルトの名無しさん2014/07/29(火) 00:32:02.60ID:A/TMSH0w

トラウマだったのね。

330デフォルトの名無しさん2014/07/29(火) 09:33:14.47ID:Rzs2MIMk

自分の経験上、>>328みたいにプログラミング言語の機能の話を
狭い視点とか言い出す奴って
コードをロクに書けないSEモドキに多くて、
そういう奴に限ってリファクタリングにも否定的なんだよね

コード読めないからリファクタリングの価値を実感出来ないのかな？

331デフォルトの名無しさん2014/07/29(火) 13:10:26.45ID:DxicYUyC

夏休みの学生が妄想で書き込むスレ

332デフォルトの名無しさん2014/07/29(火) 18:26:00.62ID:Wf2KiU9x

自分と同じドカタ仕事してる奴以外は
全て学生に見えてしまう様になったら病気です

333デフォルトの名無しさん2014/07/29(火) 20:26:27.73ID:vPKzHxKl

自分の経験上、リファクタリングしたがる奴は例外なく低スキル。

334デフォルトの名無しさん2014/07/29(火) 20:36:44.73ID:ahLU5tbJ

アホに効果を実感させるところまでが能力の内です

335デフォルトの名無しさん2014/07/29(火) 21:31:45.45ID:X6c6OHYr

アホSEがExcel仕様書の罫線を二重罫線に書き換えて
仕事したつもりになってるのに比べたら
比較にならないレベルの価値があるよ > リファクタリング

336デフォルトの名無しさん2014/07/29(火) 21:41:52.70ID:jt6qgrVo

２重罫線を大事にする客だって多いわ。
客はコードの中じゃなくて、資料とか見るんだわ。

リファクタリングなんかしたらね、
なんかちょっと挙動変わってるんだけど？
障害じゃないけど勝手に変えちゃ駄目でしょ。
うん？次からは言います？いや、そもそも動いてるもん変えなくていいよ
って話になる。

なんでもかんでもリファクタリングだのオブジェクト指向だの、
時と状況関係なしにやろうとするアホが多いんだよな。

337デフォルトの名無しさん2014/07/29(火) 22:05:08.74ID:Lzz8ZlFD

工数改善の見通しが数字で説明できるならともかく
実感とかで勝手にリファクタされたらたまらんわｗ

338デフォルトの名無しさん2014/07/29(火) 22:24:39.47ID:7mGq5kmY

受託開発やってるところと
自社サービスの開発やってるところは
何もかもが全然違うんだから、
分けて議論しないと平行線のまま

339デフォルトの名無しさん2014/07/29(火) 22:32:24.06ID:jt6qgrVo

SEがどーのこーの言ってるんだから受託だろ

340デフォルトの名無しさん2014/07/29(火) 22:51:00.80ID:X6c6OHYr

受託なんてドカタを人月で売って稼ぐビジネスモデルなんだから、

リファクタリングでコードを拡張しやすく保ち、
機能拡張を他社より速く行う事で競争優位に立つ

とか、そういうのは関係ないじゃん？

お前らマクドナルドのパートと大差無いんだから、
技術者の議論に入ってきちゃダメだよ

341デフォルトの名無しさん2014/07/29(火) 23:05:38.45ID:Lzz8ZlFD

>>340
ほー。
具体的にどういう課題があってどんなリファクタして、プロジェクトがどの程度成果上げたのか具体的に説明してみ？

壊れたレコードみたいに本で読んだこと繰り返して、しかも理解が浅くて現実が見えてないっぽいから
底辺派遣てすぐばれるよｗ

342デフォルトの名無しさん2014/07/29(火) 23:07:53.67ID:fZzOasD9

>>341
現実つーかレスの意味が見えてないのはお前のほうだな

343デフォルトの名無しさん2014/07/29(火) 23:56:17.33ID:vPKzHxKl

何か高度な裏の意味があるらしい

344デフォルトの名無しさん2014/07/30(水) 00:19:39.30ID:2joTlTTw

自社サービスで食っていけてるってだけで圧倒的な成果だろうな

労働集約型な受託開発なんて価格競争で擦り減るばかりで
エンジニアに何のメリットもないし、早く脱出すべきなんだけど
脱出するためのスキルが溜まらない負のスパイラル

345デフォルトの名無しさん2014/07/30(水) 09:05:15.28ID:NitIOFnC

SEが設計してコーダがコード書くってスタイルと
リファクタリングは相性悪いだろうな

346デフォルトの名無しさん2014/07/30(水) 11:16:11.07ID:l4R9UcQd

SEの設計が日本語プログラミングになってるからな。
日本語と一対一のコードでないとめんどくさいことになる。

347デフォルトの名無しさん2014/07/30(水) 18:54:49.24ID:z3bvSX8e

>>346
それで食えないスパゲティの一丁上がりかw

348デフォルトの名無しさん2014/07/30(水) 20:26:49.42ID:njRDxY7Y

リファクタリングは1にも2にも自分のためにやるものだ
デスマーチを充実したアフターファイブに変えたければやっとけｗ

349デフォルトの名無しさん2014/07/30(水) 21:00:14.66ID:JOmnGzMa

>>346
その日本語プログラミングではBASICにも劣る
抽象化しか出来ないのが問題なんだよね

350デフォルトの名無しさん2014/07/30(水) 21:00:10.81ID:O2fC1zxl

そしてリファクタスパイラルへ…

351デフォルトの名無しさん2014/07/30(水) 22:54:34.89ID:xH5zP1F6

リファクタリング否定派は技術力に乏しく低脳という風潮

一理ある

352デフォルトの名無しさん2014/07/30(水) 23:20:51.69ID:B3MDpURs

どう考えてもすぐリファクタする方が低脳だろｗ
リファクタしたがる奴の傾向として

・理解力の不足。
自分に理解できないものをすぐ諦めてクソ呼ばわりする。
他人の書いたコードの一貫したポリシーや目的を汲み取れないから、先人が用意してくれた便利なライブラリも使えない。
理解できないから規約も無視しがちで、彼の書いたところだけ作りがおかしい。

・謙虚さの不足。
相手を見下して、自分のほうがいいものが作れると根拠なく信じてる。
すでに用意されているものを再発明するだけならまだいいが、
しばしば完成されたフレームワークの重要な部分にクソを差し込んでめちゃくちゃにする。

・計画性の不足。
先の見通しが利かないから、行き当たりばったりでクソしか作れない。
リファクタも行き当たりばったりにやるから、クソが超臭うクソになるだけということになりがち。
挙句に自分で訳がわからなくなって、成果物を全部消したりする。

・客観性の不足
自分のやったことの成果を、客観的に見ることが出来ない。
リファクタしたことで、掛けた工数がどれくらいでペイしたとか、数字で物事を考えられない。
彼がリファクタするのは、単に楽しいから。本人は仕事してる気になってるが、周囲から見ると遊んでるだけ。

という感じ。
そもそも最初からちゃんと書く能力があったら、リファクタしたいと思うことは少ないはず。

353デフォルトの名無しさん2014/07/30(水) 23:55:14.83ID:2joTlTTw

>>352
> ・理解力の不足。
> 自分に理解できないものをすぐ諦めてクソ呼ばわりする。
> 他人の書いたコードの一貫したポリシーや目的を汲み取れないから、先人が用意してくれた便利なライブラリも使えない。
> 理解できないから規約も無視しがちで、彼の書いたところだけ作りがおかしい。
>
> ・謙虚さの不足。
> 相手を見下して、自分のほうがいいものが作れると根拠なく信じてる。
> すでに用意されているものを再発明するだけならまだいいが、
> しばしば完成されたフレームワークの重要な部分にクソを差し込んでめちゃくちゃにする。

とりあえず、最初の二つだけで良いから
リファクタリングとの関係を論理的に説明してみ？

354デフォルトの名無しさん2014/07/31(木) 00:02:21.65ID:Jagb4X9u

>>353
他人の書いたコードを書き換えたがるんだよ…
自分に理解できないからクソだ。という理屈で。

クソに感じるのは自分の能力が足りないせいだということに気づかない。

355デフォルトの名無しさん2014/07/31(木) 00:08:01.18ID:jvFYVzT/

そんな奴、実際には見た事無いが
受託開発だとレベル低いから居るのかもしれんね

356デフォルトの名無しさん2014/07/31(木) 00:28:09.58ID:1DTVAKx3

>>354
具体的にはどう書き換えられたの？

共通化できる処理を各所にバラバラに書き散らかしてたのを
シンプルにまとめられた挙句
「DRYも理解出来ないアホが開発に関わるとか意味が分からない」
って言われたとか？

357デフォルトの名無しさん2014/07/31(木) 00:49:44.01ID:OYcKACC5

コードオナニストは、常にコード以外の観点が欠けているのが特徴。
いくら諭しても話が噛み合わず、日夜コードのブラッシュアップに励んでいる。

358デフォルトの名無しさん2014/07/31(木) 00:51:52.79ID:Jagb4X9u

>>356
知らん。問答無用で差し戻したから。

散々テストしたはずなのに客先に持ってったら動きが変わってて
共通モジュールに手が入ってたんで何やったのか聞いたら「わかりにくかったんでリファクタしました。」
何年も動いた実績あるモジュールにそんな理由でいじんなアホか死ね

>「共通化できる処理を各所に（略」
うん。そうだな…だいたい君と同じぐらいの理解度の奴だったよ。

359デフォルトの名無しさん2014/07/31(木) 00:54:29.60ID:jvFYVzT/

> 散々テストしたはずなのに客先に持ってったら動きが変わってて

それリファクタリングになってないから
リファクタリングじゃない話を使ってリファクタリング批判してどうすんだよ

360デフォルトの名無しさん2014/07/31(木) 01:01:10.62ID:Jagb4X9u

>>359
別にリファクタは批判してないよ？
考えもなしにリファクタしたがる奴を批判してるんだ。

361デフォルトの名無しさん2014/07/31(木) 01:07:13.72ID:jvFYVzT/

>>360
お前んところがレベル低くて、勝手にコードぶっ壊す馬鹿が居るってだけの
リファクタリングと関係ない話を一般論として語られても、
底辺は可哀想だなって感想しか持ち様が無いぞ

362デフォルトの名無しさん2014/07/31(木) 01:09:10.48ID:OYcKACC5

>>359
お前はリファクタリングのつもりかもしれんが
完璧なテストが存在しない以上、挙動が変わる危険は常につきまとうんだよ。

363デフォルトの名無しさん2014/07/31(木) 01:15:43.10ID:jvFYVzT/

完璧なテストとか言う以前に、
ろくに自動テストとか書いてないでしょ？

ていうか、レビューもまともに機能してない
（じゃなかったら>>358のケースなんてコードがマージされるはずない）
テストもマトモに書いてないじゃ、そりゃトラブルよ

364デフォルトの名無しさん2014/07/31(木) 01:21:33.19ID:1DTVAKx3

Excelで書かれたチェックリスト片手に手動でテストして
「散々テストしたのに」って言ってそう

365デフォルトの名無しさん2014/07/31(木) 07:53:29.99ID:RHNsF96S

>>336
挙動を変えるのはリファクタリングじゃなくて仕様変更だろ

366デフォルトの名無しさん2014/07/31(木) 21:56:38.46ID:w9LroIYe

仕様変更でもバグ修正でもいいが、
コードを書き換えたら挙動が変わることがある。

つまり、機能追加もバグ修正もするなってことだ。

367デフォルトの名無しさん2014/07/31(木) 22:08:52.98ID:t7+Ucdvo

ネストが揃ってないとか空行が多いとか
変数がはるか上で宣言されてるけど使ってるのは遥か下に固まってるとか
理解力以前に目が疲れるコードをどうにかしろって言ってるんだよ

368デフォルトの名無しさん2014/08/01(金) 18:46:58.63ID:xnEk5c3C

変数定義の位置を移動したりスペースを除去したり
するのもリファクタリングなわけだが

369デフォルトの名無しさん2014/08/01(金) 19:22:03.81ID:+GTzrZhA

失敗例をあげてリファクタリングは糞って言ってるの最高に滑稽。
井戸の王様を気取ってる蛙か

370デフォルトの名無しさん2014/08/01(金) 20:37:16.99ID:zWTZP0nt

OO批判と同じ流れだな

371デフォルトの名無しさん2014/08/01(金) 20:43:59.51ID:fzo9r37p

リファクタリングが糞なんじゃないよ
リファクタリングしたがる人が糞なんだよ

372デフォルトの名無しさん2014/08/01(金) 21:19:55.74ID:7+EywXB6

>>371
ゴミみたいなコードばっか書いてっから
他人にリファクタリングされまくっちゃうんだろ

373デフォルトの名無しさん2014/08/01(金) 22:07:17.79ID:2Z4Uf/Xj

新人はリファクタしたがっていかん
関数の共通化とかGenericsとかTemplateとか覚えたてのこと使いたがる

ちょっとしたクソが一晩したらそびえたつ巨大なクソに

374デフォルトの名無しさん2014/08/02(土) 01:12:27.41ID:tvZxKsuR

技術レベルの低い人ってのは初心者に近くて
リファクタリングという技術用語を理解できないんだよ。

だからわかり易い言葉に置き換えるといい
リファクタリング＝整理整頓・改善

こう言い換えれば、改善する必要があるんです。
整理整頓すると普段の仕事が捗るんです。ということになる

こう言い換えれば、反対する人はいなくなるよ。

375デフォルトの名無しさん2014/08/02(土) 01:27:17.11ID:nhTOdUsW

生理整頓した状態を維持しながら仕事しろよｗ
個人レベルの話ならクソコードをフィックス前にに最低限他人が読めるようにするのなんて責務のうちだ

リファクタはどっちかというと組織再編といったほうがいい
課題と今後の見通しがあってはじめてやることで

376デフォルトの名無しさん2014/08/02(土) 02:10:54.57ID:tvZxKsuR

>>375
その責務を果たさない奴が、
行き当たりばったりのコード書くんだよな。
そいつに限ってリファクタリングの意味を理解してないという。
もう技術者として終わってるとしか言いようが無いね。

377デフォルトの名無しさん2014/08/02(土) 08:46:20.40ID:Mu2XuA5N

リファクタリング本を一回読んだとき何を感じるかだよな。
ああそうそう、こういう点で苦しくなってたんだ、って気付くか、
何一つピンとこずに何やってんのこの本？と思うか。

378デフォルトの名無しさん2014/08/02(土) 11:09:34.62ID:nhTOdUsW

クソコードを普通のコードに直す作業をあんまりリファクタと呼びたくないｗ

379デフォルトの名無しさん2014/08/02(土) 11:27:29.15ID:h5SZ209F

結合テストとかまで進んじゃったら無理だよね

380デフォルトの名無しさん2014/08/02(土) 11:55:25.68ID:nhTOdUsW

リリースした後でバージョンアップのついでにやるもんだろ

381デフォルトの名無しさん2014/08/02(土) 11:59:50.68ID:tvZxKsuR

ボーイスカウトの法則といって、
コードを修正するときは、修正する前よりも
綺麗にするもんです。

これが出来るのと出来ないのが、
初心者と中級者の境目。
もちろん、出来ないほうが初心者ね。
これが許されるのは新卒1年ぐらいなもん。

382デフォルトの名無しさん2014/08/02(土) 12:22:30.70ID:DmU4GxTK

規模が小さいうちは手抜きで簡単なコードを書くだろ？
最初から拡張性とかそういうものを考えて作りこまない。

で、規模が大きくなってきた時に、将来性のことを
考慮して作り変えればいいんだが、
最初の手抜きのコードをそのままに、手抜きを真似して
同じようなコードを追加するやつどうにかならんかね。

規模に応じたコードの書き換えをしない。できない。
発想がない。そういうい奴がクソコードを量産するんだよ。

383デフォルトの名無しさん2014/08/02(土) 12:37:41.39ID:Ydx1jnyI

権限のない末端PGが現場の手続き無視してユニットテストのないコードを
勝手に修正する、自称リファクタリングは非常に迷惑。

日本の受託開発の仕事ではリファクタリングなんてするべきではない。

384デフォルトの名無しさん2014/08/02(土) 12:42:59.05ID:DmU4GxTK

>>383
ユニットテストが無いことが前提になってる時点で、
やっぱり、その程度の所が、リファクタリングを嫌ってるんだなとしか
思えないよ。残念だったね。君のところの技術不足を露呈しただけ。
えと、技術力不足であることを自覚してね？落ち込むところだよ。

385デフォルトの名無しさん2014/08/02(土) 13:29:01.01ID:a3/R4SSz

最初から厳密に書けばいいんだよ
手抜きコピーが多いのは、そういうものかと思ってしまうからだ
自称上級者がスタートアップ書くことが多いが、手抜き繰り返して
しまいには自分自身が変な癖背負い込んでいくだろう
初期段階でよい方向に導くには、最初のやつががんばるしかない

386デフォルトの名無しさん2014/08/02(土) 13:37:36.15ID:DmU4GxTK

人間誰しも、最初は初心者で
一年後には今よりも成長しているという
前提にたつと最初から完璧なコードを書くのは不可能

どんなに優れたコードを書いたとしても
一年後の自分はもっと優れたコードを書ける。

387デフォルトの名無しさん2014/08/02(土) 14:03:04.41ID:nhTOdUsW

>>386
この程度の奴がリファクタしたがるんだよなあ…

リファクタってのはある設計から別の設計に軸足を移すことだ。
書き散らしたクソコードを書き直すのは、リリース前にやっておくべきそれ以前の問題なんだよ。

お前の末端の画面とか帳票とかは、誰も共通機能として使ってないから汚かろうがクソだろうが問題ないよ。
お前の自己満足のためにプロジェクトとめられてたまるか。
どんなクソでも、客の前にひりだしたクソはてめえのクソだ。受け入れて前に進め。

388デフォルトの名無しさん2014/08/02(土) 14:06:28.03ID:nhTOdUsW

大体最初からある程度ちゃんとしたプログラムも書けないやつに
まともなユニットテスト作れるわけないだろうが。

389デフォルトの名無しさん2014/08/02(土) 14:26:29.65ID:1FEiY+vP

理想だけど
組織には逆らえない

390デフォルトの名無しさん2014/08/02(土) 14:42:12.73ID:wGpqnjMj

関数の中身やprivateな関数のインターフェースを修正するようなリファクタリングと、
ライブラリのpublicなインターフェースを変更するような
影響範囲の大きいリファクタリングの話が混じってる気がする

後者はそう簡単じゃないよ
影響範囲に入る全ての開発者と調整が付かない限り変更できない
（勝手に変更したら、ライブラリ使用者側から見たら仕様変更だからリファクタリングにならない）

391デフォルトの名無しさん2014/08/02(土) 14:44:44.99ID:atIEditt

初心者にオススメなのは、派生開発でコードを読むときに、動作確認をテストで書くことかな。これはとっつきやすい。
『レガシーコード改善ガイド』では「仕様化テスト」のところ。

392デフォルトの名無しさん2014/08/02(土) 14:54:07.48ID:1BrdY1ES

>>380
そんな意識の奴と仕事したくないわ

393デフォルトの名無しさん2014/08/02(土) 15:20:52.89ID:DmU4GxTK

リファクタリングするなっていってる奴がいるけどさ、
時間が十分にあるという前提にたつと
とたんに何も言えなくなってしまう

それってリファクタリングがダメなのではなくて
時間がないという問題だから。

じゃあ、なんで時間が足りないんですか？
今までと同じやり方してるんじゃないですか？って
追い詰めると、泣き出しちゃうｗ

394デフォルトの名無しさん2014/08/02(土) 15:21:48.08ID:DmU4GxTK

>>390
そういう場合は、旧関数の互換性を保ちながら
新しい関数を作ればいいんだよ。

395デフォルトの名無しさん2014/08/02(土) 15:32:36.71ID:WtoScNjl

>>390
そういうことのないように依存性を無くすようにプログラミングする
プログラマの規律が無いだけ

396デフォルトの名無しさん2014/08/02(土) 17:35:26.06ID:w2qydRR0

当たり前のことを当たり前に理解してそれを前提としている人と、
当たり前のことなのに全く理解しないでそれを前提とできない人とが会話しているようだ。

397デフォルトの名無しさん2014/08/02(土) 19:06:34.85ID:jgRhK7n4

ウォーターフォールだったり、詳細設計書で日本語プログラミングしたりしてるとこと
リファクタリングは相性悪いよ
開発の全体を見直さないと、一部だけ優れた手法を取り入れようとしても
歪みが出て上手く行かないんだよね

398デフォルトの名無しさん2014/08/02(土) 19:30:03.16ID:DmU4GxTK

うまくいかないんじゃなくて
難しいだけだろ？

それを実行する力が技術力なわけで。

399デフォルトの名無しさん2014/08/02(土) 19:41:02.16ID:q1w4boEu

どうしても自分が書いたコードを書きなおしたい人がいるようだけど
そんなコードはいずれバグで書きなおされるんだから、あまり気にしない方が良い。
その情熱は悪くないけど、もっと前向きに使うべきだよ。

400デフォルトの名無しさん2014/08/02(土) 19:57:31.28ID:DmU4GxTK

前向きって新しいコードを書くってこと？
残念だけど、開発ってのは既存のコードの修正がほとんどだよ。

新しい機能を追加するといっても
前よりも効率よく開発するために既存の部分を、
使いまわす（コピペじゃないからね！）するために
既存の部分を修正して使えるようにするんだから。

401デフォルトの名無しさん2014/08/02(土) 19:57:37.46ID:FIwNTFpf

>>397みたいな事言ってると、拡張を繰り返すうちにコードが保守不能なカオスになって
もう無理だから全部捨てて作り直しだー、ってなるんだよ

でもSIerとしては、それが飯の種だから良いんだけどね

402デフォルトの名無しさん2014/08/02(土) 20:03:28.32ID:DmU4GxTK

全部捨てて作り直しだーまで追い詰めるって馬鹿だと思う。
少しずつ変化させていくことができないからそうなるんだよね。
全部いっぺんに変えるなんて現実的じゃないんだから。

全部いっぺんに変えることは不可能。じゃあどうするか？
それに答えられないから、どんどん壊れていくんだよ。

まあ、少しづつ良くしていくことが出来るのも技術力なわけで。
それを頭でわかっているのと実行するのとは全然違うわけで、
その実行できる力ってのが技術力そのものなわけで。

403デフォルトの名無しさん2014/08/02(土) 20:19:36.36ID:q1w4boEu

>>400
前向きってのは、コード書きの脳からデザイナーの脳に変われるように努力しろって事。

404デフォルトの名無しさん2014/08/02(土) 20:23:43.06ID:DmU4GxTK

>>403
何に逃げてるのさ？

両方できるようになるというのなら正しい意見だが、
別のものに逃げたらだめだろ。

まるでペンもイラレもろくに使えない奴が
発想力とかいうのに逃げているのと同じ。

コードをまともに書けるようになった上でデザイナーになることはできる。
だけど、コードから逃げてもデザイナーにはなれない。

405デフォルトの名無しさん2014/08/02(土) 20:23:58.64ID:J1UwFk0L

よくある設計とコーディングっていう役割分担からしてくるっとる。
プログラミングなんて、設計九割五分なのに。
実装なんざオマケのオマケ。

SEとプログラマ、とわけてプログラマがキーボード叩く役とか、きがくるっとる。
まぁ聡明なお前らの会社は違うだろうけどね。

406デフォルトの名無しさん2014/08/02(土) 20:28:21.78ID:DmU4GxTK

「前向き」って言ってる奴が、
コードとデザインの両方を手に入れるじゃなくて、
コードから逃げてデザインを求めていて笑えるよ。
そういう奴は両方できない。

407デフォルトの名無しさん2014/08/02(土) 20:33:33.15ID:a3/R4SSz

やっぱり自分でコード書かなきゃやってる気がしない

408デフォルトの名無しさん2014/08/03(日) 00:40:07.16ID:ppjITjjs

もう最近ガチガチの詳細設計やるとこって殆ど無いだろ
コメント的仮想コードとかで詳細は終わらせちゃうところが多い
その方が柔軟だしな

409デフォルトの名無しさん2014/08/03(日) 00:45:38.31ID:CSranqfK

一応UMLでシーケンス図とクラスとPublicメソッドだけはきっちり作ってるな
DBアクセスとかあたりまで
そっから先はprivateで実装して
アプリのフレームワークに依存しないメソッドとかクラスとかはプCommonフォルダに各自放り込んでもらう

で上手くいくと思ったけど
Commonがかなりカオスなことに

410デフォルトの名無しさん2014/08/03(日) 07:51:54.04ID:KHwMExMo

>>408
あー、主に非技術者がやる作業だね。

411デフォルトの名無しさん2014/08/03(日) 07:57:18.76ID:mU4IZymt

>>409
＞Commonがかなりカオスなことに

kwsk

412デフォルトの名無しさん2014/08/03(日) 10:20:01.47ID:1nxvzFtA

まるで業務系しか仕事がないかの勢いw

413デフォルトの名無しさん2014/08/03(日) 10:36:51.70ID:CSranqfK

>>411
コードが酷いのは予想のうちだけど
あれだけ言ったのに、規約が守られずにアプリのフレームワークに依存が作られてる
最初あたりに誰かがやったせいで後続が真似して、手続きなんとなくまとめただけみたいな処理がいっぱい
関数の共通化もうまくいってなくて
例えば分かりやすいところでは文字列をバイト列に変換してパディングするって処理があるんだけど
SJisStringUtil.ToByte
DBCodeChanger.LeftPaddingByteArray
StringModel.BytesWithSpace
こんな感じでいっぱいできてる
挙句にsTanakaとかフォルダできてるしｗ

414デフォルトの名無しさん2014/08/03(日) 10:42:19.36ID:KHwMExMo

まあありがちやねｗ

だから規約を作った人は
必ずコードレビューをしなくてはいけない。

415デフォルトの名無しさん2014/08/03(日) 20:06:25.42ID:lk1xFWmM

>>953
糞設計、糞コード書くような人たちが
集まってコードレビューしてもなんの意味もない
しかもそういう人って声が大きいだけが取り柄みたいな人だろうし

416デフォルトの名無しさん2014/08/03(日) 21:25:01.28ID:LWW935BO

ロングパスきっちり通せよｗ

417デフォルトの名無しさん2014/08/03(日) 23:57:33.38ID:tNPEJw6R

Ａ社に発注して作らせた大規模なソフトを、
Ｂ社に一時的にメンテナンスさせて、
今はＣ社に機能拡張させているとか言う例が実際にあるからなー

それぞれがそレなりにちゃんとした会社であっても、
開発者の継続性が０の場合、
中のソースがかなり混乱するのは仕方ないかもしれん。

418デフォルトの名無しさん2014/08/04(月) 22:06:42.37ID:w1xJJUBp

リファクタリングはアートですよ。
アートは人間が生み出すものではありません。
ある日、天から降りてくるんです。
この感覚がわからない人は、アートしたことが無いんです。
つまり、リファクタリングもわからないってことです。

419デフォルトの名無しさん2014/08/04(月) 22:17:15.14ID:p5AMhKr8

わかる、わかるぜ～
ソースコードがある書き方になりたがってねだってくるんだぜ～
俺はそのとおりに書き写してるだけなんだぜ～

420デフォルトの名無しさん2014/08/04(月) 22:19:31.15ID:w1xJJUBp

やべえ。
適当ぶっこいてたらマジキチ召喚しちまった。
ちょっと反省。

421デフォルトの名無しさん2014/08/04(月) 22:54:50.48ID:O7gnQe0p

自作自演乙

422デフォルトの名無しさん2014/08/27(水) 12:13:22.10ID:RluTUsi0

他人のコードだと思って、何の前情報もない状態でコードを読み
そこから読み取れる情報だけで、「なんで？」って思う実装を減らしていくのがリファクタリング

もちろん、処理の効率とかをよくする場合もあるけど、
どっちかというと、そういうのよりも第三者が見て読みやすいコードである状態を保つ事のほうが重要
(リファクタリングで大幅に処理コストが改善できるような糞実装が最初にされてることは稀)

ただ、リファクタリングをできるレベルに達していない職場も少なくない
とくに業務系や人売りで奴隷を集めた職場とかは、大抵メンバーのスキルが足りてなさすぎて無理
っていうか設計(という名のゴミファイル作成)段階からそびえ立つうんこを作っていってるから、実装時は既に手遅れ

423デフォルトの名無しさん2014/09/04(木) 15:14:28.47ID:NCM4vLJB

リファクタリングの誤用
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism

リファクタリングの境界線
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringBoundary

424デフォルトの名無しさん2014/09/13(土) 02:08:52.13ID:Bjr83Kqx

ボキもリファクタリングして欲しいです
https://twitter.com/y_konogi/status/510266774290694144/photo/1

425デフォルトの名無しさん2014/09/13(土) 02:46:33.71ID:99VHFg4q

ちんこの振る舞いを保持したまま変化させる、もちろん性的な意味で。

426デフォルトの名無しさん2014/09/13(土) 03:35:58.05ID:WOkelzJA

インタフェースの変更はリファクタリングか
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
> 宣言（Javaで言うメソッドやフィールド）の順序を変更することは、リファクタリングと呼べるのか？
> リファクタリングの定義で、「理解や修正が簡単になるように」というフレーズを使った。
> 宣言部分を変更すると、理解や修正が簡単になるのだろうか？私は、そういう場合もあると思う。
> ソフトウェアの内部構造を変更しないという点が紛らわしいかもしれない。リネームしても実行内容は変化しない。
> だがリネームは、プログラムの理解度を向上させる非常に重要なリファクタリングの一種である。

427デフォルトの名無しさん2014/09/13(土) 13:49:13.80ID:9aicrkfD

あれもこれも取り入れた「オブジェクト指向」とまるっきり同じパターンだな
どんどん曖昧な意味になりそう

428デフォルトの名無しさん2014/09/13(土) 14:14:43.12ID:Fgrmdz5F

すべてリファクタリングの結果発生する作業だろ。
まったく理解できていないな。まさに本末転倒

429デフォルトの名無しさん2014/09/13(土) 16:14:30.25ID:WJGPx/6o

要件を仕様にまとめるのもリファクタリングですか？

430デフォルトの名無しさん2014/09/13(土) 20:28:39.39ID:Y1nBtaE7

>>429
リファクタリングの一部ではあるな

431デフォルトの名無しさん2014/09/13(土) 20:33:35.66ID:zttb1Mfl

OpenSSLがリファクタリングされまくっているな

432デフォルトの名無しさん2014/09/14(日) 00:35:49.32ID:a/rqPd2y

>>429
違う

> リファクタリング中に2,3日システムが動かなくなっちゃってーなどと言ってる奴がいたら、
> んなもんリファクタリングじゃあなーいと言ってやれ。ドキュメントをリファクタリングしちゃるとか言ってる奴、
> それもリファクタリングじゃねーぞコラ。そういうのは、リストラクチャリング（再構築）というのだッ

433デフォルトの名無しさん2014/09/14(日) 02:43:07.06ID:XHTMIvTT

客の要件はそのままプログラムにできるけど、
それじゃあ最適化できてないから
外面の挙動は変わらない範囲で最適化を行う。
コードの実体だけがリファクタリングの対象じゃないだろ。

434デフォルトの名無しさん2014/09/14(日) 03:54:19.00ID:a/rqPd2y

>>433
それこそがリファクタリングの誤用で
リファクタリングではないと述べられていること。

435デフォルトの名無しさん2014/09/14(日) 10:24:07.39ID:NZ+I8Nx6

最適化じゃないんだよ
最適化なんかできるわけねーだろってのが大前提なんだよ

436デフォルトの名無しさん2014/09/14(日) 13:02:21.11ID:bjSSfYoR

バグも含めて機能そのままで、構造だけ変える（良くするつもり）ができるっていうのが結構単純な
還元主義的な思い込みで、実際の構造物は両者は一体というか、都合良くできないと思うんだよね。

テスト駆動とかもそうだけど、この種のスローガンが胡散臭いのは、物作りの本質的な困難を直視
しないで、小手先の技法を当てはめれば解決みたいに喧伝しすぎるところにあるんじゃないかと思う。

437デフォルトの名無しさん2014/09/14(日) 14:21:12.62ID:TJC+Xrrg

別に胡散臭いとは思わないが、真に受けちゃったバカが「リファクタリング最強！」とか言い出すのはかなりうざい。

438デフォルトの名無しさん2014/09/14(日) 15:42:46.67ID:a/rqPd2y

>>436
> バグも含めて機能そのままで、構造だけ変える（良くするつもり）ができるっていうのが結構単純な
> 還元主義的な思い込みで、

できるよ。

というか、リファクタリングは構造を良くしましょう（終わり）じゃなくて、
構造を良くするのは当然の話しとして、機能をそのままにするためにはどうすればいいか？
って所が出発点で、

機能をそのままにするために、編み出された様々なテクニックが
リファクタリング手法なんだよ。

できないというのなら、リファクタリング手法（それには名前が付いている）
一つ一つに対して出来ない根拠を述べてみてよ。

君は単に、リファクタリングに手法があることを知らないで、
闇雲に自己流でなおそうとしてみて失敗しただけでしょう？

439デフォルトの名無しさん2014/09/14(日) 15:44:54.17ID:a/rqPd2y

なんだ、自分で自白してるじゃんかｗ

> この種のスローガン

スローガンとしか認識していないｗ

リファクタリングは、数学的な証明と
なんらかわらないんだが。

440デフォルトの名無しさん2014/09/14(日) 18:12:37.41ID:d9eejC+C

ダメなコードは直すことでよくできる
という公理が大前提
1000行もあるようなおバカ関数を数学的に定式化して改善するのは無意味なこと
見れば何をすべきかわかる

441デフォルトの名無しさん2014/09/14(日) 18:52:51.74ID:a/rqPd2y

>>440
つまりどういうこと？
リファクタリングすればいいって話を
言葉を変えていってるだけだよね？

442デフォルトの名無しさん2014/09/14(日) 19:25:36.36ID:3Rt2m2d6

リファクタリングを知らない人は、
リファクタリングを一気に直してしまおうと
思っているに違いない。

リファクタリングが問題が起きることがありえない
小さな修正の繰り返しであることをしらない。

443デフォルトの名無しさん2014/09/14(日) 19:30:47.61ID:NZ+I8Nx6

デザパタ信者みたいなのが暴走して悪評を広めてるんだろう

444デフォルトの名無しさん2014/09/14(日) 19:32:04.00ID:3Rt2m2d6

その悪評を鵜呑みにしているのが
頭悪いと言われる所以なわけで。

自分の頭で考えろよとｗ

445デフォルトの名無しさん2014/09/14(日) 21:08:34.07ID:oiv3svus

リファクタリング

446デフォルトの名無しさん2014/09/15(月) 00:27:34.64ID:irRiVyM3

流石に数学の定理と同等か言い過ぎだろ。
パターンと同じでさ、セオリーやメソッドじゃない、ちょっとしたコツの集積だろ

オブジェクト指向、CMMI、PMBOKとかと同じでさ、アメリカ人の教授とかはそういうのまとめて
自分が言い出しっぺになって、学会ごっこしたり、資格試験の元締めやろうとしたりするのが好きなんだよ。

そういう商売に乗せられているだけなのに、さも学術的な根拠があるものとして「勉強」したりするのが
偉いと思っている奴はどっかオツムが弱いとしか言いようがないw

447デフォルトの名無しさん2014/09/15(月) 00:37:25.87ID:9UWhhSIJ

>>446
数学の定理じゃなくて、数学の証明だろ？

a + b = c を b = c - a
に置き換えるようなもの。

式の変形だよ。

リファクタリングのテクニックっていうのはどれも
この式の変形と同じようなもの。

一部の人が勘違いしているように、ぶっ壊して同じように作りなおすことじゃなくて、
項の移動のように、全く同じ結果になる変形をしているにすぎないんだよ。

448デフォルトの名無しさん2014/09/15(月) 00:39:47.71ID:9UWhhSIJ

>>446
あと警告として、自分が知らないことを
勉強している奴は生意気だっていうのやめたほうがいいよ。
中学生かよ。あいつ勉強なんかしてるんだぜーってｗ

449デフォルトの名無しさん2014/09/15(月) 00:43:11.40ID:irRiVyM3

何が「警告」だよ
笑わせるな

450デフォルトの名無しさん2014/09/15(月) 00:44:52.76ID:9UWhhSIJ

いや、普通に恥ずかしいでしょ？

ガリ勉ガリ勉いって勉強しない悪ガキ。
自分が後で困るというのに。

警告してあげないといつまでたっても
気づかないよ。

451デフォルトの名無しさん2014/09/15(月) 01:15:03.90ID:WaQuX0Y8

ぶっ壊して同じ結果が得られるように作り直すこととの違いを教えてください。

452デフォルトの名無しさん2014/09/15(月) 01:41:27.21ID:j8xvklWY

イチから作り直したい病と
現実の範囲で出来る事だけやる工夫の違い

453デフォルトの名無しさん2014/09/15(月) 02:07:53.50ID:WaQuX0Y8

機能やクラスを抽出するのだって破壊を伴うんじゃないの。
リスクが少ない範囲での変更もあれば、
時には大胆なリファクタリングもあると思うけど。

454デフォルトの名無しさん2014/09/15(月) 04:21:21.27ID:9UWhhSIJ

>>451
> ぶっ壊して同じ結果が得られるように作り直すこととの違いを教えてください。
たとえば数学で、3x - 11 = 4 のxを求めるという問題があった時

1. 移項とい手法を使って、3x = 4 + 11 にして、
2. 足し算という手法を使って、3x = 15 にして
3. 両辺を同じ数で割るという手法を使って、x = 5
という風に、変形をしても等しいと証明されている
安全な手法を使ってシンプルな形に変形していくのがリファクタリング

>>453
大胆なリファクタリングって何よ？

まずさ、数学の式の変形のやり方と一緒で、
リファクタリング手法には名前があるって知ってる？

一覧見つけてきたから、これのどれが大胆で破壊を伴うのかちゃんと説明してくれ。
http://d.hatena.ne.jp/asakichy/20100607/1275877997

455デフォルトの名無しさん2014/09/15(月) 04:22:40.33ID:9UWhhSIJ

>>453が言ってる、
大胆なリファクタリングというのは、

これらの手法を使わずに
いきなり最終的な答えを
だそうとしていることでしょ？

それはリファクタリングじゃない。

456デフォルトの名無しさん2014/09/15(月) 04:24:53.24ID:9UWhhSIJ

>>452も少し勘違いしているね。

リファクタリングを「ソースコードを綺麗にしましょう」ということを
英語で言ったものとしか認識していないようだ。

リファクタリングというのは、安全に変形できるという
手法を使って、いっぽずつ書き換えていくもの。

手法を使わない書き換えはリファクタリングじゃない。

457デフォルトの名無しさん2014/09/15(月) 10:57:57.36ID:z+pQ6G77

>>456
それな
その手法の確立というか
その手法の念押しというか
そういう面も大きい

458デフォルトの名無しさん2014/09/15(月) 11:09:38.77ID:pNNQiIbO

これがリファクタ信者の暴走か

459デフォルトの名無しさん2014/09/15(月) 11:28:39.31ID:kUSteVkT

リファクタリングの「関数の抽出」をやったら
増えた関数呼び出し分の実行コストが無視出来なくて
仕様を満たさなくなってしまいました

460デフォルトの名無しさん2014/09/15(月) 11:46:22.25ID:9UWhhSIJ

>>459
そしたら「関数のインライン化」という
リファクタリングをすれば
動作を変えることなく、仕様を満たせるようになるよ。

やっぱり問題が起きた時にやるのは
リファクタリングだね（笑）

461デフォルトの名無しさん2014/09/15(月) 11:49:22.77ID:kUSteVkT

つまり途中で一回ぶっ壊して同じ結果が得られるように作り直すわけね
良いと思うよ

462デフォルトの名無しさん2014/09/15(月) 12:21:05.22ID:NXR59SQz

リファクタリングがゲシュタルト崩壊しそうなスレだ。

463デフォルトの名無しさん2014/09/15(月) 12:43:17.41ID:zrs0o34A

安全を過信しすぎだな

464デフォルトの名無しさん2014/09/15(月) 12:46:23.34ID:9UWhhSIJ

>>461
一回ぶっ壊したらだめだろｗ
それではリファクタリングになっていない。

リファクタリングは壊さずに直すことであり
壊さないで直すための手法がまとめられている。
http://d.hatena.ne.jp/asakichy/20100607/1275877997

465デフォルトの名無しさん2014/09/15(月) 13:45:51.89ID:kUSteVkT

>>464
>>459の操作で一回ぶっ壊れてるじゃん
少なくとも「関数の抽出」はリファクタリングの操作としてアトミックじゃない

466デフォルトの名無しさん2014/09/15(月) 15:20:24.10ID:4lL49qVx

慌てずリファクタリングの公式に沿って変更すれば副作用は一切ない。

467デフォルトの名無しさん2014/09/15(月) 15:20:49.07ID:9UWhhSIJ

>>465
> 少なくとも「関数の抽出」はリファクタリングの操作としてアトミックじゃない

アトミックだけど？

リファクタリング本を見ればしっかり書いてあるよ。
アトミックに作業する方法。

どうせあんたは関数を消して書きなおす（書き直してる間
元の関数がなくなってる状態）が起きるって思ってるんだろうけど。

ほんと、やり方をしらんのね。しらんから壊れるって言ってる。
わかりやすい。

468デフォルトの名無しさん2014/09/15(月) 15:21:50.80ID:9UWhhSIJ

ちなみに、リファクタリングブラウザを使えばもっと簡単に行える。
もちろん、リファクタリング本にはそういうツールを使わないやり方も書いてある。

469デフォルトの名無しさん2014/09/15(月) 15:45:17.66ID:wmpEGwKw

>>459と>>460の間に一回壊れてるよね

470デフォルトの名無しさん2014/09/15(月) 15:51:22.11ID:wmpEGwKw

>>467
手で書き直したとかじゃなくて、メソッドの抽出することで
仕様を満たさなくなるケースもあるって話だろう

その直後にインライン化したとしても、一旦仕様を満たさない状態になったのは事実

471デフォルトの名無しさん2014/09/15(月) 15:53:23.99ID:KlWrYY91

まあ俺ぐらいリファクタリングに精通すると、最初からリファクタリング後の最終形になるように最初からコーディングできちゃうわけで、あえてリファクタリングを意識しなくていいわけなんだけどね。

中島敦の「名人伝」にでてくる「弓ってなに？」といった弓の名手のごとし。

472デフォルトの名無しさん2014/09/15(月) 15:55:47.97ID:9UWhhSIJ

>>469
壊れてないよｗ
ばかなのかな？
人の話きかないよね。

473デフォルトの名無しさん2014/09/15(月) 15:57:45.71ID:9UWhhSIJ

>>470
> 手で書き直したとかじゃなくて、メソッドの抽出することで
> 仕様を満たさなくなるケースもあるって話だろう

メソッドの抽出で仕様を満たさなくなることはありません。

> その直後にインライン化したとしても、一旦仕様を満たさない状態になったのは事実

あんたの言ってる「仕様」って関数呼び出し○ナノ秒以内で
あることっていう要件の話だよね？ｗ
それは仕様ではない。

474デフォルトの名無しさん2014/09/15(月) 16:00:52.19ID:9UWhhSIJ

>>471
それは過剰な設計になってるよ。

コードの規模に応じて、適切な設計というのは異なる。

コードに修正が入る、それがバグの修正でない限り
機能化拡張だろう。

機能拡張にともなって規模が増るというような時にリファクタリングをするんだ。
機能追加とリファクタリングはわけてやるものだから、
機能追加前、もしくは機能追加後にリファクタリングね。

最初から過剰な拡張性をもたせるのはよくない。

475デフォルトの名無しさん2014/09/15(月) 16:31:02.56ID:9UWhhSIJ

今更ながら>>1が言っていたことって正しいんだなって思った。

ソースコードを綺麗に作りなおすのがリファクタリングだって
思っている奴が多いこと多いこと。

476デフォルトの名無しさん2014/09/15(月) 16:59:56.60ID:WaQuX0Y8

ポリモーフィズム化するのは機能追加だアホ

477デフォルトの名無しさん2014/09/15(月) 17:07:57.72ID:kUSteVkT

>>473
> あんたの言ってる「仕様」って関数呼び出し○ナノ秒以内で
> あることっていう要件の話だよね？ｗ
> それは仕様ではない。

ループの中で繰り返し呼び出されたら馬鹿にならん差になることもある
仕様かどうかはケースバイケースだアホ

478デフォルトの名無しさん2014/09/15(月) 17:15:35.47ID:kUSteVkT

リファクタリングの「関数のインライン化」をやったら
生成されるプログラムのバイナリサイズが許容範囲を超えて
仕様を満たさなくなってしまいました

479デフォルトの名無しさん2014/09/15(月) 17:17:53.19ID:9UWhhSIJ

ID:kUSteVkT必死すぎだなｗ

”要件” を満たせないなら、
同じ仕様のまま要件を満たすように
リファクタリングすればいいだろうｗ

480デフォルトの名無しさん2014/09/15(月) 17:32:28.60ID:9UWhhSIJ

ID:kUSteVkTアは書いたコードが要件を満たせなかったら
そのコードを捨てて一から作り直んだろうかｗ

481デフォルトの名無しさん2014/09/15(月) 17:33:12.92ID:kUSteVkT

一日中スレに張り付いてる ID:9UWhhSIJ に必死過ぎと言われてもな…

で、リファクタリングの手法に則って変換しても
要件を満たせないケースがあると認めるのか？

482デフォルトの名無しさん2014/09/15(月) 17:38:23.74ID:9UWhhSIJ

やっと要件といったねｗ

リファクタリングは仕様を変えずに
コードをわかりやすい形に修正するものだから
要件を満たさなく慣れば、満たすように
リファクタリングすればいいってことで終わる話だ。

なんせリファクタリングしても仕様は変わらないのだから
仕様を変えずに要件を満たせるように作り変えられる。

483デフォルトの名無しさん2014/09/15(月) 17:44:05.42ID:kUSteVkT

>>482
いや、俺は最後に修正をコミットするときに仕様を満たしてれば
途中で壊れてようがリファクタリングとしてOKって立場だから、それで良いよ

でも、お前はリファクタリングの手法に則ってれば
絶対に壊れることは無いっていう立場だろ？(>>454-456)

484デフォルトの名無しさん2014/09/15(月) 18:58:56.46ID:j8xvklWY

絶対に壊れない奥義は秘中の秘で
師匠に皆伝を認められないと伝授してもらえないんだよ

485デフォルトの名無しさん2014/09/15(月) 19:33:35.36ID:wbbrJGCJ

リファクタリングってどのタイミングでやる事を想定してるのかな
プロジェクトにそんな工程存在しないし
終わって凍結したコードを後から修正なんてしないでしょ
不具合とか新機能とか更改する案件が出てきて初めて
次のプロジェクトやりましょうってなるわけでしょ
そうなったとしてコードの機能追加や修正はあっても
このスレで言う仕様通りに動くものにわざわざ手をつけるなんてことするかな

486デフォルトの名無しさん2014/09/15(月) 19:40:39.59ID:q3fGkS61

やりたい時がやるべき時なんだよ。
コードがクソだと思ったら何時でもそれがリファクタリングのタイミング。

487デフォルトの名無しさん2014/09/15(月) 19:58:17.80ID:wbbrJGCJ

だからそんなタイミングなんて実際存在しないよねって話をしてるのに

488デフォルトの名無しさん2014/09/15(月) 20:46:42.81ID:q3fGkS61

>>487
だからコードがクソだと思わなかったらやる必要ないんだって

489デフォルトの名無しさん2014/09/15(月) 21:25:15.72ID:9UWhhSIJ

>>483
> いや、俺は最後に修正をコミットするときに仕様を満たしてれば
> 途中で壊れてようがリファクタリングとしてOKって立場だから、それで良いよ

リファクタリングの誤用
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism
> ……のだが、リファクタリングは、適切に使われてはいない。
> リファクタリング中に2,3日システムが動かなくなっちゃってーなどと言ってる奴がいたら、
> んなもんリファクタリングじゃあなーいと言ってやれ。ドキュメントをリファクタリング
> しちゃるとか言ってる奴、それもリファクタリングじゃねーぞコラ。そういうのは、リストラクチャリング（再構築）というのだッ。

> リファクタリングはより具体的な技術のことで、小さな「振る舞いを保持したままの変化」
> （リファクタリングと呼ばれている）から成り立っている。システムをリファクタリングするときは、
> 数分以上、システムが壊れたままにしてはいけない。

490デフォルトの名無しさん2014/09/15(月) 21:31:41.31ID:eEkAvSkz

>>486
＞やりたい時がやるべき時なんだよ。

趣味だよなこういうのは
死ぬまでいじってろ

491デフォルトの名無しさん2014/09/15(月) 21:36:40.31ID:9UWhhSIJ

>>490
趣味とは、汚くても動けばいい。と
客の前で言えないことを、こっそりやること。

492デフォルトの名無しさん2014/09/15(月) 22:30:57.87ID:kUSteVkT

>>489
コミットするまでシステムはそのままなんだから（正確にはデプロイするまでだが）
完全にリファクタリングの定義に沿ってるよね
誤用してるのはお前だね

493デフォルトの名無しさん2014/09/15(月) 22:47:48.33ID:W2xZfE+V

IDEのリファクタリングのメニューから選べる機械的にできる変換のみを
リファクタリングとする派閥があるんだよ
要件を満たすかではなく、機械的にできる事が重要なわけ

なお、これは底辺の馬鹿でも可能な「ドカタ・スタイル」として認知されてる

494デフォルトの名無しさん2014/09/15(月) 23:33:30.39ID:jSabMZv+

>>492
これはひどい
バカというより迷惑

495デフォルトの名無しさん2014/09/16(火) 02:50:25.03ID:BRRsQsEe

>>446
>オブジェクト指向、CMMI、PMBOKとかと同じでさ、アメリカ人の教授とかはそういうのまとめて
>自分が言い出しっぺになって、学会ごっこしたり、資格試験の元締めやろうとしたりするのが好きなんだよ。

リファクタリングって、資格試験制度や学会作ろうって動きがあるのかな？
パターンはなんかやってるところあるよね。

496デフォルトの名無しさん2014/09/16(火) 04:23:48.75ID:1lKEIB+1

>>493
> IDEのリファクタリングのメニューから選べる機械的にできる変換のみを
> リファクタリングとする派閥があるんだよ

それは、リファクタリングをわかってない派閥であり、
無知なリファクタリング反対派となんらかわらないよ。

リファクタリング本を読んでいれば、
リファクタリングブラウザで行えるのは
リファクタリングのほんの一部だって知ってる。

497デフォルトの名無しさん2014/09/16(火) 12:38:21.05ID:5ipzkeYr

リファクタラー内部抗争勃発

498デフォルトの名無しさん2014/09/16(火) 13:41:58.56ID:UosJEOFn

リファクタリング前と後で同じテストが通ればOK派と、
リファクタリング中のどの時点でもテストが通らないとダメ派か。

499デフォルトの名無しさん2014/09/16(火) 19:13:39.64ID:BRRsQsEe

リファクタリングのアトミックな単位は一文字削除

500デフォルトの名無しさん2014/09/16(火) 20:19:15.75ID:c0zqQ2NF

>>1
リファクタリング自体が理想論。

つまりは、自分（以下Ａ）と同等かそれ以上の腕の持ち主だけで人材が構成されている必要がある。ただし、これは自分視点。
しかし、この状態だと、Ａ以上の腕の持ち主からＡを見ると、Ａは足手まといで汚いソースを作り上げる元凶。
上級者が、切磋琢磨していく状態なら良いが、上級者なんて1%もいない。99%の下手が次々と入ってきてクズソースを乱発。
腕の良い者達は、クズソースのリファクタ作業だけをやるハメに。
腕の良い者達だけでやっていれば、もっと早く開発ができるのに。しかしリファクタリングというとできるのは腕の良いものだけ。
よってクズの尻拭いを永久にやらされる上級者は、腐る。
そしておしまい。

リファクタ云々よりクズの徹底排除こそ最優先。
それがなされなければ、確実にクズソースの生成のほうが圧倒的に早い。

501デフォルトの名無しさん2014/09/16(火) 20:29:13.06ID:c0zqQ2NF

３行で言うと

1%の有能な人間のリファクタリングの速度より
99%を占めるクズが作り出すクズソース量産スピードのほうが速い
だから、間に合わない。

ということだね。

502デフォルトの名無しさん2014/09/16(火) 21:19:30.50ID:LXIAs8Mg

隠された4行目は

そして、1%の有能な人間はここにはいない。

か？

503デフォルトの名無しさん2014/09/16(火) 21:22:31.12ID:1lKEIB+1

>>500
何が理想論なのかと思えば、
あんたの会社では無理って話なんだね。

504デフォルトの名無しさん2014/09/17(水) 00:27:57.13ID:5OnPRq9A

また俺の会社すげえ自慢か
ITドカタのクセに生意気だ

505デフォルトの名無しさん2014/09/17(水) 01:33:42.78ID:ZHv/uS3X

なんで力量がはっきりしてない人のソースレビューもせずに、
終わってからリファクタリングしてるの。クズじゃないの。
自分のコード書くだけが仕事じゃねーんだぞ。

506デフォルトの名無しさん2014/09/17(水) 01:41:26.78ID:bT3aRSk/

リファクタリングが工程になのであればら、彼の知っている開発手法はそもそもTDDに向いてないので、その前提でTDDの話なんてできないと思うのです

世の中にはCIって概念があるのを知らないのだろうか

まぁ土方なら仕方ないと思いますが

507デフォルトの名無しさん2014/09/17(水) 01:43:13.03ID:bT3aRSk/

TDDすれと間違えたし、誤字りまくった
てへぺろ

508デフォルトの名無しさん2014/09/17(水) 02:10:48.96ID:B5vXdL5P

リバースエンジニアリングが難しいのと同じで、
自分でソースを書くよりも、
他人が書いたソースを読むのは、ずっと難しい

仕様書→ソースは、簡単
ソース→仕様書は、難しい

509デフォルトの名無しさん2014/09/17(水) 04:16:14.76ID:YtdMSBzp

>>504
> また俺の会社すげえ自慢か

俺の会社だせえ自慢じゃね？ｗ

510デフォルトの名無しさん2014/09/17(水) 04:18:50.43ID:YtdMSBzp

>>508
> 他人が書いたソースを読むのは、ずっと難しい

最近これ違うと思うようになってきた。

他人が書いたソースが読みにくいと思ったら
そのソースは他人が読むように書かれていない
自分よがりなソースコードなんだよ。

読む方に非があるんじゃなくて、書くほうが悪い

511デフォルトの名無しさん2014/09/17(水) 07:16:49.41ID:5OnPRq9A

自分よがりなんて書いてる奴は、他人に読みやすい文章になるような注意力に欠けた
独りよがりの文章しか書けないんだろうな。

512デフォルトの名無しさん2014/09/17(水) 12:15:48.80ID:Kfgv1MV9

>>511
うわあ読解力ﾊﾟﾈｪ

513デフォルトの名無しさん2014/09/17(水) 21:24:55.43ID:YtdMSBzp

>>511
> 独りよがりの文章しか書けないんだろうな。
独りよがりって、自分よがりと同じ意味じゃね？

514デフォルトの名無しさん2014/09/17(水) 23:24:58.57ID:IUDVFBKE

君達は本当に頭が悪いんだな

515デフォルトの名無しさん2014/09/18(木) 00:20:18.22ID:spGOayPR

うむ

http://www.weblio.jp/content/%E8%87%AA%E5%88%86%E3%82%88%E3%81%8C%E3%82%8A

自分よがり
読み方：じぶんよがり
別表記：自分善がり

ひとりよがり（独り善がり）に同じ。周囲を顧慮せずに自分の都合や損得のみで物事を考えること。

516デフォルトの名無しさん2014/09/18(木) 19:33:06.94ID:ot8C9XJ5

>>500
まぁほぼ同意だな

517デフォルトの名無しさん2014/09/18(木) 20:26:58.62ID:spGOayPR

>>516
自作自演しなくていいよ。
そんなコメント普通しないからｗ

518デフォルトの名無しさん2014/09/18(木) 22:19:08.95ID:+GRlEEjB

要求仕様の変更に追随するために設計を変えていくのがリファクタだ

撒き散らしたクソコード直すのはリファクタとは言わん
テストの前に個々人レベルでやる仕事だ

519デフォルトの名無しさん2014/09/18(木) 22:31:11.52ID:Lc9LBSGA

他人が作ったものをメンテする時は
まず他人にやらせろってこと？

520デフォルトの名無しさん2014/09/18(木) 23:29:47.48ID:i6De8Pgm

クソコード直すのがリファクタリングでいいと思うお

521デフォルトの名無しさん2014/09/18(木) 23:52:12.25ID:CfthWkvp

結局言葉遊びの域を出なかったね

522デフォルトの名無しさん2014/09/18(木) 23:53:02.19ID:LNiMu1bm

つーかリファクタリングとか言いにくいから修正でいいじゃん

523デフォルトの名無しさん2014/09/19(金) 00:33:41.85ID:Y0Ellmpg

リファクタリングを定義しようぜ
とりあえずQA形式にして質問と回答は最近の書き込みから適当に埋めた

＜＜リファクタリングとは＞＞
Q 何時やるの？ A やりたい時。糞コードを見つけたら。今でしょ
Q 具体的には(工程では)いつ？ A 回答なし
Q やる必要あるの？ A 回答なし
Q 誰がやるの？A 自称上級者
Q 上級者の定義は？A 回答なし
Q その上級者には何かメリットが？A 回答なし
Q リファクタリングってお金もらえるの？A ボランティア
Q どういう効果が期待できるの？ A 将来的なリスクを回避する、または逆にリスクを抱える

524デフォルトの名無しさん2014/09/19(金) 17:39:57.70ID:J2pxYtIB

>>500に対して>>503の返しするということは、>>500の話が論が正しいことを>>503が認めているということ。

つまるところ、会社の構成員の実力によって不可能になるということ。
をあんたの会社では～。の一文で認めている。

ゆえにその切り返しをするなら、リファクタリングは議論する価値がないということ

525デフォルトの名無しさん2014/09/19(金) 17:51:51.67ID:VKWv7B4z

ちょっと何言ってるのかわかりませんわ

526デフォルトの名無しさん2014/09/19(金) 18:08:18.14ID:J2pxYtIB

誰でもできることでないなら、実現は夢物語ということだ

527デフォルトの名無しさん2014/09/19(金) 18:36:04.63ID:iHgvKusj

工程を確保して
下がやりたいと言ったら邪魔するなというだけの話かもしれない

528デフォルトの名無しさん2014/09/19(金) 18:47:45.84ID:5Sq7tp9D

>>524
行き詰まるところ先人達が考えて考えた結果

　新言語の開発

にしか答えがないんだよなww
どんな素人でも言語のルールには逆らえない。つまり従わざるを得ない。
理論だけで劇的な変化があったのなんて

GOTOレス

だけだろ。

わかりやすくステップ数で言うけどjavaで10ステップで組まれていてごちゃごちゃなプログラムがある。
仕様変更するのに1万ステップの変更が必要。これを、新言語おまんこ女学院言語で開発すると、

main()
おまんちょ（）

って書くだけで同じ機能が実現され、

仕様変更には

use ここか？ここがええんか？
main
おまんちょ（伝説の第４９手目（３箇所、同時、左手だけちょうどいい微速））

って直せば実現できる言語が生まれれば、これ以上の可読性の向上はないわけで。
馬鹿でも簡単に、馬鹿でも可読性が高く、馬鹿でもスピーディーに・・・・を求めて新言語というのは生まれている

529デフォルトの名無しさん2014/09/19(金) 18:48:57.11ID:5Sq7tp9D

>javaで10ステップ
を
>javaで10万ステップ
に訂正

530デフォルトの名無しさん2014/09/19(金) 19:42:02.22ID:97jwqaFX

>>485
パッケージ製品のメジャーバージョンアップとか？
一般的なIT土方の工事現場にはまず縁ないわな

531デフォルトの名無しさん2014/09/19(金) 20:44:14.36ID:/lOvQPWO

リファクタリングしない人は
修正する時、テストしないの？

テストするならリファクタリングしても
問題ないよね。

532デフォルトの名無しさん2014/09/19(金) 20:59:36.15ID:6gllmAz9

全部埋めてやったぞ

＜＜リファクタリングとは＞＞
Q 何時やるの？ A やりたい時。糞コードを見つけたら。今でしょ
Q 具体的には(工程では)いつ？ A アジャイルですから。工程て何？
Q やる必要あるの？ A やらなきゃバグでるよ？いつか破綻するよ？
Q 誰がやるの？A 自称上級者
Q 上級者の定義は？A 糞コードを発見する嗅覚を持つこと
Q その上級者には何かメリットが？A コードが綺麗な方が気持ちいいだろ
Q リファクタリングってお金もらえるの？A ボランティア
Q どういう効果が期待できるの？ A 将来的なリスクを回避する、または逆にリスクを抱える

533デフォルトの名無しさん2014/09/19(金) 21:28:04.06ID:/lOvQPWO

＜＜リファクタリングとは＞＞
Q 何時やるの？ A テスト駆動開発においては、テスト記述→コードを書く→リファクタリングの順番で開発する
Q 具体的には(工程では)いつ？ A コードを書いた直後。工程で言えば開発工程
Q やる必要あるの？ A 義務だろうね。小説で言えば清書する必要あるの？ぐらいのレベル。
Q 誰がやるの？A 客観的指標（McCab等）で差があるコードを見比べて、優れている方を言えるレベルの人全員
Q 上級者の定義は？A 客観的指標（McCab等）で計測して良いとされるコードを書ける人
Q その上級者には何かメリットが？A 上級者であっても、可読性やメンテナンス性が高いコードの方が早く機能追加・修正・不具合対応ができる。
Q リファクタリングってお金もらえるの？A 開発の一部であり、清書みたいなものなので当然お金はもらえる。
Q どういう効果が期待できるの？ A 期待ではなく事実としてメリットがある。メリットは二つ上に書いたとおり。

534デフォルトの名無しさん2014/09/19(金) 21:57:34.29ID:Xfkvubm0

当然お金はもらえるってなんだよワロタ

535デフォルトの名無しさん2014/09/19(金) 22:04:08.26ID:GUgRmWP+

>>534
たとえばさ、誤字脱字、これはあっても読めれば別に問題ないんだよ。
でも見つけたら直すだろう？

そうやって誤字脱字の見直し、修正が例え1時間で終わったとしても
業務である以上、それは給料に変わるんだよ。

536デフォルトの名無しさん2014/09/19(金) 22:35:47.59ID:6gllmAz9

問題ないのに直すのは明らかに無駄な労力だろ
リファクタリングてそういう事なのか？

537デフォルトの名無しさん2014/09/20(土) 00:28:50.80ID:zqGI0i/Q

そこらに地雷が埋まってても踏まなきゃ平気なんだよ

538デフォルトの名無しさん2014/09/20(土) 00:35:33.60ID:BGuuw2+W

>>531
そもそもテストは各工程に含まれてるよね？
一度コードに手を付けたらリファクタリングだろうが何だろうがテストはやり直しだよ
工程をこなしてる間つまりリリースし終わって暇にでもならないと
リファクタリングなんか入り込む余地なんて無いぞ
要するに無駄ってことじゃないの

539デフォルトの名無しさん2014/09/20(土) 01:43:02.74ID:b8OT/FfJ

>>536
「ソースコードを読むのに時間が掛かる」は
一番重要な問題だよ。

それが開発工数の大半を占めているんだから

540デフォルトの名無しさん2014/09/20(土) 10:04:40.32ID:zqGI0i/Q

まあ理論的に完璧なリファクタリング手法を使っても
無関係であるはずの部分でコンパイラやＯＳのバグを踏んだらそれまでだから
実テストにやたら工数のかかってたらその後はさわれないだろうね

541デフォルトの名無しさん2014/09/20(土) 10:58:44.27ID:b8OT/FfJ

テストやりました。バグが見つかりました。

ソースコードが汚くて、コードの意味がわかりません。
ソースコードが汚くて、バグの原因がわかりません。
あちこちにコピペされてて、バグの修正が大変です。
バグを修正したら、別のバグが発生しました。
バグを修正しましたが、処理が複数のモジュールに
分散していたので多くの再テストが必要です。

こういうのを解決するのがリファクタリング。

542デフォルトの名無しさん2014/09/20(土) 11:27:24.57ID:41dsRCcO

違うね。

> テストやりました。バグが見つかりました。
> （以下略）

それはデバッグや。

543デフォルトの名無しさん2014/09/20(土) 11:43:01.81ID:b8OT/FfJ

>>542
いや、それは前置きだから。

リファクタリングが解決するのは、
デバッグまでの過程で発生する問題。

同じデバッグという目的であっても、
その目的を達成するまでの時間は違うんだよ。

544デフォルトの名無しさん2014/09/20(土) 11:48:06.25ID:zub5QpR2

ちょっと意味が分からない

545デフォルトの名無しさん2014/09/20(土) 12:22:36.52ID:McF0jAPW

開発段階ですでにスケジュールオーバーしてる現場だらけなのに机上の空論w
新言語開発しろw

546デフォルトの名無しさん2014/09/20(土) 13:18:35.72ID:b8OT/FfJ

>>544
意味がわからないレベルの人っているんだよねｗ

547デフォルトの名無しさん2014/09/20(土) 14:46:45.86ID:mG0BaSkX

テストってコードを書いた本人がやるべき？

548デフォルトの名無しさん2014/09/20(土) 15:02:25.23ID:uiyrzvHx

リファクタリングすら必要ないほどの腕のいい奴を最初から揃えれば良くね？
というのと同じくらいリファクタリング理論は破綻してる

549デフォルトの名無しさん2014/09/20(土) 15:33:26.65ID:uiyrzvHx

他人のソースコードの解読は新規作成より時間がかかるケースが多々。
仕様がわかってるなら、そんなチェックをお願いしないといけない奴のソースレビューをするより、最初から自分でやったほうが早いし確実
つまり、リファクタリングの行き着く先は、無脳者を開発に入れなければ良いに行き着く。
少数精鋭方式。

550デフォルトの名無しさん2014/09/20(土) 15:48:28.37ID:Jdjsg9Fk

>>548-549
一理あるが理想論
だから現実解としてリファクタリングが出てきたんじゃないのか？

551デフォルトの名無しさん2014/09/20(土) 16:04:59.48ID:b8OT/FfJ

仕様変更っていうのは避けられないものだし、
機能追加や新しく出来た○○に対応するとか
どうしても変化は避けられないわけで
その変化にたいしてコードも変化させていかないといけないんだよ。

それにさ、人っていうのは成長するのは当たり前なのだから、
一年前の自分より、もっと優れたものを書けるようになっているはず。

一年後はさらに優れたものを書けるようになるはずだが、
それは今をきちんとやっていてできること。
過去の自分の真似ばかりしていても、成長はできないよ。

552デフォルトの名無しさん2014/09/20(土) 16:20:19.19ID:gqfYZyci

何を意味の分からん事を
と思ったら、またお前かｗ

553デフォルトの名無しさん2014/09/20(土) 18:11:49.33ID:b8OT/FfJ

>>552
言い返したいことがあるのなら
なにか言い返していいんだぜ

554デフォルトの名無しさん2014/09/20(土) 20:30:21.92ID:lV8t6mfn

>>550
でもgotoレスと違って誰も実践しないだろ？
そういうことだ。
誰が好き好んで人の尻拭いをやるというのだ

555デフォルトの名無しさん2014/09/20(土) 20:40:59.03ID:Pz5VxQ8p

リファクタリングは有能が無能の尻を拭く作業ではなく自分の尻を拭く作業だ

最初は速度など無視してとりあえず動くように作る
動いたら次に速く動くようにする
速く動いたらそれを読みやすく整える
読みやすくなったら今度は新機能を楽々追加する

これで立派なリファクタリングだ

556デフォルトの名無しさん2014/09/20(土) 21:06:59.81ID:K48fRfz5

速く動くようにするのは一番後でいいだろ

557デフォルトの名無しさん2014/09/20(土) 21:21:43.45ID:npmlG4Eq

>>556
ボトルネックが出来て、そこを解決すれば全体に速度が上がるようなものなら
後からでもどうにかなるが、全体的に微妙に遅い、微妙にリソース食っている、
それで全体的に遅くなってるだと後からじゃどうにもならない。

558デフォルトの名無しさん2014/09/20(土) 21:27:33.19ID:lV8t6mfn

>>555
実際誰もやっていない
それが、この理論の決定的な答え
誰もやらない＝やって評価されるどころか、失敗した場合の責任を問われるだけ
メリット一切無い

559デフォルトの名無しさん2014/09/20(土) 21:36:13.07ID:lV8t6mfn

>>555
そもそも、そんなものはリファクタリングではない

リファクタリングは「現時点『運用中』の動いているシステムプログラム」に勝手に手を加えること。
「まがいなりにも動いているシステムのプログラムを勝手にいじるな」
というのが世界の常識。でこの常識を変えようとした思想がリファクタリング。
ただ、結局は、誰もやらんってこと。

理由の大半は「仕様がわからん」ということ。

560デフォルトの名無しさん2014/09/20(土) 21:44:36.36ID:6heECCBq

エクストリームプログラミングから全否定かよ。
カオスだな。

561デフォルトの名無しさん2014/09/20(土) 21:54:03.46ID:UNVZl8tG

バグを仕込んでしまう可能性があるのが致命的
あとは評価制度の問題だな
長期的に絶対メリットはあるんだがそんなん誰も見ちゃいねえし

562デフォルトの名無しさん2014/09/20(土) 22:00:15.71ID:Pz5VxQ8p

他人の尻を拭くハメになったとき、リファクタリングが可能である唯一の条件は、
引継ぎ時点でリファクタリングされているソースコードであること、だ
そうでなかったらご愁傷様あきらめた方がいい

563デフォルトの名無しさん2014/09/20(土) 22:07:58.53ID:fFGu/96N

>>559
> リファクタリングは「現時点『運用中』の動いているシステムプログラム」に勝手に手を加えること。

なんでウソつくの？

本当と言い返せるものなら言い返していいんだぜ？ｗ
ただし、そんなことをしたら、ソースを要求するので
準備しておくこと。

564デフォルトの名無しさん2014/09/20(土) 22:53:25.35ID:6heECCBq

恐怖駆動開発だな。
http://www.hanselman.com/blog/FearDrivenDevelopmentFDD.aspx

レガシーコードでテストが無い and/or コードに対する理解が無い
↓
エンバグ、ビルドを壊すことへの恐怖

565デフォルトの名無しさん2014/09/20(土) 23:06:54.25ID:K48fRfz5

>>557
新しいマシン買えばいいだけじゃないか
開発費とハードウェア費用どっちが高くつくと思ってるんだ

566デフォルトの名無しさん2014/09/21(日) 01:19:15.97ID:H7xT3+nz

りファクタリングって言うのは、オブジェクト指向の言語（これが大前提）で、
開発段階にあって、試作品が第一段階で問題なく動いて、
あとは性能やコードの見直しやｶｲｾﾞﾝだよねって段階で設計へフィードバックするプロセスですよ。
その後に顧客側のチェックと納品ですよね。

運用中のシステムに手を入れるという話では無いですよ。
ｶｲｾﾞﾝを全否定ならトヨタはどうなるんでしょうか？

567デフォルトの名無しさん2014/09/21(日) 01:26:54.31ID:UIOIQYIj

一度客に納入してさあ、次に改修の仕事がきたときにリファクタリングしていたから工数が減っていたとしてもなんのメリットもないんだよな。むしろ工数が少なきゃ金が取れない。リファクタリングした分取ったら水増し請求だ。

機能やバグについて同等で、メンテしやすさだけ向上させる工程なんて日本の一般的な開発ではインセンティブゼロだよ。趣味ならともかくプロの仕事なら。

最初からリファクタリングの作業も込みで工数見積もりなり、費用請求しろ、ってそんな見積もり見て納得する客いるわけないじゃん。最初から手直しいらない納品物にして下さい、と言われてオチ。

出来上がってテスト済みのソースをあれこれいじるなんてお遊びが入り込む余地はない。

568デフォルトの名無しさん2014/09/21(日) 01:42:02.59ID:H7xT3+nz

それと、テストという概念は個人がスクリプトやツール類を書く場合には絶対に生まれてこない発想で、
多人数で、複数の技能レベルの人が、仕様書をガイドに組織的に開発に関わる条件下で必然的に生じる仕事上の手続き。

個人がコード書く場合は、ソースコード全体、アルゴリズム、関数やクラスを全て把握しているので
テストコードをいちいち書く必要がない。だからデバックという手順はあっても、関数やクラスのテストコードを
いちいち書くという発想にはならない。コード修正も容易、エラーが発生してもその場で即対応できる個人レベルの作業としては正しい。

組織で開発する部門では他人が必要なコードを仕様化した関数やクラスの動作条件を定めているから、
それを大前提としてモジュール動作をテストする必要がある。一見して馬鹿げている行為に思えるのは、
アルゴリズムを提示せずトップダウン的に関数のIN/OUTのみで仕様を提示するためにモジュールのテストが必須になる。
チェックデータの側面についていえば情報管理上テストデータが必ず必須になる。それは本物と試験用のデータが違うということ。

テストコードは本人が書くと、世界は如何にばかげた行為に時間を費やしているのかと思うだけだが、
本来は書く側は最終コードが動作すると確認した上で、２重チェックとして仕様を作成した側がテストするためのコードなり手段を作るべきだな。
人が居ないというなら、テストコード書くのでなく、統合テスト的に動作チェックすべき。

569デフォルトの名無しさん2014/09/21(日) 01:52:41.82ID:H7xT3+nz

リファクタリングは工数水増しの手段ではない。

保守とは違うので、日本の開発やってる業界のインセンティブなど関係がない。
リファクタリングとは関係がないな。

見積もりの段階でリファクタリングなどの話は出てこない。
手直しが要るといって費用請求している段階で、それはリファクタリングの問題ではなく
失敗したプロジェクトや案件だということだろう。それを誤魔化す為に誰かが嘘として
リファクタリングと言ってるだけだろう。

570デフォルトの名無しさん2014/09/21(日) 02:21:17.93ID:H7xT3+nz

もし>>567が客側の意見であれば、失敗したプロジェクトや案件とは縁を切って
再出発したほうが開発側も、客側も気持ち的にはしあわせになれますよ。

571デフォルトの名無しさん2014/09/21(日) 06:26:59.02ID:4aXz2u5s

>>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)

>リファクタリング登場の経緯と目的[編集]
>リファクタリングが登場する以前は、一度正常な動作をしたプログラムは二度と手を触れるべきではないと言われていた。
>下手に手を加えて動作が変わってしまうと、それに伴って関連する部分にも修正が加えられ、やがて修正はプロジェクト
>全体に波及し対処しきれなくなるかも知れない。またソフトウェアテストを十分に行い正常な動作が確認されたとしても、
>そのプログラムをわずかでも改変すれば、バグ (欠陥) が見つかったときに改変があったプログラムを疑わなければならない。

572デフォルトの名無しさん2014/09/21(日) 06:35:53.53ID:4aXz2u5s

>>566
>りファクタリングって言うのは、オブジェクト指向の言語（これが大前提）

は？wwwwwwwwwwwwwwwwwwww
オブジェクト指向とそうではない言語での違いを説明しろよ
オブジェクト指向という言葉になんか宗教的妄信でもしてるのか？

573デフォルトの名無しさん2014/09/21(日) 09:08:44.80ID:aP8Aq0OA

必要なのはコードのリファクタリングではなく
チームメンバのリファクタリングである

574デフォルトの名無しさん2014/09/21(日) 09:29:51.06ID:48QWsy10

言い換えると、ソースコードをリファクタリング出来るように
チームメンバーの技術力を高めることである。

575デフォルトの名無しさん2014/09/21(日) 09:47:59.75ID:dzDyx0VV

> チームメンバのリファクタリングである
リファクタリングて振舞いを変えてはいかんのでは？

576デフォルトの名無しさん2014/09/21(日) 12:25:58.75ID:MCI/5nTd

例えばバグが多く、しかも非常にメンテしにくい糞コードがあったとする
この場合
1. バグを含んだままリファクタリングして、その後バグを直す
2. 先にバグを直して正しいテストを通る様にしてから、リファクタリングに着手する
どっち？

577デフォルトの名無しさん2014/09/21(日) 12:33:35.65ID:48QWsy10

>>576
原則としては2番

ただし、今既に十分なテストがあるのなら、
リファクタリングしてもよい。

ようするに「バグが有ることに気づいていなかった」と考える。

バグが有るといえども、その状態で使われていたのであれば、
問題ない範囲（把握している範囲）で使われていたわけで、
使われていた部分の動きが変わっていなければ何も問題ない。

適切に動いていないバグの部分の動きが変わった所で
誰も困らない。そもそもバグは仕様ではないのだから。

578デフォルトの名無しさん2014/09/21(日) 13:51:42.60ID:C0Gh49Ld

>>576
2. 一択。
1. は死亡フラグ。

579デフォルトの名無しさん2014/09/21(日) 15:34:48.90ID:4aXz2u5s

ホント現実をみてないな
クソコードの影にクソ仕様書あり

仕様が網羅されていないクソ仕様書、そしてあってるのかあってないのかもわからんクソソース
そして、仕様を完全把握しているものは不在（いない）

コードを読みやすくする？直す？どーやってなおすんだよ正しい仕様不明なのに
手を入れなければ責任問題は自分にはかからない
正式に仕事として認可されるまでは、さわらずほっとく。こんなのが大量なんだ現実は

まともな仕様書を作るやつは、まともなプログラムも書いている。でもそれは修正等々なんて必要のないソース

リファクタリングの対象となるソースは、前者のクソコード、クソ仕様書のほうだ。正解が不明なのにどうやって直すんだ

580デフォルトの名無しさん2014/09/21(日) 16:39:44.45ID:48QWsy10

>>579
具体的に、クソコードになってしまう
クソ仕様の例を言ってみて。
思いつかないんだよね。

581デフォルトの名無しさん2014/09/21(日) 16:40:37.43ID:48QWsy10

> コードを読みやすくする？直す？どーやってなおすんだよ正しい仕様不明なのに

それは、正しい仕様がなければ、
現在のコードの動きを仕様と考えればいいだけ。

582デフォルトの名無しさん2014/09/21(日) 16:53:43.27ID:4aXz2u5s

>>581
クソソース1万ステップもよみとーない
句読点のない文章みたいに処理の区切りがまったくないような文体で書かれたソースなんぞ誰が手をつけるか

583デフォルトの名無しさん2014/09/21(日) 16:54:11.17ID:Ep6XnQTS

開発手法が根本からおかしい
リファクタリング以前の問題

584デフォルトの名無しさん2014/09/21(日) 16:55:08.58ID:4aXz2u5s

>>580
クソ仕様って誰が言った？
クソ仕様「書」って言ってるの。馬鹿なの？あほなの？無能なの？
おまえマ板の無職windowsさんでしょ

585デフォルトの名無しさん2014/09/21(日) 17:12:48.09ID:48QWsy10

>>584
じゃあ、そのクソ仕様書の具体例を
言ってみて。

586デフォルトの名無しさん2014/09/21(日) 17:14:26.03ID:48QWsy10

>>582
> 句読点のない文章みたいに処理の区切りがまったくないような文体で書かれたソースなんぞ誰が手をつけるか

でも、バグがあったら直さないといけないし、
仕様変更、機能追加があったら、手を付けないといけないよね？

587デフォルトの名無しさん2014/09/21(日) 17:24:56.25ID:SqCSMf85

うちのソースコードはほとんどが綺麗だから
句読点のない文章みたいに処理の区切りがまったくないような文体で書かれたソース
なんてほとんど無いよ。

そんな汚いソースがたくさんある所は、
手をつける箇所＝リファクタリングするべき場所でしょう。

588デフォルトの名無しさん2014/09/21(日) 17:25:48.01ID:J4CuFh4O

この板はガセネタをもとにした煽り合いのスレしかないみたいだな

・××と言われているが本当は○○
・こんなことも知らないの？

これが２ちゃんクヲリチーだな

589デフォルトの名無しさん2014/09/21(日) 19:17:45.62ID:4aXz2u5s

>>585
作ってあげるよ、クソ仕様書

機能：
　俺の心の中にあるいい塩梅で、業務を遂行する処理

以上

これは極端に書いたが、冗談抜きで口頭で仕様をやりとりしたのか
いっさい、仕様書に、当該機能部分の記載がない。

590デフォルトの名無しさん2014/09/21(日) 20:05:10.80ID:6N1L/uhm

嫌なら辞めれば良いのに
って思う

591デフォルトの名無しさん2014/09/21(日) 20:10:42.85ID:qWzZkk5b

>>590
どっちにたいして言ってるのかわからんよ、その文では

クソシステムが嫌と言ってる人に言ってるのか、
リファクタリングｗをしないやつはだめだって言ってるやつに言ってるのか

どっちにも解釈できる

592デフォルトの名無しさん2014/09/21(日) 21:44:29.99ID:5OzBoJXn

クソソース1万ステップ読まなくていいようにするためにリファクタリングするんじゃないか

593デフォルトの名無しさん2014/09/21(日) 21:45:48.38ID:9ZybMmhl

マーチン・フラウアーのリファクタリング本てruby版とjava版て言語が違うだけで内容は重複してるの？
それとも別の内容が多いから両方買った方がいい？

594デフォルトの名無しさん2014/09/21(日) 22:48:11.16ID:SqCSMf85

>>589
それがソースコードとなんの関係があるの？

その曖昧な仕様によって、作られる機能が
曖昧になるだろう。

だが、機能が曖昧になるだけで、
それを実現するコードの読みやすさは関係ないはずだ。

595デフォルトの名無しさん2014/09/21(日) 23:01:02.38ID:SqCSMf85

>>593

>>454ででてるリンク先の一覧が内容の比較として使えるよ。
多くは重複しているが、それぞれ片方にしかないものもある。

と思ったが、Java版、新装版がでたんだったか。
旧版、新装版、両方持っているが新装版の方はまだ見てないやｗ

ぱっとみ片方にしかないものは、言語の特徴によるものっぽいから
重複率は同じか少し高くなるだけだろうね。

それでも俺はそのうちRuby版かうけどねｗ

596デフォルトの名無しさん2014/09/22(月) 01:14:38.68ID:8ME10ieO

リファクタリング真理教か原理主義かしらんがウゼエ

597デフォルトの名無しさん2014/09/22(月) 06:10:50.31ID:mZl8n2a+

>>596
リファクタリングっつって真理教とか妄想するお前が一番オームくさい。

リファクタリング大勝利！！！

598デフォルトの名無しさん2014/09/22(月) 06:22:02.06ID:VFEp2OOw

Aさんがリファクタリングしました。
Bさんが読みましたAさんのリファクタリングがクソです。Bさん直しました。
Cさん見ましたBさんのソースコードクソです。Cさん直しました。
永遠と、、、、、

個人の力量、感性によって結果が大きく作用してしまうものは、学術的工学的な基本がないからどうにもならない。

599デフォルトの名無しさん2014/09/22(月) 08:09:32.93ID:mZl8n2a+

普通は、

Aさんがリファクタリングしました。
Bさんが読みましたAさんのリファクタリングがクソです。Bさん直しました。
Cさん見ましたBさんのソースコードクソです。Cさん直しました。

Cさんリファクタリング大勝利！！！・・・でしょ？

600デフォルトの名無しさん2014/09/22(月) 08:34:50.21ID:mZl8n2a+

Class レイザラモンFoo Extends Object
Public サルinit(void);
Public　クエリFoo(String SQL文はクソ);
Protect ないですFoo(void);
Destractor システム緊急停止オペ呼んでくさいFoo(void);
End Class

こんな仕様のクラスを業務システムのスーパークラスにしてあとは全て継承
という仕様は誰だって疑問を持つと思うんだが、そこを直すのがリファクタリング。

リファクタリング大勝利！！！

601デフォルトの名無しさん2014/09/22(月) 11:41:29.79ID:y9q7ZqSb

>>598
それリファクタリング関係ないしｗ

なぜなら、俺が作ったコードを誰かが編集した時に、
変な修正の仕方をされることがあるから。

それを直すのがリファクタリングなわけ。

602デフォルトの名無しさん2014/09/22(月) 12:15:28.88ID:4rgv3mOC

>>599
再びAさんが担当した時、Cさんのコードを読めず仕事になりませんでした。
Cさんリファクタリング大勝利！！！

603デフォルトの名無しさん2014/09/22(月) 13:03:42.75ID:BRLO2XpR

優れたの方コードを採用すればいいだけだろ。

604デフォルトの名無しさん2014/09/22(月) 13:12:39.94ID:8Zrs8f+9

個人の知識の違いによってソースの見え方が違うからな
アホが天才のコードを見ると何じゃこりゃってなるし、逆もまた然り

605デフォルトの名無しさん2014/09/22(月) 13:51:20.75ID:BRLO2XpR

知識って・・・そんなの一機能5分もあれば
知らない状態から理解できるだろ。

どんだけ素人なんだ？

つーか知らない時点で、判断できないわけで
議論からはお役御免なわけだが

606デフォルトの名無しさん2014/09/22(月) 13:53:03.85ID:BRLO2XpR

それに、知らないなら何をやっているか
理解できないわけで、リファクタリング出来るわけがないな。

607デフォルトの名無しさん2014/09/22(月) 17:49:10.78ID:8HtrhTyn

おれはやらな～いw

これでリファクタリングは崩壊するwww

608デフォルトの名無しさん2014/09/22(月) 19:42:14.76ID:OvpzlkOF

アホみたいな話だが結局>>598が真理だよな。
リファクタリングする人は、自分のコードもいずれリファクタリングされる事を受けいれねばならん。

609デフォルトの名無しさん2014/09/22(月) 20:32:19.28ID:0yRqeFm6

リファクタリングはただのコード修正と思ってもらってかまわない

610デフォルトの名無しさん2014/09/22(月) 20:44:04.47ID:jEzIKioA

リファクタリングするよ派はここでなにしてんの？しないよ派とじゃれあってるのが楽しいの？
やり合ってる本人は議論してるつもりかもしれないけど、外から見てるとしょうもなさすぎてｗｗ

611デフォルトの名無しさん2014/09/22(月) 21:11:07.07ID:BRLO2XpR

>>607
それは単に、プログラム？なにそれおいしいの？
動けばいいでしょ？って言ってるだけでしょう？
そんな会社はリファクタリング以前に
仕事が終わってる。

612デフォルトの名無しさん2014/09/22(月) 22:45:37.55ID:rMqlGcxC

>>1が考えるようなことは誰もが考えてる。
その結果、新しい開発言語が生まれているということを理解できないのか？
過去、多くの開発手法・開発スタイルが提唱されたが、
社会に受け入れられたものは、「理論」と「それを強制する新しい開発言語」が常にワンセットになっていた

「超絶スパゲッティコード」を少しでもまともにするために
　　原因の「goto」を取り除く方法として、「gotoレス」という理論とともに「3つの基本構造を使うようにした、構造化プログラミング言語」が生まれ
「グローバル変数の多用がデバッグを困難にする問題」を少しでもまともにするために
　　原因の「不必要にメモリをどこからでもアクセスできる状態」を取り除くため「カプセル化」が提唱され、オブジェクト指向言語に組み込まれ
等々・・・・。

何を持ってリファクタリングといいたいのかわからないが、汚いコードを綺麗なコードになおすというなら。
リファクタリングが成功したといえる、最終のコードはどのようなものなのか。具体的に示す必要がある。
プログラムとして存在するあらゆるコードパターンに対応した、綺麗なコードを示してくれ。
それを明示できないうちは>>598の意見が正しい。
個人の感性次第なら、汚いコードと周りは言うが書いているプログラマにとってはリファクタリング不要な綺麗なコードと判断するだろう。

先人達は、その時代のプログラムコードの問題を考えた。
その答えが、理論を具現化した新プログラミング言語の開発だ。

>>1はしのごのいうなら、リファクタリング後の形になるプログラミング言語を生み出せ。
どんな馬鹿でも、その綺麗なプログラミングになるプログラミング言語を。

613デフォルトの名無しさん2014/09/22(月) 22:52:50.40ID:BRLO2XpR

>612
新しい言語というから何かと思えば
gotoレスとかカプセル化とか

全然新しくないじゃないか。
30年ぐらい前の話だろ。

614デフォルトの名無しさん2014/09/22(月) 22:55:02.43ID:BRLO2XpR

> 何を持ってリファクタリングといいたいのかわからないが
無知は勉強すればいいだけ。恥ずかしいことなんて無いよ！
>>423, >>426あたりを読むといいよ。

リファクタリングの誤用
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism
リファクタリングの境界線
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringBoundary
インタフェースの変更はリファクタリングか
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
> 宣言（Javaで言うメソッドやフィールド）の順序を変更することは、リファクタリングと呼べるのか？
> リファクタリングの定義で、「理解や修正が簡単になるように」というフレーズを使った。
> 宣言部分を変更すると、理解や修正が簡単になるのだろうか？私は、そういう場合もあると思う。
> ソフトウェアの内部構造を変更しないという点が紛らわしいかもしれない。リネームしても実行内容は変化しない。

615デフォルトの名無しさん2014/09/22(月) 22:58:10.11ID:BRLO2XpR

>>614を見ればわかるけど、

リファクタリングを
汚いコードを綺麗なコードに直すこと
とは書いてないんだよね。

なんでこんなふうに間違って解釈してるのかな？

それって、汚いコードが（あなたの所に）多いってだけで、
リファクタリング以前の解決するべき問題だよね？

リファクタリングとはソフトウェアの変化とともに、
あるべき設計に安全に変化させる方法のこと。

616デフォルトの名無しさん2014/09/22(月) 23:03:19.25ID:rMqlGcxC

>>613
あ？３０年前だ？
がきんちょがてきとーなことぬかしてんじゃねーぞ？
３０年前のコードならgoto乱発が現役だ
汎用機に大量にその証拠があるわ
どあほが。

617デフォルトの名無しさん2014/09/22(月) 23:04:10.78ID:rMqlGcxC

>>615
具体性がございません。
個人の感性次第でよろしいですか？
なら退職時、全部アセンブラコードだけにしちゃいますがｗ

618デフォルトの名無しさん2014/09/22(月) 23:24:14.03ID:OvpzlkOF

>>615
（お前にとっての）あるべき設計だな

619デフォルトの名無しさん2014/09/23(火) 07:26:06.78ID:0ZBouPvA

このスレも

↓のスレも
ソースコード品質検定試験が世の中には必要だ
http://kanae.2ch.net/test/read.cgi/prog/1411354584/

同一人物が立てたスレだと自白しました。
そして、人物の正体も自白しました。

>5 名前：仕様書無しさん[sage] 投稿日：2014/09/22(月) 17:48:09.54
>無職Windowsしか使えないリファクタリング馬鹿がまたスレたてやがった
>
>6 名前：仕様書無しさん[sage] 投稿日：2014/09/22(月) 21:31:27.59
>>>5
>たてたね。それで？
>
>なにか言い返したいことがあるのなら
>いっていいだぜ？ｗ
>
>7 自分：仕様書無しさん[sage] 投稿日：2014/09/23(火) 07:22:55.61
>>>5
>自然と、「無職」「Windowsしか使えない」「ム板でリファクタリングスレ」を立てたことを認めているww

さすが、無職でWindowsしか使えないだけはあるw
だれも同調してくれないww　説得力もカリスマ性も感じないからなw

620デフォルトの名無しさん2014/09/23(火) 12:26:15.85ID:aBTcR7ac

>>617
具体例はここに書いてあるよ。

> >>614を見ればわかるけど、
>
> リファクタリングを
> 汚いコードを綺麗なコードに直すこと
> とは書いてないんだよね。

621デフォルトの名無しさん2014/09/23(火) 16:29:00.40ID:wrw0I4Vi

まだ無職が語るの？
恥ずかしいからお前の社会的立場を恥ずかしくない位置にリファクタリングしてからプログラムのリファクタリングを語れよw

622デフォルトの名無しさん2014/09/23(火) 16:45:57.11ID:wrw0I4Vi

しかし、この超売り手市場なのに就職出来ないって、相当無能なんだな

623デフォルトの名無しさん2014/09/24(水) 17:32:35.84ID:iVFJW3Cg

いやぁ馬鹿スレを止めてくれてありがたい

完全に自爆だけどな(笑

624デフォルトの名無しさん2014/09/25(木) 08:00:06.24ID:2gwTj0ip

え？
マジで！？いろいろ見て回ってきたけど
ゲーム作りたくてプログラマになったけど、就職できず、Windowsしか扱えないので、派遣でコボルやるもクビになって無職
なの？！( ；´Д｀)

そんな身分で、現役のプロのプログラマにプログラム、プログラミングにたついて講釈たれてたの？
ε-(´∀｀; )

どんだけ、恥知らずというか、身の程知らずというか、小保方というか。
空いた口が塞がらないわ(^◇^;)

マジでお前自信をリファクタしろよ(・Д・)ノ

625デフォルトの名無しさん2014/09/25(木) 12:50:36.36ID:fB0UYRRr

という妄想を書く人って、
実社会では自分が落ちこぼれなのかな。

626デフォルトの名無しさん2014/09/25(木) 17:28:15.70ID:oxMb9EZk

不用意に自供しといて妄想とかw

627デフォルトの名無しさん2014/10/05(日) 23:35:12.83ID:gYmu4Dn/

リファクタリング良さそうなんだけど、いろいろ疑問点があります

上で内部的インターフェイスの変更もリファクタリングに含まれるという話がありましたが
インターフェイスを作り変えたら対応するテストケースも作り変える必要がありますよね？

その場合、リファクタリング内でテストケースに手を付けて
インターフェイスとテストケースを同時に作ってしまっていいものでしょうか？

外部的インターフェイスに指定したテストケースのみパスすれば
問題ないと考えるのでしょうか？

628デフォルトの名無しさん2014/10/07(火) 01:36:41.20ID:0pCKu6Fp

テストケースは全部通さないと駄目だよ
人間の書くテストが全部網羅してるとも限らないから
テストの穴を突いた部分が他所で影響してるかもしれない
原則としてよほどの事でもない限り一度リリースしたら手をつけないがベスト
リファクタリングなんて幻想だからやめなさい

629デフォルトの名無しさん2014/10/07(火) 09:53:16.20ID:pP8u07NL

インタフェースを作り替えたらテストも必要
というかテストできない・しづらいインタフェースを作ったらあかん

6306272014/10/07(火) 20:19:23.95ID:J1sG3mPW

>>628
＞テストケースは全部通さないと駄目だよ

内部動作をリファクタリングする場合はそうだと思います。

＞人間の書くテストが全部網羅してるとも限らないから
＞テストの穴を突いた部分が他所で影響してるかもしれない

１００％のテストはないけど、十分捕捉率の高いテストと
十分機能変更の余地が低いリファクタリング手法の組み合わせで
実用になるというのがリファクタリングの主張ですよね。

内部動作のリファクタリグだけならそれでいいんですけど、
ただやっぱりインターフェイスの拡張・取捨選択も
やりたくて、そういう場合どうすればいいのかなと。

＞原則としてよほどの事でもない限り一度リリースしたら手をつけないがベスト

一度リリースしたっきりでソースのことを忘れ去っても
大丈夫なプロジェクトならそうかもしれませんが、
リファクタリングがターゲットにするプロジェクトは
リリースした後に（リファクタリングするしないに関わらず）
何度も手を付けてメンテナンスすることが要求されるような
継続性のあるプロジェクトではないでしょうか？

＞リファクタリングなんて幻想だからやめなさい

上手くいくと言っている人も多いので、
安易に幻想だと断定もできないように思います。
幻想だとはっきり納得出来たらやめます。

6316272014/10/07(火) 20:20:02.46ID:J1sG3mPW

>>629
＞インタフェースを作り替えたらテストも必要
＞というかテストできない・しづらいインタフェースを作ったらあかん

テストしづらくはないのですが、
例えば１つ１つの public メソッドにテストを書いていたら
とても作業が時間内に終わらないというような、
時間がかかってしまう的な問題です。

でも public メソッドはクラスの持つインターフェイスだから
テストは必要ってことですか？

632デフォルトの名無しさん2014/10/08(水) 15:43:43.04ID:AP5j0Y8f

ただ、そのテストのメンテナンス、テストを減らしたり、改善したり、
そういう話はまだ多くないんですね。(例えば)テストが増えてくると、
全部のテスト通すのに 3 時間かかったりとか、テストの量自体が問題になってくる。
またテストが実装に深く依存してて、リファクタリングしたらテストが
ばーっと真っ赤*49になっちゃうからやめようみたいな話とか。

テストをたくさん書けば良いってものじゃないんですよ。
設計の改善を前後で担保するためのテストだったはずなのに、
設計改善の邪魔をしてるんじゃないか？と。
テストが変更のコストを一定にするという夢を俺たちは見てやってきたのに、
テストが増えると変更コストが上がっていないかい？という問題に対してどう戦うか、
それが今の TDD の主戦場だと思っています。

http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview43.html

633デフォルトの名無しさん2014/10/08(水) 17:47:03.08ID:No3WRPQd

>>632
下手なテストを書くとそうなるって話ですね。

634デフォルトの名無しさん2014/10/08(水) 23:56:17.82ID:UFd7lKdk

よくわからんが何かの言い訳に使えそうな

635デフォルトの名無しさん2014/10/09(木) 10:21:37.01ID:IFg54I5e

テストできない・しづらいインタフェースを作ったらあかん

636デフォルトの名無しさん2014/10/09(木) 20:44:29.80ID:zf/NUEdS

ボタン一個一発こそ至高

637デフォルトの名無しさん2014/10/12(日) 07:13:20.02ID:jwvcB2bY

>>627
有能な人材だけで構成されているなら可能
でも有能な人材はそもそもそんなコードを書かない
つまり、現実では実現不能ということ。

よく考えてよ。
ゲーム会社への就職も面接すらいけずに終わり、他の会社も全滅、登録派遣しかなく
ようやく派遣されたCOBOLでクビになり、
自分は有能だと思い込んでいるケドWindowsしか使えない
無職の人の立てたスレだよ？

638デフォルトの名無しさん2014/10/12(日) 13:23:31.01ID:08qsWg0a

>>637
返信ありがとうございます

＞よく考えてよ。
誰が立てたかでなく、何を言っているかで判断しています

＞有能な人材だけで構成されているなら可能
627 では可能かどうかという聞き方はしていないのですが、
627 のどの部分を指して可能と言われているのでしょうか？

＞でも有能な人材はそもそもそんなコードを書かない
これも、627 ではどんなコードかに関して言及していないと
思うのですが、そんなコードというのは何を指しているのでしょうか？

639デフォルトの名無しさん2014/10/12(日) 14:51:47.69ID:jjrAIsW+

世の中に汚いコードが溢れてるってことだなｗ

リファクタリングは汚いコードを直すことじゃないよ。
コードは修正するたびに（≒機能追加）
どんどんコードが増えていく。

素人集団は、コードの既存部分を直さずに追加するだけで終わらせる。

有能な人材はそもそも汚いコードを書かないというが、
それは、有能な人材は、リファクタリングをしながら機能追加していくから
汚いコードに"成長しない" ということを意味する。

640デフォルトの名無しさん2014/10/12(日) 15:32:46.02ID:08qsWg0a

設計がまずかったり場当たり的に組んでしまったりして
いったん汚いコードになってしまったらもう手遅れですか？

汚いコードをインターフェイスを変えつつ
改善していきたいと思っているのですが

641デフォルトの名無しさん2014/10/12(日) 16:01:06.81ID:jjrAIsW+

>>648
「汚いコード」のうちは未完成と考えるよ。

設計書だってレポートだって小説だって
書いた最初は下書きでそれから清書するもんだろ？

642デフォルトの名無しさん2014/10/13(月) 12:31:48.66ID:dRUWRUgv

コードが汚いとか騒ぐやつは総じて低スキル

643デフォルトの名無しさん2014/10/13(月) 17:48:27.91ID:qVWnI3+v

>>640
汚いのを綺麗にする行為をリファクタリングとは"呼ばない"

これが原理主義者の主張するところである

644デフォルトの名無しさん2014/10/13(月) 21:27:10.38ID:mV3fqIh9

>>643
ではリファクタリグしたとしても汚いコードは汚いままなのですね

645デフォルトの名無しさん2014/10/13(月) 22:25:07.42ID:0J6BIdC+

>>644
汚いコードはリファクタリング前に綺麗にしてから
リファクタリングするから、
リファクタリング後は当然綺麗になってるよ。

646デフォルトの名無しさん2014/10/13(月) 22:41:00.86ID:mV3fqIh9

>>645
リファクタリグとは別に、汚いコードを綺麗にする方法があるのですね
どうやるんでしょう？

647デフォルトの名無しさん2014/10/13(月) 22:43:13.35ID:zulUt3IX

>>646
まず何が綺麗で何が汚いかを勉強することだね。
それを知らないことにはどうしようもない。

逆に知ってしまえば、具体的な質問ができるようになるよ
汚い××というコードを、綺麗な○○に変化させるには
どうしたらいいでしょうか？って

そういう質問なら答えがちゃんと言える。
君の今のレベルの質問は曖昧すぎて答えがない。

648デフォルトの名無しさん2014/11/22(土) 11:07:28.63ID:jhiCG8Ku

>>642
その高スキルに限って自分のソースが保守できずに早々に放棄する
書きなぐり続けるのはその繰り返しのため

649デフォルトの名無しさん2014/11/22(土) 16:04:31.14ID:6qlI/h48

>>642
俺様のコードは凡人には分からない
協調作業が出来ないタイプの典型
困ります､俺のプロジェクトから即刻リジェクト
してほしいです
田中お前だよ

650デフォルトの名無しさん2014/11/25(火) 12:34:50.30ID:aVHf4ing

世の中なんでも使い捨てで楽な方に向かってるのに
プログラミングの世界は古いものを大事に使いたがる不思議
怠惰なフログラマこそ率先してコードを使い捨てにすべきじゃね？

651デフォルトの名無しさん2014/11/25(火) 23:55:42.35ID:n1duvf0w

>>650
使い捨てる理由の大半はどんなにうまく保存しようとしても劣化し続けるから。
ソフトウェアはそういう物理的制約から書いたものはずっと同じまま残り続ける。
うまくバックアップや環境が残りさえすれば半永久的に使い続けることが出来る
わけだから、怠惰であればあるほどそういう資産を積み上げていくんだよ。

652デフォルトの名無しさん2014/11/26(水) 12:34:55.88ID:1UftDcOY

>>651
バカだな劣化するからリファクタリングとかいう下らない事が流行るんだぞ

653デフォルトの名無しさん2014/11/26(水) 19:48:43.25ID:0BkZoqqN

再利用って考え方がそもそもコストが高いんだよ
もんじゅとか例に挙げなくてもリサイクルって金掛かるだけで
利権で儲けるしかない仕組みだって判るよね

654デフォルトの名無しさん2014/11/27(木) 00:55:26.29ID:dibuY+0s

再利用のコストに関しては単純に何回再利用するかで変わってくるから、
コストの高い再利用をしているお前が悪いんじゃないのとしか言えない。

リファクタリングも同じで、2度と手を入れないような部分や新規プロジェクトを
渡り歩くような人には不要なもの。ただ昨今のアジャイル開発とか呼ばれている
ものだと、ある程度の期間は修正や追加が必要になってくる。無計画に接ぎ木を
してわけの分からないキメラを作るより、ある程度剪定して理解できる範疇に
修める必要があるよねっていうのがリファクタリング。

655デフォルトの名無しさん2014/11/27(木) 12:34:12.35ID:jH/Xs+Kz

>>654
ソフトウェアの再利用もその都度コストがかかるんだが？
普通は回数に比例してコストが増加するぞ

656デフォルトの名無しさん2014/11/27(木) 12:41:38.96ID:r+bsdp9/

>>655
> ソフトウェアの再利用もその都度コストがかかるんだが？
> 普通は回数に比例してコストが増加するぞ
再利用するために何らかの変更が必要なら、そのときだけコストがかかるが、
以降はコストかからんだろ。

657デフォルトの名無しさん2014/11/27(木) 23:29:56.27ID:kUiumU8R

再利用前提で作ろうとしてる時点で余計なコトスがかかっとるわい

658デフォルトの名無しさん2014/11/28(金) 02:38:41.57ID:LrjKc3Ws

古くなった原発の再利用

659デフォルトの名無しさん2014/11/28(金) 04:18:59.87ID:MN0ISYZx

再利用性や拡張性というのは、将来のことだから仕様外。
仕様外だからプログラミングの対象外。

おわり。

660デフォルトの名無しさん2014/11/28(金) 07:48:17.97ID:IEXuWLi+

再利用と考えるからいけない。
モジュール化。

適切なモジュール化は、再利用出来るだけじゃなく、
複雑度も減ってバグも少なくなる。

適切なモジュール化が出来ない奴が
再利用にコストがかかるとか
コードが再利用できないとか言う。

661デフォルトの名無しさん2014/11/28(金) 12:44:59.78ID:X4M4SbHd

>>660
それは再利用じゃないよ
機能を小さく保つ事で、本来の目的である一次利用出来る範囲が広がるだけだ
それを便宜的に「再利用しやすい」などと表現してる訳だ
ソフトウェア本来の目的とは異なる本当の意味での再利用にはコストがかかるんだよ

662デフォルトの名無しさん2014/11/28(金) 17:41:36.95ID:03S1h8mH

本当の意味での再利用？
そんなもんに興味持つ必要はなさそうだが？

>>660
それな。
本当にそれ。

663デフォルトの名無しさん2014/11/29(土) 01:59:23.82ID:TbFyYdBX

>>661
> 機能を小さく保つ事で、本来の目的である一次利用出来る範囲が広がるだけだ
一次利用が出来る範囲が広がる＝再利用だろｗ

664デフォルトの名無しさん2014/11/29(土) 13:13:20.77ID:U5ivpV2C

再利用じゃなくて流用と言えばいいのに

665デフォルトの名無しさん2014/11/29(土) 14:17:24.97ID:v2v5Wnkr

全く修正しないで使うのが再利用。
コピーして修正して使うのが流用

流用をすると、AとA'というコードが生まれなんで二つに分かれてるの？
違いはなんんあの？と結局両方を読まないといけなくなる。
流用するたびに読むべきコードがどんどん増えていく。
はてに一つを修正するともう片方の修正を忘れるとか。

なので全く修正しないで使う「再利用」でないと意味が無い。
全く修正しないで使えるのだからコピーする必要はなくなる

666デフォルトの名無しさん2014/11/29(土) 14:46:23.56ID:A4nuaoXO

流用元から流用先がどこにどれだけあるかは基本的に分からない。
流用元に何かバグがあって修正する必要があった場合に論理的に考えると
流用先も直しておいた方がいいor直す必要がある。ただ流用先を全て特定
することは難しく、特に流用先で動くように変数名とか変えてあると確実に
漏れる。バグじゃなくても何か修正追加したいと思った時の事を考えると
コピペをばらまくより関数で再利用するほうがいいよねってなる。

ただ人間は欲深いもので1つの関数にあれもこれも詰め込んで破綻させる
奴が出てきたりする。こういうのを見て、関数なんて作らなくてコピペでいい
だろって奴が出てきて無限ループする。

667デフォルトの名無しさん2014/11/29(土) 22:16:12.25ID:UEas1JmU

頑張って同じ機能がすでにあるか探して、
あったらあまりいいコードじゃなくても正しく仕様を満たすからそれ使って
散々気をつけてんのに誰かが変更しやがる

668デフォルトの名無しさん2014/11/30(日) 12:24:33.02ID:NxMP0P1A

リファクタリングと言う名の正義

669デフォルトの名無しさん2014/12/05(金) 19:01:54.53ID:cszTTiF/

>>668
同意､正義を振りかざす曲者

670デフォルトの名無しさん2014/12/21(日) 11:54:37.04ID:LOCxTeYe

>>661,660
>ソフトウェア本来の目的とは異なる本当の意味での再利用にはコストがかかるんだよ
　
　アプリ内でのモジュールの共通化（＝アプリに特化したフレームワーク、ライブラリ
の抽出）と、どんなプロジェクトでも使えるようにフレームワークやライブラリーを
汎用化するのは似て非なるものだと思う。

671デフォルトの名無しさん2015/02/15(日) 22:12:39.01ID:wyXhgSeE

>>1-1000
テスト

672デフォルトの名無しさん2016/03/27(日) 21:55:32.43ID:N7IGtcj3

どのタイミングでやったら工数に影響を与えずにできるの?

673デフォルトの名無しさん2016/09/10(土) 20:12:17.64ID:/nLYt7vC

みんな、言い負かされないようにリファクタリングを定義してるから、本当の目的がなんなのかぼやけちゃってるよね。

保守性（機能変更のし易さ）と速度の向上

リファクタリングの目的はこれでしょ。
それが必要ならリファクタリングすればいいし、将来的な機能変更もなく速度にもとくに問題がないなのら、どんなに汚いコードであっても下手にいじる必要はないよね。

むろん、個人で作った（使ってる）プログラムならリファクタリングするかしないかはその人の勝手だけど。

674デフォルトの名無しさん2016/11/02(水) 19:22:35.91ID:5cFgMElw

>>673
次の変更がきてから変更すればいいじゃない？

675デフォルトの名無しさん2016/11/11(金) 18:20:08.17ID:cgCFsvxz

なるほど

676デフォルトの名無しさん2017/02/06(月) 05:50:15.98ID:ZR9n4VuA

大抵の趣味人はリファクタリングなんかせずに垂れ流しだろ

677デフォルトの名無しさん2017/02/06(月) 06:14:33.50ID:gKoTGA+M

趣味としてのリファクタリングも結構面白いけど

678デフォルトの名無しさん2017/02/06(月) 06:41:48.30ID:gKoTGA+M

あとwikiから

"Code refactoring is the process of restructuring existing computer code―changing the factoring―without changing its external behavior. "

リファクタリングとは既存のコードを再構成する工程であり、
そのコードの外的な振る舞いを変えずに
問題の細分化(factoringを意訳)を変えることである。

だってさ、こんなスレよりよっぽどわかりやすいや

679デフォルトの名無しさん2017/02/06(月) 06:56:02.14ID:cswrm9tC

リファクタリングにはユニットテスト必須だよな

680デフォルトの名無しさん2017/02/06(月) 12:26:12.33ID:I8OzMN90

ユニットが再編成されたコードの外的な振る舞いをテストする
という意味ではユニットテストはその目的を果たしてないけどな

681デフォルトの名無しさん2017/02/06(月) 13:37:16.68ID:2jscAFeG

うちの会社の糞プロジェクトはリファクタしてことでバグ生んで大炎上してたな

682デフォルトの名無しさん2017/02/06(月) 16:24:54.25ID:gWijZw93

>>680
外的な振る舞いを変えないのがリファクタリングだろ

683デフォルトの名無しさん2017/02/06(月) 20:52:46.36ID:De1q4r3Z

>>682
なんだ？だからテストしなくても良いとか言いたいのか？

684デフォルトの名無しさん2017/02/06(月) 21:26:39.16ID:cswrm9tC

>>683
なんでそうなるんだ？
リファクタリングによって振る舞いが変わってない事を確認する為にユニットテストが必須という話をしてるのに

685デフォルトの名無しさん2017/02/06(月) 21:43:37.79ID:De1q4r3Z

>>684
なんでそうなるんだ？
ユニットが再編成されたコードの外的な振る舞いが変わっていない事を確認する為にユニットテストは使えないという話をしてるのに

686デフォルトの名無しさん2017/02/06(月) 22:00:46.99ID:w4i0A8ue

分子構造が再構築された全ての細胞の働きがもとそれと１つも変わらないならそれは再構築前と同じ生物になるのではないか
という理屈

687デフォルトの名無しさん2017/02/06(月) 22:00:51.21ID:eyaDYQgE

>>684
テストが必要っていうのは正しいが、そのテストはユニットテストとは限らん。

まず>>678に書いてある「外的な振る舞い」というのは
どこが外的かを考える必要がある。

リファクタリング対象がモジュール（クラス等）であれば
必要なテストはユニットテストだ。

だけど設計に近いレベルであれば必要なテストというのは
E2Eテストやシステムテストだったりする。

何をリファクタリングするかによって必要なテストは変わる

688デフォルトの名無しさん2017/02/07(火) 11:38:03.93ID:pecoNgwz

>>687
設計に近いレベルの変更というのがどういうものを指すのか良くわからんが、E2Eテストやシステムテストが必要になるコード変更はリファクタリングとは言わないでしょ。

689デフォルトの名無しさん2017/02/07(火) 11:39:08.61ID:qLX8GhSK

えっ！？

690デフォルトの名無しさん2017/02/07(火) 12:21:09.75ID:TOEOKA4e

>>688
むしろその規模のリファクタリングでなければコーダーのオナニー以上の意味がないくらいなのだが

691デフォルトの名無しさん2017/02/07(火) 13:06:50.95ID:pecoNgwz

>>690
規模の話はしていない。
1箇所数行のリファクタリングであろうが、1万箇所数万行のリファクタリングであろうが話は同じ。

E2Eテストやシステムテストでなければテストできないようなリファクタリングって、具体的にどんなものなんだ？

692デフォルトの名無しさん2017/02/07(火) 15:04:10.93ID:hq/hh9Cr

>>691
リファクタリングで効率が良くなったとして、ユニットテストレベルで勝手にリリースして
本当は他のシステムで必要な協調動作パラメータの再調整が必要だったり
想定してたバッファがパンクする可能性とか想像できんの？
そもそもリファクタリング単体の案件なんてまず発生しないし
他の案件の一部にねじ込むってパターンがほとんどだから結局テストは全工程やる事になるけど

693デフォルトの名無しさん2017/02/07(火) 15:27:04.15ID:pecoNgwz

>>692
「他のシステムで必要な協調動作パラメータの再調整が必要」なほどの大きな変更を「外的な振る舞いが変わっていない」と表現・定義して、それがリファクタリングであるというのはちょっと同意できない。

そもそも、>>687で
> 何をリファクタリングするかによって必要なテストは変わる
ということなので、E2Eテストやシステムテストが必要なリファクタリングとは、具体的にどんなものか、というのが疑問なんだけど。

694デフォルトの名無しさん2017/02/07(火) 15:28:33.61ID:pecoNgwz

>>692
> 想定してたバッファがパンクする可能性とか想像できんの？
あと、これ、単なるバグ（または設計ミス）でしょ。
しかも、単体レベルで検知可能。

695デフォルトの名無しさん2017/02/07(火) 16:00:21.23ID:WNm+xswo

>>692 のレベルが低すぎて笑う

696デフォルトの名無しさん2017/02/07(火) 18:13:12.04ID:hq/hh9Cr

レベル低くて結構だが
要件から漏れた設計なんて後からいくらでも見つかるのが現実
最初から設計や実装が完璧ならリリース後のコードに手を付けようなんて考えすら出てこないだろ

697デフォルトの名無しさん2017/02/07(火) 18:17:09.92ID:i748zAYA

ID:pecoNgwzがすごい小さい世界で生きていることだけはよくわかる

698デフォルトの名無しさん2017/02/07(火) 20:26:46.11ID:hbaz0JGp

スレタイ通りの人達

699デフォルトの名無しさん2017/02/07(火) 21:49:17.94ID:6yEMM6pR

>>691
> 1箇所数行のリファクタリングであろうが
君はこれで何がリファクターされると考えているのかね？
既存のコードを君好みのノーテーションに変える事をリファクタリングとは言わないのだよ
リファクタリングとはただのコード修正とは違うという意味
君分かってないよね

700デフォルトの名無しさん2017/02/07(火) 21:55:16.30ID:WNm+xswo

っていう勘違いをここまで堂々と話してるところが2chだなぁと感じる

701デフォルトの名無しさん2017/02/07(火) 21:58:23.39ID:S1oxUZhq

>>691
> E2Eテストやシステムテストでなければテストできないようなリファクタリングって、具体的にどんなものなんだ？

違う言語にリファクタリングした場合

702デフォルトの名無しさん2017/02/07(火) 22:06:09.85ID:S1oxUZhq

>>692
> リファクタリングで効率が良くなったとして、ユニットテストレベルで勝手にリリースして
> 本当は他のシステムで必要な協調動作パラメータの再調整が必要だったり
> 想定してたバッファがパンクする可能性とか想像できんの？

これリファクタリングと全く関係ないよね？

機能追加で便利になったとして、ユニットテストレベルで勝手にリリースして
本当は他のシステムで必要な協調動作パラメータの再調整が必要だったり
想定してたバッファがパンクする可能性とか想像できんの？

703デフォルトの名無しさん2017/02/07(火) 22:10:27.76ID:WNm+xswo

>>701
言語関係ないと思うが。
出来た実行可能ファイルかライブラリーか知らんがそれの挙動が変える前と代わっていないかテストすればいいだけだろ

704デフォルトの名無しさん2017/02/07(火) 22:11:07.79ID:S1oxUZhq

>>692
> そもそもリファクタリング単体の案件なんてまず発生しないし
当たり前。何かの修正があるときに
適切な形に変えるのがリファクタリング

「何かの修正」が加わる前の時点での適切な設計と
「何かの修正」が加わった後の適切な設計は必ずしも同じではない

「何かの修正」を加えるときは、もし最初から「何かの修正」が存在したと
仮定した時の適切な設計も同時に実現しなければいけない

修正するたびに適切な設計から離れていく、修正するたびに
壊していくようなやり方は責任あるプロの仕事とはいえない

> 他の案件の一部にねじ込むってパターンがほとんどだから結局テストは全工程やる事になるけど

結局テストは全行程やるんだから、修正のたびにリファクタリングを加えてなんのもんだもない

705デフォルトの名無しさん2017/02/07(火) 22:11:57.21ID:S1oxUZhq

>>703
だから、出来た実行可能ファイルかライブラリーか知らんがそれの挙動が変える前と代わっていないか
E2Eテストやシステムテストでテストするんだよ

706デフォルトの名無しさん2017/02/07(火) 22:21:19.34ID:NKjx6bYj

>>705
実行ファイル一つならそうである可能性もあるけど、ライブラリだったらシステム全体ではないよね。言語関係ないとはそういうこと。

707デフォルトの名無しさん2017/02/07(火) 22:24:10.12ID:NKjx6bYj

勘違いさせたならすまんが、俺は別にリファクタリングにシステムテストとかが必要ないなんて思ってない。その一つとは別人。

708デフォルトの名無しさん2017/02/07(火) 22:44:43.58ID:K2oda13o

リファクタにE2Eテストがいらないというのはある意味ただしいんだよ
アジャイルにおけるリファクタなんかがまさにそう
自動テストありきでイテレーションに組み込まれる
ただリファクタにも色々あるよねって話

709デフォルトの名無しさん2017/02/07(火) 22:53:25.47ID:hbaz0JGp

リファクタリングの責任範囲はユニットテスト迄でシステムテストとかは機能の変更、追加、向上なんかの範囲だと思うけどね
この二つを混ぜてリファクタリングと呼んでる人が一定数いて話をややこしくしてる
もちろんリリース前には一通りテストはするけどそれはそれ。リファクタリングに必要なテストとは別物

710デフォルトの名無しさん2017/02/07(火) 22:55:46.93ID:NKjx6bYj

>>708
いやE2Eテストが自動化出来ないというわけでもないからちょっと違うくない？
リファクタリングにも色々あるよねというのには同意。
リファクタリングの対象を決めることは大事だよね。
システム全体をリファクタリングしようとしても成功率は低い。だからE2Eテストはいらない(システム全体を一度に変えようとすんな)と言いたい気持ちも解る。

711デフォルトの名無しさん2017/02/07(火) 22:57:24.46ID:6yEMM6pR

>>709
責任範囲がユニッテテスト迄w
もはや何を言いたいのか自分でも分かってないだろお前w

712デフォルトの名無しさん2017/02/07(火) 23:01:56.40ID:hbaz0JGp

>>711
君が言いたいことは分かんないけど自分の言いたいことはわかってるよ

713デフォルトの名無しさん2017/02/07(火) 23:08:35.66ID:6yEMM6pR

>>712
いや分かってねえよお前w

既存のユニットテストが利用出来るようなコード修正は
お前のコードオナニー以外の何者でもない
お前はリファクタリングという正義を笠に着てコードオナニーをしているだけの
童貞コーダーにすぎないのだよ

714デフォルトの名無しさん2017/02/07(火) 23:11:01.58ID:hbaz0JGp

>>713
まさに混同してる人が話をややこしくしてる見本

715デフォルトの名無しさん2017/02/07(火) 23:16:01.53ID:S1oxUZhq

>>706
何だその意味がない答えは？

> 実行ファイル一つならそうである可能性もあるけど、ライブラリだったらシステム全体ではないよね。言語関係ないとはそういうこと。

ライブラリだったらシステム全体ではないかもしれないけど、実行ファイル一つならそうである可能性もある

716デフォルトの名無しさん2017/02/07(火) 23:16:32.08ID:K2oda13o

>>710
まあそうね

>>713
いやわかってないのはおまえ
リファクタといえば一般的にはTDDありきのおまえのいうオナニーだ

717デフォルトの名無しさん2017/02/07(火) 23:17:49.44ID:S1oxUZhq

>>709
> システムテストとかは機能の変更、追加、向上なんかの範囲だと思うけどね

意味が全くわからん。外から見たときに機能も何も変わらなくて
内部の設計が良くなってるならそれはリファクタリング

718デフォルトの名無しさん2017/02/07(火) 23:19:18.43ID:S1oxUZhq

>>716
> リファクタといえば一般的にはTDDありきの

TDDがリファクタリングありきなのであって
リファクタリングはTDDとは関係ない

719デフォルトの名無しさん2017/02/07(火) 23:22:44.32ID:K2oda13o

>>718
関係ないのではなくリファクタがそれだけではないってだけ
おまえめんどくさいな

720デフォルトの名無しさん2017/02/07(火) 23:23:22.80ID:S1oxUZhq

>>719
それだけじゃないっていうのなら、
他に何があるのかを言えよ

お前は否定するだけで、自分の意見を何も言ってない

721デフォルトの名無しさん2017/02/07(火) 23:23:38.10ID:6yEMM6pR

>>716
んなアホなw
まともなリファクタリングしている奴だって大勢いるわw

722デフォルトの名無しさん2017/02/07(火) 23:23:56.74ID:NKjx6bYj

>>715
だから違う言語にしたというのと、システムテストをするというのは無関係だって話だよ。それだけ。

723デフォルトの名無しさん2017/02/07(火) 23:25:16.66ID:NKjx6bYj

ID:6yEMM6pR がまともなリファクタリングを語るのはもうギャグにしか見えない

724デフォルトの名無しさん2017/02/07(火) 23:32:41.16ID:S1oxUZhq

>>722
外部から見たときの動きを変えずに、内部の言語を変えたら
ユニットテストもつかえねーだろ。
何を言ってんだお前

725デフォルトの名無しさん2017/02/07(火) 23:37:57.69ID:hbaz0JGp

>>717
そう言ってるつもりだけど？機能の変更までやったらシステムテストは必要だけどそれはリファクタリングの後の工程だよねってこと

726デフォルトの名無しさん2017/02/07(火) 23:41:30.42ID:NKjx6bYj

>>724
なんで？例えばC互換のABI作れる言語なんて山ほどあるけど(バイナリ作る言語ではほぼ必須機能だよね)
他にも内部の言語は変えたけどモジュールの外向きのラッパーは今までと同じ言語で書くというのもあるだろ

727デフォルトの名無しさん2017/02/07(火) 23:46:26.22ID:6yEMM6pR

>>725
お前頭沸いてんなw
そもそもテストの存在意義すら分かってねえじゃねえかw
ユニットテストは必要だけどシステムテストは必要ないなどと言う開発メソッドは
人類の歴史上でただの一度たりとも存在した事はねえよw

728デフォルトの名無しさん2017/02/07(火) 23:53:55.55ID:S1oxUZhq

>>726
なんでお前特別な状況下においてできるって話をしてるんだ？
一般的にはできない（やらない）だろ

729デフォルトの名無しさん2017/02/08(水) 00:00:15.94ID:xLLPMt9l

>>728
別に特別とは思わないけど。例もあるよね。
FirefoxのメディアパーサーをRustで書き直した話とか。

730デフォルトの名無しさん2017/02/08(水) 00:03:59.64ID:oBIe6m9v

>>720
ほんとめんどくさいな
バカがオナニーと言ってるようなifをswitchに変えるリファクタからソフトアーキ自体を変えるものまで全てリファクタだっつってんだろ

731デフォルトの名無しさん2017/02/08(水) 00:16:01.83ID:ahyxJIg+

>>730←自分のオナニーが認められないから根本的な設計思想の変更までリファクタリングだと言いだす極端すぎるバカｗ

732デフォルトの名無しさん2017/02/08(水) 00:37:41.54ID:E3hlYujb

>>731
涙ふけよ

733デフォルトの名無しさん2017/02/08(水) 03:53:58.44ID:/T6I+uKy

バカをチンカス野郎と言い換えても
罵倒であることは変わりない
これがリファクタリングでしょ？

734デフォルトの名無しさん2017/02/08(水) 04:18:31.48ID:TcrM+SWf

「外部からみた振る舞いを変えずに内部の設計を変更すること」がリファクタリング
ここでいう"外部"が関数の外部だったりシステムの外部だったりするけど、どっちもリファクタリング

リファクタリングを実施するのは設計～製作工程
TDDなら製作と同時にユニットテストも当然走る
TDDであってもそうで無くても、製作後にテストの工程は当然流す

添削おなしゃす

735デフォルトの名無しさん2017/02/08(水) 05:18:42.07ID:ahyxJIg+

>>734
> TDDなら製作と同時にユニットテストも当然走る
> TDDであってもそうで無くても、製作後にテストの工程は当然流す
これはリファクタリングの定義とは関係ないし
TDDでなくてもユニットテストは当然走る

736デフォルトの名無しさん2017/02/08(水) 09:24:40.45ID:pGBkCxNv

>>735
内省したのか？

737デフォルトの名無しさん2017/02/08(水) 09:39:48.42ID:nBuIwUQ3

>>735
>これはリファクタリングの定義とは関係ないし
そうだね
上の方でごっちゃにしてる人が居たからついでに書いたけど、語弊があったね

>TDDでなくてもユニットテストは当然走る
そうだね
製作と"同時に"走るかどうかだけの違いだと思う

738デフォルトの名無しさん2017/02/08(水) 09:46:07.86ID:tJ+Jm8vl

おれはTDDなんて大嫌いだ
あれ考えやつはアホ

739デフォルトの名無しさん2017/02/08(水) 09:47:23.69ID:3ajnzt+4

>>738
どんなところが嫌いなん？

740デフォルトの名無しさん2017/02/08(水) 13:47:01.32ID:DMN235DC

>>739
日本の社畜プログラマーは文系卒のゴミばっかりだから
日本のソフト業界は大量のゴミを一部の有能なエンジニアがコントロールすることでなんとか成立してる
ゴミにTDDなんてやらせたら有能な人間がリファクタリングに追われる羽目になる

741デフォルトの名無しさん2017/02/08(水) 14:21:20.51ID:HCDAsN67

>>740
どうせゴミが書いたコードなんて修正しなければならないんだから、テストがちゃんと書かれてる方がそれをパスするようにリファクタリング出来てマシだろ。

742デフォルトの名無しさん2017/02/08(水) 18:18:22.76ID:DMN235DC

ゴミが書いたテストコードなんて使えるわけなかろう
時間の無駄

743デフォルトの名無しさん2017/02/08(水) 19:05:55.15ID:nBuIwUQ3

それTDD関係ないじゃん

744デフォルトの名無しさん2017/02/08(水) 19:51:16.87ID:z7CrxHSJ

テストコード真っ先にレビューしろよ

745デフォルトの名無しさん2017/02/08(水) 19:54:03.00ID:ahyxJIg+

>>740←TDDもリファクタリングも分かってないゴミwこういうのがリファクタオナニストw

746デフォルトの名無しさん2017/02/08(水) 20:10:43.25ID:9HGTCoP8

リファクタリング前提の開発なんて小規模開発以外はやるものじゃないね

747デフォルトの名無しさん2017/02/08(水) 20:59:58.04ID:ahyxJIg+

それを言うならプロトタイピングだろw
なんだよリファクタリング前提てw

748デフォルトの名無しさん2017/02/08(水) 21:04:39.44ID:saIve44q

>>747
オナニー君まだいたの？

749デフォルトの名無しさん2017/02/08(水) 22:05:08.20ID:EqksEKaR

>>746
> リファクタリング前提の開発なんて小規模開発以外はやるものじゃないね

設計に問題があるときどうしてるの？
問題があるっていうのは、最初の時点で間違っていた場合の他
機能追加などで最初の想定と変わってしまった場合

リファクタリングしないで、問題ある設計のまま
開発を続行するの？

大きい開発ほど最初に想定しなかった事態が起こるはずだけど？

750デフォルトの名無しさん2017/02/08(水) 22:42:04.56ID:E3hlYujb

>>749
それをリファクタリングと言うのか
ただの上流への出戻り、やり直し、糞開発じゃないの

>>747
アジャイルって知ってる？オナニーくん

751デフォルトの名無しさん2017/02/08(水) 22:59:10.86ID:EqksEKaR

>>750
> ただの上流への出戻り、やり直し、糞開発じゃないの

上流へ出戻りするのは良いんだが、
今のコードはどうするんだよ？捨てるのか？

リファクタリングというのは今のコードをよく知られている
手順を使って安全に（バグを入れることなく）変化させていくことをいう

リファクタリングの勉強をちゃんとした人なら、知っているはずだが
リファクタリングしないことを選択すべき理由として
作り直したほうが速い場合っていうのがある。

作り直したほうが早い場合はリファクタリングの哲学によって作りなおすが、
コードを安全に変化させたほうが早い場合は当然リファクタリングをする。

で最初の質問に戻るが、お前コードを修正したほうが早い場合でも
リファクタリングしないで、コードを捨てて作り直すって言ってんの？
それとも行き当たりばったりなただの修正を行ってバグ発生させるの？

752デフォルトの名無しさん2017/02/08(水) 23:15:25.00ID:/T6I+uKy

現状それなりに動いているけど
将来性を考慮しての改善するのがリファクタリングでしょ

そもそもマトモに動いてないコードは問題外

753デフォルトの名無しさん2017/02/08(水) 23:18:57.65ID:EqksEKaR

> 将来性を考慮しての改善するのがリファクタリングでしょ
YAGNIに反するからそれは違う。
その将来が絶対来るというのなら話は別だけど

754デフォルトの名無しさん2017/02/08(水) 23:22:55.16ID:E3hlYujb

>>751
うーんw
いずれにしてもコードを捨てる捨てないに関わらず設計に問題があるものをその開発中に直すことをおれの界隈ではリファクタリングとは言わないね
おまえがそれをリファクタリングと言うのは自由なので好きにしてくれw

755デフォルトの名無しさん2017/02/08(水) 23:27:19.72ID:EqksEKaR

>>754
俺が言ってるんじゃなくて世間一般の定義。

っていうか開発中とそうでないのが別れてる時点で
お前、前時代的だしなぁ。

お前なら一日に何十回もデプロイするような
ウェブアプリをどうやって変化させていくんだ？

「俺にはできません。」ですかな？ｗ

756デフォルトの名無しさん2017/02/08(水) 23:31:13.83ID:EqksEKaR

ちなみに、TDDでは最初にテストコードを書いて
それに通る最小限の実装を書く、その後リファクタリングを
行うというのを繰り返して開発するものので、

http://www.atmarkit.co.jp/ait/articles/1403/05/news035.html#025
> 開発中に直すことをおれの界隈ではリファクタリングとは言わないね

> 開発中に直すことをおれの界隈ではリファクタリングとは言わないね
というのはもぐり、無知レベルでしかないよ

757デフォルトの名無しさん2017/02/08(水) 23:31:50.65ID:EqksEKaR

引用を間違えた

http://www.atmarkit.co.jp/ait/articles/1403/05/news035.html#025
>【5】テストを成功状態にしたままリファクタリングする

758デフォルトの名無しさん2017/02/08(水) 23:36:21.44ID:E3hlYujb

うーんw
自ら話を反らしていくスタイルw

759デフォルトの名無しさん2017/02/08(水) 23:38:20.99ID:EqksEKaR

それてないじゃん？ｗ

それてるっていうのなら、戻していいよ。君の手で

760デフォルトの名無しさん2017/02/08(水) 23:53:10.75ID:E3hlYujb

うーんww
そもそも少人数短期イテレーション開発におけるリファクタリングの話なんて始めからしてないのだがw
毎日デプロイするwebアプリ？そんな小さな話も全くしてないw
おまえが数億円契約の大規模開発をやったことないのはよくわかったw

761デフォルトの名無しさん2017/02/09(木) 01:52:04.00ID:CNUBJX7I

>>760
大規模だからって何の自慢になると思ってるんだ？

大規模は別にどうでもいいよ
どういった開発をしているのかが重要だろ。

いくら金がかかっているからって
ろくでもないやつばっかり集めて人海戦術で
ひたすら効率の悪い開発方法をしている？
だとしたら自慢どころか恥だよね。

もっと規模とか金以外に自慢できることないの？

762デフォルトの名無しさん2017/02/09(木) 04:01:02.59ID:VpXdxNl0

>>753
は？
while文よりfor文の方がわかりやすいね
って書き直す事のどこが機能追加なの？

読みやすくしておくことも未来への投資じゃね？

763デフォルトの名無しさん2017/02/09(木) 06:44:32.92ID:IOSaScxB

リファクタリングに開発規模は関係ない
レガシーコードの山に頭抱えながら仕事するのも自由だし、好きにしてくれ

764デフォルトの名無しさん2017/02/09(木) 07:38:20.57ID:W9c8fNbT

規模が大きい開発はクソコーダーがクソコードを量産してくるから俺様が随時コードを書き換えてやる

ってのが ID:E3hlYujb の主張
こういうリファクタオナニストに好きにさせてはいけない

765デフォルトの名無しさん2017/02/09(木) 08:20:04.14ID:2NAFiD3Z

リファクタリングに必要な見積りを出してくれ

766デフォルトの名無しさん2017/02/09(木) 11:43:47.05ID:qhoyYE05

>>765
これな

767デフォルトの名無しさん2017/02/09(木) 11:48:27.92ID:qhoyYE05

>>764
そうじゃなくて作ってからリファクタリングなんてやってる暇があるなら先にレビューで潰すってことさ
それでも設計レベルでの変更が必要にるならレビュアもゴミだったってだけのこと

768デフォルトの名無しさん2017/02/09(木) 12:39:15.13ID:Ra4XvV1b

本当に大規模開発やったことあるのか？
新規で作って作りっぱなしだったのか？

769デフォルトの名無しさん2017/02/09(木) 12:49:33.29ID:2OmAEiex

>>767
それこそ規模の大小は関係ないわけだが
結局なにが言いたいのお前

770デフォルトの名無しさん2017/02/09(木) 13:07:11.30ID:/WGpXuP3

>>769
関係ないことはない
設計レベルでの見直しをリファクタリンクを言うのであればそんなことがやすやすと可能なのは少規模開発だけ

771デフォルトの名無しさん2017/02/09(木) 13:11:02.24ID:/WGpXuP3

話を戻すと開発中にそんな状況になるのを俺はリファクタリングとは言わん
リファクタリングとはもっと前向きなものだ

っていうことを>>750から何度も言ってるからだけなんだがねw

772デフォルトの名無しさん2017/02/09(木) 14:01:01.97ID:Ra4XvV1b

じゃあ何のことをリファクタリングと呼んでるの？

773デフォルトの名無しさん2017/02/09(木) 14:27:10.00ID:VpXdxNl0

そもそもファクタリングとは？
それをやり直すってことでしょ

774デフォルトの名無しさん2017/02/09(木) 15:01:34.48ID:Lyr2GEHi

じゃあ逆に聞くけど設計から変えてUTのコードがそのまま使えるケースってどんなの？w
テストコードの書き換えが必要な改修は開発スキームとして事前にスケジュールに組み込まれるリファクタリングとは全く別ものだろww

775デフォルトの名無しさん2017/02/09(木) 15:14:26.88ID:lnTHGhne

別にリファクタリングは個別のユニットテストに影響ないレベルとは限らないでしょ。
リファクタリング対象によってそこは取捨選択すべき。

776デフォルトの名無しさん2017/02/09(木) 17:19:48.49ID:EPpoXydB

結論から言えば概念としてのリファクタリングは否定しないが、
リファクタリングのための工数なんて実際は取れないし、
そんな余計なリソースがあるなら他の事に回した方がいい
所詮暇を持て余した学生の戯言だよ

777デフォルトの名無しさん2017/02/09(木) 19:13:25.68ID:Lyr2GEHi

>>775
いやだから話の前提が>>749だから選択も糞もないくやらないといけない状況でそれをリファクタリングとはいわねーって
もうええわww

778デフォルトの名無しさん2017/02/09(木) 19:41:42.20ID:2NAFiD3Z

プロジェクトの開始時にリファクタリングの見積も出してね
オーバーした分はお金出せないからね

779デフォルトの名無しさん2017/02/09(木) 20:10:08.12ID:VpXdxNl0

だからまずファクタリングの定義からしようか
それをやり直すってだけの話でしょ

780デフォルトの名無しさん2017/02/09(木) 20:29:21.19ID:Ra4XvV1b

機能要件を満たすため
非機能要件を満たすため
オナニーするため
目的が何であろうとリファクタリングはリファクタリングですよ

781デフォルトの名無しさん2017/02/09(木) 21:09:00.44ID:DXVOdvHd

オブジェクト指向でシステム開発するなら、リファクタリングは必須です。
クラスの設計、インターフェースの抽出・設計といったプログラミング前に
既に必要です。

782デフォルトの名無しさん2017/02/09(木) 21:09:16.18ID:W9c8fNbT

>>771
> リファクタリングとはもっと前向きなものだ

ここへ来ていきなり精神論かよ
やっぱり頭沸いてんだろお前w

783デフォルトの名無しさん2017/02/09(木) 21:29:45.22ID:l61bzEJu

とりあえず動くものを新規で作って書き換える場合か、すでに動いているもので、修正が入りまくって汚くなったものを整理するくらいしかない。

自由にいじくりまわすのをリファクタリングとは言わない。

784デフォルトの名無しさん2017/02/09(木) 21:35:33.02ID:CNUBJX7I

>>762
> while文よりfor文の方がわかりやすいね
> って書き直す事のどこが機能追加なの？

while文よりfor文の方がわかりやすいねとか
俺は言ってない。お前が言ったことだ。

お前は、機能追加じゃない例を自分で出して
自分で自分にツッコミを入れてるだけなんだが、

何がしたいの？

785デフォルトの名無しさん2017/02/09(木) 21:39:19.62ID:lnTHGhne

とりあえずみんな
http://www.shoeisha.co.jp/book/detail/9784798116839
とか
https://estore.ohmsha.co.jp/titles/978427405019P
これ読んでる？

786デフォルトの名無しさん2017/02/09(木) 21:42:53.34ID:CNUBJX7I

>>777
> いやだから話の前提が>>749だから選択も糞もないくやらないといけない状況でそれをリファクタリングとはいわねーって

お前根本的に間違ってるんだわ。

まず先に最初の話のツッコミ漏れを補完しておくとだな
>>749で設計に問題があるときはどうするのか聞いた。
これは言い換えると「やり直し以外の選択の余地がない例」として上げたんだよ。

それなのに、>>750で
> ただの上流への出戻り、やり直し、糞開発じゃないの
やり直しすればいいじゃんって、お前アスペか？

やり直し以外の選択肢の余地がないことにたいして、
「やり直ししろ」ってそれは反論になってない
俺が意図してる答えだ

でな、リファクタリングかどうかっていうのは、手段なの
「糞もないくやらないといけない状況」のときに、
リファクタリングを使って、修正を行うのか
リファクタリングを使わずに、修正を行うかの話

ここまで言えば、お前が根本的に間違ってることが理解できるだろ？
お前はリファクタリングが手段であることをわかってない。どんな状況かはどうでもいい。
修正をするときに、どうやって修正するかの話だ。

お前は、リファクタリングしないで、行き当たりばったりで修正してバグを入れ込むんだろう？
俺はリファクタリング（わかりやすく言えばリファクタリングの本に書いてあるテクニック）を使って修正するんだよ

787デフォルトの名無しさん2017/02/09(木) 21:45:29.54ID:CNUBJX7I

>>778
> プロジェクトの開始時にリファクタリングの見積も出してね

リファクタリングが手段であることを知れば、
「リファクタリング（手段）の見積もり」がおかしい言い方だとわかるだろう。

正しく言うならば「プロジェクトの開始時に修正の見積もだしてね」だ
修正にはバグだけじゃなくて仕様の追加や間違いによる修正も含まれる。

あとは修正するしかない状況で、行き当たりばったりで修正するか
リファクタリングで修正するかの違いなだけだ

788デフォルトの名無しさん2017/02/09(木) 21:46:27.58ID:CNUBJX7I

>>776
> リファクタリングのための工数なんて実際は取れないし、
リファクタリングのための工数が取れなくて
リファクタリングを使わない修正であれば
工数が取れるっておかしくね？ｗ

789デフォルトの名無しさん2017/02/09(木) 21:52:20.21ID:lnTHGhne

https://estore.ohmsha.co.jp/titles/978427405019P

リファクタリングに工数がーとか言ってる奴はこれ特に読んで欲しい

7907622017/02/09(木) 21:55:31.20ID:VpXdxNl0

>>784
ほらな
きちんと書いてないと
こうやって誤解されるわけだ
言いたかったのは

「現状while文で処理されていて問題ないけど
このケースはfor文の方がわかりやすいから書き直そう！」
どこに機能追加される余地があんの？

791デフォルトの名無しさん2017/02/09(木) 21:57:10.56ID:CNUBJX7I

>>790
> どこに機能追加される余地があんの？
ないよ？

誰がそこに機能追加される余地があるって
言ってるの？

お前？

792デフォルトの名無しさん2017/02/09(木) 21:58:18.00ID:lnTHGhne

>>791
>>753 こいつ

793デフォルトの名無しさん2017/02/09(木) 21:58:44.70ID:CNUBJX7I

>>753には while とか for の話は
明らかに書いてないけど？

794デフォルトの名無しさん2017/02/09(木) 21:59:52.90ID:VpXdxNl0

>>791
あのさー
YAGNIに反するって言ったのは誰なんですかね？
余計な機能はつけるなってことでしょ？
whileからforに書き換えるのに何か機能追加されんの？

795デフォルトの名無しさん2017/02/09(木) 22:01:15.92ID:CNUBJX7I

YAGNIの話？

753 自分：デフォルトの名無しさん[sage] 投稿日：2017/02/08(水) 23:18:57.65 ID:EqksEKaR [3/7]
> 将来性を考慮しての改善するのがリファクタリングでしょ
YAGNIに反するからそれは違う。

これがどうfor やwhileと関係すんの？

796デフォルトの名無しさん2017/02/09(木) 22:02:47.10ID:lnTHGhne

ほんまやね。レス辿って明らかにおかしいのを見つけたがら言ったけどそれforのレスにかすりもしなかったわ。すまん。

797デフォルトの名無しさん2017/02/09(木) 22:06:33.30ID:Lyr2GEHi

>>786
おまえ日本人か？w

798デフォルトの名無しさん2017/02/09(木) 22:08:07.52ID:CNUBJX7I

下手に勘違いされると困るから補足しておくと、

汚いから修正するってだけならYAGNIでやるべきではないが、

その部分を修正していたり読む必要があるならば、
いつ必要しているの？今でしょ？ってことで
今すぐ必要としていることなわけだから、
そこを修正するのはYAGNIではない

799デフォルトの名無しさん2017/02/09(木) 22:25:26.99ID:lnTHGhne

読まなきゃ汚いと思わないんだから、矛盾してるような気がするけど。
必要ないのに汚いコードを読み始める酔狂な奴が居るとしたら別だけど。

800デフォルトの名無しさん2017/02/09(木) 22:29:02.28ID:CNUBJX7I

> 読まなきゃ汚いと思わないんだから
いや、コードメトリクスツールなどをつかえば
読まなくても、客観的に汚いとわかる

801デフォルトの名無しさん2017/02/09(木) 22:29:15.76ID:Ra4XvV1b

>>797
いつになったら何のことをリファクタリングと呼んでるか書いてくれるの？

802デフォルトの名無しさん2017/02/09(木) 22:34:05.44ID:Ra4XvV1b

汚いから直すってのもリファクタリングと呼ぶと思うけど、
汚いから直すってのは実際の開発現場じゃなかなか難しいと思うよ

その汚さが原因で性能が出ないとか、機能追加できない、し辛いって明確な理由があれば別だけどね

803デフォルトの名無しさん2017/02/09(木) 22:41:25.83ID:CNUBJX7I

>>802
> その汚さが原因で性能が出ないとか、機能追加できない、し辛いって明確な理由があれば別だけどね

だから俺は聞いたんだよ？

そういうどうしても直さなければいけないときに
リファクタリングで安全に修正するのか？
それとも行き当たりばったりに修正してバグを入れるのか？って

804デフォルトの名無しさん2017/02/09(木) 22:43:53.46ID:Ra4XvV1b

いや、俺に噛みつかれましても

805デフォルトの名無しさん2017/02/09(木) 22:45:29.16ID:Lyr2GEHi

>>801
理解できる頭がないのに質問するなよw
何度も言ってるだろうがww

806デフォルトの名無しさん2017/02/09(木) 22:47:35.42ID:CNUBJX7I

リファクタリングを行うタイミングを間違ってるんだよね

俺は何らかの機能修正とかでコードをいじるときに
関連するところを少しづつなおす
大抵が数行程度で10分もかからずに終わる

こまめに修正しないで、手遅れになってからやろうとするから
大規模になってしまって、別途工数が～とかいう話になるんだよ。

手遅れになってしまったものを修正する工数がないからと
手遅れなコードのままさらにコードを追加するから
さらに手遅れになっていくんだろうが

807デフォルトの名無しさん2017/02/09(木) 22:59:39.83ID:lnTHGhne

>>806
多分解ってると思うけどその言い方は誤解を生むと思うぞ。
リファクタリングと機能追加は明確に分けるべきで、リファクタリングして、テスト走らせて振る舞いが変わってない事を確認してから機能追加に入るべき

808デフォルトの名無しさん2017/02/09(木) 23:07:28.39ID:Ra4XvV1b

>>805
他人の否定はしてるけど、自分では何も言ってないよ君

809デフォルトの名無しさん2017/02/09(木) 23:07:33.91ID:2NAFiD3Z

リファクタリング=上腕二頭筋

810デフォルトの名無しさん2017/02/09(木) 23:12:13.46ID:CNUBJX7I

>>807
うん。わかってる

> リファクタリングして、テスト走らせて振る舞いが変わってない事を確認してから機能追加に入るべき

どちらもあるよ。

機能追加してからリファクタリングする物の典型的な例がTDD
Red/Green/Refactor 通りの順番

811デフォルトの名無しさん2017/02/10(金) 00:46:58.66ID:/WxwB06L

どんどん別の手法がまざっていく洗脳馬鹿

812デフォルトの名無しさん2017/02/10(金) 01:18:18.70ID:+KYQgfiL

別の手法ってなんの話だ？

813デフォルトの名無しさん2017/02/10(金) 02:12:34.39ID:/WxwB06L

>>810 のことだよ。

814デフォルトの名無しさん2017/02/10(金) 02:25:45.27ID:+KYQgfiL

> Red/Green/Refactor 通りの順番

これのことか？

Refactorはリファクタリングのことだよ
別の手法じゃなくて全く同じもの

815デフォルトの名無しさん2017/02/10(金) 12:06:41.01ID:QRGeJWes

1.機能追加前にテスト書く
2.追加コード書く
3.テスト
4.ダメならテストに通るまでコードいじる

もしかしてこれもリファクタリング扱いしてるの？

816デフォルトの名無しさん2017/02/10(金) 12:38:04.04ID:+HewTgrG

>>815
それはRed→Greenのところでしょ…

817デフォルトの名無しさん2017/02/10(金) 21:26:25.38ID:1oBD+cZp

　最近、特定のフラグ変数に関するif文の山をswitch構文に清書し直したんだけど、これってリファクタリング？

818デフォルトの名無しさん2017/02/10(金) 21:34:25.32ID:/WxwB06L

>>816
それさ、リファクタリングのいち定義であってリファクタリングではないから。

819デフォルトの名無しさん2017/02/10(金) 21:35:50.89ID:/WxwB06L

>>817
そのif文が変ならな。まともなif文なら書き換える必要がない。

820デフォルトの名無しさん2017/02/10(金) 21:37:35.22ID:/WxwB06L

>>817
ただswitch文にすると仕様変更時にswitch文では対応できなくなる可能性があるので逆かもしれない。

821デフォルトの名無しさん2017/02/10(金) 21:42:51.54ID:+KYQgfiL

>>817
確かにswitchでかけるならばifよりswitchの方が少しだけ見やすくなるけど、
大抵はリファクタリングにはならないよ
巨大なswitchもリファクタリングすべき対象となる

何がダメなのかというと比較の回数がifのときと変わってないから。
比較が多い＝複雑なので、これは単なる書き方の違いでしかなくて
リファクタリングとまではいかない。重要なのは比較回数

じゃあどうすべきかというと、一番簡単な方法は
関数テーブル（ルックアップテーブル）を使う方法
大量のswitchでの比較が条件が揃えば0個にまで減る

822デフォルトの名無しさん2017/02/10(金) 21:46:49.78ID:+KYQgfiL

>>818
> それさ、リファクタリングのいち定義であって

> Red/Green/Refactor 通りの順番
がリファクタリングの定義に見えるんだ・・・

ここにはどこにもリファクタリングの定義なんてものは
書いてないんだが

>>816が言ってるのは、Red→Greenでやる内容は
リファクタリングじゃないよって言ってるだけでしょ

俺からも補足するが、リファクタリングは
動いているコードを、動いているコードに置き換えることだよ。

修正前と修正後のどちらかが動いていなければ
それはリファクタリングではない

823デフォルトの名無しさん2017/02/10(金) 21:57:11.80ID:+KYQgfiL

* Green
　　1.機能追加前にテスト書く
* Red
　　2.追加コード書く
　　3.テスト
　　4.ダメならテストに通るまでコードいじる
　　5.テストに通った。やったー完成だ！ ←ふざけんじゃないよ。なんだこのコピペだらけで無駄がばかりのクソコードは
* Green
　　6.リファクタリングする
　　7. 読みやすくなりました。←このコードならレビューする気になる。シンプルあとで読んだ人も理解しやすいだろう
　　8. 完成、1に戻る

824デフォルトの名無しさん2017/02/10(金) 22:00:06.48ID:+KYQgfiL

現実にはこの5. テストに通っただけの状態で
完成としてしまうやつが多いんだよな。

そういうコードで許される環境っていうのは
コードレビューが行われていない。
コードを見ずにテストに通ればOKとしてしまう環境

そして向かうはデスマーチｗ

825デフォルトの名無しさん2017/02/10(金) 22:14:40.62ID:/WxwB06L

駄目だこりゃ。なんでそういう手順がリファクタリングなのか？

826デフォルトの名無しさん2017/02/10(金) 22:20:09.64ID:+KYQgfiL

>>825
お前が理解してないだけだよｗ

827デフォルトの名無しさん2017/02/10(金) 22:33:35.95ID:+HewTgrG

Refactorとリファクタリングが同じ意味の言葉だってのが伝わってないのかも知れないな

828デフォルトの名無しさん2017/02/10(金) 22:38:11.34ID:+KYQgfiL

あ、はい間違えました

>　6.リファクタリングする

これじゃリファクタリンギングですねｗ

829デフォルトの名無しさん2017/02/10(金) 22:59:58.18ID:/WxwB06L

このスレってそもそも特定のリファクタリング作業のスレッドか。話がかみ合わないわけだ。

830デフォルトの名無しさん2017/02/10(金) 23:48:55.17ID:+KYQgfiL

誰が特定のリファクタリング作業の話をしてるんだ？
誰がはどうでもいいや「特定の」ってどれのことだよ？

831デフォルトの名無しさん2017/02/11(土) 00:00:12.78ID:o1zrWG0U

TDDの例出したからTDDに限定した話だって勘違いしてるんでしょ

832デフォルトの名無しさん2017/02/11(土) 00:04:14.10ID:p/3UeWk3

>>829
「特定の」がなにか言うだけだよ。
お前がちゃんと考えて発言しているなら
簡単な質問なはずだが？

もっとも俺はお前が何も考えてないってことを
あぶり出すために「特定の」が何か聞いたんだけどなｗ

833デフォルトの名無しさん2017/02/21(火) 23:44:51.93ID:8I0Tfvzv

お、あぶり出してるねえ

834デフォルトの名無しさん2017/02/22(水) 01:09:25.60ID:TiP/fttU

このスレの存在忘れてたわｗ
なんだ逃げたのかｗ

835デフォルトの名無しさん2017/02/22(水) 12:59:43.56ID:zJ9IFSdf

>>423 >>426 のやつNot Foundになってた

リファクタリングの誤用
https://bliki-ja.github.io/RefactoringMalapropism/

リファクタリングの境界線
[見当たらない]

インタフェースの変更はリファクタリングか
https://bliki-ja.github.io/IsChangingInterfacesRefactoring/

未知のバグフィックスはリファクタリングか？
https://bliki-ja.github.io/IsFixingAnUnknownBugRefactoring/

最適化はリファクタリングか？
https://bliki-ja.github.io/IsOptimizationRefactoring/

宣言の順序変更はリファクタリングか？
https://bliki-ja.github.io/IsDeclarationOrderingRefactoring/

836デフォルトの名無しさん2017/02/23(木) 18:03:32.56ID:G3lxPXWh

定義から定まってないからなリファクタリングって
いや、実在するのか？

837デフォルトの名無しさん2017/02/23(木) 22:07:14.34ID:Ka1UMSVA

殆どの用語は定義なんか定まってないよ
数学でさえ、ある用語に対して数学ではこういう定義で
使いましょうと決めているだけ

838デフォルトの名無しさん2017/02/26(日) 20:54:48.09ID:wNjUkQs3

ソースを組んだときと今とでチンコのポジションを若干変更した
これがリファクタリングである

839デフォルトの名無しさん2017/02/26(日) 22:44:41.65ID:zOBszuQK

特定の統合開発環境のリファクタリング機能をリファクタリングだと言ってるやつはいなくなったなw

840デフォルトの名無しさん2017/02/27(月) 01:14:12.49ID:IXzsv4Rb

俺の中では変数名の変更=リファクタリング

Visual Studioの機能名がそうだったから

841デフォルトの名無しさん2017/02/27(月) 01:49:20.76ID:j4xHFZFw

俺の中では、マーチンファウラーのリファクタリング本（古い方）に
のっているのがリファクタリング
変数名の変更ももちろんのってる

後はそのリファクタリングをどれだけ簡単に
正確に行えるかの違い。

ローカルスコープ程度で済むものなら良いけど
スコープが広い部分のリファクタリングは手動でやるのは大変
それを自動的に間違いなく行える、静的型付け言語＋IDEの力は偉大