2ちゃんねる★スマホ版★■掲示板に戻る■全部1-最新50

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

1 :
2010/05/29(土) 17:25:56
テストも書かないでリファクタリングとかうけるw

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

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

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

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

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

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

で?
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
その通りです。
何か嫌がらせされてる気がする。
12 :
2010/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
ばーかばーか
20 :
2010/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
リファクタリングがなんなのか、メリットとデメリットについてなど
理解してないからだろ

こういう成功例を見せながら地道に説得していくしかないんじゃないの?
ttp://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
そもそも本当に1階にも手を入れないと倒れるのか?
やってみたら意外と倒壊しないんじゃないの?、とか
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
42 :
2010/06/28(月) 02:42:24
>>39
>リファクタリングしている=暇そうにしていると思っているっぽい。

正解だから困る
43 :
2010/06/29(火) 21:31:04
>38
組み込み向け「軽量Ruby」と「Rubyチップ」、福岡県が経産省の事業で開発へ
ttp://itpro.nikkeibp.co.jp/article/NEWS/20100628/349693/?ST=oss

的外れな提示だったらすまそ。
44 :
2010/06/30(水) 14:19:54
組み込みにスクリプト言語とな?w
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
リファクタリングなんてやって意味があると思ってる奴は消防

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

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

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

A〜Zまでの共通処理が走ってるPクラスを蹴飛ばしてPAクラスを新しく作って
A−PA、B〜Z−Pの関係を新しくぶった切るような切込みはできんやろ?
せいぜいPの処理に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
いや、上で書いたのはあくまで例だよ
上の例は処理をまとめることによって明らかに構造が汚くなってるよね?
この先もまとめたPクラスにA〜Zへのどれかの追加が入るたびに
case B、case C・・・と追加されていくだろうね
そのときPクラスを消滅する選択肢は誰か選べるんだろか?

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

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

したら、その仕様書もなしでリファクタリングをするってことは
仕様書もないのにプログラムの構造を「俺が好き」なだけの構造にただ意味もなく
書き換えてるだけのマスターベーションなんだよ
53 :
2011/06/01(水) 23:55:42.31
どこの幼房かしらんが、
case B、case Cとなるようなまとめ方はアフォがやるものだろ。
それはリファクタリング以前の問題。
54 :
2011/06/02(木) 06:38:02.16
>>53
ほうほう、それじゃ上記の例でPの共通部分にAのみに変更がかかったらどう修正する気?
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を入れる
自分のソース見てみろ
今回は俺が逃げ道塞いだから自前で実装って言っただけだろ?w
正気に戻ればPクラスなんてつくらねーんだけどな
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
違うな
大抵の場合、外部とのやりとりをA〜Zまでまとめない一心でPクラスで作ってしまうから
Aだけ切り離してもインターフェースがPを通しているのでPにAへの変更を吸収してもらうほかないって感じになってるはず
じゃないとまとめたうまみないしねw
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きったら今度は命名した奴のセンスに丸投げすることになる
それが必ずしもわかりいい名前をつけてくれるとは限らない
また、複数個所でこの文字列を使うことがあったとして・・・いや・・・ないだろ?w
あるならなにかおかしいんだw

文字列の場合、数値とはちょっと違う事情があってこういう定数を#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
あんまり気にしなくていいよ
「ちゃんとインスタンスの生成箇所をしっかり制御すれば」=「グローバル変数なんて使うほどお馬鹿じゃなければ」
って意味だからw
93 :
2011/06/05(日) 14:26:48.94
>>92
ちょっと待て、たかがグローバル変数を使わないだけのことを
「ちゃんとインスタンスの生成箇所をしっかり制御」
なんて仰々しく書いてたのか
94 :
2011/06/05(日) 14:28:38.99
>>93
仰々しく書いたつもりはないけど
君にはできないことだよねw
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
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
かわいそうな環境の人?w


そういう場合に、古い関数を
DeprecatedやObsoleteと書いて
リファクタリングする方法もあるよ
110 :
2011/10/10(月) 15:29:15.75
おお、Javaがやってる方法じゃん
Java PGは可哀想な子だからな
111 :
2011/10/10(月) 15:31:03.21
DeprecatedやObsoleteは
どの言語でもやってることだろ。

なんかこう、俺とは一段以上 下のレベルの
奴しか見当たらんよなw
112 :
2011/10/10(月) 15:49:03.28
そう。どの言語でもやってる。
何故ならインターフェースなどそう簡単に変更できないからだ。

それなのに
> 必要なことがあるかもしれないが、それは、通知すればいいだけの話。
のような事を書くほど低レベルのPGはJava PGだけだと予想して釣ってみたが、
やっぱりその通りだったねw
113 :
2011/10/10(月) 15:55:41.96
「なんかこう、俺とは一段以上下のレベルの奴しか見当たらんよなw」(キリッ
114 :
2011/10/10(月) 16:24:50.97
>>112
意味がわからんw

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

お前頭が硬すぎじゃね?
115 :
2011/10/10(月) 16:48:43.88
めんどくさいからコードに対する変更はもう全部リファクタリングでいいよ
116 :
2011/10/10(月) 19:15:25.35
>>109
若干かわいそうな環境かも。

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

それでも自担当の部分だけでもリファクタリングする工数が
貰えるだけマシなのかも知れんけどね。
117 :
2011/10/10(月) 21:13:00.47
JavaのPGやってるけど
privateメソッドを修正するだけでもJAVADOCの修正とかユニットテストが更新されるからって
チーム内でそれを拒む人いるんだよなー
ってか、お前が俺のソースコピペして、俺がその責任背負わなくなくなるのが嫌なんだろwwwどうせwww
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
でっていう

教えてほしいならそう言えよw
そうでないのなら、やり方はひとつじゃないんだし、お前の好きなようにやれば?
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年物のソースコードとかあるからな
166 :
2011/11/06(日) 16:44:42.65
リファクタリングとか、
10万行のソースコードがあったとして、
その10万行のソースコードを、読んだってレベルじゃなくて、そうとう熟知した状態で
1人で行わなきゃならない
ていうか、それできるレベルなら、多分最初から書き直したほうが綺麗に書ける

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

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

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

既存の動きに影響を与えない方法ってのがあるんだよ。
これを使わないとリファクタリングにはならない。
行き当たりばったりの思いつき修正とはわけが違う。
論理的に考えぬかれた体系化されたテクニック。
それカタログ化して解説した本が、世の中にでてるリファクタリング本
168 :
2011/11/06(日) 17:24:22.30
>リファクタリングとか、
>10万行のソースコードがあったとして、
>その10万行のソースコードを、読んだってレベルじゃなくて、そうとう熟知した状態で
>1人で行わなきゃならない
>ていうか、それできるレベルなら、多分最初から書き直したほうが綺麗に書ける

とてもじゃないが、まともに教育を受けた人間の書いた日本語には見えない。
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
とかいって逃げたいから自分の言葉で説明しないで本に書いてあるとか言ってるんでしょ?
わかるよ
説明できない人ってみんなそうだもの
あんたもいっしょ

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

そんな糞みたいな脳みそしかないんだったら技術者なんてやめちゃえばいいのに
178 :
2011/11/08(火) 01:14:10.32
>>177
コンプレックス刺激されすぎw
179 :
2011/11/08(火) 01:17:58.36
単純なシチュエーションだと、今動いているものがあって
それに仕様変更や機能追加をする"前"にリファクタリングしたり

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

さすがに何も用事が無いのにリファクタリングはしないぞw
180 :
2011/11/08(火) 06:35:51.23
>>179
ローカルのHDDの中で勝手にやってろレベルだなw
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
あるけど
そこでそんなに違いが出るとは思えないんだよね
大手もそう考えるから(いや実際そうなんだろう)PGは派遣ばかりなわけだしね
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
そのストーリーって重要な部分なの?w
しかもそんな馬鹿みたいな長文書いて大事な要点がちっとも書いてないじゃん

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

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

だろ?
お前の国語の能力低すぎてリファクタリングまで怪しくなるわw
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
重複の除去が有効とか書いてあるじゃん

前にやった仕事で、ほんの一部を除いて同一の機能を持つモジュール2つが
別々の人によってそれぞれ実装されてて
目玉飛び出そうになったのを思い出した
199 :
2011/11/16(水) 21:30:50.10
別にいいじゃん
その2つをくっつけることで後に呼び出し先Aの機能を修正したいだけなのに
その機能がわざわざまとめられてるために
もう一つの呼び出し先Bのソースまで洗わないといけなくなるかもしんないだろ

まとめるのは必ずしも正解ではない
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では正しいだろうな
だが、日本の工業製品ではNG

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

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

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

修正した本人は「いいんですーこれが本来あるべき姿なんです〜」って主張しようと
修正するほうは「糞が・・・」って思うっしょ?
まあ、MSの出荷するもんにみんなが愚痴をこぼす瞬間だと思うけど
203 :
2011/11/17(木) 22:50:23.01
>>202
で、その壁を超えられる所が勝ち組で
超えられないところはどんどんブラック会社化するわけだ。

仕事、つまらないだろう?w
204 :
2011/11/17(木) 22:55:03.81
>>203
でもいくらもないっしょ?
日本のITって進化に失敗してて紙業務を電子化したような仕事のほうが多いよね?
韓国にもすっかり抜かれちゃったみたいで国内全員でショボーンって感じじゃない?
研究開発分野と本当に極一部だけだろうね
まあ、いまそういう開発してても日本じゃいつ紙業務の電子化ITにまわされるかわからないから
勝ち組って意味でいうと海外脱出組が勝ち組だろうね
205 :
2011/11/17(木) 22:58:57.20
>>204
ごめんな。

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

選ぶ会社の時点で勝ち負けが決まるよね。
仕事、つまらないだろう?w
206 :
2011/11/17(木) 23:01:51.10
うちは少数精鋭なんで(使えない奴はやめさせられる)
同じコードをいくつも書くとかそんな無駄なことやってられないんだよね。

テストも人海戦術で同じことを何度もやるとか、時間的に無理だし、
もちろん手動テストは極力減らすので、変更したって
影響があるならすぐ分かる。
207 :
2011/11/17(木) 23:02:59.45
>>205
ウェブ系なんて工業製品とかわんねーけどな
あんなん汎用性見越して組む必要あるかね?

寿命が短いからどう組んでもどうとでも動くが正解だろ?
納期まで早い方が真
お前の世界こそプログラムを綺麗にまとめて褒める奴1人もいないと思うがな
208 :
2011/11/17(木) 23:38:17.66
>>207
汎用性見越して組むとか言ってないんだが。

無駄にある重複コードをまとめると言ってるだけ。
209 :
2011/11/17(木) 23:39:39.61
重複コードを作ると、納期が延びます。

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

少しの修正であっちこっち修正して、
あっちこっちテストして納期伸ばしてるのは誰ですか?w
210 :
2011/11/18(金) 00:57:17.23
>>209
それって何箇所?
10箇所?20箇所?程度なら貼ったほうが速いよね?
思いっきりまとめあげられてて難しい仕組みに頭ひねってソース解読しなきゃいけないぐらいだったら
単純コピーで貼ってあってくれたほうがまだソース読みやすいよね

っていうか件数が100件いかない程度のコピペならお前が便所に席を立った間にやっておいてやるよ
この程度の件数だったらどう組んでも変わらない
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 使用がバッチィからコードもバッチイって発想はないのか?
234 :
2011/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
結局、
外から見た目の振る舞いが変わるか/変わらないかがポイントで、
外から見た目の振る舞い=仕様であって
内部構造≒設計は、リファクタリングの対象
って事でおk?
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
最初からずっとこのスレにいるのは
お前だけだよw
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
言葉の揚げ足取りに終始しててウザいだけのスレになっちゃってるなw
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
そういうコードこそ、リファクタリングが楽しいんじゃないの?
274 :
2012/10/16(火) 18:35:14.51
趣味でやるならすごく楽しい。一人でやるのなら絶対リファクタリングしてる。
けど仕事となると時間が取れない。
さらなる機能追加と他言語への移植作業用のドキュメントが優先になってまつorz
移植作業前にリファクタリングできたら解読も楽だろうになあ。
そんなことより成果物(ドキュメント)が優先だってさ。しゃーねーや。
275 :
2013/07/11(木) NY:AN:NY.AN
refakuta
276 :
2013/07/11(木) NY:AN:NY.AN
リファク太
277 :
2014/01/10(金) 07:46:54.18
リファクトスタンダード
278 :
2014/01/21(火) 23:03:30.89
リファクタリング本はかなり勉強になったな。
ぐちゃぐちゃなコードしか書けなかったのが、リファクタリングしまくってたら
最初からオブジェクト指向やらデザインパターンやらを考慮したコードが書けるようになってた。
279 :
デフォルトの名無しさん
2014/07/25(金) 01:44:17.80 ID:S+8bjftN
リファクタリング中にバグが見つかっても修正しちゃいけないんですか?
振る舞いが変わるわけだし。
リファクタリング原理主義者の方の意見が聞きたいです。
280 :
2014/07/25(金) 07:34:43.94 ID:FDyePLlK
好きにすれば?どうせ個人でやってんだろ
一人ならほんと楽しいよねリファクタ。

業務でリファクタなんかできねーよ
リリースしてから何年も動いてるパッケージに手入れられるわけないだろ!
281 :
2014/07/25(金) 10:51:25.65 ID:nHudeAGx
業務でリファクタリングの時は、バグの種類にもよるけど基本的にはそのまま。
勿論、リファクタリング後に修正することを見越してリファクタリングすることになる。
実は、バグを見つける為にリファクタリングすることもあるので、「できねーよ」で済まない場合もあるのよ。
282 :
2014/07/25(金) 11:26:11.42 ID:PjU5XzSY
バグを見つけるためにリファクタリングをすることはあるが
改修はリファクタリング前のコードに対して行うことになるなぁ
283 :
デフォルトの名無しさん
2014/07/25(金) 12:21:15.76 ID:CQdwbNpj
リファクタリングとは
テストの合格を維持したままの
コードの修正でしょ
284 :
2014/07/25(金) 12:41:48.16 ID:mmV7Js8i
上を納得というか安心させるための無駄検証にコストを掛けた後だと
いじくれないというのはわかる

だがサブシステムを小分けして
その範囲内で裁量をもたせられるようにしてないのはアカン
285 :
2014/07/25(金) 13:58:36.59 ID:fPj1ZcPi
>>282
> 改修はリファクタリング前のコードに対して行うことになるなぁ

それって人件費を無駄に捨ててるじゃないか?
会社に損害与えてるよ。
プロ意識無いのかね?
286 :
2014/07/25(金) 20:12:11.75 ID:zPq/iOJh
リファクタリングしたがる人とは仕事したくないよね
287 :
デフォルトの名無しさん
2014/07/25(金) 20:12:41.10 ID:Fz0v1PBn
でも実は一発目無計画で作ってリファクタリングするのが一番品質がいい
288 :
2014/07/25(金) 21:18:52.98 ID:JraUdqnP
一発目無計画っていうのがありえなさすぎ。
趣味のプログラミングだろそれは。
289 :
2014/07/25(金) 22:15:52.25 ID:Xbv85is1
>>287
それは全然不思議じゃないね。
下書きだと思えばいい。

一発で書くよりも、下書きして全体を理解してから
清書する。
290 :
2014/07/25(金) 23:03:10.49 ID:mmV7Js8i
神ならざる身で限界を知りつつも最善を目指す手法ではないか
291 :
2014/07/25(金) 23:24:21.34 ID:oKdTZN9u
考え方の違いなんだよね。この業界に「ボーイスカウトの規則」っていう言葉があるらしい。

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


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

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

それが出来ない人は、バグも多いんだよ。してシンプルにしてないから。
複雑なものはバグが多い。複雑だからコードを理解していない。
理解してないからバグが出る。当たり前の話。
292 :
2014/07/25(金) 23:31:13.15 ID:zPq/iOJh
そういう自己満足だけの身勝手な修正が一番たちが悪いんだよ
293 :
2014/07/25(金) 23:33:03.76 ID:oKdTZN9u
>>292
なんでですか?

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

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

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


あなたは、まったく筋違いの否定をしているのでは?
294 :
2014/07/25(金) 23:42:25.29 ID:zPq/iOJh
>>293
そもそも前提が間違ってる。
きれいなコードって何だ?お前のオナニーだろ?
コード修正したいなら、きちんと設計のレビューを受けてチームの了承得てからにしろ。
295 :
2014/07/26(土) 00:11:53.24 ID:NIQWGSzg
コードがスパゲティになってしまって、
簡単な機能追加ですら2週間もかかるようになってしまってた
(しかも、テストを繰り返しても正しさに自身が持てなかった)のが、
3週間ほど時間をかけてリファクタリングした結果
簡単な機能追加なら1時間もかからず行えるようになりました
296 :
2014/07/26(土) 01:29:58.80 ID:b/ARCjIF
今どきスパゲティコードなど、そうそうお目にかかるもんじゃない
297 :
デフォルトの名無しさん
2014/07/26(土) 02:28:53.78 ID:+7Kb6odc
リファクタリングするもしないも、そのソフトの特性や現場事情があんだから、
まずそういう情報がないとなんとも言えねーだろ。
共通して言えるのは独断で判断するなってことだよ。
298 :
2014/07/26(土) 08:38:26.34 ID:NIQWGSzg
>>296
ちゃんとリファクタリングするようになったからね
299 :
2014/07/26(土) 09:05:17.83 ID:EislOxX9
設計の手法が確立してきたからだろw
300 :
デフォルトの名無しさん
2014/07/26(土) 09:15:20.20 ID:HnYXSVS2
リファクタリングする前のコードを保存しておいて
リファクタリングしてテストに合格したら
前のコードを消去すれば安全だよ
301 :
2014/07/26(土) 09:33:49.93 ID:NIQWGSzg
>>300
マトモなバージョン管理システムとBTSは導入済み前提でしょうよ
でなきゃリファクタリングなんて無理
302 :
デフォルトの名無しさん
2014/07/26(土) 11:28:39.87 ID:lCiymgo1
>>288
神が降りてきて、わぁぁぁぁぁってプログラム書く手が動くような事あるだろ?
303 :
2014/07/26(土) 11:34:58.07 ID:EislOxX9
業務ではないなw
304 :
2014/07/26(土) 13:52:30.19 ID: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.33 ID:EislOxX9
クソコード書いて、次は誰かがもっといいコード書くだろうからそれマネしようとか思ってたら
俺のクソがプロジェクト中にコピペされて救いようがなくなってたことならある
306 :
2014/07/26(土) 23:32:58.38 ID:F6Vf17wA
>>305
それそれ、誰もが知ってるコピペパターンw

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

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

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

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

そういう場合でもコードはなるべくシンプルになるようにしなくちゃいけないのだが、
モノマネパターンの通り、なぜか同じ形を真似ようとする。
できないわけじゃないのに真似をする。何も考えてないのかねって思う。
307 :
2014/07/27(日) 02:21:16.13 ID:xgsJlmZ9
仕様書が別になってたらどんなに処理が似てても別にするなあ
308 :
2014/07/27(日) 09:42:53.89 ID:r3KMo0jq
似てる処理を共通化できないのは設計がきちんと出来てない証拠
仕樣的に別物とか関係ない
309 :
2014/07/27(日) 09:55:49.81 ID:xgsJlmZ9
いやあるよ。
だいたい仕様変更が入ったときって、仕様書の画面毎とかだかし、
テストも仕様書毎につくるから、共通化してもテストの工数あんま減らんし。
修正になった仕様書の枚数と、手をいれる工数が一致してるとすごく客に説明しやすい。

>似てる処理を共通化できないのは
断じて違う。「似てる処理」を共通化するんじゃない。部品を共通化するんだ。
このへん誤解してなんど泣いたことか。
おまえのその考え方はスパゲッティまっしぐら。
310 :
2014/07/27(日) 09:59:56.78 ID:EfhXqtXt
>>309
どんな考えでもいいけど何かしらの共通化がされてたら
> 修正になった仕様書の枚数と、手をいれる工数が一致
これは成立しないぞ
まず自分の矛盾に気付くのが先のようだ。
311 :
2014/07/27(日) 10:34:57.72 ID:xgsJlmZ9
>>310
青いのう
部品を共通化するって考え方が徹底してれば、だいたいの場合は一致するもんだ。

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

うん、これも共通化してるなら何でも同じとか言われそうだな
現実のブツ無しだと説明が難しいが…
312 :
2014/07/27(日) 10:58:40.58 ID:EfhXqtXt
>>311
説明が難しいのはお前が「部品」とかいうオレオレ言語使って自己満足してるからだ。
ワケの分からん独自理論開発するまえに基本をしっかり勉強しろ。
313 :
2014/07/27(日) 11:02:04.82 ID:M1h0x0Bb
>>311
甘いのう
残念ながら今時の設計者の中にはコードを全く書けないやつが少なからず居る
よって、共通化なんて幻想に過ぎぬわwww
314 :
2014/07/27(日) 11:19:32.95 ID:aZ1TYiI9
func1(){
a b c d
}

func0{
a b
}

func11(){
func0() c d
}

func12()
func0() e f
}
上のような共通化は似てる処理と部品どっちが主張しているんだ?
315 :
2014/07/27(日) 11:22:29.85 ID:xgsJlmZ9
>>312
独自理論じゃないよ!みんなそう言ってるよ!
お前こそ本読んで知った気になってるだけだろ!頭でっかちめ

確かに、だいたい初心者向けの本には同じ処理を共通化すべしとか適当に書いてあるから、
実際の経験がないと理解しづらい部分ではある。
316 :
2014/07/27(日) 13:06:38.84 ID:oB6jVO7Z
>>315
「部品」で意味してるのは何なんですか?
317 :
2014/07/27(日) 14:19:58.36 ID:xgsJlmZ9
>>316
ごめん。一般的じゃなかった。
「機能」って読み替えて。
318 :
デフォルトの名無しさん
2014/07/27(日) 14:22:31.05 ID:5m0dj4Xz
人間は細胞でできているだろ
プログラムも細胞で作れば上手くいく
俺の独自理論だけど
319 :
2014/07/27(日) 14:35:22.28 ID:b6NTPR2W
うだうだ言わずに 60兆個の細胞を持ってこい
320 :
2014/07/27(日) 15:03:56.50 ID:kK8gelhu
共通化するときの決まりの一つとして、
全く同じコードの時に共通化するのであって
似ているコードを共通化してはいけない。

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

引数で分岐しだすとアウトだな。
321 :
2014/07/27(日) 15:10:03.90 ID:oB6jVO7Z
>>317
あーなるほど
わざわざありがとうございます
322 :
2014/07/27(日) 18:36:01.67 ID:b6NTPR2W
経験的にforの内部、ifの内部は関数にまとめると都合よいことが多い
そして気が付くと xxhelper, xximpl, xxsub といった関数であふれるw
323 :
2014/07/27(日) 22:38:54.70 ID:j6qWMrth
>>320
似ている理由を吟味するのがリファクタリングだろ。
似ている理由を吟味した結果、同じことをちょっと違った実装しているだけと気付けば問題なく共通化できる。
324 :
2014/07/28(月) 00:24:14.35 ID:PUM3vemV
>>323
設計段階で、最初から同じものだと分かってるものでさえのちのち弊害出てくるのに。
後付けでコード眺めて似てるじゃんとか思っただけのもんがまともに共通化できるわけないだろうが
325 :
2014/07/28(月) 09:35:31.93 ID:DND3Jclf
それを吟味するってことだろ。JK
326 :
2014/07/28(月) 19:34:15.48 ID:dU5jf/g6
コードの字面で共通化とか言ってたらそら失敗するわ
327 :
2014/07/28(月) 22:31:59.96 ID:ZMdkhV+Q
共有化するには物事を抽象化するセンスが問われるから、
低能が共有化しようとして失敗するのは良く分かるよ

それに、言語によってはクロージャやメタプログラミングが無かったり
有っても扱い難かったりして、実現可能な抽象化が限られるケースもある
328 :
2014/07/28(月) 23:39:29.31 ID:PUM3vemV
クロージャwメタプログラミングw
どんだけ狭い視点で話してんだよ
それかなにか、お前は世界中で使われるライブラリの設計者かなにかか?w

お前のコードとか会社に出たら即ゴミ箱行きだよww
ただの帳票出力で得意げにtemplate使ってんじゃねえwwww後引き継ぐ奴の身になれ
死ね。くさかどああkjsdふぁj;fじゃ死ねええええ
329 :
2014/07/29(火) 00:32:02.60 ID:A/TMSH0w
トラウマだったのね。
330 :
2014/07/29(火) 09:33:14.47 ID:Rzs2MIMk
自分の経験上、>>328みたいにプログラミング言語の機能の話を
狭い視点とか言い出す奴って
コードをロクに書けないSEモドキに多くて、
そういう奴に限ってリファクタリングにも否定的なんだよね

コード読めないからリファクタリングの価値を実感出来ないのかな?
331 :
デフォルトの名無しさん
2014/07/29(火) 13:10:26.45 ID:DxicYUyC
夏休みの学生が妄想で書き込むスレ
332 :
2014/07/29(火) 18:26:00.62 ID:Wf2KiU9x
自分と同じドカタ仕事してる奴以外は
全て学生に見えてしまう様になったら病気です
333 :
2014/07/29(火) 20:26:27.73 ID:vPKzHxKl
自分の経験上、リファクタリングしたがる奴は例外なく低スキル。
334 :
2014/07/29(火) 20:36:44.73 ID:ahLU5tbJ
アホに効果を実感させるところまでが能力の内です
335 :
2014/07/29(火) 21:31:45.45 ID:X6c6OHYr
アホSEがExcel仕様書の罫線を二重罫線に書き換えて
仕事したつもりになってるのに比べたら
比較にならないレベルの価値があるよ > リファクタリング
336 :
デフォルトの名無しさん
2014/07/29(火) 21:41:52.70 ID:jt6qgrVo
2重罫線を大事にする客だって多いわ。
客はコードの中じゃなくて、資料とか見るんだわ。

リファクタリングなんかしたらね、
なんかちょっと挙動変わってるんだけど?
障害じゃないけど勝手に変えちゃ駄目でしょ。
うん?次からは言います?いや、そもそも動いてるもん変えなくていいよ
って話になる。

なんでもかんでもリファクタリングだのオブジェクト指向だの、
時と状況関係なしにやろうとするアホが多いんだよな。
337 :
2014/07/29(火) 22:05:08.74 ID:Lzz8ZlFD
工数改善の見通しが数字で説明できるならともかく
実感とかで勝手にリファクタされたらたまらんわw
338 :
2014/07/29(火) 22:24:39.47 ID:7mGq5kmY
受託開発やってるところと
自社サービスの開発やってるところは
何もかもが全然違うんだから、
分けて議論しないと平行線のまま
339 :
デフォルトの名無しさん
2014/07/29(火) 22:32:24.06 ID:jt6qgrVo
SEがどーのこーの言ってるんだから受託だろ
340 :
2014/07/29(火) 22:51:00.80 ID:X6c6OHYr
受託なんてドカタを人月で売って稼ぐビジネスモデルなんだから、

リファクタリングでコードを拡張しやすく保ち、
機能拡張を他社より速く行う事で競争優位に立つ

とか、そういうのは関係ないじゃん?


お前らマクドナルドのパートと大差無いんだから、
技術者の議論に入ってきちゃダメだよ
341 :
2014/07/29(火) 23:05:38.45 ID:Lzz8ZlFD
>>340
ほー。
具体的にどういう課題があってどんなリファクタして、プロジェクトがどの程度成果上げたのか具体的に説明してみ?

壊れたレコードみたいに本で読んだこと繰り返して、しかも理解が浅くて現実が見えてないっぽいから
底辺派遣てすぐばれるよw
342 :
2014/07/29(火) 23:07:53.67 ID:fZzOasD9
>>341
現実つーかレスの意味が見えてないのはお前のほうだな
343 :
2014/07/29(火) 23:56:17.33 ID:vPKzHxKl
何か高度な裏の意味があるらしい
344 :
2014/07/30(水) 00:19:39.30 ID:2joTlTTw
自社サービスで食っていけてるってだけで圧倒的な成果だろうな

労働集約型な受託開発なんて価格競争で擦り減るばかりで
エンジニアに何のメリットもないし、早く脱出すべきなんだけど
脱出するためのスキルが溜まらない負のスパイラル
345 :
2014/07/30(水) 09:05:15.28 ID:NitIOFnC
SEが設計してコーダがコード書くってスタイルと
リファクタリングは相性悪いだろうな
346 :
2014/07/30(水) 11:16:11.07 ID:l4R9UcQd
SEの設計が日本語プログラミングになってるからな。
日本語と一対一のコードでないとめんどくさいことになる。
347 :
2014/07/30(水) 18:54:49.24 ID:z3bvSX8e
>>346
それで食えないスパゲティの一丁上がりかw
348 :
2014/07/30(水) 20:26:49.42 ID:njRDxY7Y
リファクタリングは1にも2にも自分のためにやるものだ
デスマーチを充実したアフターファイブに変えたければやっとけw
349 :
2014/07/30(水) 21:00:14.66 ID:JOmnGzMa
>>346
その日本語プログラミングではBASICにも劣る
抽象化しか出来ないのが問題なんだよね
350 :
2014/07/30(水) 21:00:10.81 ID:O2fC1zxl
そしてリファクタスパイラルへ…
351 :
2014/07/30(水) 22:54:34.89 ID:xH5zP1F6
リファクタリング否定派は技術力に乏しく低脳という風潮

一理ある
352 :
2014/07/30(水) 23:20:51.69 ID:B3MDpURs
どう考えてもすぐリファクタする方が低脳だろw
リファクタしたがる奴の傾向として

・理解力の不足。
自分に理解できないものをすぐ諦めてクソ呼ばわりする。
他人の書いたコードの一貫したポリシーや目的を汲み取れないから、先人が用意してくれた便利なライブラリも使えない。
理解できないから規約も無視しがちで、彼の書いたところだけ作りがおかしい。

・謙虚さの不足。
相手を見下して、自分のほうがいいものが作れると根拠なく信じてる。
すでに用意されているものを再発明するだけならまだいいが、
しばしば完成されたフレームワークの重要な部分にクソを差し込んでめちゃくちゃにする。

・計画性の不足。
先の見通しが利かないから、行き当たりばったりでクソしか作れない。
リファクタも行き当たりばったりにやるから、クソが超臭うクソになるだけということになりがち。
挙句に自分で訳がわからなくなって、成果物を全部消したりする。

・客観性の不足
自分のやったことの成果を、客観的に見ることが出来ない。
リファクタしたことで、掛けた工数がどれくらいでペイしたとか、数字で物事を考えられない。
彼がリファクタするのは、単に楽しいから。本人は仕事してる気になってるが、周囲から見ると遊んでるだけ。

という感じ。
そもそも最初からちゃんと書く能力があったら、リファクタしたいと思うことは少ないはず。
353 :
2014/07/30(水) 23:55:14.83 ID:2joTlTTw
>>352
> ・理解力の不足。
> 自分に理解できないものをすぐ諦めてクソ呼ばわりする。
> 他人の書いたコードの一貫したポリシーや目的を汲み取れないから、先人が用意してくれた便利なライブラリも使えない。
> 理解できないから規約も無視しがちで、彼の書いたところだけ作りがおかしい。
>
> ・謙虚さの不足。
> 相手を見下して、自分のほうがいいものが作れると根拠なく信じてる。
> すでに用意されているものを再発明するだけならまだいいが、
> しばしば完成されたフレームワークの重要な部分にクソを差し込んでめちゃくちゃにする。

とりあえず、最初の二つだけで良いから
リファクタリングとの関係を論理的に説明してみ?
354 :
2014/07/31(木) 00:02:21.65 ID:Jagb4X9u
>>353
他人の書いたコードを書き換えたがるんだよ…
自分に理解できないからクソだ。という理屈で。

クソに感じるのは自分の能力が足りないせいだということに気づかない。
355 :
2014/07/31(木) 00:08:01.18 ID:jvFYVzT/
そんな奴、実際には見た事無いが
受託開発だとレベル低いから居るのかもしれんね
356 :
2014/07/31(木) 00:28:09.58 ID:1DTVAKx3
>>354
具体的にはどう書き換えられたの?

共通化できる処理を各所にバラバラに書き散らかしてたのを
シンプルにまとめられた挙句
「DRYも理解出来ないアホが開発に関わるとか意味が分からない」
って言われたとか?
357 :
2014/07/31(木) 00:49:44.01 ID:OYcKACC5
コードオナニストは、常にコード以外の観点が欠けているのが特徴。
いくら諭しても話が噛み合わず、日夜コードのブラッシュアップに励んでいる。
358 :
2014/07/31(木) 00:51:52.79 ID:Jagb4X9u
>>356
知らん。問答無用で差し戻したから。

散々テストしたはずなのに客先に持ってったら動きが変わってて
共通モジュールに手が入ってたんで何やったのか聞いたら「わかりにくかったんでリファクタしました。」
何年も動いた実績あるモジュールにそんな理由でいじんなアホか死ね

>「共通化できる処理を各所に(略」
うん。そうだな…だいたい君と同じぐらいの理解度の奴だったよ。
359 :
2014/07/31(木) 00:54:29.60 ID:jvFYVzT/
> 散々テストしたはずなのに客先に持ってったら動きが変わってて

それリファクタリングになってないから
リファクタリングじゃない話を使ってリファクタリング批判してどうすんだよ
360 :
2014/07/31(木) 01:01:10.62 ID:Jagb4X9u
>>359
別にリファクタは批判してないよ?
考えもなしにリファクタしたがる奴を批判してるんだ。
361 :
2014/07/31(木) 01:07:13.72 ID:jvFYVzT/
>>360
お前んところがレベル低くて、勝手にコードぶっ壊す馬鹿が居るってだけの
リファクタリングと関係ない話を一般論として語られても、
底辺は可哀想だなって感想しか持ち様が無いぞ
362 :
2014/07/31(木) 01:09:10.48 ID:OYcKACC5
>>359
お前はリファクタリングのつもりかもしれんが
完璧なテストが存在しない以上、挙動が変わる危険は常につきまとうんだよ。
363 :
2014/07/31(木) 01:15:43.10 ID:jvFYVzT/
完璧なテストとか言う以前に、
ろくに自動テストとか書いてないでしょ?

ていうか、レビューもまともに機能してない
(じゃなかったら>>358のケースなんてコードがマージされるはずない)
テストもマトモに書いてないじゃ、そりゃトラブルよ
364 :
2014/07/31(木) 01:21:33.19 ID:1DTVAKx3
Excelで書かれたチェックリスト片手に手動でテストして
「散々テストしたのに」って言ってそう
365 :
2014/07/31(木) 07:53:29.99 ID:RHNsF96S
>>336
挙動を変えるのはリファクタリングじゃなくて仕様変更だろ
366 :
2014/07/31(木) 21:56:38.46 ID:w9LroIYe
仕様変更でもバグ修正でもいいが、
コードを書き換えたら挙動が変わることがある。

つまり、機能追加もバグ修正もするなってことだ。
367 :
2014/07/31(木) 22:08:52.98 ID:t7+Ucdvo
ネストが揃ってないとか空行が多いとか
変数がはるか上で宣言されてるけど使ってるのは遥か下に固まってるとか
理解力以前に目が疲れるコードをどうにかしろって言ってるんだよ
368 :
デフォルトの名無しさん
2014/08/01(金) 18:46:58.63 ID:xnEk5c3C
変数定義の位置を移動したりスペースを除去したり
するのもリファクタリングなわけだが
369 :
2014/08/01(金) 19:22:03.81 ID:+GTzrZhA
失敗例をあげてリファクタリングは糞って言ってるの最高に滑稽。
井戸の王様を気取ってる蛙か
370 :
2014/08/01(金) 20:37:16.99 ID:zWTZP0nt
OO批判と同じ流れだな
371 :
2014/08/01(金) 20:43:59.51 ID:fzo9r37p
リファクタリングが糞なんじゃないよ
リファクタリングしたがる人が糞なんだよ
372 :
2014/08/01(金) 21:19:55.74 ID:7+EywXB6
>>371
ゴミみたいなコードばっか書いてっから
他人にリファクタリングされまくっちゃうんだろ
373 :
2014/08/01(金) 22:07:17.79 ID:2Z4Uf/Xj
新人はリファクタしたがっていかん
関数の共通化とかGenericsとかTemplateとか覚えたてのこと使いたがる

ちょっとしたクソが一晩したらそびえたつ巨大なクソに
374 :
2014/08/02(土) 01:12:27.41 ID:tvZxKsuR
技術レベルの低い人ってのは初心者に近くて
リファクタリングという技術用語を理解できないんだよ。

だからわかり易い言葉に置き換えるといい
リファクタリング=整理整頓・改善

こう言い換えれば、改善する必要があるんです。
整理整頓すると普段の仕事が捗るんです。ということになる

こう言い換えれば、反対する人はいなくなるよ。
375 :
2014/08/02(土) 01:27:17.11 ID:nhTOdUsW
生理整頓した状態を維持しながら仕事しろよw
個人レベルの話ならクソコードをフィックス前にに最低限他人が読めるようにするのなんて責務のうちだ

リファクタはどっちかというと組織再編といったほうがいい
課題と今後の見通しがあってはじめてやることで
376 :
2014/08/02(土) 02:10:54.57 ID:tvZxKsuR
>>375
その責務を果たさない奴が、
行き当たりばったりのコード書くんだよな。
そいつに限ってリファクタリングの意味を理解してないという。
もう技術者として終わってるとしか言いようが無いね。
377 :
2014/08/02(土) 08:46:20.40 ID:Mu2XuA5N
リファクタリング本を一回読んだとき何を感じるかだよな。
ああそうそう、こういう点で苦しくなってたんだ、って気付くか、
何一つピンとこずに何やってんのこの本?と思うか。
378 :
2014/08/02(土) 11:09:34.62 ID:nhTOdUsW
クソコードを普通のコードに直す作業をあんまりリファクタと呼びたくないw
379 :
2014/08/02(土) 11:27:29.15 ID:h5SZ209F
結合テストとかまで進んじゃったら無理だよね
380 :
2014/08/02(土) 11:55:25.68 ID:nhTOdUsW
リリースした後でバージョンアップのついでにやるもんだろ
381 :
2014/08/02(土) 11:59:50.68 ID:tvZxKsuR
ボーイスカウトの法則といって、
コードを修正するときは、修正する前よりも
綺麗にするもんです。

これが出来るのと出来ないのが、
初心者と中級者の境目。
もちろん、出来ないほうが初心者ね。
これが許されるのは新卒1年ぐらいなもん。
382 :
2014/08/02(土) 12:22:30.70 ID:DmU4GxTK
規模が小さいうちは手抜きで簡単なコードを書くだろ?
最初から拡張性とかそういうものを考えて作りこまない。

で、規模が大きくなってきた時に、将来性のことを
考慮して作り変えればいいんだが、
最初の手抜きのコードをそのままに、手抜きを真似して
同じようなコードを追加するやつどうにかならんかね。

規模に応じたコードの書き換えをしない。できない。
発想がない。そういうい奴がクソコードを量産するんだよ。
383 :
2014/08/02(土) 12:37:41.39 ID:Ydx1jnyI
権限のない末端PGが現場の手続き無視してユニットテストのないコードを
勝手に修正する、自称リファクタリングは非常に迷惑。

日本の受託開発の仕事ではリファクタリングなんてするべきではない。
384 :
2014/08/02(土) 12:42:59.05 ID:DmU4GxTK
>>383
ユニットテストが無いことが前提になってる時点で、
やっぱり、その程度の所が、リファクタリングを嫌ってるんだなとしか
思えないよ。残念だったね。君のところの技術不足を露呈しただけ。
えと、技術力不足であることを自覚してね?落ち込むところだよ。
385 :
2014/08/02(土) 13:29:01.01 ID:a3/R4SSz
最初から厳密に書けばいいんだよ
手抜きコピーが多いのは、そういうものかと思ってしまうからだ
自称上級者がスタートアップ書くことが多いが、手抜き繰り返して
しまいには自分自身が変な癖背負い込んでいくだろう
初期段階でよい方向に導くには、最初のやつががんばるしかない
386 :
2014/08/02(土) 13:37:36.15 ID:DmU4GxTK
人間誰しも、最初は初心者で
一年後には今よりも成長しているという
前提にたつと最初から完璧なコードを書くのは不可能

どんなに優れたコードを書いたとしても
一年後の自分はもっと優れたコードを書ける。
387 :
2014/08/02(土) 14:03:04.41 ID:nhTOdUsW
>>386
この程度の奴がリファクタしたがるんだよなあ…

リファクタってのはある設計から別の設計に軸足を移すことだ。
書き散らしたクソコードを書き直すのは、リリース前にやっておくべきそれ以前の問題なんだよ。

お前の末端の画面とか帳票とかは、誰も共通機能として使ってないから汚かろうがクソだろうが問題ないよ。
お前の自己満足のためにプロジェクトとめられてたまるか。
どんなクソでも、客の前にひりだしたクソはてめえのクソだ。受け入れて前に進め。
388 :
2014/08/02(土) 14:06:28.03 ID:nhTOdUsW
大体最初からある程度ちゃんとしたプログラムも書けないやつに
まともなユニットテスト作れるわけないだろうが。
389 :
2014/08/02(土) 14:26:29.65 ID:1FEiY+vP
理想だけど
組織には逆らえない
390 :
2014/08/02(土) 14:42:12.73 ID:wGpqnjMj
関数の中身やprivateな関数のインターフェースを修正するようなリファクタリングと、
ライブラリのpublicなインターフェースを変更するような
影響範囲の大きいリファクタリングの話が混じってる気がする

後者はそう簡単じゃないよ
影響範囲に入る全ての開発者と調整が付かない限り変更できない
(勝手に変更したら、ライブラリ使用者側から見たら仕様変更だからリファクタリングにならない)
391 :
2014/08/02(土) 14:44:44.99 ID:atIEditt
初心者にオススメなのは、派生開発でコードを読むときに、動作確認をテストで書くことかな。これはとっつきやすい。
『レガシーコード改善ガイド』では「仕様化テスト」のところ。
392 :
デフォルトの名無しさん
2014/08/02(土) 14:54:07.48 ID:1BrdY1ES
>>380
そんな意識の奴と仕事したくないわ
393 :
2014/08/02(土) 15:20:52.89 ID:DmU4GxTK
リファクタリングするなっていってる奴がいるけどさ、
時間が十分にあるという前提にたつと
とたんに何も言えなくなってしまう

それってリファクタリングがダメなのではなくて
時間がないという問題だから。

じゃあ、なんで時間が足りないんですか?
今までと同じやり方してるんじゃないですか?って
追い詰めると、泣き出しちゃうw
394 :
2014/08/02(土) 15:21:48.08 ID:DmU4GxTK
>>390
そういう場合は、旧関数の互換性を保ちながら
新しい関数を作ればいいんだよ。
395 :
デフォルトの名無しさん
2014/08/02(土) 15:32:36.71 ID:WtoScNjl
>>390
そういうことのないように依存性を無くすようにプログラミングする
プログラマの規律が無いだけ
396 :
2014/08/02(土) 17:35:26.06 ID:w2qydRR0
当たり前のことを当たり前に理解してそれを前提としている人と、
当たり前のことなのに全く理解しないでそれを前提とできない人とが会話しているようだ。
397 :
2014/08/02(土) 19:06:34.85 ID:jgRhK7n4
ウォーターフォールだったり、詳細設計書で日本語プログラミングしたりしてるとこと
リファクタリングは相性悪いよ
開発の全体を見直さないと、一部だけ優れた手法を取り入れようとしても
歪みが出て上手く行かないんだよね
398 :
2014/08/02(土) 19:30:03.16 ID:DmU4GxTK
うまくいかないんじゃなくて
難しいだけだろ?

それを実行する力が技術力なわけで。
399 :
2014/08/02(土) 19:41:02.16 ID:q1w4boEu
どうしても自分が書いたコードを書きなおしたい人がいるようだけど
そんなコードはいずれバグで書きなおされるんだから、あまり気にしない方が良い。
その情熱は悪くないけど、もっと前向きに使うべきだよ。
400 :
2014/08/02(土) 19:57:31.28 ID:DmU4GxTK
前向きって新しいコードを書くってこと?
残念だけど、開発ってのは既存のコードの修正がほとんどだよ。

新しい機能を追加するといっても
前よりも効率よく開発するために既存の部分を、
使いまわす(コピペじゃないからね!)するために
既存の部分を修正して使えるようにするんだから。
401 :
2014/08/02(土) 19:57:37.46 ID:FIwNTFpf
>>397みたいな事言ってると、拡張を繰り返すうちにコードが保守不能なカオスになって
もう無理だから全部捨てて作り直しだー、ってなるんだよ

でもSIerとしては、それが飯の種だから良いんだけどね
402 :
2014/08/02(土) 20:03:28.32 ID:DmU4GxTK
全部捨てて作り直しだーまで追い詰めるって馬鹿だと思う。
少しずつ変化させていくことができないからそうなるんだよね。
全部いっぺんに変えるなんて現実的じゃないんだから。

全部いっぺんに変えることは不可能。じゃあどうするか?
それに答えられないから、どんどん壊れていくんだよ。

まあ、少しづつ良くしていくことが出来るのも技術力なわけで。
それを頭でわかっているのと実行するのとは全然違うわけで、
その実行できる力ってのが技術力そのものなわけで。
403 :
2014/08/02(土) 20:19:36.36 ID:q1w4boEu
>>400
前向きってのは、コード書きの脳からデザイナーの脳に変われるように努力しろって事。
404 :
2014/08/02(土) 20:23:43.06 ID:DmU4GxTK
>>403
何に逃げてるのさ?

両方できるようになるというのなら正しい意見だが、
別のものに逃げたらだめだろ。

まるでペンもイラレもろくに使えない奴が
発想力とかいうのに逃げているのと同じ。

コードをまともに書けるようになった上でデザイナーになることはできる。
だけど、コードから逃げてもデザイナーにはなれない。
405 :
2014/08/02(土) 20:23:58.64 ID:J1UwFk0L
よくある設計とコーディングっていう役割分担からしてくるっとる。
プログラミングなんて、設計九割五分なのに。
実装なんざオマケのオマケ。

SEとプログラマ、とわけてプログラマがキーボード叩く役とか、きがくるっとる。
まぁ聡明なお前らの会社は違うだろうけどね。
406 :
2014/08/02(土) 20:28:21.78 ID:DmU4GxTK
「前向き」って言ってる奴が、
コードとデザインの両方を手に入れるじゃなくて、
コードから逃げてデザインを求めていて笑えるよ。
そういう奴は両方できない。
407 :
2014/08/02(土) 20:33:33.15 ID:a3/R4SSz
やっぱり自分でコード書かなきゃやってる気がしない
408 :
デフォルトの名無しさん
2014/08/03(日) 00:40:07.16 ID:ppjITjjs
もう最近ガチガチの詳細設計やるとこって殆ど無いだろ
コメント的仮想コードとかで詳細は終わらせちゃうところが多い
その方が柔軟だしな
409 :
2014/08/03(日) 00:45:38.31 ID:CSranqfK
一応UMLでシーケンス図とクラスとPublicメソッドだけはきっちり作ってるな
DBアクセスとかあたりまで
そっから先はprivateで実装して
アプリのフレームワークに依存しないメソッドとかクラスとかはプCommonフォルダに各自放り込んでもらう

で上手くいくと思ったけど
Commonがかなりカオスなことに
410 :
2014/08/03(日) 07:51:54.04 ID:KHwMExMo
>>408
あー、主に非技術者がやる作業だね。
411 :
2014/08/03(日) 07:57:18.76 ID:mU4IZymt
>>409
>Commonがかなりカオスなことに

kwsk
412 :
2014/08/03(日) 10:20:01.47 ID:1nxvzFtA
まるで業務系しか仕事がないかの勢いw
413 :
2014/08/03(日) 10:36:51.70 ID:CSranqfK
>>411
コードが酷いのは予想のうちだけど
あれだけ言ったのに、規約が守られずにアプリのフレームワークに依存が作られてる
最初あたりに誰かがやったせいで後続が真似して、手続きなんとなくまとめただけみたいな処理がいっぱい
関数の共通化もうまくいってなくて
例えば分かりやすいところでは文字列をバイト列に変換してパディングするって処理があるんだけど
SJisStringUtil.ToByte
DBCodeChanger.LeftPaddingByteArray
StringModel.BytesWithSpace
こんな感じでいっぱいできてる
挙句にsTanakaとかフォルダできてるしw
414 :
2014/08/03(日) 10:42:19.36 ID:KHwMExMo
まあありがちやねw

だから規約を作った人は
必ずコードレビューをしなくてはいけない。
415 :
2014/08/03(日) 20:06:25.42 ID:lk1xFWmM
>>953
糞設計、糞コード書くような人たちが
集まってコードレビューしてもなんの意味もない
しかもそういう人って声が大きいだけが取り柄みたいな人だろうし
416 :
デフォルトの名無しさん
2014/08/03(日) 21:25:01.28 ID:LWW935BO
ロングパスきっちり通せよw
417 :
2014/08/03(日) 23:57:33.38 ID:tNPEJw6R
A社に発注して作らせた大規模なソフトを、
B社に一時的にメンテナンスさせて、
今はC社に機能拡張させているとか言う例が実際にあるからなー

それぞれがそレなりにちゃんとした会社であっても、
開発者の継続性が0の場合、
中のソースがかなり混乱するのは仕方ないかもしれん。
418 :
デフォルトの名無しさん
2014/08/04(月) 22:06:42.37 ID:w1xJJUBp
リファクタリングはアートですよ。
アートは人間が生み出すものではありません。
ある日、天から降りてくるんです。
この感覚がわからない人は、アートしたことが無いんです。
つまり、リファクタリングもわからないってことです。
419 :
2014/08/04(月) 22:17:15.14 ID:p5AMhKr8
わかる、わかるぜ〜
ソースコードがある書き方になりたがってねだってくるんだぜ〜
俺はそのとおりに書き写してるだけなんだぜ〜
420 :
デフォルトの名無しさん
2014/08/04(月) 22:19:31.15 ID:w1xJJUBp
やべえ。
適当ぶっこいてたらマジキチ召喚しちまった。
ちょっと反省。
421 :
2014/08/04(月) 22:54:50.48 ID:O7gnQe0p
自作自演乙
422 :
2014/08/27(水) 12:13:22.10 ID:RluTUsi0
他人のコードだと思って、何の前情報もない状態でコードを読み
そこから読み取れる情報だけで、「なんで?」って思う実装を減らしていくのがリファクタリング

もちろん、処理の効率とかをよくする場合もあるけど、
どっちかというと、そういうのよりも第三者が見て読みやすいコードである状態を保つ事のほうが重要
(リファクタリングで大幅に処理コストが改善できるような糞実装が最初にされてることは稀)

ただ、リファクタリングをできるレベルに達していない職場も少なくない
とくに業務系や人売りで奴隷を集めた職場とかは、大抵メンバーのスキルが足りてなさすぎて無理
っていうか設計(という名のゴミファイル作成)段階からそびえ立つうんこを作っていってるから、実装時は既に手遅れ
423 :
2014/09/04(木) 15:14:28.47 ID:NCM4vLJB
リファクタリングの誤用
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism

リファクタリングの境界線
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringBoundary
424 :
デフォルトの名無しさん
2014/09/13(土) 02:08:52.13 ID:Bjr83Kqx
ボキもリファクタリングして欲しいです
https://twitter.com/y_konogi/status/510266774290694144/photo/1
425 :
2014/09/13(土) 02:46:33.71 ID:99VHFg4q
ちんこの振る舞いを保持したまま変化させる、もちろん性的な意味で。
426 :
2014/09/13(土) 03:35:58.05 ID: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.80 ID:9aicrkfD
あれもこれも取り入れた「オブジェクト指向」とまるっきり同じパターンだな
どんどん曖昧な意味になりそう
428 :
2014/09/13(土) 14:14:43.12 ID:Fgrmdz5F
すべてリファクタリングの結果発生する作業だろ。
まったく理解できていないな。まさに本末転倒
429 :
デフォルトの名無しさん
2014/09/13(土) 16:14:30.25 ID:WJGPx/6o
要件を仕様にまとめるのもリファクタリングですか?
430 :
2014/09/13(土) 20:28:39.39 ID:Y1nBtaE7
>>429
リファクタリングの一部ではあるな
431 :
2014/09/13(土) 20:33:35.66 ID:zttb1Mfl
OpenSSLがリファクタリングされまくっているな
432 :
2014/09/14(日) 00:35:49.32 ID:a/rqPd2y
>>429
違う

> リファクタリング中に2,3日システムが動かなくなっちゃってーなどと言ってる奴がいたら、
> んなもんリファクタリングじゃあなーいと言ってやれ。 ドキュメントをリファクタリングしちゃるとか言ってる奴、
> それもリファクタリングじゃねーぞコラ。 そういうのは、リストラクチャリング(再構築)というのだッ
433 :
デフォルトの名無しさん
2014/09/14(日) 02:43:07.06 ID:XHTMIvTT
客の要件はそのままプログラムにできるけど、
それじゃあ最適化できてないから
外面の挙動は変わらない範囲で最適化を行う。
コードの実体だけがリファクタリングの対象じゃないだろ。
434 :
2014/09/14(日) 03:54:19.00 ID:a/rqPd2y
>>433
それこそがリファクタリングの誤用で
リファクタリングではないと述べられていること。
435 :
2014/09/14(日) 10:24:07.39 ID:NZ+I8Nx6
最適化じゃないんだよ
最適化なんかできるわけねーだろってのが大前提なんだよ
436 :
デフォルトの名無しさん
2014/09/14(日) 13:02:21.11 ID:bjSSfYoR
バグも含めて機能そのままで、構造だけ変える(良くするつもり)ができるっていうのが結構単純な
還元主義的な思い込みで、実際の構造物は両者は一体というか、都合良くできないと思うんだよね。

テスト駆動とかもそうだけど、この種のスローガンが胡散臭いのは、物作りの本質的な困難を直視
しないで、小手先の技法を当てはめれば解決みたいに喧伝しすぎるところにあるんじゃないかと思う。
437 :
2014/09/14(日) 14:21:12.62 ID:TJC+Xrrg
別に胡散臭いとは思わないが、真に受けちゃったバカが「リファクタリング最強!」とか言い出すのはかなりうざい。
438 :
2014/09/14(日) 15:42:46.67 ID:a/rqPd2y
>>436
> バグも含めて機能そのままで、構造だけ変える(良くするつもり)ができるっていうのが結構単純な
> 還元主義的な思い込みで、

できるよ。

というか、リファクタリングは構造を良くしましょう(終わり)じゃなくて、
構造を良くするのは当然の話しとして、機能をそのままにするためにはどうすればいいか?
って所が出発点で、

機能をそのままにするために、編み出された様々なテクニックが
リファクタリング手法なんだよ。

できないというのなら、リファクタリング手法(それには名前が付いている)
一つ一つに対して出来ない根拠を述べてみてよ。

君は単に、リファクタリングに手法があることを知らないで、
闇雲に自己流でなおそうとしてみて失敗しただけでしょう?
439 :
2014/09/14(日) 15:44:54.17 ID:a/rqPd2y
なんだ、自分で自白してるじゃんかw

> この種のスローガン

スローガンとしか認識していないw

リファクタリングは、数学的な証明と
なんらかわらないんだが。
440 :
2014/09/14(日) 18:12:37.41 ID:d9eejC+C
ダメなコードは直すことでよくできる
という公理が大前提
1000行もあるようなおバカ関数を数学的に定式化して改善するのは無意味なこと
見れば何をすべきかわかる
441 :
2014/09/14(日) 18:52:51.74 ID:a/rqPd2y
>>440
つまりどういうこと?
リファクタリングすればいいって話を
言葉を変えていってるだけだよね?
442 :
2014/09/14(日) 19:25:36.36 ID:3Rt2m2d6
リファクタリングを知らない人は、
リファクタリングを一気に直してしまおうと
思っているに違いない。

リファクタリングが問題が起きることがありえない
小さな修正の繰り返しであることをしらない。
443 :
2014/09/14(日) 19:30:47.61 ID:NZ+I8Nx6
デザパタ信者みたいなのが暴走して悪評を広めてるんだろう
444 :
2014/09/14(日) 19:32:04.00 ID:3Rt2m2d6
その悪評を鵜呑みにしているのが
頭悪いと言われる所以なわけで。

自分の頭で考えろよとw
445 :
2014/09/14(日) 21:08:34.07 ID:oiv3svus
リファクタリング
446 :
デフォルトの名無しさん
2014/09/15(月) 00:27:34.64 ID:irRiVyM3
流石に数学の定理と同等か言い過ぎだろ。
パターンと同じでさ、セオリーやメソッドじゃない、ちょっとしたコツの集積だろ

オブジェクト指向、CMMI、PMBOKとかと同じでさ、アメリカ人の教授とかはそういうのまとめて
自分が言い出しっぺになって、学会ごっこしたり、資格試験の元締めやろうとしたりするのが好きなんだよ。

そういう商売に乗せられているだけなのに、さも学術的な根拠があるものとして「勉強」したりするのが
偉いと思っている奴はどっかオツムが弱いとしか言いようがないw
447 :
2014/09/15(月) 00:37:25.87 ID:9UWhhSIJ
>>446
数学の定理じゃなくて、数学の証明だろ?

a + b = c を b = c - a
に置き換えるようなもの。

式の変形だよ。

リファクタリングのテクニックっていうのはどれも
この式の変形と同じようなもの。

一部の人が勘違いしているように、ぶっ壊して同じように作りなおすことじゃなくて、
項の移動のように、全く同じ結果になる変形をしているにすぎないんだよ。
448 :
2014/09/15(月) 00:39:47.71 ID:9UWhhSIJ
>>446
あと警告として、自分が知らないことを
勉強している奴は生意気だっていうのやめたほうがいいよ。
中学生かよ。あいつ勉強なんかしてるんだぜーってw
449 :
デフォルトの名無しさん
2014/09/15(月) 00:43:11.40 ID:irRiVyM3
何が「警告」だよ
笑わせるな
450 :
2014/09/15(月) 00:44:52.76 ID:9UWhhSIJ
いや、普通に恥ずかしいでしょ?

ガリ勉ガリ勉いって勉強しない悪ガキ。
自分が後で困るというのに。

警告してあげないといつまでたっても
気づかないよ。
451 :
デフォルトの名無しさん
2014/09/15(月) 01:15:03.90 ID:WaQuX0Y8
ぶっ壊して同じ結果が得られるように作り直すこととの違いを教えてください。
452 :
2014/09/15(月) 01:41:27.21 ID:j8xvklWY
イチから作り直したい病と
現実の範囲で出来る事だけやる工夫の違い
453 :
デフォルトの名無しさん
2014/09/15(月) 02:07:53.50 ID:WaQuX0Y8
機能やクラスを抽出するのだって破壊を伴うんじゃないの。
リスクが少ない範囲での変更もあれば、
時には大胆なリファクタリングもあると思うけど。
454 :
2014/09/15(月) 04:21:21.27 ID: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.33 ID:9UWhhSIJ
>>453が言ってる、
大胆なリファクタリングというのは、

これらの手法を使わずに
いきなり最終的な答えを
だそうとしていることでしょ?

それはリファクタリングじゃない。
456 :
2014/09/15(月) 04:24:53.24 ID:9UWhhSIJ
>>452も少し勘違いしているね。

リファクタリングを「ソースコードを綺麗にしましょう」ということを
英語で言ったものとしか認識していないようだ。

リファクタリングというのは、安全に変形できるという
手法を使って、いっぽずつ書き換えていくもの。

手法を使わない書き換えはリファクタリングじゃない。
457 :
2014/09/15(月) 10:57:57.36 ID:z+pQ6G77
>>456
それな
その手法の確立というか
その手法の念押しというか
そういう面も大きい
458 :
2014/09/15(月) 11:09:38.77 ID:pNNQiIbO
これがリファクタ信者の暴走か
459 :
2014/09/15(月) 11:28:39.31 ID:kUSteVkT
リファクタリングの「関数の抽出」をやったら
増えた関数呼び出し分の実行コストが無視出来なくて
仕様を満たさなくなってしまいました
460 :
2014/09/15(月) 11:46:22.25 ID:9UWhhSIJ
>>459
そしたら「関数のインライン化」という
リファクタリングをすれば
動作を変えることなく、仕様を満たせるようになるよ。

やっぱり問題が起きた時にやるのは
リファクタリングだね(笑)
461 :
2014/09/15(月) 11:49:22.77 ID:kUSteVkT
つまり途中で一回ぶっ壊して同じ結果が得られるように作り直すわけね
良いと思うよ
462 :
2014/09/15(月) 12:21:05.22 ID:NXR59SQz
リファクタリングがゲシュタルト崩壊しそうなスレだ。
463 :
2014/09/15(月) 12:43:17.41 ID:zrs0o34A
安全を過信しすぎだな
464 :
2014/09/15(月) 12:46:23.34 ID:9UWhhSIJ
>>461
一回ぶっ壊したらだめだろw
それではリファクタリングになっていない。

リファクタリングは壊さずに直すことであり
壊さないで直すための手法がまとめられている。
http://d.hatena.ne.jp/asakichy/20100607/1275877997
465 :
2014/09/15(月) 13:45:51.89 ID:kUSteVkT
>>464
>>459の操作で一回ぶっ壊れてるじゃん
少なくとも「関数の抽出」はリファクタリングの操作としてアトミックじゃない
466 :
2014/09/15(月) 15:20:24.10 ID:4lL49qVx
慌てずリファクタリングの公式に沿って変更すれば副作用は一切ない。
467 :
2014/09/15(月) 15:20:49.07 ID:9UWhhSIJ
>>465
> 少なくとも「関数の抽出」はリファクタリングの操作としてアトミックじゃない

アトミックだけど?

リファクタリング本を見ればしっかり書いてあるよ。
アトミックに作業する方法。

どうせあんたは関数を消して書きなおす(書き直してる間
元の関数がなくなってる状態)が起きるって思ってるんだろうけど。


ほんと、やり方をしらんのね。しらんから壊れるって言ってる。
わかりやすい。
468 :
2014/09/15(月) 15:21:50.80 ID:9UWhhSIJ
ちなみに、リファクタリングブラウザを使えばもっと簡単に行える。
もちろん、リファクタリング本にはそういうツールを使わないやり方も書いてある。
469 :
2014/09/15(月) 15:45:17.66 ID:wmpEGwKw
>>459>>460の間に一回壊れてるよね
470 :
2014/09/15(月) 15:51:22.11 ID:wmpEGwKw
>>467
手で書き直したとかじゃなくて、メソッドの抽出することで
仕様を満たさなくなるケースもあるって話だろう

その直後にインライン化したとしても、一旦仕様を満たさない状態になったのは事実
471 :
2014/09/15(月) 15:53:23.99 ID:KlWrYY91
まあ俺ぐらいリファクタリングに精通すると、最初からリファクタリング後の最終形になるように最初からコーディングできちゃうわけで、あえてリファクタリングを意識しなくていいわけなんだけどね。

中島敦の「名人伝」にでてくる「弓ってなに?」といった弓の名手のごとし。
472 :
2014/09/15(月) 15:55:47.97 ID:9UWhhSIJ
>>469
壊れてないよw
ばかなのかな?
人の話きかないよね。
473 :
2014/09/15(月) 15:57:45.71 ID:9UWhhSIJ
>>470
> 手で書き直したとかじゃなくて、メソッドの抽出することで
> 仕様を満たさなくなるケースもあるって話だろう

メソッドの抽出で仕様を満たさなくなることはありません。

> その直後にインライン化したとしても、一旦仕様を満たさない状態になったのは事実

あんたの言ってる「仕様」って関数呼び出し○ナノ秒以内で
あることっていう要件の話だよね?w
それは仕様ではない。
474 :
2014/09/15(月) 16:00:52.19 ID:9UWhhSIJ
>>471
それは過剰な設計になってるよ。

コードの規模に応じて、適切な設計というのは異なる。

コードに修正が入る、それがバグの修正でない限り
機能化拡張だろう。

機能拡張にともなって規模が増るというような時にリファクタリングをするんだ。
機能追加とリファクタリングはわけてやるものだから、
機能追加前、もしくは機能追加後にリファクタリングね。

最初から過剰な拡張性をもたせるのはよくない。
475 :
2014/09/15(月) 16:31:02.56 ID:9UWhhSIJ
今更ながら>>1が言っていたことって正しいんだなって思った。

ソースコードを綺麗に作りなおすのがリファクタリングだって
思っている奴が多いこと多いこと。
476 :
デフォルトの名無しさん
2014/09/15(月) 16:59:56.60 ID:WaQuX0Y8
ポリモーフィズム化するのは機能追加だアホ
477 :
2014/09/15(月) 17:07:57.72 ID:kUSteVkT
>>473
> あんたの言ってる「仕様」って関数呼び出し○ナノ秒以内で
> あることっていう要件の話だよね?w
> それは仕様ではない。

ループの中で繰り返し呼び出されたら馬鹿にならん差になることもある
仕様かどうかはケースバイケースだアホ
478 :
2014/09/15(月) 17:15:35.47 ID:kUSteVkT
リファクタリングの「関数のインライン化」をやったら
生成されるプログラムのバイナリサイズが許容範囲を超えて
仕様を満たさなくなってしまいました
479 :
2014/09/15(月) 17:17:53.19 ID:9UWhhSIJ
ID:kUSteVkT必死すぎだなw

”要件” を満たせないなら、
同じ仕様のまま 要件を満たすように
リファクタリングすればいいだろうw
480 :
2014/09/15(月) 17:32:28.60 ID:9UWhhSIJ
ID:kUSteVkTアは書いたコードが要件を満たせなかったら
そのコードを捨てて一から作り直んだろうかw
481 :
2014/09/15(月) 17:33:12.92 ID:kUSteVkT
一日中スレに張り付いてる ID:9UWhhSIJ に必死過ぎと言われてもな…

で、リファクタリングの手法に則って変換しても
要件を満たせないケースがあると認めるのか?
482 :
2014/09/15(月) 17:38:23.74 ID:9UWhhSIJ
やっと要件といったねw

リファクタリングは仕様を変えずに
コードをわかりやすい形に修正するものだから
要件を満たさなく慣れば、満たすように
リファクタリングすればいいってことで終わる話だ。

なんせリファクタリングしても仕様は変わらないのだから
仕様を変えずに要件を満たせるように作り変えられる。
483 :
2014/09/15(月) 17:44:05.42 ID:kUSteVkT
>>482
いや、俺は最後に修正をコミットするときに仕様を満たしてれば
途中で壊れてようがリファクタリングとしてOKって立場だから、それで良いよ

でも、お前はリファクタリングの手法に則ってれば
絶対に壊れることは無いっていう立場だろ?(>>454-456)
484 :
2014/09/15(月) 18:58:56.46 ID:j8xvklWY
絶対に壊れない奥義は秘中の秘で
師匠に皆伝を認められないと伝授してもらえないんだよ
485 :
2014/09/15(月) 19:33:35.36 ID:wbbrJGCJ
リファクタリングってどのタイミングでやる事を想定してるのかな
プロジェクトにそんな工程存在しないし
終わって凍結したコードを後から修正なんてしないでしょ
不具合とか新機能とか更改する案件が出てきて初めて
次のプロジェクトやりましょうってなるわけでしょ
そうなったとしてコードの機能追加や修正はあっても
このスレで言う仕様通りに動くものにわざわざ手をつけるなんてことするかな
486 :
2014/09/15(月) 19:40:39.59 ID:q3fGkS61
やりたい時がやるべき時なんだよ。
コードがクソだと思ったら何時でもそれがリファクタリングのタイミング。
487 :
2014/09/15(月) 19:58:17.80 ID:wbbrJGCJ
だからそんなタイミングなんて実際存在しないよねって話をしてるのに
488 :
2014/09/15(月) 20:46:42.81 ID:q3fGkS61
>>487
だからコードがクソだと思わなかったらやる必要ないんだって
489 :
2014/09/15(月) 21:25:15.72 ID:9UWhhSIJ
>>483
> いや、俺は最後に修正をコミットするときに仕様を満たしてれば
> 途中で壊れてようがリファクタリングとしてOKって立場だから、それで良いよ

リファクタリングの誤用
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism
> ……のだが、リファクタリングは、適切に使われてはいない。
> リファクタリング中に2,3日システムが動かなくなっちゃってーなどと言ってる奴がいたら、
> んなもんリファクタリングじゃあなーいと言ってやれ。 ドキュメントをリファクタリング
> しちゃるとか言ってる奴、 それもリファクタリングじゃねーぞコラ。 そういうのは、リストラクチャリング(再構築)というのだッ。

> リファクタリングはより具体的な技術のことで、 小さな「振る舞いを保持したままの変化」
> (リファクタリングと呼ばれている)から成り立っている。 システムをリファクタリングするときは、
> 数分以上、システムが壊れたままにしてはいけない。
490 :
2014/09/15(月) 21:31:41.31 ID:eEkAvSkz
>>486
>やりたい時がやるべき時なんだよ。

趣味だよなこういうのは
死ぬまでいじってろ
491 :
2014/09/15(月) 21:36:40.31 ID:9UWhhSIJ
>>490
趣味とは、汚くても動けばいい。と
客の前で言えないことを、こっそりやること。
492 :
2014/09/15(月) 22:30:57.87 ID:kUSteVkT
>>489
コミットするまでシステムはそのままなんだから(正確にはデプロイするまでだが)
完全にリファクタリングの定義に沿ってるよね
誤用してるのはお前だね
493 :
2014/09/15(月) 22:47:48.33 ID:W2xZfE+V
IDEのリファクタリングのメニューから選べる機械的にできる変換のみを
リファクタリングとする派閥があるんだよ
要件を満たすかではなく、機械的にできる事が重要なわけ

なお、これは底辺の馬鹿でも可能な「ドカタ・スタイル」として認知されてる
494 :
2014/09/15(月) 23:33:30.39 ID:jSabMZv+
>>492
これはひどい
バカというより迷惑
495 :
デフォルトの名無しさん
2014/09/16(火) 02:50:25.03 ID:BRRsQsEe
>>446
>オブジェクト指向、CMMI、PMBOKとかと同じでさ、アメリカ人の教授とかはそういうのまとめて
>自分が言い出しっぺになって、学会ごっこしたり、資格試験の元締めやろうとしたりするのが好きなんだよ。

リファクタリングって、資格試験制度や学会作ろうって動きがあるのかな?
パターンはなんかやってるところあるよね。
496 :
2014/09/16(火) 04:23:48.75 ID:1lKEIB+1
>>493
> IDEのリファクタリングのメニューから選べる機械的にできる変換のみを
> リファクタリングとする派閥があるんだよ

それは、リファクタリングをわかってない派閥であり、
無知なリファクタリング反対派となんらかわらないよ。

リファクタリング本を読んでいれば、
リファクタリングブラウザで行えるのは
リファクタリングのほんの一部だって知ってる。
497 :
2014/09/16(火) 12:38:21.05 ID:5ipzkeYr
リファクタラー内部抗争勃発
498 :
2014/09/16(火) 13:41:58.56 ID:UosJEOFn
リファクタリング前と後で同じテストが通ればOK派と、
リファクタリング中のどの時点でもテストが通らないとダメ派か。
499 :
デフォルトの名無しさん
2014/09/16(火) 19:13:39.64 ID:BRRsQsEe
リファクタリングのアトミックな単位は一文字削除
500 :
2014/09/16(火) 20:19:15.75 ID:c0zqQ2NF
>>1
リファクタリング自体が理想論。

つまりは、自分(以下A)と同等かそれ以上の腕の持ち主だけで人材が構成されている必要がある。ただし、これは自分視点。
しかし、この状態だと、A以上の腕の持ち主からAを見ると、Aは足手まといで汚いソースを作り上げる元凶。
上級者が、切磋琢磨していく状態なら良いが、上級者なんて1%もいない。99%の下手が次々と入ってきてクズソースを乱発。
腕の良い者達は、クズソースのリファクタ作業だけをやるハメに。
腕の良い者達だけでやっていれば、もっと早く開発ができるのに。しかしリファクタリングというとできるのは腕の良いものだけ。
よってクズの尻拭いを永久にやらされる上級者は、腐る。
そしておしまい。

リファクタ云々よりクズの徹底排除こそ最優先。
それがなされなければ、確実にクズソースの生成のほうが圧倒的に早い。
501 :
2014/09/16(火) 20:29:13.06 ID:c0zqQ2NF
3行で言うと

1%の有能な人間のリファクタリングの速度より
99%を占めるクズが作り出すクズソース量産スピードのほうが速い
だから、間に合わない。

ということだね。
502 :
2014/09/16(火) 21:19:30.50 ID:LXIAs8Mg
隠された4行目は

そして、1%の有能な人間はここにはいない。

か?
503 :
2014/09/16(火) 21:22:31.12 ID:1lKEIB+1
>>500
何が理想論なのかと思えば、
あんたの会社では無理って話なんだね。
504 :
2014/09/17(水) 00:27:57.13 ID:5OnPRq9A
また俺の会社すげえ自慢か
ITドカタのクセに生意気だ
505 :
デフォルトの名無しさん
2014/09/17(水) 01:33:42.78 ID:ZHv/uS3X
なんで力量がはっきりしてない人のソースレビューもせずに、
終わってからリファクタリングしてるの。クズじゃないの。
自分のコード書くだけが仕事じゃねーんだぞ。
506 :
2014/09/17(水) 01:41:26.78 ID:bT3aRSk/
リファクタリングが工程になのであればら、彼の知っている開発手法はそもそもTDDに向いてないので、その前提でTDDの話なんてできないと思うのです

世の中にはCIって概念があるのを知らないのだろうか

まぁ土方なら仕方ないと思いますが
507 :
2014/09/17(水) 01:43:13.03 ID:bT3aRSk/
TDDすれと間違えたし、誤字りまくった
てへぺろ
508 :
2014/09/17(水) 02:10:48.96 ID:B5vXdL5P
リバースエンジニアリングが難しいのと同じで、
自分でソースを書くよりも、
他人が書いたソースを読むのは、ずっと難しい

仕様書→ソースは、簡単
ソース→仕様書は、難しい
509 :
2014/09/17(水) 04:16:14.76 ID:YtdMSBzp
>>504
> また俺の会社すげえ自慢か

俺の会社だせえ自慢じゃね?w
510 :
2014/09/17(水) 04:18:50.43 ID:YtdMSBzp
>>508
> 他人が書いたソースを読むのは、ずっと難しい

最近これ違うと思うようになってきた。

他人が書いたソースが読みにくいと思ったら
そのソースは他人が読むように書かれていない
自分よがりなソースコードなんだよ。

読む方に非があるんじゃなくて、書くほうが悪い
511 :
2014/09/17(水) 07:16:49.41 ID:5OnPRq9A
自分よがりなんて書いてる奴は、他人に読みやすい文章になるような注意力に欠けた
独りよがりの文章しか書けないんだろうな。
512 :
デフォルトの名無しさん
2014/09/17(水) 12:15:48.80 ID:Kfgv1MV9
>>511
うわあ読解力パネェ
513 :
2014/09/17(水) 21:24:55.43 ID:YtdMSBzp
>>511
> 独りよがりの文章しか書けないんだろうな。
独りよがりって、自分よがりと同じ意味じゃね?
514 :
2014/09/17(水) 23:24:58.57 ID:IUDVFBKE
君達は本当に頭が悪いんだな
515 :
2014/09/18(木) 00:20:18.22 ID: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.94 ID:ot8C9XJ5
>>500
まぁほぼ同意だな
517 :
2014/09/18(木) 20:26:58.62 ID:spGOayPR
>>516
自作自演しなくていいよ。
そんなコメント普通しないからw
518 :
2014/09/18(木) 22:19:08.95 ID:+GRlEEjB
要求仕様の変更に追随するために設計を変えていくのがリファクタだ

撒き散らしたクソコード直すのはリファクタとは言わん
テストの前に個々人レベルでやる仕事だ
519 :
2014/09/18(木) 22:31:11.52 ID:Lc9LBSGA
他人が作ったものをメンテする時は
まず他人にやらせろってこと?
520 :
2014/09/18(木) 23:29:47.48 ID:i6De8Pgm
クソコード直すのがリファクタリングでいいと思うお
521 :
2014/09/18(木) 23:52:12.25 ID:CfthWkvp
結局言葉遊びの域を出なかったね
522 :
2014/09/18(木) 23:53:02.19 ID:LNiMu1bm
つーかリファクタリングとか言いにくいから修正でいいじゃん
523 :
2014/09/19(金) 00:33:41.85 ID: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.70 ID:J2pxYtIB
>>500に対して>>503の返しするということは、>>500の話が論が正しいことを>>503が認めているということ。

つまるところ、会社の構成員の実力によって不可能になるということ。
をあんたの会社では〜。の一文で認めている。

ゆえにその切り返しをするなら、リファクタリングは議論する価値がないということ
525 :
2014/09/19(金) 17:51:51.67 ID:VKWv7B4z
ちょっと何言ってるのかわかりませんわ
526 :
2014/09/19(金) 18:08:18.14 ID:J2pxYtIB
誰でもできることでないなら、実現は夢物語ということだ
527 :
2014/09/19(金) 18:36:04.63 ID:iHgvKusj
工程を確保して
下がやりたいと言ったら邪魔するなというだけの話かもしれない
528 :
2014/09/19(金) 18:47:45.84 ID:5Sq7tp9D
>>524
行き詰まるところ先人達が考えて考えた結果

 新言語の開発

にしか答えがないんだよなww
どんな素人でも言語のルールには逆らえない。つまり従わざるを得ない。
理論だけで劇的な変化があったのなんて

GOTOレス

だけだろ。

わかりやすくステップ数で言うけどjavaで10ステップで組まれていてごちゃごちゃなプログラムがある。
仕様変更するのに1万ステップの変更が必要。これを、新言語おまんこ女学院言語で開発すると、

main()
おまんちょ()

って書くだけで同じ機能が実現され、

仕様変更には

use ここか?ここがええんか?
main
おまんちょ(伝説の第49手目(3箇所、同時、左手だけちょうどいい微速))

って直せば実現できる言語が生まれれば、これ以上の可読性の向上はないわけで。
馬鹿でも簡単に、馬鹿でも可読性が高く、馬鹿でもスピーディーに・・・・を求めて新言語というのは生まれている
529 :
2014/09/19(金) 18:48:57.11 ID:5Sq7tp9D
>javaで10ステップ

>javaで10万ステップ
に訂正
530 :
2014/09/19(金) 19:42:02.22 ID:97jwqaFX
>>485
パッケージ製品のメジャーバージョンアップとか?
一般的なIT土方の工事現場にはまず縁ないわな
531 :
2014/09/19(金) 20:44:14.36 ID:/lOvQPWO
リファクタリングしない人は
修正する時、テストしないの?

テストするならリファクタリングしても
問題ないよね。
532 :
2014/09/19(金) 20:59:36.15 ID:6gllmAz9
全部埋めてやったぞ

<<リファクタリングとは>>
Q 何時やるの? A やりたい時。糞コードを見つけたら。今でしょ
Q 具体的には(工程では)いつ? A アジャイルですから。工程て何?
Q やる必要あるの? A やらなきゃバグでるよ?いつか破綻するよ?
Q 誰がやるの?A 自称上級者
Q 上級者の定義は?A 糞コードを発見する嗅覚を持つこと
Q その上級者には何かメリットが?A コードが綺麗な方が気持ちいいだろ
Q リファクタリングってお金もらえるの?A ボランティア
Q どういう効果が期待できるの? A 将来的なリスクを回避する、または逆にリスクを抱える
533 :
2014/09/19(金) 21:28:04.06 ID:/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.29 ID:Xfkvubm0
当然お金はもらえるってなんだよワロタ
535 :
2014/09/19(金) 22:04:08.26 ID:GUgRmWP+
>>534
たとえばさ、誤字脱字、これはあっても読めれば別に問題ないんだよ。
でも見つけたら直すだろう?

そうやって誤字脱字の見直し、修正が例え1時間で終わったとしても
業務である以上、それは給料に変わるんだよ。
536 :
2014/09/19(金) 22:35:47.59 ID:6gllmAz9
問題ないのに直すのは明らかに無駄な労力だろ
リファクタリングてそういう事なのか?
537 :
2014/09/20(土) 00:28:50.80 ID:zqGI0i/Q
そこらに地雷が埋まってても踏まなきゃ平気なんだよ
538 :
2014/09/20(土) 00:35:33.60 ID:BGuuw2+W
>>531
そもそもテストは各工程に含まれてるよね?
一度コードに手を付けたらリファクタリングだろうが何だろうがテストはやり直しだよ
工程をこなしてる間つまりリリースし終わって暇にでもならないと
リファクタリングなんか入り込む余地なんて無いぞ
要するに無駄ってことじゃないの
539 :
2014/09/20(土) 01:43:02.74 ID:b8OT/FfJ
>>536
「ソースコードを読むのに時間が掛かる」は
一番重要な問題だよ。

それが開発工数の大半を占めているんだから
540 :
2014/09/20(土) 10:04:40.32 ID:zqGI0i/Q
まあ理論的に完璧なリファクタリング手法を使っても
無関係であるはずの部分でコンパイラやOSのバグを踏んだらそれまでだから
実テストにやたら工数のかかってたらその後はさわれないだろうね
541 :
2014/09/20(土) 10:58:44.27 ID:b8OT/FfJ
テストやりました。バグが見つかりました。

ソースコードが汚くて、コードの意味がわかりません。
ソースコードが汚くて、バグの原因がわかりません。
あちこちにコピペされてて、バグの修正が大変です。
バグを修正したら、別のバグが発生しました。
バグを修正しましたが、処理が複数のモジュールに
分散していたので多くの再テストが必要です。


こういうのを解決するのがリファクタリング。
542 :
2014/09/20(土) 11:27:24.57 ID:41dsRCcO
違うね。

> テストやりました。バグが見つかりました。
> (以下略)

それはデバッグや。
543 :
2014/09/20(土) 11:43:01.81 ID:b8OT/FfJ
>>542
いや、それは前置きだから。

リファクタリングが解決するのは、
デバッグまでの過程で発生する問題。

同じデバッグという目的であっても、
その目的を達成するまでの時間は違うんだよ。
544 :
2014/09/20(土) 11:48:06.25 ID:zub5QpR2
ちょっと意味が分からない
545 :
デフォルトの名無しさん
2014/09/20(土) 12:22:36.52 ID:McF0jAPW
開発段階ですでにスケジュールオーバーしてる現場だらけなのに机上の空論w
新言語開発しろw
546 :
2014/09/20(土) 13:18:35.72 ID:b8OT/FfJ
>>544
意味がわからないレベルの人っているんだよねw
547 :
2014/09/20(土) 14:46:45.86 ID:mG0BaSkX
テストってコードを書いた本人がやるべき?
548 :
2014/09/20(土) 15:02:25.23 ID:uiyrzvHx
リファクタリングすら必要ないほどの腕のいい奴を最初から揃えれば良くね?
というのと同じくらいリファクタリング理論は破綻してる
549 :
2014/09/20(土) 15:33:26.65 ID:uiyrzvHx
他人のソースコードの解読は新規作成より時間がかかるケースが多々。
仕様がわかってるなら、そんなチェックをお願いしないといけない奴のソースレビューをするより、最初から自分でやったほうが早いし確実
つまり、リファクタリングの行き着く先は、無脳者を開発に入れなければ良いに行き着く。
少数精鋭方式。
550 :
2014/09/20(土) 15:48:28.37 ID:Jdjsg9Fk
>>548-549
一理あるが理想論
だから現実解としてリファクタリングが出てきたんじゃないのか?
551 :
2014/09/20(土) 16:04:59.48 ID:b8OT/FfJ
仕様変更っていうのは避けられないものだし、
機能追加や新しく出来た○○に対応するとか
どうしても変化は避けられないわけで
その変化にたいしてコードも変化させていかないといけないんだよ。

それにさ、人っていうのは成長するのは当たり前なのだから、
一年前の自分より、もっと優れたものを書けるようになっているはず。

一年後はさらに優れたものを書けるようになるはずだが、
それは今をきちんとやっていてできること。
過去の自分の真似ばかりしていても、成長はできないよ。
552 :
2014/09/20(土) 16:20:19.19 ID:gqfYZyci
何を意味の分からん事を
と思ったら、またお前かw
553 :
2014/09/20(土) 18:11:49.33 ID:b8OT/FfJ
>>552
言い返したいことがあるのなら
なにか言い返していいんだぜ
554 :
2014/09/20(土) 20:30:21.92 ID:lV8t6mfn
>>550
でもgotoレスと違って誰も実践しないだろ?
そういうことだ。
誰が好き好んで人の尻拭いをやるというのだ
555 :
2014/09/20(土) 20:40:59.03 ID:Pz5VxQ8p
リファクタリングは有能が無能の尻を拭く作業ではなく自分の尻を拭く作業だ

最初は速度など無視してとりあえず動くように作る
動いたら次に速く動くようにする
速く動いたらそれを読みやすく整える
読みやすくなったら今度は新機能を楽々追加する

これで立派なリファクタリングだ
556 :
2014/09/20(土) 21:06:59.81 ID:K48fRfz5
速く動くようにするのは一番後でいいだろ
557 :
2014/09/20(土) 21:21:43.45 ID:npmlG4Eq
>>556
ボトルネックが出来て、そこを解決すれば全体に速度が上がるようなものなら
後からでもどうにかなるが、全体的に微妙に遅い、微妙にリソース食っている、
それで全体的に遅くなってるだと後からじゃどうにもならない。
558 :
2014/09/20(土) 21:27:33.19 ID:lV8t6mfn
>>555
実際誰もやっていない
それが、この理論の決定的な答え
誰もやらない=やって評価されるどころか、失敗した場合の責任を問われるだけ
メリット一切無い
559 :
2014/09/20(土) 21:36:13.07 ID:lV8t6mfn
>>555
そもそも、そんなものはリファクタリングではない

リファクタリングは「現時点『運用中』の動いているシステムプログラム」に勝手に手を加えること。
「まがいなりにも動いているシステムのプログラムを勝手にいじるな」
というのが世界の常識。でこの常識を変えようとした思想がリファクタリング。
ただ、結局は、誰もやらんってこと。

理由の大半は「仕様がわからん」ということ。
560 :
2014/09/20(土) 21:44:36.36 ID:6heECCBq
エクストリームプログラミングから全否定かよ。
カオスだな。
561 :
デフォルトの名無しさん
2014/09/20(土) 21:54:03.46 ID:UNVZl8tG
バグを仕込んでしまう可能性があるのが致命的
あとは評価制度の問題だな
長期的に絶対メリットはあるんだがそんなん誰も見ちゃいねえし
562 :
2014/09/20(土) 22:00:15.71 ID:Pz5VxQ8p
他人の尻を拭くハメになったとき、リファクタリングが可能である唯一の条件は、
引継ぎ時点でリファクタリングされているソースコードであること、だ
そうでなかったらご愁傷様あきらめた方がいい
563 :
2014/09/20(土) 22:07:58.53 ID:fFGu/96N
>>559
> リファクタリングは「現時点『運用中』の動いているシステムプログラム」に勝手に手を加えること。

なんでウソつくの?

本当と言い返せるものなら言い返していいんだぜ?w
ただし、そんなことをしたら、ソースを要求するので
準備しておくこと。
564 :
2014/09/20(土) 22:53:25.35 ID:6heECCBq
恐怖駆動開発だな。
http://www.hanselman.com/blog/FearDrivenDevelopmentFDD.aspx

レガシーコードでテストが無い and/or コードに対する理解が無い

エンバグ、ビルドを壊すことへの恐怖
565 :
2014/09/20(土) 23:06:54.25 ID:K48fRfz5
>>557
新しいマシン買えばいいだけじゃないか
開発費とハードウェア費用どっちが高くつくと思ってるんだ
566 :
2014/09/21(日) 01:19:15.97 ID:H7xT3+nz
りファクタリングって言うのは、オブジェクト指向の言語(これが大前提)で、
開発段階にあって、試作品が第一段階で問題なく動いて、
あとは性能やコードの見直しやカイゼンだよねって段階で設計へフィードバックするプロセスですよ。
その後に顧客側のチェックと納品ですよね。

運用中のシステムに手を入れるという話では無いですよ。
カイゼンを全否定ならトヨタはどうなるんでしょうか?
567 :
デフォルトの名無しさん
2014/09/21(日) 01:26:54.31 ID:UIOIQYIj
一度客に納入してさあ、次に改修の仕事がきたときにリファクタリングしていたから工数が減っていたとしてもなんのメリットもないんだよな。むしろ工数が少なきゃ金が取れない。リファクタリングした分取ったら水増し請求だ。

機能やバグについて同等で、メンテしやすさだけ向上させる工程なんて日本の一般的な開発ではインセンティブゼロだよ。趣味ならともかくプロの仕事なら。

最初からリファクタリングの作業も込みで工数見積もりなり、費用請求しろ、ってそんな見積もり見て納得する客いるわけないじゃん。最初から手直しいらない納品物にして下さい、と言われてオチ。

出来上がってテスト済みのソースをあれこれいじるなんてお遊びが入り込む余地はない。
568 :
2014/09/21(日) 01:42:02.59 ID:H7xT3+nz
それと、テストという概念は個人がスクリプトやツール類を書く場合には絶対に生まれてこない発想で、
多人数で、複数の技能レベルの人が、仕様書をガイドに組織的に開発に関わる条件下で必然的に生じる仕事上の手続き。

個人がコード書く場合は、ソースコード全体、アルゴリズム、関数やクラスを全て把握しているので
テストコードをいちいち書く必要がない。だからデバックという手順はあっても、関数やクラスのテストコードを
いちいち書くという発想にはならない。コード修正も容易、エラーが発生してもその場で即対応できる個人レベルの作業としては正しい。

組織で開発する部門では他人が必要なコードを仕様化した関数やクラスの動作条件を定めているから、
それを大前提としてモジュール動作をテストする必要がある。一見して馬鹿げている行為に思えるのは、
アルゴリズムを提示せずトップダウン的に関数のIN/OUTのみで仕様を提示するためにモジュールのテストが必須になる。
チェックデータの側面についていえば情報管理上テストデータが必ず必須になる。それは本物と試験用のデータが違うということ。

テストコードは本人が書くと、世界は如何にばかげた行為に時間を費やしているのかと思うだけだが、
本来は書く側は最終コードが動作すると確認した上で、2重チェックとして仕様を作成した側がテストするためのコードなり手段を作るべきだな。
人が居ないというなら、テストコード書くのでなく、統合テスト的に動作チェックすべき。
569 :
2014/09/21(日) 01:52:41.82 ID:H7xT3+nz
リファクタリングは工数水増しの手段ではない。

保守とは違うので、日本の開発やってる業界のインセンティブなど関係がない。
リファクタリングとは関係がないな。

見積もりの段階でリファクタリングなどの話は出てこない。
手直しが要るといって費用請求している段階で、それはリファクタリングの問題ではなく
失敗したプロジェクトや案件だということだろう。それを誤魔化す為に誰かが嘘として
リファクタリングと言ってるだけだろう。
570 :
2014/09/21(日) 02:21:17.93 ID:H7xT3+nz
もし>>567が客側の意見であれば、失敗したプロジェクトや案件とは縁を切って
再出発したほうが開発側も、客側も気持ち的にはしあわせになれますよ。
571 :
2014/09/21(日) 06:26:59.02 ID: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.53 ID:4aXz2u5s
>>566
>りファクタリングって言うのは、オブジェクト指向の言語(これが大前提)

は?wwwwwwwwwwwwwwwwwwww
オブジェクト指向とそうではない言語での違いを説明しろよ
オブジェクト指向という言葉になんか宗教的妄信でもしてるのか?
573 :
2014/09/21(日) 09:08:44.80 ID:aP8Aq0OA
必要なのはコードのリファクタリングではなく
チームメンバのリファクタリングである
574 :
2014/09/21(日) 09:29:51.06 ID:48QWsy10
言い換えると、ソースコードをリファクタリング出来るように
チームメンバーの技術力を高めることである。
575 :
2014/09/21(日) 09:47:59.75 ID:dzDyx0VV
> チームメンバのリファクタリングである
リファクタリングて振舞いを変えてはいかんのでは?
576 :
2014/09/21(日) 12:25:58.75 ID:MCI/5nTd
例えばバグが多く、しかも非常にメンテしにくい糞コードがあったとする
この場合
1. バグを含んだままリファクタリングして、その後バグを直す
2. 先にバグを直して正しいテストを通る様にしてから、リファクタリングに着手する
どっち?
577 :
2014/09/21(日) 12:33:35.65 ID:48QWsy10
>>576
原則としては2番

ただし、今既に十分なテストがあるのなら、
リファクタリングしてもよい。

ようするに「バグが有ることに気づいていなかった」と考える。

バグが有るといえども、その状態で使われていたのであれば、
問題ない範囲(把握している範囲)で使われていたわけで、
使われていた部分の動きが変わっていなければ何も問題ない。

適切に動いていないバグの部分の動きが変わった所で
誰も困らない。そもそもバグは仕様ではないのだから。
578 :
デフォルトの名無しさん
2014/09/21(日) 13:51:42.60 ID:C0Gh49Ld
>>576
2. 一択。
1. は死亡フラグ。
579 :
2014/09/21(日) 15:34:48.90 ID:4aXz2u5s
ホント現実をみてないな
クソコードの影にクソ仕様書あり

仕様が網羅されていないクソ仕様書、そしてあってるのかあってないのかもわからんクソソース
そして、仕様を完全把握しているものは不在(いない)

コードを読みやすくする?直す?どーやってなおすんだよ正しい仕様不明なのに
手を入れなければ責任問題は自分にはかからない
正式に仕事として認可されるまでは、さわらずほっとく。こんなのが大量なんだ現実は

まともな仕様書を作るやつは、まともなプログラムも書いている。でもそれは修正等々なんて必要のないソース

リファクタリングの対象となるソースは、前者のクソコード、クソ仕様書のほうだ。正解が不明なのにどうやって直すんだ
580 :
2014/09/21(日) 16:39:44.45 ID:48QWsy10
>>579
具体的に、クソコードになってしまう
クソ仕様の例を言ってみて。
思いつかないんだよね。
581 :
2014/09/21(日) 16:40:37.43 ID:48QWsy10
> コードを読みやすくする?直す?どーやってなおすんだよ正しい仕様不明なのに

それは、正しい仕様がなければ、
現在のコードの動きを仕様と考えればいいだけ。
582 :
2014/09/21(日) 16:53:43.27 ID:4aXz2u5s
>>581
クソソース1万ステップもよみとーない
句読点のない文章みたいに処理の区切りがまったくないような文体で書かれたソースなんぞ誰が手をつけるか
583 :
2014/09/21(日) 16:54:11.17 ID:Ep6XnQTS
開発手法が根本からおかしい
リファクタリング以前の問題
584 :
2014/09/21(日) 16:55:08.58 ID:4aXz2u5s
>>580
クソ仕様って誰が言った?
クソ仕様「書」って言ってるの。馬鹿なの?あほなの?無能なの?
おまえマ板の無職windowsさんでしょ
585 :
2014/09/21(日) 17:12:48.09 ID:48QWsy10
>>584
じゃあ、そのクソ仕様書の具体例を
言ってみて。
586 :
2014/09/21(日) 17:14:26.03 ID:48QWsy10
>>582
> 句読点のない文章みたいに処理の区切りがまったくないような文体で書かれたソースなんぞ誰が手をつけるか

でも、バグがあったら直さないといけないし、
仕様変更、機能追加があったら、手を付けないといけないよね?
587 :
2014/09/21(日) 17:24:56.25 ID:SqCSMf85
うちのソースコードはほとんどが綺麗だから
句読点のない文章みたいに処理の区切りがまったくないような文体で書かれたソース
なんてほとんど無いよ。

そんな汚いソースがたくさんある所は、
手をつける箇所=リファクタリングするべき場所でしょう。
588 :
デフォルトの名無しさん
2014/09/21(日) 17:25:48.01 ID:J4CuFh4O
この板はガセネタをもとにした煽り合いのスレしかないみたいだな

・××と言われているが本当は○○
・こんなことも知らないの?

これが2ちゃんクヲリチーだな
589 :
2014/09/21(日) 19:17:45.62 ID:4aXz2u5s
>>585
作ってあげるよ、クソ仕様書

機能:
 俺の心の中にあるいい塩梅で、業務を遂行する処理

以上


これは極端に書いたが、冗談抜きで口頭で仕様をやりとりしたのか
いっさい、仕様書に、当該機能部分の記載がない。
590 :
2014/09/21(日) 20:05:10.80 ID:6N1L/uhm
嫌なら辞めれば良いのに
って思う
591 :
2014/09/21(日) 20:10:42.85 ID:qWzZkk5b
>>590
どっちにたいして言ってるのかわからんよ、その文では

クソシステムが嫌と言ってる人に言ってるのか、
リファクタリングwをしないやつはだめだって言ってるやつに言ってるのか

どっちにも解釈できる
592 :
2014/09/21(日) 21:44:29.99 ID:5OzBoJXn
クソソース1万ステップ読まなくていいようにするためにリファクタリングするんじゃないか
593 :
2014/09/21(日) 21:45:48.38 ID:9ZybMmhl
マーチン・フラウアーのリファクタリング本てruby版とjava版て言語が違うだけで内容は重複してるの?
それとも別の内容が多いから両方買った方がいい?
594 :
2014/09/21(日) 22:48:11.16 ID:SqCSMf85
>>589
それがソースコードとなんの関係があるの?

その曖昧な仕様によって、作られる機能が
曖昧になるだろう。

だが、機能が曖昧になるだけで、
それを実現するコードの読みやすさは関係ないはずだ。
595 :
2014/09/21(日) 23:01:02.38 ID:SqCSMf85
>>593

>>454ででてるリンク先の一覧が内容の比較として使えるよ。
多くは重複しているが、それぞれ片方にしかないものもある。

と思ったが、Java版、新装版がでたんだったか。
旧版、新装版、両方持っているが新装版の方はまだ見てないやw

ぱっとみ片方にしかないものは、言語の特徴によるものっぽいから
重複率は同じか少し高くなるだけだろうね。

それでも俺はそのうちRuby版かうけどねw
596 :
デフォルトの名無しさん
2014/09/22(月) 01:14:38.68 ID:8ME10ieO
リファクタリング真理教か原理主義かしらんがウゼエ
597 :
2014/09/22(月) 06:10:50.31 ID:mZl8n2a+
>>596
リファクタリングっつって真理教とか妄想するお前が一番オームくさい。

リファクタリング大勝利!!!
598 :
2014/09/22(月) 06:22:02.06 ID:VFEp2OOw
Aさんがリファクタリングしました。
Bさんが読みましたAさんのリファクタリングがクソです。Bさん直しました。
Cさん見ましたBさんのソースコードクソです。Cさん直しました。
永遠と、、、、、

個人の力量、感性によって結果が大きく作用してしまうものは、学術的工学的な基本がないからどうにもならない。
599 :
2014/09/22(月) 08:09:32.93 ID:mZl8n2a+
普通は、

Aさんがリファクタリングしました。
Bさんが読みましたAさんのリファクタリングがクソです。Bさん直しました。
Cさん見ましたBさんのソースコードクソです。Cさん直しました。

Cさんリファクタリング大勝利!!! ・・・でしょ?
600 :
2014/09/22(月) 08:34:50.21 ID: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.79 ID:y9q7ZqSb
>>598
それリファクタリング関係ないしw

なぜなら、俺が作ったコードを誰かが編集した時に、
変な修正の仕方をされることがあるから。

それを直すのがリファクタリングなわけ。
602 :
2014/09/22(月) 12:15:28.88 ID:4rgv3mOC
>>599
再びAさんが担当した時、Cさんのコードを読めず仕事になりませんでした。
Cさんリファクタリング大勝利!!!
603 :
2014/09/22(月) 13:03:42.75 ID:BRLO2XpR
優れたの方コードを採用すればいいだけだろ。
604 :
2014/09/22(月) 13:12:39.94 ID:8Zrs8f+9
個人の知識の違いによってソースの見え方が違うからな
アホが天才のコードを見ると何じゃこりゃってなるし、逆もまた然り
605 :
2014/09/22(月) 13:51:20.75 ID:BRLO2XpR
知識って・・・そんなの一機能5分もあれば
知らない状態から理解できるだろ。

どんだけ素人なんだ?

つーか知らない時点で、判断できないわけで
議論からはお役御免なわけだが
606 :
2014/09/22(月) 13:53:03.85 ID:BRLO2XpR
それに、知らないなら何をやっているか
理解できないわけで、リファクタリング出来るわけがないな。
607 :
2014/09/22(月) 17:49:10.78 ID:8HtrhTyn
おれはやらな〜いw


これでリファクタリングは崩壊するwww
608 :
2014/09/22(月) 19:42:14.76 ID:OvpzlkOF
アホみたいな話だが結局>>598が真理だよな。
リファクタリングする人は、自分のコードもいずれリファクタリングされる事を受けいれねばならん。
609 :
2014/09/22(月) 20:32:19.28 ID:0yRqeFm6
リファクタリングはただのコード修正と思ってもらってかまわない
610 :
2014/09/22(月) 20:44:04.47 ID:jEzIKioA
リファクタリングするよ派はここでなにしてんの?しないよ派とじゃれあってるのが楽しいの?
やり合ってる本人は議論してるつもりかもしれないけど、外から見てるとしょうもなさすぎてww
611 :
2014/09/22(月) 21:11:07.07 ID:BRLO2XpR
>>607
それは単に、プログラム?なにそれおいしいの?
動けばいいでしょ?って言ってるだけでしょう?
そんな会社はリファクタリング以前に
仕事が終わってる。
612 :
2014/09/22(月) 22:45:37.55 ID:rMqlGcxC
>>1が考えるようなことは誰もが考えてる。
その結果、新しい開発言語が生まれているということを理解できないのか?
過去、多くの開発手法・開発スタイルが提唱されたが、
社会に受け入れられたものは、「理論」と「それを強制する新しい開発言語」が常にワンセットになっていた

「超絶スパゲッティコード」を少しでもまともにするために
    原因の「goto」を取り除く方法として、「gotoレス」という理論とともに「3つの基本構造を使うようにした、構造化プログラミング言語」が生まれ
「グローバル変数の多用がデバッグを困難にする問題」を少しでもまともにするために
    原因の「不必要にメモリをどこからでもアクセスできる状態」を取り除くため「カプセル化」が提唱され、オブジェクト指向言語に組み込まれ
等々・・・・。

何を持ってリファクタリングといいたいのかわからないが、汚いコードを綺麗なコードになおすというなら。
リファクタリングが成功したといえる、最終のコードはどのようなものなのか。具体的に示す必要がある。
プログラムとして存在するあらゆるコードパターンに対応した、綺麗なコードを示してくれ。
それを明示できないうちは>>598の意見が正しい。
個人の感性次第なら、汚いコードと周りは言うが書いているプログラマにとってはリファクタリング不要な綺麗なコードと判断するだろう。

先人達は、その時代のプログラムコードの問題を考えた。
その答えが、理論を具現化した新プログラミング言語の開発だ。

>>1はしのごのいうなら、リファクタリング後の形になるプログラミング言語を生み出せ。
どんな馬鹿でも、その綺麗なプログラミングになるプログラミング言語を。
613 :
2014/09/22(月) 22:52:50.40 ID:BRLO2XpR
>612
新しい言語というから何かと思えば
gotoレスとかカプセル化とか

全然新しくないじゃないか。
30年ぐらい前の話だろ。
614 :
2014/09/22(月) 22:55:02.43 ID:BRLO2XpR
> 何を持ってリファクタリングといいたいのかわからないが
無知は勉強すればいいだけ。恥ずかしいことなんて無いよ!
>>423, >>426あたりを読むといいよ。

リファクタリングの誤用
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?RefactoringMalapropism
リファクタリングの境界線
ttp://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.11 ID:BRLO2XpR
>>614を見ればわかるけど、

リファクタリングを
汚いコードを綺麗なコードに直すこと
とは書いてないんだよね。

なんでこんなふうに間違って解釈してるのかな?

それって、汚いコードが(あなたの所に)多いってだけで、
リファクタリング以前の解決するべき問題だよね?

リファクタリングとはソフトウェアの変化とともに、
あるべき設計に安全に変化させる方法のこと。
616 :
2014/09/22(月) 23:03:19.25 ID:rMqlGcxC
>>613
あ?30年前だ?
がきんちょがてきとーなことぬかしてんじゃねーぞ?
30年前のコードならgoto乱発が現役だ
汎用機に大量にその証拠があるわ
どあほが。
617 :
2014/09/22(月) 23:04:10.78 ID:rMqlGcxC
>>615
具体性がございません。
個人の感性次第でよろしいですか?
なら退職時、全部アセンブラコードだけにしちゃいますがw
618 :
2014/09/22(月) 23:24:14.03 ID:OvpzlkOF
>>615
(お前にとっての)あるべき設計だな
619 :
2014/09/23(火) 07:26:06.78 ID: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
>たてたね。それで?
>
>なにか言い返したいことがあるのなら
>いっていいだぜ?w
>
>7 自分:仕様書無しさん[sage] 投稿日:2014/09/23(火) 07:22:55.61
>>>5
>自然と、「無職」「Windowsしか使えない」「ム板でリファクタリングスレ」を立てたことを認めているww


さすが、無職でWindowsしか使えないだけはあるw
だれも同調してくれないww 説得力もカリスマ性も感じないからなw
620 :
2014/09/23(火) 12:26:15.85 ID:aBTcR7ac
>>617
具体例はここに書いてあるよ。

> >>614を見ればわかるけど、
>
> リファクタリングを
> 汚いコードを綺麗なコードに直すこと
> とは書いてないんだよね。
621 :
2014/09/23(火) 16:29:00.40 ID:wrw0I4Vi
まだ無職が語るの?
恥ずかしいからお前の社会的立場を恥ずかしくない位置にリファクタリングしてからプログラムのリファクタリングを語れよw
622 :
2014/09/23(火) 16:45:57.11 ID:wrw0I4Vi
しかし、この超売り手市場なのに就職出来ないって、相当無能なんだな
623 :
2014/09/24(水) 17:32:35.84 ID:iVFJW3Cg
いやぁ馬鹿スレを止めてくれてありがたい

完全に自爆だけどな(笑
624 :
2014/09/25(木) 08:00:06.24 ID:2gwTj0ip
え?
マジで!?いろいろ見て回ってきたけど
ゲーム作りたくてプログラマになったけど、就職できず、Windowsしか扱えないので、派遣でコボルやるもクビになって無職
なの?!( ;´Д`)

そんな身分で、現役のプロのプログラマにプログラム、プログラミングにたついて講釈たれてたの?
ε-(´∀`; )

どんだけ、恥知らずというか、身の程知らずというか、小保方というか。
空いた口が塞がらないわ(^◇^;)

マジでお前自信をリファクタしろよ(・Д・)ノ
625 :
2014/09/25(木) 12:50:36.36 ID:fB0UYRRr
という妄想を書く人って、
実社会では自分が落ちこぼれなのかな。
626 :
2014/09/25(木) 17:28:15.70 ID:oxMb9EZk
不用意に自供しといて妄想とかw
627 :
2014/10/05(日) 23:35:12.83 ID:gYmu4Dn/
リファクタリング良さそうなんだけど、いろいろ疑問点があります

上で内部的インターフェイスの変更もリファクタリングに含まれるという話がありましたが
インターフェイスを作り変えたら対応するテストケースも作り変える必要がありますよね?

その場合、リファクタリング内でテストケースに手を付けて
インターフェイスとテストケースを同時に作ってしまっていいものでしょうか?

外部的インターフェイスに指定したテストケースのみパスすれば
問題ないと考えるのでしょうか?
628 :
2014/10/07(火) 01:36:41.20 ID:0pCKu6Fp
テストケースは全部通さないと駄目だよ
人間の書くテストが全部網羅してるとも限らないから
テストの穴を突いた部分が他所で影響してるかもしれない
原則としてよほどの事でもない限り一度リリースしたら手をつけないがベスト
リファクタリングなんて幻想だからやめなさい
629 :
2014/10/07(火) 09:53:16.20 ID:pP8u07NL
インタフェースを作り替えたらテストも必要
というかテストできない・しづらいインタフェースを作ったらあかん
630 :
2014/10/07(火) 20:19:23.95 ID:J1sG3mPW
>>628
> テストケースは全部通さないと駄目だよ

内部動作をリファクタリングする場合はそうだと思います。

> 人間の書くテストが全部網羅してるとも限らないから
> テストの穴を突いた部分が他所で影響してるかもしれない

100%のテストはないけど、十分捕捉率の高いテストと
十分機能変更の余地が低いリファクタリング手法の組み合わせで
実用になるというのがリファクタリングの主張ですよね。

内部動作のリファクタリグだけならそれでいいんですけど、
ただやっぱりインターフェイスの拡張・取捨選択も
やりたくて、そういう場合どうすればいいのかなと。

> 原則としてよほどの事でもない限り一度リリースしたら手をつけないがベスト

一度リリースしたっきりでソースのことを忘れ去っても
大丈夫なプロジェクトならそうかもしれませんが、
リファクタリングがターゲットにするプロジェクトは
リリースした後に(リファクタリングするしないに関わらず)
何度も手を付けてメンテナンスすることが要求されるような
継続性のあるプロジェクトではないでしょうか?

> リファクタリングなんて幻想だからやめなさい

上手くいくと言っている人も多いので、
安易に幻想だと断定もできないように思います。
幻想だとはっきり納得出来たらやめます。
631 :
2014/10/07(火) 20:20:02.46 ID:J1sG3mPW
>>629
> インタフェースを作り替えたらテストも必要
> というかテストできない・しづらいインタフェースを作ったらあかん

テストしづらくはないのですが、
例えば1つ1つの public メソッドにテストを書いていたら
とても作業が時間内に終わらないというような、
時間がかかってしまう的な問題です。

でも public メソッドはクラスの持つインターフェイスだから
テストは必要ってことですか?
632 :
2014/10/08(水) 15:43:43.04 ID:AP5j0Y8f
ただ、そのテストのメンテナンス、テストを減らしたり、改善したり、
そういう話はまだ多くないんですね。(例えば)テストが増えてくると、
全部のテスト通すのに 3 時間かかったりとか、 テストの量自体が問題になってくる。
またテストが実装に深く依存してて、リファクタリングしたらテストが
ばーっと真っ赤*49になっちゃうからやめようみたいな話とか。

テストをたくさん書けば良いってものじゃないんですよ。
設計の改善を前後で担保するためのテストだったはずなのに、
設計改善の邪魔をしてるんじゃないか? と。
テストが変更のコストを一定にするという夢を俺たちは見てやってきたのに、
テストが増えると変更コストが上がっていないかい? という問題に対してどう戦うか、
それが今の TDD の主戦場だと思っています。

http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview43.html
633 :
2014/10/08(水) 17:47:03.08 ID:No3WRPQd
>>632
下手なテストを書くとそうなるって話ですね。
634 :
2014/10/08(水) 23:56:17.82 ID:UFd7lKdk
よくわからんが何かの言い訳に使えそうな
635 :
2014/10/09(木) 10:21:37.01 ID:IFg54I5e
テストできない・しづらいインタフェースを作ったらあかん
636 :
2014/10/09(木) 20:44:29.80 ID:zf/NUEdS
ボタン一個一発こそ至高
637 :
2014/10/12(日) 07:13:20.02 ID:jwvcB2bY
>>627
有能な人材だけで構成されているなら可能
でも有能な人材はそもそもそんなコードを書かない
つまり、現実では実現不能ということ。


よく考えてよ。
ゲーム会社への就職も面接すらいけずに終わり、他の会社も全滅、登録派遣しかなく
ようやく派遣されたCOBOLでクビになり、
自分は有能だと思い込んでいるケドWindowsしか使えない
無職の人の立てたスレだよ?
638 :
2014/10/12(日) 13:23:31.01 ID:08qsWg0a
>>637
返信ありがとうございます

> よく考えてよ。
誰が立てたかでなく、何を言っているかで判断しています

> 有能な人材だけで構成されているなら可能
627 では可能かどうかという聞き方はしていないのですが、
627 のどの部分を指して可能と言われているのでしょうか?

> でも有能な人材はそもそもそんなコードを書かない
これも、627 ではどんなコードかに関して言及していないと
思うのですが、そんなコードというのは何を指しているのでしょうか?
639 :
2014/10/12(日) 14:51:47.69 ID:jjrAIsW+
世の中に汚いコードが溢れてるってことだなw

リファクタリングは汚いコードを直すことじゃないよ。
コードは修正するたびに(≒機能追加)
どんどんコードが増えていく。

素人集団は、コードの既存部分を直さずに追加するだけで終わらせる。

有能な人材はそもそも汚いコードを書かないというが、
それは、有能な人材は、リファクタリングをしながら機能追加していくから
汚いコードに"成長しない" ということを意味する。
640 :
2014/10/12(日) 15:32:46.02 ID:08qsWg0a
設計がまずかったり場当たり的に組んでしまったりして
いったん汚いコードになってしまったらもう手遅れですか?

汚いコードをインターフェイスを変えつつ
改善していきたいと思っているのですが
641 :
2014/10/12(日) 16:01:06.81 ID:jjrAIsW+
>>648
「汚いコード」のうちは未完成と考えるよ。

設計書だってレポートだって小説だって
書いた最初は下書きでそれから清書するもんだろ?
642 :
2014/10/13(月) 12:31:48.66 ID:dRUWRUgv
コードが汚いとか騒ぐやつは総じて低スキル
643 :
2014/10/13(月) 17:48:27.91 ID:qVWnI3+v
>>640
汚いのを綺麗にする行為をリファクタリングとは"呼ばない"


これが原理主義者の主張するところである
644 :
2014/10/13(月) 21:27:10.38 ID:mV3fqIh9
>>643
ではリファクタリグしたとしても汚いコードは汚いままなのですね
645 :
2014/10/13(月) 22:25:07.42 ID:0J6BIdC+
>>644
汚いコードはリファクタリング前に綺麗にしてから
リファクタリングするから、
リファクタリング後は当然綺麗になってるよ。
646 :
2014/10/13(月) 22:41:00.86 ID:mV3fqIh9
>>645
リファクタリグとは別に、汚いコードを綺麗にする方法があるのですね
どうやるんでしょう?
647 :
2014/10/13(月) 22:43:13.35 ID:zulUt3IX
>>646
まず何が綺麗で何が汚いかを勉強することだね。
それを知らないことにはどうしようもない。

逆に知ってしまえば、具体的な質問ができるようになるよ
汚い××というコードを、綺麗な○○に変化させるには
どうしたらいいでしょうか?って

そういう質問なら答えがちゃんと言える。
君の今のレベルの質問は曖昧すぎて答えがない。
648 :
2014/11/22(土) 11:07:28.63 ID:jhiCG8Ku
>>642
その高スキルに限って自分のソースが保守できずに早々に放棄する
書きなぐり続けるのはその繰り返しのため
649 :
2014/11/22(土) 16:04:31.14 ID:6qlI/h48
>>642
俺様のコードは凡人には分からない
協調作業が出来ないタイプの典型
困ります、俺のプロジェクトから即刻リジェクト
してほしいです
田中お前だよ
650 :
2014/11/25(火) 12:34:50.30 ID:aVHf4ing
世の中なんでも使い捨てで楽な方に向かってるのに
プログラミングの世界は古いものを大事に使いたがる不思議
怠惰なフログラマこそ率先してコードを使い捨てにすべきじゃね?
651 :
2014/11/25(火) 23:55:42.35 ID:n1duvf0w
>>650
使い捨てる理由の大半はどんなにうまく保存しようとしても劣化し続けるから。
ソフトウェアはそういう物理的制約から書いたものはずっと同じまま残り続ける。
うまくバックアップや環境が残りさえすれば半永久的に使い続けることが出来る
わけだから、怠惰であればあるほどそういう資産を積み上げていくんだよ。
652 :
2014/11/26(水) 12:34:55.88 ID:1UftDcOY
>>651
バカだな劣化するからリファクタリングとかいう下らない事が流行るんだぞ
653 :
2014/11/26(水) 19:48:43.25 ID:0BkZoqqN
再利用って考え方がそもそもコストが高いんだよ
もんじゅとか例に挙げなくてもリサイクルって金掛かるだけで
利権で儲けるしかない仕組みだって判るよね
654 :
2014/11/27(木) 00:55:26.29 ID:dibuY+0s
再利用のコストに関しては単純に何回再利用するかで変わってくるから、
コストの高い再利用をしているお前が悪いんじゃないのとしか言えない。

リファクタリングも同じで、2度と手を入れないような部分や新規プロジェクトを
渡り歩くような人には不要なもの。 ただ昨今のアジャイル開発とか呼ばれている
ものだと、ある程度の期間は修正や追加が必要になってくる。 無計画に接ぎ木を
してわけの分からないキメラを作るより、ある程度剪定して理解できる範疇に
修める必要があるよねっていうのがリファクタリング。
655 :
2014/11/27(木) 12:34:12.35 ID:jH/Xs+Kz
>>654
ソフトウェアの再利用もその都度コストがかかるんだが?
普通は回数に比例してコストが増加するぞ
656 :
2014/11/27(木) 12:41:38.96 ID:r+bsdp9/
>>655
> ソフトウェアの再利用もその都度コストがかかるんだが?
> 普通は回数に比例してコストが増加するぞ
再利用するために何らかの変更が必要なら、そのときだけコストがかかるが、
以降はコストかからんだろ。
657 :
2014/11/27(木) 23:29:56.27 ID:kUiumU8R
再利用前提で作ろうとしてる時点で余計なコトスがかかっとるわい
658 :
デフォルトの名無しさん
2014/11/28(金) 02:38:41.57 ID:LrjKc3Ws
古くなった原発の再利用
659 :
2014/11/28(金) 04:18:59.87 ID:MN0ISYZx
再利用性や拡張性というのは、将来のことだから仕様外。
仕様外だからプログラミングの対象外。

おわり。
660 :
2014/11/28(金) 07:48:17.97 ID:IEXuWLi+
再利用と考えるからいけない。
モジュール化。

適切なモジュール化は、再利用出来るだけじゃなく、
複雑度も減ってバグも少なくなる。

適切なモジュール化が出来ない奴が
再利用にコストがかかるとか
コードが再利用できないとか言う。
661 :
2014/11/28(金) 12:44:59.78 ID:X4M4SbHd
>>660
それは再利用じゃないよ
機能を小さく保つ事で、本来の目的である一次利用出来る範囲が広がるだけだ
それを便宜的に「再利用しやすい」などと表現してる訳だ
ソフトウェア本来の目的とは異なる本当の意味での再利用にはコストがかかるんだよ
662 :
2014/11/28(金) 17:41:36.95 ID:03S1h8mH
本当の意味での再利用?
そんなもんに興味持つ必要はなさそうだが?

>>660
それな。
本当にそれ。
663 :
2014/11/29(土) 01:59:23.82 ID:TbFyYdBX
>>661
> 機能を小さく保つ事で、本来の目的である一次利用出来る範囲が広がるだけだ
一次利用が出来る範囲が広がる=再利用だろw
664 :
2014/11/29(土) 13:13:20.77 ID:U5ivpV2C
再利用じゃなくて流用と言えばいいのに
665 :
2014/11/29(土) 14:17:24.97 ID:v2v5Wnkr
全く修正しないで使うのが再利用。
コピーして修正して使うのが流用

流用をすると、AとA'というコードが生まれなんで二つに分かれてるの?
違いはなんんあの?と結局両方を読まないといけなくなる。
流用するたびに読むべきコードがどんどん増えていく。
はてに一つを修正するともう片方の修正を忘れるとか。

なので全く修正しないで使う「再利用」でないと意味が無い。
全く修正しないで使えるのだからコピーする必要はなくなる
666 :
2014/11/29(土) 14:46:23.56 ID:A4nuaoXO
流用元から流用先がどこにどれだけあるかは基本的に分からない。
流用元に何かバグがあって修正する必要があった場合に論理的に考えると
流用先も直しておいた方がいいor直す必要がある。 ただ流用先を全て特定
することは難しく、特に流用先で動くように変数名とか変えてあると確実に
漏れる。バグじゃなくても何か修正追加したいと思った時の事を考えると
コピペをばらまくより関数で再利用するほうがいいよねってなる。

ただ人間は欲深いもので1つの関数にあれもこれも詰め込んで破綻させる
奴が出てきたりする。こういうのを見て、関数なんて作らなくてコピペでいい
だろって奴が出てきて無限ループする。
667 :
2014/11/29(土) 22:16:12.25 ID:UEas1JmU
頑張って同じ機能がすでにあるか探して、
あったらあまりいいコードじゃなくても正しく仕様を満たすからそれ使って
散々気をつけてんのに誰かが変更しやがる
668 :
2014/11/30(日) 12:24:33.02 ID:NxMP0P1A
リファクタリングと言う名の正義
669 :
2014/12/05(金) 19:01:54.53 ID:cszTTiF/
>>668
同意、正義を振りかざす曲者
670 :
2014/12/21(日) 11:54:37.04 ID:LOCxTeYe
>>661,660
>ソフトウェア本来の目的とは異なる本当の意味での再利用にはコストがかかるんだよ
 
 アプリ内でのモジュールの共通化(=アプリに特化したフレームワーク、ライブラリ
の抽出)と、どんなプロジェクトでも使えるようにフレームワークやライブラリーを
汎用化するのは似て非なるものだと思う。
671 :
2015/02/15(日) 22:12:39.01 ID:wyXhgSeE
>>1-1000
テスト
672 :
2016/03/27(日) 21:55:32.43 ID:N7IGtcj3
どのタイミングでやったら工数に影響を与えずにできるの?
673 :
2016/09/10(土) 20:12:17.64 ID:/nLYt7vC
みんな、言い負かされないようにリファクタリングを定義してるから、本当の目的がなんなのかぼやけちゃってるよね。

保守性(機能変更のし易さ)と速度の向上

リファクタリングの目的はこれでしょ。
それが必要ならリファクタリングすればいいし、将来的な機能変更もなく速度にもとくに問題がないなのら、どんなに汚いコードであっても下手にいじる必要はないよね。

むろん、個人で作った(使ってる)プログラムならリファクタリングするかしないかはその人の勝手だけど。
674 :
2016/11/02(水) 19:22:35.91 ID:5cFgMElw
>>673
次の変更がきてから変更すればいいじゃない?
675 :
2016/11/11(金) 18:20:08.17 ID:cgCFsvxz
なるほど
676 :
デフォルトの名無しさん
2017/02/06(月) 05:50:15.98 ID:ZR9n4VuA
大抵の趣味人はリファクタリングなんかせずに垂れ流しだろ
677 :
デフォルトの名無しさん
2017/02/06(月) 06:14:33.50 ID:gKoTGA+M
趣味としてのリファクタリングも結構面白いけど
678 :
デフォルトの名無しさん
2017/02/06(月) 06:41:48.30 ID: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.14 ID:cswrm9tC
リファクタリングにはユニットテスト必須だよな
680 :
デフォルトの名無しさん
2017/02/06(月) 12:26:12.33 ID:I8OzMN90
ユニットが再編成されたコードの外的な振る舞いをテストする
という意味ではユニットテストはその目的を果たしてないけどな
681 :
2017/02/06(月) 13:37:16.68 ID:2jscAFeG
うちの会社の糞プロジェクトはリファクタしてことでバグ生んで大炎上してたな
682 :
デフォルトの名無しさん
2017/02/06(月) 16:24:54.25 ID:gWijZw93
>>680
外的な振る舞いを変えないのがリファクタリングだろ
683 :
デフォルトの名無しさん
2017/02/06(月) 20:52:46.36 ID:De1q4r3Z
>>682
なんだ?だからテストしなくても良いとか言いたいのか?
684 :
デフォルトの名無しさん
2017/02/06(月) 21:26:39.16 ID:cswrm9tC
>>683
なんでそうなるんだ?
リファクタリングによって振る舞いが変わってない事を確認する為にユニットテストが必須という話をしてるのに
685 :
デフォルトの名無しさん
2017/02/06(月) 21:43:37.79 ID:De1q4r3Z
>>684
なんでそうなるんだ?
ユニットが再編成されたコードの外的な振る舞いが変わっていない事を確認する為にユニットテストは使えないという話をしてるのに
686 :
2017/02/06(月) 22:00:46.99 ID:w4i0A8ue
分子構造が再構築された全ての細胞の働きがもとそれと1つも変わらないならそれは再構築前と同じ生物になるのではないか
という理屈
687 :
2017/02/06(月) 22:00:51.21 ID:eyaDYQgE
>>684
テストが必要っていうのは正しいが、そのテストはユニットテストとは限らん。

まず>>678に書いてある「外的な振る舞い」というのは
どこが外的かを考える必要がある。

リファクタリング対象がモジュール(クラス等)であれば
必要なテストはユニットテストだ。

だけど設計に近いレベルであれば必要なテストというのは
E2Eテストやシステムテストだったりする。

何をリファクタリングするかによって必要なテストは変わる
688 :
2017/02/07(火) 11:38:03.93 ID:pecoNgwz
>>687
設計に近いレベルの変更というのがどういうものを指すのか良くわからんが、E2Eテストやシステムテストが必要になるコード変更はリファクタリングとは言わないでしょ。
689 :
2017/02/07(火) 11:39:08.61 ID:qLX8GhSK
えっ!?
690 :
デフォルトの名無しさん
2017/02/07(火) 12:21:09.75 ID:TOEOKA4e
>>688
むしろその規模のリファクタリングでなければコーダーのオナニー以上の意味がないくらいなのだが
691 :
2017/02/07(火) 13:06:50.95 ID:pecoNgwz
>>690
規模の話はしていない。
1箇所数行のリファクタリングであろうが、1万箇所数万行のリファクタリングであろうが話は同じ。

E2Eテストやシステムテストでなければテストできないようなリファクタリングって、具体的にどんなものなんだ?
692 :
2017/02/07(火) 15:04:10.93 ID:hq/hh9Cr
>>691
リファクタリングで効率が良くなったとして、ユニットテストレベルで勝手にリリースして
本当は他のシステムで必要な協調動作パラメータの再調整が必要だったり
想定してたバッファがパンクする可能性とか想像できんの?
そもそもリファクタリング単体の案件なんてまず発生しないし
他の案件の一部にねじ込むってパターンがほとんどだから結局テストは全工程やる事になるけど
693 :
2017/02/07(火) 15:27:04.15 ID:pecoNgwz
>>692
「他のシステムで必要な協調動作パラメータの再調整が必要」なほどの大きな変更を「外的な振る舞いが変わっていない」と表現・定義して、それがリファクタリングであるというのはちょっと同意できない。

そもそも、>>687
> 何をリファクタリングするかによって必要なテストは変わる
ということなので、E2Eテストやシステムテストが必要なリファクタリングとは、具体的にどんなものか、というのが疑問なんだけど。
694 :
2017/02/07(火) 15:28:33.61 ID:pecoNgwz
>>692
> 想定してたバッファがパンクする可能性とか想像できんの?
あと、これ、単なるバグ(または設計ミス)でしょ。
しかも、単体レベルで検知可能。
695 :
デフォルトの名無しさん
2017/02/07(火) 16:00:21.23 ID:WNm+xswo
>>692 のレベルが低すぎて笑う
696 :
2017/02/07(火) 18:13:12.04 ID:hq/hh9Cr
レベル低くて結構だが
要件から漏れた設計なんて後からいくらでも見つかるのが現実
最初から設計や実装が完璧ならリリース後のコードに手を付けようなんて考えすら出てこないだろ
697 :
2017/02/07(火) 18:17:09.92 ID:i748zAYA
ID:pecoNgwzがすごい小さい世界で生きていることだけはよくわかる
698 :
2017/02/07(火) 20:26:46.11 ID:hbaz0JGp
スレタイ通りの人達
699 :
デフォルトの名無しさん
2017/02/07(火) 21:49:17.94 ID:6yEMM6pR
>>691
> 1箇所数行のリファクタリングであろうが
君はこれで何がリファクターされると考えているのかね?
既存のコードを君好みのノーテーションに変える事をリファクタリングとは言わないのだよ
リファクタリングとはただのコード修正とは違うという意味
君分かってないよね
700 :
デフォルトの名無しさん
2017/02/07(火) 21:55:16.30 ID:WNm+xswo
っていう勘違いをここまで堂々と話してるところが2chだなぁと感じる
701 :
2017/02/07(火) 21:58:23.39 ID:S1oxUZhq
>>691
> E2Eテストやシステムテストでなければテストできないようなリファクタリングって、具体的にどんなものなんだ?

違う言語にリファクタリングした場合
702 :
2017/02/07(火) 22:06:09.85 ID:S1oxUZhq
>>692
> リファクタリングで効率が良くなったとして、ユニットテストレベルで勝手にリリースして
> 本当は他のシステムで必要な協調動作パラメータの再調整が必要だったり
> 想定してたバッファがパンクする可能性とか想像できんの?

これリファクタリングと全く関係ないよね?


機能追加で便利になったとして、ユニットテストレベルで勝手にリリースして
本当は他のシステムで必要な協調動作パラメータの再調整が必要だったり
想定してたバッファがパンクする可能性とか想像できんの?
703 :
デフォルトの名無しさん
2017/02/07(火) 22:10:27.76 ID:WNm+xswo
>>701
言語関係ないと思うが。
出来た実行可能ファイルかライブラリーか知らんがそれの挙動が変える前と代わっていないかテストすればいいだけだろ
704 :
2017/02/07(火) 22:11:07.79 ID:S1oxUZhq
>>692
> そもそもリファクタリング単体の案件なんてまず発生しないし
当たり前。何かの修正があるときに
適切な形に変えるのがリファクタリング

「何かの修正」が加わる前の時点での適切な設計と
「何かの修正」が加わった後の適切な設計は必ずしも同じではない

「何かの修正」を加えるときは、もし最初から「何かの修正」が存在したと
仮定した時の適切な設計も同時に実現しなければいけない

修正するたびに適切な設計から離れていく、修正するたびに
壊していくようなやり方は責任あるプロの仕事とはいえない

> 他の案件の一部にねじ込むってパターンがほとんどだから結局テストは全工程やる事になるけど

結局テストは全行程やるんだから、修正のたびにリファクタリングを加えてなんのもんだもない
705 :
2017/02/07(火) 22:11:57.21 ID:S1oxUZhq
>>703
だから、出来た実行可能ファイルかライブラリーか知らんがそれの挙動が変える前と代わっていないか
E2Eテストやシステムテストでテストするんだよ
706 :
デフォルトの名無しさん
2017/02/07(火) 22:21:19.34 ID:NKjx6bYj
>>705
実行ファイル一つならそうである可能性もあるけど、ライブラリだったらシステム全体ではないよね。言語関係ないとはそういうこと。
707 :
デフォルトの名無しさん
2017/02/07(火) 22:24:10.12 ID:NKjx6bYj
勘違いさせたならすまんが、俺は別にリファクタリングにシステムテストとかが必要ないなんて思ってない。その一つとは別人。
708 :
2017/02/07(火) 22:44:43.58 ID:K2oda13o
リファクタにE2Eテストがいらないというのはある意味ただしいんだよ
アジャイルにおけるリファクタなんかがまさにそう
自動テストありきでイテレーションに組み込まれる
ただリファクタにも色々あるよねって話
709 :
2017/02/07(火) 22:53:25.47 ID:hbaz0JGp
リファクタリングの責任範囲はユニットテスト迄でシステムテストとかは機能の変更、追加、向上なんかの範囲だと思うけどね
この二つを混ぜてリファクタリングと呼んでる人が一定数いて話をややこしくしてる
もちろんリリース前には一通りテストはするけどそれはそれ。リファクタリングに必要なテストとは別物
710 :
デフォルトの名無しさん
2017/02/07(火) 22:55:46.93 ID:NKjx6bYj
>>708
いやE2Eテストが自動化出来ないというわけでもないからちょっと違うくない?
リファクタリングにも色々あるよねというのには同意。
リファクタリングの対象を決めることは大事だよね。
システム全体をリファクタリングしようとしても成功率は低い。だからE2Eテストはいらない(システム全体を一度に変えようとすんな)と言いたい気持ちも解る。
711 :
デフォルトの名無しさん
2017/02/07(火) 22:57:24.46 ID:6yEMM6pR
>>709
責任範囲がユニッテテスト迄w
もはや何を言いたいのか自分でも分かってないだろお前w
712 :
2017/02/07(火) 23:01:56.40 ID:hbaz0JGp
>>711
君が言いたいことは分かんないけど自分の言いたいことはわかってるよ
713 :
デフォルトの名無しさん
2017/02/07(火) 23:08:35.66 ID:6yEMM6pR
>>712
いや分かってねえよお前w

既存のユニットテストが利用出来るようなコード修正は
お前のコードオナニー以外の何者でもない
お前はリファクタリングという正義を笠に着てコードオナニーをしているだけの
童貞コーダーにすぎないのだよ
714 :
2017/02/07(火) 23:11:01.58 ID:hbaz0JGp
>>713
まさに混同してる人が話をややこしくしてる見本
715 :
2017/02/07(火) 23:16:01.53 ID:S1oxUZhq
>>706
何だその意味がない答えは?

> 実行ファイル一つならそうである可能性もあるけど、ライブラリだったらシステム全体ではないよね。言語関係ないとはそういうこと。

ライブラリだったらシステム全体ではないかもしれないけど、実行ファイル一つならそうである可能性もある
716 :
2017/02/07(火) 23:16:32.08 ID:K2oda13o
>>710
まあそうね

>>713
いやわかってないのはおまえ
リファクタといえば一般的にはTDDありきのおまえのいうオナニーだ
717 :
2017/02/07(火) 23:17:49.44 ID:S1oxUZhq
>>709
> システムテストとかは機能の変更、追加、向上なんかの範囲だと思うけどね

意味が全くわからん。外から見たときに機能も何も変わらなくて
内部の設計が良くなってるならそれはリファクタリング
718 :
2017/02/07(火) 23:19:18.43 ID:S1oxUZhq
>>716
> リファクタといえば一般的にはTDDありきの

TDDがリファクタリングありきなのであって
リファクタリングはTDDとは関係ない
719 :
2017/02/07(火) 23:22:44.32 ID:K2oda13o
>>718
関係ないのではなくリファクタがそれだけではないってだけ
おまえめんどくさいな
720 :
2017/02/07(火) 23:23:22.80 ID:S1oxUZhq
>>719
それだけじゃないっていうのなら、
他に何があるのかを言えよ

お前は否定するだけで、自分の意見を何も言ってない
721 :
デフォルトの名無しさん
2017/02/07(火) 23:23:38.10 ID:6yEMM6pR
>>716
んなアホなw
まともなリファクタリングしている奴だって大勢いるわw
722 :
デフォルトの名無しさん
2017/02/07(火) 23:23:56.74 ID:NKjx6bYj
>>715
だから違う言語にしたというのと、システムテストをするというのは無関係だって話だよ。それだけ。
723 :
デフォルトの名無しさん
2017/02/07(火) 23:25:16.66 ID:NKjx6bYj
ID:6yEMM6pR がまともなリファクタリングを語るのはもうギャグにしか見えない
724 :
2017/02/07(火) 23:32:41.16 ID:S1oxUZhq
>>722
外部から見たときの動きを変えずに、内部の言語を変えたら
ユニットテストもつかえねーだろ。
何を言ってんだお前
725 :
2017/02/07(火) 23:37:57.69 ID:hbaz0JGp
>>717
そう言ってるつもりだけど?機能の変更までやったらシステムテストは必要だけどそれはリファクタリングの後の工程だよねってこと
726 :
デフォルトの名無しさん
2017/02/07(火) 23:41:30.42 ID:NKjx6bYj
>>724
なんで?例えばC互換のABI作れる言語なんて山ほどあるけど(バイナリ作る言語ではほぼ必須機能だよね)
他にも内部の言語は変えたけどモジュールの外向きのラッパーは今までと同じ言語で書くというのもあるだろ
727 :
デフォルトの名無しさん
2017/02/07(火) 23:46:26.22 ID:6yEMM6pR
>>725
お前頭沸いてんなw
そもそもテストの存在意義すら分かってねえじゃねえかw
ユニットテストは必要だけどシステムテストは必要ないなどと言う開発メソッドは
人類の歴史上でただの一度たりとも存在した事はねえよw
728 :
2017/02/07(火) 23:53:55.55 ID:S1oxUZhq
>>726
なんでお前特別な状況下においてできるって話をしてるんだ?
一般的にはできない(やらない)だろ
729 :
デフォルトの名無しさん
2017/02/08(水) 00:00:15.94 ID:xLLPMt9l
>>728
別に特別とは思わないけど。例もあるよね。
FirefoxのメディアパーサーをRustで書き直した話とか。
730 :
2017/02/08(水) 00:03:59.64 ID:oBIe6m9v
>>720
ほんとめんどくさいな
バカがオナニーと言ってるようなifをswitchに変えるリファクタからソフトアーキ自体を変えるものまで全てリファクタだっつってんだろ
731 :
デフォルトの名無しさん
2017/02/08(水) 00:16:01.83 ID:ahyxJIg+
>>730←自分のオナニーが認められないから根本的な設計思想の変更までリファクタリングだと言いだす極端すぎるバカw
732 :
2017/02/08(水) 00:37:41.54 ID:E3hlYujb
>>731
涙ふけよ
733 :
デフォルトの名無しさん
2017/02/08(水) 03:53:58.44 ID:/T6I+uKy
バカをチンカス野郎と言い換えても
罵倒であることは変わりない
これがリファクタリングでしょ?
734 :
2017/02/08(水) 04:18:31.48 ID:TcrM+SWf
「外部からみた振る舞いを変えずに内部の設計を変更すること」がリファクタリング
ここでいう"外部"が関数の外部だったりシステムの外部だったりするけど、どっちもリファクタリング

リファクタリングを実施するのは設計〜製作工程
TDDなら製作と同時にユニットテストも当然走る
TDDであってもそうで無くても、製作後にテストの工程は当然流す

添削おなしゃす
735 :
デフォルトの名無しさん
2017/02/08(水) 05:18:42.07 ID:ahyxJIg+
>>734
> TDDなら製作と同時にユニットテストも当然走る
> TDDであってもそうで無くても、製作後にテストの工程は当然流す
これはリファクタリングの定義とは関係ないし
TDDでなくてもユニットテストは当然走る
736 :
2017/02/08(水) 09:24:40.45 ID:pGBkCxNv
>>735
内省したのか?
737 :
2017/02/08(水) 09:39:48.42 ID:nBuIwUQ3
>>735
>これはリファクタリングの定義とは関係ないし
そうだね
上の方でごっちゃにしてる人が居たからついでに書いたけど、語弊があったね

>TDDでなくてもユニットテストは当然走る
そうだね
製作と"同時に"走るかどうかだけの違いだと思う
738 :
2017/02/08(水) 09:46:07.86 ID:tJ+Jm8vl
おれはTDDなんて大嫌いだ
あれ考えやつはアホ
739 :
デフォルトの名無しさん
2017/02/08(水) 09:47:23.69 ID:3ajnzt+4
>>738
どんなところが嫌いなん?
740 :
2017/02/08(水) 13:47:01.32 ID:DMN235DC
>>739
日本の社畜プログラマーは文系卒のゴミばっかりだから
日本のソフト業界は大量のゴミを一部の有能なエンジニアがコントロールすることでなんとか成立してる
ゴミにTDDなんてやらせたら有能な人間がリファクタリングに追われる羽目になる
741 :
デフォルトの名無しさん
2017/02/08(水) 14:21:20.51 ID:HCDAsN67
>>740
どうせゴミが書いたコードなんて修正しなければならないんだから、テストがちゃんと書かれてる方がそれをパスするようにリファクタリング出来てマシだろ。
742 :
2017/02/08(水) 18:18:22.76 ID:DMN235DC
ゴミが書いたテストコードなんて使えるわけなかろう
時間の無駄
743 :
2017/02/08(水) 19:05:55.15 ID:nBuIwUQ3
それTDD関係ないじゃん
744 :
2017/02/08(水) 19:51:16.87 ID:z7CrxHSJ
テストコード真っ先にレビューしろよ
745 :
デフォルトの名無しさん
2017/02/08(水) 19:54:03.00 ID:ahyxJIg+
>>740←TDDもリファクタリングも分かってないゴミwこういうのがリファクタオナニストw
746 :
2017/02/08(水) 20:10:43.25 ID:9HGTCoP8
リファクタリング前提の開発なんて小規模開発以外はやるものじゃないね
747 :
デフォルトの名無しさん
2017/02/08(水) 20:59:58.04 ID:ahyxJIg+
それを言うならプロトタイピングだろw
なんだよリファクタリング前提てw
748 :
2017/02/08(水) 21:04:39.44 ID:saIve44q
>>747
オナニー君まだいたの?
749 :
2017/02/08(水) 22:05:08.20 ID:EqksEKaR
>>746
> リファクタリング前提の開発なんて小規模開発以外はやるものじゃないね

設計に問題があるときどうしてるの?
問題があるっていうのは、最初の時点で間違っていた場合の他
機能追加などで最初の想定と変わってしまった場合

リファクタリングしないで、問題ある設計のまま
開発を続行するの?

大きい開発ほど最初に想定しなかった事態が起こるはずだけど?
750 :
2017/02/08(水) 22:42:04.56 ID:E3hlYujb
>>749
それをリファクタリングと言うのか
ただの上流への出戻り、やり直し、糞開発じゃないの

>>747
アジャイルって知ってる?オナニーくん
751 :
2017/02/08(水) 22:59:10.86 ID:EqksEKaR
>>750
> ただの上流への出戻り、やり直し、糞開発じゃないの

上流へ出戻りするのは良いんだが、
今のコードはどうするんだよ?捨てるのか?


リファクタリングというのは今のコードをよく知られている
手順を使って安全に(バグを入れることなく)変化させていくことをいう


リファクタリングの勉強をちゃんとした人なら、知っているはずだが
リファクタリングしないことを選択すべき理由として
作り直したほうが速い場合っていうのがある。

作り直したほうが早い場合はリファクタリングの哲学によって作りなおすが、
コードを安全に変化させたほうが早い場合は当然リファクタリングをする。

で最初の質問に戻るが、お前コードを修正したほうが早い場合でも
リファクタリングしないで、コードを捨てて作り直すって言ってんの?
それとも行き当たりばったりなただの修正を行ってバグ発生させるの?
752 :
デフォルトの名無しさん
2017/02/08(水) 23:15:25.00 ID:/T6I+uKy
現状それなりに動いているけど
将来性を考慮しての改善するのがリファクタリングでしょ

そもそもマトモに動いてないコードは問題外
753 :
2017/02/08(水) 23:18:57.65 ID:EqksEKaR
> 将来性を考慮しての改善するのがリファクタリングでしょ
YAGNIに反するからそれは違う。
その将来が絶対来るというのなら話は別だけど
754 :
2017/02/08(水) 23:22:55.16 ID:E3hlYujb
>>751
うーんw
いずれにしてもコードを捨てる捨てないに関わらず設計に問題があるものをその開発中に直すことをおれの界隈ではリファクタリングとは言わないね
おまえがそれをリファクタリングと言うのは自由なので好きにしてくれw
755 :
2017/02/08(水) 23:27:19.72 ID:EqksEKaR
>>754
俺が言ってるんじゃなくて世間一般の定義。

っていうか開発中とそうでないのが別れてる時点で
お前、前時代的だしなぁ。

お前なら一日に何十回もデプロイするような
ウェブアプリをどうやって変化させていくんだ?

「俺にはできません。」ですかな?w
756 :
2017/02/08(水) 23:31:13.83 ID:EqksEKaR
ちなみに、TDDでは最初にテストコードを書いて
それに通る最小限の実装を書く、その後リファクタリングを
行うというのを繰り返して開発するものので、

http://www.atmarkit.co.jp/ait/articles/1403/05/news035.html#025
> 開発中に直すことをおれの界隈ではリファクタリングとは言わないね


> 開発中に直すことをおれの界隈ではリファクタリングとは言わないね
というのはもぐり、無知レベルでしかないよ
757 :
2017/02/08(水) 23:31:50.65 ID:EqksEKaR
引用を間違えた

http://www.atmarkit.co.jp/ait/articles/1403/05/news035.html#025
>【5】テストを成功状態にしたままリファクタリングする
758 :
2017/02/08(水) 23:36:21.44 ID:E3hlYujb
うーんw
自ら話を反らしていくスタイルw
759 :
2017/02/08(水) 23:38:20.99 ID:EqksEKaR
それてないじゃん?w

それてるっていうのなら、戻していいよ。君の手で
760 :
2017/02/08(水) 23:53:10.75 ID:E3hlYujb
うーんww
そもそも少人数短期イテレーション開発におけるリファクタリングの話なんて始めからしてないのだがw
毎日デプロイするwebアプリ?そんな小さな話も全くしてないw
おまえが数億円契約の大規模開発をやったことないのはよくわかったw
761 :
2017/02/09(木) 01:52:04.00 ID:CNUBJX7I
>>760
大規模だからって何の自慢になると思ってるんだ?

大規模は別にどうでもいいよ
どういった開発をしているのかが重要だろ。

いくら金がかかっているからって
ろくでもないやつばっかり集めて人海戦術で
ひたすら効率の悪い開発方法をしている?
だとしたら自慢どころか恥だよね。

もっと規模とか金以外に自慢できることないの?
762 :
デフォルトの名無しさん
2017/02/09(木) 04:01:02.59 ID:VpXdxNl0
>>753
は?
while文よりfor文の方がわかりやすいね
って書き直す事のどこが機能追加なの?

読みやすくしておくことも未来への投資じゃね?
763 :
2017/02/09(木) 06:44:32.92 ID:IOSaScxB
リファクタリングに開発規模は関係ない
レガシーコードの山に頭抱えながら仕事するのも自由だし、好きにしてくれ
764 :
デフォルトの名無しさん
2017/02/09(木) 07:38:20.57 ID:W9c8fNbT
規模が大きい開発はクソコーダーがクソコードを量産してくるから俺様が随時コードを書き換えてやる

ってのが ID:E3hlYujb の主張
こういうリファクタオナニストに好きにさせてはいけない
765 :
2017/02/09(木) 08:20:04.14 ID:2NAFiD3Z
リファクタリングに必要な見積りを出してくれ
766 :
2017/02/09(木) 11:43:47.05 ID:qhoyYE05
>>765
これな
767 :
2017/02/09(木) 11:48:27.92 ID:qhoyYE05
>>764
そうじゃなくて作ってからリファクタリングなんてやってる暇があるなら先にレビューで潰すってことさ
それでも設計レベルでの変更が必要にるならレビュアもゴミだったってだけのこと
768 :
2017/02/09(木) 12:39:15.13 ID:Ra4XvV1b
本当に大規模開発やったことあるのか?
新規で作って作りっぱなしだったのか?
769 :
デフォルトの名無しさん
2017/02/09(木) 12:49:33.29 ID:2OmAEiex
>>767
それこそ規模の大小は関係ないわけだが
結局なにが言いたいのお前
770 :
2017/02/09(木) 13:07:11.30 ID:/WGpXuP3
>>769
関係ないことはない
設計レベルでの見直しをリファクタリンクを言うのであればそんなことがやすやすと可能なのは少規模開発だけ
771 :
2017/02/09(木) 13:11:02.24 ID:/WGpXuP3
話を戻すと開発中にそんな状況になるのを俺はリファクタリングとは言わん
リファクタリングとはもっと前向きなものだ

っていうことを>>750から何度も言ってるからだけなんだがねw
772 :
2017/02/09(木) 14:01:01.97 ID:Ra4XvV1b
じゃあ何のことをリファクタリングと呼んでるの?
773 :
デフォルトの名無しさん
2017/02/09(木) 14:27:10.00 ID:VpXdxNl0
そもそもファクタリングとは?
それをやり直すってことでしょ
774 :
2017/02/09(木) 15:01:34.48 ID:Lyr2GEHi
じゃあ逆に聞くけど設計から変えてUTのコードがそのまま使えるケースってどんなの?w
テストコードの書き換えが必要な改修は開発スキームとして事前にスケジュールに組み込まれるリファクタリングとは全く別ものだろww
775 :
デフォルトの名無しさん
2017/02/09(木) 15:14:26.88 ID:lnTHGhne
別にリファクタリングは個別のユニットテストに影響ないレベルとは限らないでしょ。
リファクタリング対象によってそこは取捨選択すべき。
776 :
2017/02/09(木) 17:19:48.49 ID:EPpoXydB
結論から言えば概念としてのリファクタリングは否定しないが、
リファクタリングのための工数なんて実際は取れないし、
そんな余計なリソースがあるなら他の事に回した方がいい
所詮暇を持て余した学生の戯言だよ
777 :
2017/02/09(木) 19:13:25.68 ID:Lyr2GEHi
>>775
いやだから話の前提が>>749だから選択も糞もないくやらないといけない状況でそれをリファクタリングとはいわねーって
もうええわww
778 :
2017/02/09(木) 19:41:42.20 ID:2NAFiD3Z
プロジェクトの開始時にリファクタリングの見積も出してね
オーバーした分はお金出せないからね
779 :
デフォルトの名無しさん
2017/02/09(木) 20:10:08.12 ID:VpXdxNl0
だからまずファクタリングの定義からしようか
それをやり直すってだけの話でしょ
780 :
2017/02/09(木) 20:29:21.19 ID:Ra4XvV1b
機能要件を満たすため
非機能要件を満たすため
オナニーするため
目的が何であろうとリファクタリングはリファクタリングですよ
781 :
デフォルトの名無しさん
2017/02/09(木) 21:09:00.44 ID:DXVOdvHd
オブジェクト指向でシステム開発するなら、リファクタリングは必須です。
クラスの設計、インターフェースの抽出・設計といったプログラミング前に
既に必要です。
782 :
デフォルトの名無しさん
2017/02/09(木) 21:09:16.18 ID:W9c8fNbT
>>771
> リファクタリングとはもっと前向きなものだ

ここへ来ていきなり精神論かよ
やっぱり頭沸いてんだろお前w
783 :
デフォルトの名無しさん
2017/02/09(木) 21:29:45.22 ID:l61bzEJu
とりあえず動くものを新規で作って書き換える場合か、すでに動いているもので、修正が入りまくって汚くなったものを整理するくらいしかない。

自由にいじくりまわすのをリファクタリングとは言わない。
784 :
2017/02/09(木) 21:35:33.02 ID:CNUBJX7I
>>762
> while文よりfor文の方がわかりやすいね
> って書き直す事のどこが機能追加なの?

while文よりfor文の方がわかりやすいねとか
俺は言ってない。お前が言ったことだ。

お前は、機能追加じゃない例を自分で出して
自分で自分にツッコミを入れてるだけなんだが、

何がしたいの?
785 :
デフォルトの名無しさん
2017/02/09(木) 21:39:19.62 ID:lnTHGhne
786 :
2017/02/09(木) 21:42:53.34 ID:CNUBJX7I
>>777
> いやだから話の前提が>>749だから選択も糞もないくやらないといけない状況でそれをリファクタリングとはいわねーって

お前根本的に間違ってるんだわ。

まず先に最初の話のツッコミ漏れを補完しておくとだな
>>749で設計に問題があるときはどうするのか聞いた。
これは言い換えると「やり直し以外の選択の余地がない例」として上げたんだよ。

それなのに、>>750
> ただの上流への出戻り、やり直し、糞開発じゃないの
やり直しすればいいじゃんって、お前アスペか?

やり直し以外の選択肢の余地がないことにたいして、
「やり直ししろ」ってそれは反論になってない
俺が意図してる答えだ

でな、リファクタリングかどうかっていうのは、手段なの
「糞もないくやらないといけない状況」のときに、
リファクタリングを使って、修正を行うのか
リファクタリングを使わずに、修正を行うかの話

ここまで言えば、お前が根本的に間違ってることが理解できるだろ?
お前はリファクタリングが手段であることをわかってない。どんな状況かはどうでもいい。
修正をするときに、どうやって修正するかの話だ。

お前は、リファクタリングしないで、行き当たりばったりで修正してバグを入れ込むんだろう?
俺はリファクタリング(わかりやすく言えばリファクタリングの本に書いてあるテクニック)を使って修正するんだよ
787 :
2017/02/09(木) 21:45:29.54 ID:CNUBJX7I
>>778
> プロジェクトの開始時にリファクタリングの見積も出してね

リファクタリングが手段であることを知れば、
「リファクタリング(手段)の見積もり」がおかしい言い方だとわかるだろう。

正しく言うならば「プロジェクトの開始時に修正の見積もだしてね」だ
修正にはバグだけじゃなくて仕様の追加や間違いによる修正も含まれる。


あとは修正するしかない状況で、行き当たりばったりで修正するか
リファクタリングで修正するかの違いなだけだ
788 :
2017/02/09(木) 21:46:27.58 ID:CNUBJX7I
>>776
> リファクタリングのための工数なんて実際は取れないし、
リファクタリングのための工数が取れなくて
リファクタリングを使わない修正であれば
工数が取れるっておかしくね?w
789 :
デフォルトの名無しさん
2017/02/09(木) 21:52:20.21 ID:lnTHGhne
https://estore.ohmsha.co.jp/titles/978427405019P

リファクタリングに工数がーとか言ってる奴はこれ特に読んで欲しい
790 :
762
2017/02/09(木) 21:55:31.20 ID:VpXdxNl0
>>784
ほらな
きちんと書いてないと
こうやって誤解されるわけだ
言いたかったのは

「現状while文で処理されていて問題ないけど
このケースはfor文の方がわかりやすいから書き直そう!」
どこに機能追加される余地があんの?
791 :
2017/02/09(木) 21:57:10.56 ID:CNUBJX7I
>>790
> どこに機能追加される余地があんの?
ないよ?

誰がそこに機能追加される余地があるって
言ってるの?

お前?
792 :
デフォルトの名無しさん
2017/02/09(木) 21:58:18.00 ID:lnTHGhne
>>791
>>753 こいつ
793 :
2017/02/09(木) 21:58:44.70 ID:CNUBJX7I
>>753には while とか for の話は
明らかに書いてないけど?
794 :
デフォルトの名無しさん
2017/02/09(木) 21:59:52.90 ID:VpXdxNl0
>>791
あのさー
YAGNIに反するって言ったのは誰なんですかね?
余計な機能はつけるなってことでしょ?
whileからforに書き換えるのに何か機能追加されんの?
795 :
2017/02/09(木) 22:01:15.92 ID: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.10 ID:lnTHGhne
ほんまやね。レス辿って明らかにおかしいのを見つけたがら言ったけどそれforのレスにかすりもしなかったわ。すまん。
797 :
2017/02/09(木) 22:06:33.30 ID:Lyr2GEHi
>>786
おまえ日本人か?w
798 :
2017/02/09(木) 22:08:07.52 ID:CNUBJX7I
下手に勘違いされると困るから補足しておくと、

汚いから修正するってだけならYAGNIでやるべきではないが、

その部分を修正していたり読む必要があるならば、
いつ必要しているの?今でしょ?ってことで
今すぐ必要としていることなわけだから、
そこを修正するのはYAGNIではない
799 :
デフォルトの名無しさん
2017/02/09(木) 22:25:26.99 ID:lnTHGhne
読まなきゃ汚いと思わないんだから、矛盾してるような気がするけど。
必要ないのに汚いコードを読み始める酔狂な奴が居るとしたら別だけど。
800 :
2017/02/09(木) 22:29:02.28 ID:CNUBJX7I
> 読まなきゃ汚いと思わないんだから
いや、コードメトリクスツールなどをつかえば
読まなくても、客観的に汚いとわかる
801 :
2017/02/09(木) 22:29:15.76 ID:Ra4XvV1b
>>797
いつになったら何のことをリファクタリングと呼んでるか書いてくれるの?
802 :
2017/02/09(木) 22:34:05.44 ID:Ra4XvV1b
汚いから直すってのもリファクタリングと呼ぶと思うけど、
汚いから直すってのは実際の開発現場じゃなかなか難しいと思うよ

その汚さが原因で性能が出ないとか、機能追加できない、し辛いって明確な理由があれば別だけどね
803 :
2017/02/09(木) 22:41:25.83 ID:CNUBJX7I
>>802
> その汚さが原因で性能が出ないとか、機能追加できない、し辛いって明確な理由があれば別だけどね

だから俺は聞いたんだよ?

そういうどうしても直さなければいけないときに
リファクタリングで安全に修正するのか?
それとも行き当たりばったりに修正してバグを入れるのか?って
804 :
2017/02/09(木) 22:43:53.46 ID:Ra4XvV1b
いや、俺に噛みつかれましても
805 :
2017/02/09(木) 22:45:29.16 ID:Lyr2GEHi
>>801
理解できる頭がないのに質問するなよw
何度も言ってるだろうがww
806 :
2017/02/09(木) 22:47:35.42 ID:CNUBJX7I
リファクタリングを行うタイミングを間違ってるんだよね

俺は何らかの機能修正とかでコードをいじるときに
関連するところを少しづつなおす
大抵が数行程度で10分もかからずに終わる


こまめに修正しないで、手遅れになってからやろうとするから
大規模になってしまって、別途工数が〜とかいう話になるんだよ。

手遅れになってしまったものを修正する工数がないからと
手遅れなコードのままさらにコードを追加するから
さらに手遅れになっていくんだろうが
807 :
デフォルトの名無しさん
2017/02/09(木) 22:59:39.83 ID:lnTHGhne
>>806
多分解ってると思うけどその言い方は誤解を生むと思うぞ。
リファクタリングと機能追加は明確に分けるべきで、リファクタリングして、テスト走らせて振る舞いが変わってない事を確認してから機能追加に入るべき
808 :
2017/02/09(木) 23:07:28.39 ID:Ra4XvV1b
>>805
他人の否定はしてるけど、自分では何も言ってないよ君
809 :
2017/02/09(木) 23:07:33.91 ID:2NAFiD3Z
リファクタリング=上腕二頭筋
810 :
2017/02/09(木) 23:12:13.46 ID:CNUBJX7I
>>807
うん。わかってる

> リファクタリングして、テスト走らせて振る舞いが変わってない事を確認してから機能追加に入るべき

どちらもあるよ。

機能追加してからリファクタリングする物の典型的な例がTDD
Red/Green/Refactor 通りの順番
811 :
デフォルトの名無しさん
2017/02/10(金) 00:46:58.66 ID:/WxwB06L
どんどん別の手法がまざっていく洗脳馬鹿
812 :
2017/02/10(金) 01:18:18.70 ID:+KYQgfiL
別の手法ってなんの話だ?
813 :
デフォルトの名無しさん
2017/02/10(金) 02:12:34.39 ID:/WxwB06L
>>810 のことだよ。
814 :
2017/02/10(金) 02:25:45.27 ID:+KYQgfiL
> Red/Green/Refactor 通りの順番

これのことか?

Refactorはリファクタリングのことだよ
別の手法じゃなくて全く同じもの
815 :
2017/02/10(金) 12:06:41.01 ID:QRGeJWes
1.機能追加前にテスト書く
2.追加コード書く
3.テスト
4.ダメならテストに通るまでコードいじる

もしかしてこれもリファクタリング扱いしてるの?
816 :
2017/02/10(金) 12:38:04.04 ID:+HewTgrG
>>815
それはRed→Greenのところでしょ…
817 :
2017/02/10(金) 21:26:25.38 ID:1oBD+cZp
 最近、特定のフラグ変数に関するif文の山をswitch構文に清書し直したんだけど、これってリファクタリング?
818 :
デフォルトの名無しさん
2017/02/10(金) 21:34:25.32 ID:/WxwB06L
>>816
それさ、リファクタリングのいち定義であってリファクタリングではないから。
819 :
デフォルトの名無しさん
2017/02/10(金) 21:35:50.89 ID:/WxwB06L
>>817
そのif文が変ならな。まともなif文なら書き換える必要がない。
820 :
デフォルトの名無しさん
2017/02/10(金) 21:37:35.22 ID:/WxwB06L
>>817
ただswitch文にすると仕様変更時にswitch文では対応できなくなる可能性があるので逆かもしれない。
821 :
2017/02/10(金) 21:42:51.54 ID:+KYQgfiL
>>817
確かにswitchでかけるならばifよりswitchの方が少しだけ見やすくなるけど、
大抵はリファクタリングにはならないよ
巨大なswitchもリファクタリングすべき対象となる

何がダメなのかというと比較の回数がifのときと変わってないから。
比較が多い=複雑なので、これは単なる書き方の違いでしかなくて
リファクタリングとまではいかない。重要なのは比較回数

じゃあどうすべきかというと、一番簡単な方法は
関数テーブル(ルックアップテーブル)を使う方法
大量のswitchでの比較が条件が揃えば0個にまで減る
822 :
2017/02/10(金) 21:46:49.78 ID:+KYQgfiL
>>818
> それさ、リファクタリングのいち定義であって


> Red/Green/Refactor 通りの順番
がリファクタリングの定義に見えるんだ・・・

ここにはどこにもリファクタリングの定義なんてものは
書いてないんだが

>>816が言ってるのは、Red→Greenでやる内容は
リファクタリングじゃないよって言ってるだけでしょ

俺からも補足するが、リファクタリングは
動いているコードを、動いているコードに置き換えることだよ。

修正前と修正後のどちらかが動いていなければ
それはリファクタリングではない
823 :
2017/02/10(金) 21:57:11.80 ID:+KYQgfiL
* Green
  1.機能追加前にテスト書く
* Red
  2.追加コード書く
  3.テスト
  4.ダメならテストに通るまでコードいじる
  5.テストに通った。やったー完成だ! ←ふざけんじゃないよ。なんだこのコピペだらけで無駄がばかりのクソコードは
* Green
  6.リファクタリングする
  7. 読みやすくなりました。←このコードならレビューする気になる。シンプルあとで読んだ人も理解しやすいだろう
  8. 完成、1に戻る
824 :
2017/02/10(金) 22:00:06.48 ID:+KYQgfiL
現実にはこの5. テストに通っただけの状態で
完成としてしまうやつが多いんだよな。

そういうコードで許される環境っていうのは
コードレビューが行われていない。
コードを見ずにテストに通ればOKとしてしまう環境

そして向かうはデスマーチw
825 :
デフォルトの名無しさん
2017/02/10(金) 22:14:40.62 ID:/WxwB06L
駄目だこりゃ。なんでそういう手順がリファクタリングなのか?
826 :
2017/02/10(金) 22:20:09.64 ID:+KYQgfiL
>>825
お前が理解してないだけだよw
827 :
2017/02/10(金) 22:33:35.95 ID:+HewTgrG
Refactorとリファクタリングが同じ意味の言葉だってのが伝わってないのかも知れないな
828 :
2017/02/10(金) 22:38:11.34 ID:+KYQgfiL
あ、はい間違えました

> 6.リファクタリングする

これじゃ リファクタリンギング ですねw
829 :
デフォルトの名無しさん
2017/02/10(金) 22:59:58.18 ID:/WxwB06L
このスレってそもそも特定のリファクタリング作業のスレッドか。話がかみ合わないわけだ。
830 :
2017/02/10(金) 23:48:55.17 ID:+KYQgfiL
誰が特定のリファクタリング作業の話をしてるんだ?
誰がはどうでもいいや「特定の」ってどれのことだよ?
831 :
2017/02/11(土) 00:00:12.78 ID:o1zrWG0U
TDDの例出したからTDDに限定した話だって勘違いしてるんでしょ
832 :
2017/02/11(土) 00:04:14.10 ID:p/3UeWk3
>>829
「特定の」がなにか言うだけだよ。
お前がちゃんと考えて発言しているなら
簡単な質問なはずだが?

もっとも俺はお前が何も考えてないってことを
あぶり出すために「特定の」が何か聞いたんだけどなw
833 :
デフォルトの名無しさん
2017/02/21(火) 23:44:51.93 ID:8I0Tfvzv
お、あぶり出してるねえ
834 :
2017/02/22(水) 01:09:25.60 ID:TiP/fttU
このスレの存在忘れてたわw
なんだ逃げたのかw
835 :
2017/02/22(水) 12:59:43.56 ID: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.56 ID:G3lxPXWh
定義から定まってないからなリファクタリングって
いや、実在するのか?
837 :
2017/02/23(木) 22:07:14.34 ID:Ka1UMSVA
殆どの用語は定義なんか定まってないよ
数学でさえ、ある用語に対して数学ではこういう定義で
使いましょうと決めているだけ
838 :
2017/02/26(日) 20:54:48.09 ID:wNjUkQs3
ソースを組んだときと今とでチンコのポジションを若干変更した
これがリファクタリングである
839 :
デフォルトの名無しさん
2017/02/26(日) 22:44:41.65 ID:zOBszuQK
特定の統合開発環境のリファクタリング機能をリファクタリングだと言ってるやつはいなくなったなw
840 :
2017/02/27(月) 01:14:12.49 ID:IXzsv4Rb
俺の中では変数名の変更=リファクタリング

Visual Studioの機能名がそうだったから
841 :
2017/02/27(月) 01:49:20.76 ID:j4xHFZFw
俺の中では、マーチン ファウラーのリファクタリング本(古い方)に
のっているのがリファクタリング
変数名の変更ももちろんのってる

後はそのリファクタリングをどれだけ簡単に
正確に行えるかの違い。

ローカルスコープ程度で済むものなら良いけど
スコープが広い部分のリファクタリングは手動でやるのは大変
それを自動的に間違いなく行える、静的型付け言語+IDEの力は偉大
842 :
2017/02/27(月) 02:49:09.61 ID:Ydy+ZWkb
あるスコープの中で外部から見た仕様を変えずに内部の設計を変えるのがリファクタリング
843 :
2017/02/27(月) 17:22:25.25 ID:IXzsv4Rb
>>842
それではチンコのポジションも
844 :
2017/02/27(月) 22:10:17.46 ID:Ydy+ZWkb
チンポジ設計
326KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: