リファクタリングをただのコード修正と思ってる人へ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2010/05/29(土) 17:25:56まずな、リファクタリングでは機能追加・修正は行わない。
動作はまったく同じでコードをきれいに書き換えること。
書き換えるといっても、これなら同じ動きだろ？って推測でやってはいけない。
まずテストを書く。ユニットテストをできるように、
単一のクラスでインスタンスを作る。
汚いコードなのだからたいていは依存関係のせいで単一ではクラスが生成できない
それを生成するために、クラスの動作を書き換える。
といっても元のコードは修正しない。継承やプリプロセッサを使って
依存関係を断ち切るために既存のコードを上書きする。
どうしてもそれが不可能な場合には、決められた手順で最小のコード修正を行う
そうやって既存のクラスのユニットテストを行う。
それでやっとリファクタリングが行える。
既存のクラスのユニットテストを通るように新たなコードに修正、
もしくは新規作成して置き換える。
この手順と考え方を守ってないのはリファクタリングではない。
で？
0002デフォルトの名無しさん
2010/05/29(土) 17:27:430003デフォルトの名無しさん
2010/05/29(土) 17:33:05プロセスだ。やり方だ。
コードがきれいになったからリファクタリングをしたと
思うのは間違いだ。
バグを入れないのは当たり前だが、コードの動作を変えずに
決められたた手順をもちい、クラス間の依存関係を減らすことで
ユニットテストできるようにする作業がリファクタリングだ。
テストコードが増えてなければ、それはコードを書き直しただけで
リファクタリングとは呼ばない。
リファクタリングブラウザとは、このリファクタリング作業を簡単にするための
ツールであり、リファクタリングブラウザの機能を使った作業（名前変更など）そのものは
リファクタリングではない。
0004デフォルトの名無しさん
2010/05/29(土) 17:41:18新たな設計方針にたどり着ける。
テストしやすい設計。
クラスを単独で生成できるように
依存関係（クラスが別のクラスを使用するなど）が
少ない設計。
publicメソッドの引数には、なるべくクラスを使わない。
クラス内部で別のクラスを生成しない（必要な場合は外部から渡す）
0005デフォルトの名無しさん
2010/05/29(土) 17:59:47全部main(String [] arg)で作るんですねわかりま…
0006デフォルトの名無しさん
2010/05/29(土) 18:00:340007デフォルトの名無しさん
2010/05/29(土) 18:07:01こういう考えの流れになっていないとだめ
リファクタリングしたい
↓
リファクタリングするにはユニットテストコードが必要
↓
既存のコードを（なるべく）修正せずにテストするにはどうするか。
↓
（依存関係が無ければ簡単にテストコードを書けるが、たいていはそのままではテストコードかけないので）
既存のコード・クラスをどうやって他のコード・クラスとの依存関係から分離させるか。
この分離が一番大変な作業。
分離させることに成功したらあとは簡単。
ユニットテストを書いてコードを修正すればよい。
0008デフォルトの名無しさん
2010/05/29(土) 18:17:410009デフォルトの名無しさん
2010/05/29(土) 18:24:16名前変更（リファクタリングブラウザの機能）というのは、
例えて言うのなら小説を書く（リファクタリング）ときの文房具（リファクタリングブラウザ）と
同じ関係だよ。
文房具を使って文字を書いたり、消しゴムで消したりという作業は、
小説を書くための道具を使っているわけだが、
本質的には小説を書く行為そのものではない。
0010デフォルトの名無しさん
2010/05/29(土) 23:54:350011デフォルトの名無しさん
2010/05/30(日) 00:14:58その通りです。
何か嫌がらせされてる気がする。
001211
2010/05/30(日) 00:52:51ソフトウェアテストで良い本ありませんか。
0013デフォルトの名無しさん
2010/05/30(日) 02:51:03レガシーコード改善ガイド
0014デフォルトの名無しさん
2010/05/30(日) 10:13:00言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
0015デフォルトの名無しさん
2010/05/30(日) 18:16:22だと思った
>>1の一行目で分かった
0016デフォルトの名無しさん
2010/05/30(日) 19:47:36コーダの思いがこもってるんだからあ
0017デフォルトの名無しさん
2010/05/30(日) 22:16:420018デフォルトの名無しさん
2010/05/30(日) 22:34:43釘宮風にたのむ
0019デフォルトの名無しさん
2010/05/30(日) 22:44:120021デフォルトの名無しさん
2010/05/31(月) 21:06:25チルノのパーフェクト算数教室？
0022デフォルトの名無しさん
2010/06/01(火) 01:55:41これは、コード修正じゃなくてりふぁくたりんぐなんだから！
ちゃんと勉強してから出直しなさい！
なによ……わざわざしてあげるんだから…何か言いなさいよ！
あっ、べ、別にアンタのためにやるんじゃないんだから、
勘違いしないでよね！ばーかばーか！
0023デフォルトの名無しさん
2010/06/01(火) 12:35:24目的に即してれば、細かいことは違ったって問題ないのに、それは手順としてあーだーこーだ・・・みっともない。
0024デフォルトの名無しさん
2010/06/04(金) 19:59:43遅レスですまん
ファウラーの「リファクタリング」は必読
「パターン指向リファクタリング入門」はオススメ
あと、関連してデザインパターン関連の本を読んでおくといいかも
0025デフォルトの名無しさん
2010/06/19(土) 17:52:31そもそもリファクタリングするために必要なユニットテスト技術も未熟だからか。
日本は技術レベルが低いよ。
愚痴はここまでにして、データベースのフィールドってリファクタリングするのに
厄介だよね。ただの文字列だと名前変更に追尾できない。
それはO/Rマッパー使ってもそうだけど、データベース関連はリファクタリングを念頭に置くと、
SQLとデータベースからクラスとして自動生成したほうがいいのかもしれない。
このクラス（仮にDBCLASSとする)ではデータベースのフィールドが一メソッド（プロパティ）になる。
これはビジネスロジックを書くいわゆるモデルではなく、データベースの構造をあらわすだけのクラス。
DBCLASSのプロパティを変更しても、DBCLASS内部でアクセスしているデータベースのフィールド名は変わらない。
逆にアクセス先のデータベースのフィールド名を変えると、DBCLASS内部でアクセスする
データベースのフィールド名も自動的に変わる。
0026デフォルトの名無しさん
2010/06/19(土) 17:56:15フォームのクエリー名にも当てはまるんだよな。
要はデータではなく、意味がある名前であるキーを
ただの文字列として扱うのはやめようということ。
フォームのクエリー名を変更したら、
自動的にコードの名前に反映させたい。（逆もあり）
そのためのコードの生成機能が必要だよ。
0027デフォルトの名無しさん
2010/06/19(土) 18:14:03いまだにフォームの設定かいたら、その部分のコードが自動生成されないの？
みんなふつうにやってるとおもったんだが気のせいであったか。
0028デフォルトの名無しさん
2010/06/19(土) 18:22:48何の話？
自動生成されたとしても、それを文字列で扱っていたらだめだよ。
ようはリファクタリングブラウザで、それがキーとして認識されるような形になってほしい。
リファクタリングだけじゃなくて、コード補完もできるようになるから間違いが減るしね。
コンパイル時点でのエラー検出もおこなえるようになる。
0029デフォルトの名無しさん
2010/06/19(土) 22:20:10いつも波風が立つのはなぜだろう
0030デフォルトの名無しさん
2010/06/19(土) 22:24:56理解してないからだろ
こういう成功例を見せながら地道に説得していくしかないんじゃないの？
ttp://ascii.jp/elem/000/000/497/497905/
0031デフォルトの名無しさん
2010/06/19(土) 23:08:32いい記事だった。
そこの社長ぐらい、うちんとこの社長も柔軟な頭だったらいいんだがなあ
0032デフォルトの名無しさん
2010/06/20(日) 02:34:06例えば平屋を拡張して2階、3階と増やしていったら、
1階にも手に入れないと、いつか倒壊しますよね?とか。
0033デフォルトの名無しさん
2010/06/20(日) 06:23:440034デフォルトの名無しさん
2010/06/20(日) 15:29:28やってみたら意外と倒壊しないんじゃないの？、とか
0035デフォルトの名無しさん
2010/06/20(日) 18:34:34だから目先のコスト増に怯えて将来の飛躍の芽を摘んでしまう。
0036デフォルトの名無しさん
2010/06/20(日) 20:56:47理解のない人にはリファクタリングしているとはあえて言わないのも手だと
Ruby版リファクタ本に書いてあって目から鱗だったわ
0037デフォルトの名無しさん
2010/06/23(水) 13:48:440038デフォルトの名無しさん
2010/06/24(木) 08:19:110039デフォルトの名無しさん
2010/06/27(日) 21:52:39どうもそいつはリファクタリングしている=暇そうにしていると思っているっぽい。
0040デフォルトの名無しさん
2010/06/27(日) 22:30:050041デフォルトの名無しさん
2010/06/27(日) 22:31:35http://www.infoq.com/jp/news/2010/06/decision-to-refactor
0042デフォルトの名無しさん
2010/06/28(月) 02:42:24>リファクタリングしている=暇そうにしていると思っているっぽい。
正解だから困る
0043デフォルトの名無しさん
2010/06/29(火) 21:31:04組み込み向け「軽量Ruby」と「Rubyチップ」、福岡県が経産省の事業で開発へ
ttp://itpro.nikkeibp.co.jp/article/NEWS/20100628/349693/?ST=oss
的外れな提示だったらすまそ。
0044デフォルトの名無しさん
2010/06/30(水) 14:19:540045デフォルトの名無しさん
2010/06/30(水) 15:22:41組み込み機器のほうの話なのか
0046デフォルトの名無しさん
2010/07/01(木) 01:28:430047デフォルトの名無しさん
2010/07/01(木) 09:36:51いちおうLuaはヤマハのルータなんかにも使われているぽい。
0048デフォルトの名無しさん
2010/09/15(水) 19:43:18http://www.infoq.com/jp/news/2010/09/large-scale-refactoring
0049デフォルトの名無しさん
2011/06/01(水) 22:25:20.30Ａ〜Ｚまであるクラスの共通処理をＰクラスとして纏めたとするわな
したら、ＰクラスをいじるたびにＡ〜Ｚまでの影響範囲を調べなあかんのやで
仮にＡにしか関係しないＰに入ってしまった共通処理を弄るのだって
一度結合したらはがしてＡクラス特有の処理としてＰクラスからＡクラスを避ける処理なんて
結構、邪魔な処理になるで
それでもＰとしてまとめてしまったらＡ〜Ｚまでサポートしていかなあかんのやで
リファクタリング、結構、だが、誰がこの未来を予測できる？
Ａ〜Ｚまでの共通処理が走ってるＰクラスを蹴飛ばしてＰＡクラスを新しく作って
Ａ−ＰＡ、Ｂ〜Ｚ−Ｐの関係を新しくぶった切るような切込みはできんやろ？
せいぜいＰの処理にcase Aを入れるような修正が精一杯やないか？
今後を考えてリファクタリングなんてする意味があるんか？
0050デフォルトの名無しさん
2011/06/01(水) 22:28:19.38自動テストが伴わないものはリファクタリングとは呼ばない。
0051デフォルトの名無しさん
2011/06/01(水) 22:28:23.130052デフォルトの名無しさん
2011/06/01(水) 22:38:24.11いや、上で書いたのはあくまで例だよ
上の例は処理をまとめることによって明らかに構造が汚くなってるよね？
この先もまとめたＰクラスにＡ〜Ｚへのどれかの追加が入るたびに
case B、case C・・・と追加されていくだろうね
そのときＰクラスを消滅する選択肢は誰か選べるんだろか？
こーゆーのってさ、その時点ででは確定しなくね？
じゃ、リファクタリングってなんのためにするの？
って根本的なところに目を向けたときに次の開発をしやすくするためでしょ？
したら、その仕様書もなしでリファクタリングをするってことは
仕様書もないのにプログラムの構造を「俺が好き」なだけの構造にただ意味もなく
書き換えてるだけのマスターベーションなんだよ
0053デフォルトの名無しさん
2011/06/01(水) 23:55:42.31case B、case Cとなるようなまとめ方はアフォがやるものだろ。
それはリファクタリング以前の問題。
0054デフォルトの名無しさん
2011/06/02(木) 06:38:02.16ほうほう、それじゃ上記の例でＰの共通部分にＡのみに変更がかかったらどう修正する気？
0055デフォルトの名無しさん
2011/06/02(木) 08:30:37.53Aが自前で実装すればいいんじゃね
それか、Pが取る引数を工夫して柔軟な対応ができるようにする
0056デフォルトの名無しさん
2011/06/02(木) 08:38:55.65Aが自前で実装するように戻す。
あとそういうのは例えばStrategyパターンを使うべきで、共通化するものじゃない。
それすら分からないなら幼房。
0057デフォルトの名無しさん
2011/06/02(木) 21:05:01.86>Aが自前で実装
だが、現実は絶対にcase Aを入れる
自分のソース見てみろ
今回は俺が逃げ道塞いだから自前で実装って言っただけだろ？ｗ
正気に戻ればＰクラスなんてつくらねーんだけどな
0058デフォルトの名無しさん
2011/06/02(木) 22:24:39.31ガキみたいなこと言うなよ池沼
0059デフォルトの名無しさん
2011/06/02(木) 22:30:46.12ほかに影響に与えずに拡張なんていくらでもやりようがあると思うよ
0060デフォルトの名無しさん
2011/06/03(金) 04:53:30.73いや、その場面でcaseとか、既にそういう実装だった場合を除いてしないと思うが…
0061デフォルトの名無しさん
2011/06/03(金) 06:40:24.29違うな
大抵の場合、外部とのやりとりをＡ〜Ｚまでまとめない一心でＰクラスで作ってしまうから
Ａだけ切り離してもインターフェースがＰを通しているのでＰにＡへの変更を吸収してもらうほかないって感じになってるはず
じゃないとまとめたうまみないしねｗ
0062デフォルトの名無しさん
2011/06/03(金) 08:28:45.65おまえは統失か。
0063デフォルトの名無しさん
2011/06/03(金) 08:32:19.791+1は？と聞かれてみんなが2と答えたら、田んぼの田だやーい間違った間違ったと
はしゃぐ鼻水垂らしたガキにしか見えないんだが。
0064デフォルトの名無しさん
2011/06/03(金) 12:43:00.66せめて反論しろよ(笑)
0065デフォルトの名無しさん
2011/06/03(金) 20:59:55.04>変更を吸収してもらうほかないって感じになってるはず
想像と主観だけ。
0066デフォルトの名無しさん
2011/06/03(金) 22:24:10.95でFA
0067デフォルトの名無しさん
2011/06/03(金) 22:29:04.53自分が何が分かってないかすらわかってない
0068デフォルトの名無しさん
2011/06/03(金) 22:47:12.11具体的な反論よろしく
0069デフォルトの名無しさん
2011/06/03(金) 23:03:07.11>>49=>>68が具体的なコード出せ。そうしたら反論してやる。
まあ、コーダー未満の池沼だから出せないだろうが。
0070デフォルトの名無しさん
2011/06/03(金) 23:41:04.87わかってないのは君だけじゃないの？
無駄だってわかりつつやるとお金もらえるからみんなやってるだけだよ
「なんのためにするリファクタリングなのか？」
って考えたらすぐに自分のやってることの無意味さに気がつくはず
現状の設計とマッチしてないから合わせるならわかるけど
それは開発段階で気がつくただの不具合だよね？
将来どうするのか？もわからないのにどうしてコードに手を入れられるの？
仕様書無しでコードに手をいれるのはダメだダメだあれほど言ってたのになんでこういうオナニーは好きにやっちゃうの？
目的がわからないのに最適（？）なコードなんてわかるわけないじゃない
なんのためのリファクタリングなの？
すべてがおかしい、でもお金になるし偉い人もやってるからやる
ただ、それだけのもんだよこれは
0071デフォルトの名無しさん
2011/06/03(金) 23:56:03.20やあ幼房。>>49を読んで意味が分かるのは池沼のおまえだけだ。
0072デフォルトの名無しさん
2011/06/04(土) 00:49:50.56うっとおしいからやめろよ
変な言葉も聞きなれない横文字も使ってないし誰でもわかる内容だ
内容の意味がわからないのは経験が浅いからだろ
0073デフォルトの名無しさん
2011/06/04(土) 06:49:03.11日本語でOK。
0074デフォルトの名無しさん
2011/06/04(土) 20:32:27.750075デフォルトの名無しさん
2011/06/04(土) 21:55:36.94プログラム中で使用する文字列をすべてヘッダで#define切っちゃうのとかよくいる
使うその場に直接書いたほうがいいことに気がつくのはいつのことだろうか？
0076デフォルトの名無しさん
2011/06/04(土) 22:44:23.36聞きかじりで行儀の良いとされる作りにしようとして
多重定義したり実際の文字列探すまでが長かったりする
くそみたいな所が多すぎるからそう感じるんだろ
0077デフォルトの名無しさん
2011/06/04(土) 22:51:42.66根拠は？
0078デフォルトの名無しさん
2011/06/04(土) 23:04:54.02意味がねぇからさ
ソースをみた瞬間に文字列が直接書いてあればその時点で意味がわかる
それを#defineきったら今度は命名した奴のセンスに丸投げすることになる
それが必ずしもわかりいい名前をつけてくれるとは限らない
また、複数個所でこの文字列を使うことがあったとして・・・いや・・・ないだろ？ｗ
あるならなにかおかしいんだｗ
文字列の場合、数値とはちょっと違う事情があってこういう定数を#defineを切るのはあまり意味ない
0079デフォルトの名無しさん
2011/06/04(土) 23:07:46.71また、数値の場合も俺は#defineを切る意味がないと思ってる
こんなこというとすぐに頭に血を上らせてソースでいきなり出てきた数値の意味が〜云々で怒るやつがいるが
俺はそうじゃなくてソースを読んで出てきた数値がわかるようなソースを書くべきだと思ってる
ちゃんとインスタンスの生成箇所をしっかり制御すればそもそもプログラム全域に一つの値が
複数使いまわされることなどほとんどない（はず）
数値計算（3.1415・・・）ですら特定のファイルにまとまる
しかし、プロジェクトにグローバルインスタンスホルダー（大域変数セット）などあると俺の言ってることは全く理解不能だと思う
0080デフォルトの名無しさん
2011/06/05(日) 00:50:06.75責務やカプセル化の話と、可読性とはイコールではないだろーに。
自分の説の論理的な飛躍に気づけないのか？
0081デフォルトの名無しさん
2011/06/05(日) 07:21:48.46「ちゃんとインスタンスの制御をしっかりすれば複数箇所に出てくることはほとんどない」
まともな名前すら付けられん人間が「しっかりとしたインスタンスの制御」なんてやると思うかい？
0082デフォルトの名無しさん
2011/06/05(日) 07:49:17.22インスタンスの管理なんてやる必要があるのはグローバル変数使ってるからだろ？
0083デフォルトの名無しさん
2011/06/05(日) 07:54:59.13だとすれば
＞ちゃんとインスタンスの生成箇所をしっかり制御すればそもそもプログラム全域に一つの値が
＞複数使いまわされることなどほとんどない（はず）
ってのはグローバル変数使ってる前提なのか
0084デフォルトの名無しさん
2011/06/05(日) 08:21:32.31なんでそうなるの？
いままでグローバル変数にばっかたよってるからそういう脳みそしかないんでしょ？
0085デフォルトの名無しさん
2011/06/05(日) 09:03:52.51管理が要らないのか要るのか、どっちなのさ
0086デフォルトの名無しさん
2011/06/05(日) 09:31:51.48それとグローバル変数がどうして関係あると思ったの？
0087デフォルトの名無しさん
2011/06/05(日) 09:39:59.44それは>>82に言ってよ
0088デフォルトの名無しさん
2011/06/05(日) 09:43:54.09なにが「だとすれば」なの？
馬鹿だからグローバル使うしか方法わからないだけじゃない？
いままでプログラム組んでてこの程度ってすごくみじめ
0089デフォルトの名無しさん
2011/06/05(日) 10:04:45.71何故にインスタンスの制御とかの話になったの？
要らないんでしょ？
0090デフォルトの名無しさん
2011/06/05(日) 12:27:20.48グローバル変数使わなければね
俺の言ってることなにか矛盾してる？
0091デフォルトの名無しさん
2011/06/05(日) 12:35:52.01「何故」と理由を聞いてるのだが
0092デフォルトの名無しさん
2011/06/05(日) 12:53:18.34あんまり気にしなくていいよ
「ちゃんとインスタンスの生成箇所をしっかり制御すれば」＝「グローバル変数なんて使うほどお馬鹿じゃなければ」
って意味だからｗ
0093デフォルトの名無しさん
2011/06/05(日) 14:26:48.94ちょっと待て、たかがグローバル変数を使わないだけのことを
「ちゃんとインスタンスの生成箇所をしっかり制御」
なんて仰々しく書いてたのか
0094デフォルトの名無しさん
2011/06/05(日) 14:28:38.99仰々しく書いたつもりはないけど
君にはできないことだよねｗ
0095デフォルトの名無しさん
2011/06/05(日) 15:03:32.48何故そう思った？
0096デフォルトの名無しさん
2011/10/09(日) 01:02:25.280097デフォルトの名無しさん
2011/10/09(日) 04:44:50.430098デフォルトの名無しさん
2011/10/09(日) 12:05:06.670099デフォルトの名無しさん
2011/10/09(日) 18:39:07.21たとえば、多角形を表示するプログラムがあったとする。
それは実際は三角形を表示するプログラムを反復実行してるとする。
三角形を表示するプログラムは、線を表示するプログラムを反復実行してるとする。
線を表示するプログラムは、点を表示するプログラムを反復実行してるとする。
すると、
点を表示するプログラムを、高速に書き換えれば、
これに依存した全てのプログラムが、その内容を変更しなくとも、高速化する。
ってのがリファクタリング。
これのポイントは、修正したのは点を表示するプログラムだけで、それ以外は一切変更していないのに、他も高速化できること。
このためには、インターフェースを極力保ったままで、中身だけを変更することが重要になる。
これがリファクタリングと、普通のコード修正との違い。
0100デフォルトの名無しさん
2011/10/09(日) 18:57:05.080101デフォルトの名無しさん
2011/10/09(日) 19:57:12.25近いが微妙にはずれている。
リファクタリングと高速化は無関係。
リファクタリングした結果、高速化することもあれば
（他にメリットがあるならば）逆に遅くなることもある
インターフェースも変えないこともあれば変えることもある。
リファクタリング本にもしっかり、「インターフェースを変えるリファクタリング」が載っている。
リファクタリングの目的はアプリ全体の動きを変えずに、ソースコードを綺麗に改善すること。
ただこの目的を達成するために、適当に修正するのとリファクタリングとでは違うものがある。
それはリファクタリングはちゃんとした手順でやるものだということ、
この手順に従うことが、修正とリファクタリングの違い。
どういった手順があるかは、リファクタリング本に書いてある。
この手順に従って修正することでバグを入れずに修正することが可能になる。
0102デフォルトの名無しさん
2011/10/09(日) 23:20:59.42高速化がリファクタリングだとは言っていないだろ。
0103デフォルトの名無しさん
2011/10/09(日) 23:59:37.52I/F変えたら機能変更だろ。
リファクタリングの範囲をどこまで取るかであって
その範囲で内部I/Fは変わることがある。
手順がどーのだって、効果的な手法がそうだってだけで、
ある作業がリファクタリングかどうかの判断に手順は関係ない。
0104デフォルトの名無しさん
2011/10/10(月) 00:31:27.92> I/F変えたら機能変更だろ。
え？ そんな事言ってもなぁ。
インターフェースを変えるリファクタリングはたくさんある。
メソッドの移動、クラスのインライン化、メソッド名の変更
引数の追加、引数オブジェクトの導入、メソッドの隠蔽
メソッドの引き上げ、階層の平坦化、継承の分割、他
リファクタリングの目的は、高速化という今すぐに効果があるメリットのためではなく、
過去にその場しのぎで対応したコードの修正とか、設計上まずいコードの修正とか
過去の負債、将来への投資として行うものだよ。
設計がまずい＝インターフェースがまずいってことはよくある話で、
コードを改善するためには、インターフェースを変えなければいけないということも当然ある。
0105デフォルトの名無しさん
2011/10/10(月) 00:40:22.190106デフォルトの名無しさん
2011/10/10(月) 00:53:59.260107デフォルトの名無しさん
2011/10/10(月) 01:04:25.82> I/F変えたら機能変更だろ。
インターフェースが機能になってるのは
ライブラリぐらいなもんだろ。
システム（アプリ）の動作さえ変えなければ
リファクタリングでインターフェース変えたっていいんだよ。。
インターフェースが変わりますって他の開発者への通知が
必要なことがあるかもしれないが、それは、通知すればいいだけの話。
それが世界中巻き込んで大変なことになろうが、
社内の一部だけしか関係ない小さなものだろうが、
「やってはいけないこと」ではない。
0108デフォルトの名無しさん
2011/10/10(月) 12:55:38.15＞必要なことがあるかもしれないが、それは、通知すればいいだけの話。
幸せな環境だ・・・
0109デフォルトの名無しさん
2011/10/10(月) 15:07:45.53かわいそうな環境の人？ｗ
そういう場合に、古い関数を
DeprecatedやObsoleteと書いて
リファクタリングする方法もあるよ
0110デフォルトの名無しさん
2011/10/10(月) 15:29:15.75Java PGは可哀想な子だからな
0111デフォルトの名無しさん
2011/10/10(月) 15:31:03.21どの言語でもやってることだろ。
なんかこう、俺とは一段以上 下のレベルの
奴しか見当たらんよなｗ
0112デフォルトの名無しさん
2011/10/10(月) 15:49:03.28何故ならインターフェースなどそう簡単に変更できないからだ。
それなのに
> 必要なことがあるかもしれないが、それは、通知すればいいだけの話。
のような事を書くほど低レベルのPGはJava PGだけだと予想して釣ってみたが、
やっぱりその通りだったねw
0113デフォルトの名無しさん
2011/10/10(月) 15:55:41.960114デフォルトの名無しさん
2011/10/10(月) 16:24:50.97意味がわからんｗ
インターフェースが簡単に変更できないからって、
絶対に変更できないわけじゃないだろ。
お前頭が硬すぎじゃね？
0115デフォルトの名無しさん
2011/10/10(月) 16:48:43.880116108
2011/10/10(月) 19:15:25.35若干かわいそうな環境かも。
機能毎に縦割りでリーダーが立ってて
「こっちは機能追加が進んでて人居ない」とか
「影響が大きい」とか言われて
とてもじゃないが変えられない。
それでも自担当の部分だけでもリファクタリングする工数が
貰えるだけマシなのかも知れんけどね。
0117デフォルトの名無しさん
2011/10/10(月) 21:13:00.47privateメソッドを修正するだけでもJAVADOCの修正とかユニットテストが更新されるからって
チーム内でそれを拒む人いるんだよなー
ってか、お前が俺のソースコピペして、俺がその責任背負わなくなくなるのが嫌なんだろｗｗｗどうせｗｗｗ
0118デフォルトの名無しさん
2011/10/25(火) 13:23:05.69http://www.infoq.com/jp/news/2011/10/thinking-and-refactoring
0119デフォルトの名無しさん
2011/10/29(土) 00:57:02.72設計ミスならリファクタリングという形で手を出すべきじゃないし
汎用性の向上にしても次の開発やバージョンアップの仕様書があってこその修正だ
単純にリファクタリングってのが何を目的としてるのかどの文献を読んでもまったく意味不明
0120デフォルトの名無しさん
2011/10/29(土) 03:24:37.60でっていう
教えてほしいならそう言えよｗ
そうでないのなら、やり方はひとつじゃないんだし、お前の好きなようにやれば？
0121デフォルトの名無しさん
2011/10/29(土) 05:48:50.42じゃあ、質問だけど
これは何を目的とした作業なの？
0122デフォルトの名無しさん
2011/10/29(土) 11:34:19.34書いたソースが自分たちのものになるのかで大きく価値が異なると思う。
複雑性が増すと修正にかかる工数が増えるけど、それを良しとするか悪しとするか。
0123デフォルトの名無しさん
2011/10/29(土) 18:57:08.38それぞれのモジュールの精度を高めるために必要な準備作業
じゃないかな
0124デフォルトの名無しさん
2011/10/29(土) 22:48:37.21じゃ、質問をかえる
その作業いつ終わるの？
0125デフォルトの名無しさん
2011/10/29(土) 23:05:14.32>時間と共に増大する複雑性への対処では。
何？複雑性って？
仕様とコードが乖離してるの？
そもそも仕様や設計がまずいの？
仕様や設計はバッチリなのにコードだけ綺麗にしようとしてる？（場面がまったく浮かばないけど）
>>123
精度？よくわからないけど
精度が高い状態と低い状態があって
それを判断する手段があるって言ってる？
高い状態はどうなってて、低い状態はどうなってるってのを説明してほしいんだけど？
0126デフォルトの名無しさん
2011/10/29(土) 23:30:50.350127デフォルトの名無しさん
2011/10/30(日) 00:00:06.96仕様が変わることによって設計がそぐわなくなったときの対処についてはどう考えているの？
仕様や設計がまずいといえばそれまでだけど、
完璧な仕様や設計は期待できないでしょ
0128デフォルトの名無しさん
2011/10/30(日) 00:12:36.900129デフォルトの名無しさん
2011/10/30(日) 01:44:30.53んー
それをコードにいれちゃうのはなんかちがうなーって思う
だって説明として仕様や設計に入ってもいないクラスが
自分の考える汎用性のためだけに入ってるってことでしょ？
まあ、昔の俺ならそういうコードいいと思ったけど
最近はこういう見切り発進みたいなコードをちっともいいと思わなくなった
むしろ余計なもん入れちゃうのってどうよ？って思う
0130デフォルトの名無しさん
2011/10/30(日) 02:01:00.62”必要だから” 入れてる。
0131デフォルトの名無しさん
2011/10/30(日) 02:32:58.38自分の考えるよりよいコードを実現するためのひとつの手段がリファクタリングなのであって、
お前がリファクタリングは不要と考えるならそれはそれでいいんじゃね
リファクタリングしなくていいよ
0132デフォルトの名無しさん
2011/10/30(日) 09:42:26.14でもそれって仕様書にないよね？
どうやって説明するの？
これまで派遣やってきたけど
そういうの許してる大手なんてみたことないけど
0133デフォルトの名無しさん
2011/10/30(日) 11:29:33.88見切り発進と思うのなら、修正した方が良いと思った内容を提案してみては。
受け入れるかは組織なり人なりタイミングによると思うけど、
少なくともうちだったら、そういう提案してくれる人は歓迎するけどなあ。
その人の持つ技術力の評価や信頼にも繋がるし。
0134デフォルトの名無しさん
2011/10/30(日) 11:55:22.16大手なんて10年は遅れてるじゃん
ゴミコード量産の現場でリファクタリングしようなんて、俺だって思わないな
メンテする奴が死ねばいい
0135デフォルトの名無しさん
2011/10/30(日) 12:08:51.05じゃあ聞くが、お前の所の仕様書には、
ifやforやローカル変数名が書いてあるのか？
使用する命令はそれ以外のものは
一切使ったらいけないと書いてあるのか？
0136デフォルトの名無しさん
2011/10/31(月) 03:11:52.86そんな話はしてないじゃん
でもこっちの場合はそういう制御文にとどまらないもんができちゃうよね？
必要のないクラスだったり関数だったり
0137デフォルトの名無しさん
2011/10/31(月) 12:33:30.90なんか勘違いしてね？
必要ないものってなんのこと言ってんの？
0138デフォルトの名無しさん
2011/10/31(月) 21:45:02.67世の中に必要なクラス・関数を網羅した
仕様書なんて無いよ。
0139デフォルトの名無しさん
2011/11/01(火) 00:54:41.88仕様と関係ないソース
汎用性のために入れましたって言うんでしょ？
0140デフォルトの名無しさん
2011/11/01(火) 00:57:56.170141デフォルトの名無しさん
2011/11/01(火) 06:03:18.76仕様と関係ない関数は不要なので、コードはすべてmainの中に書いてくださいね
0142デフォルトの名無しさん
2011/11/01(火) 07:41:02.59いくらなんでもそれは話が飛びすぎてて馬鹿っぽい
0143デフォルトの名無しさん
2011/11/01(火) 08:04:06.10特定の言語に固有の問題であって、リファクタリングの問題じゃなくね？
http://www.norvig.com/design-patterns/
0144デフォルトの名無しさん
2011/11/01(火) 20:58:54.49リファクタリングは保守の一つなのだから、
コードを修正するならば言語に関係なく発生する問題。
リファクタリングとデザパタは
特定の言語固有とか言う以前に、全く関係ない話題。
ついでにデザパタで作るのはゴミクラスではなく必要なクラス。
0145デフォルトの名無しさん
2011/11/01(火) 21:19:29.93よう、レガシー
0146デフォルトの名無しさん
2011/11/01(火) 21:21:02.730147デフォルトの名無しさん
2011/11/01(火) 22:09:32.23ゴミクラスと言いたくもなるわい
0148デフォルトの名無しさん
2011/11/01(火) 22:12:41.23たとえばどんなの？
0149デフォルトの名無しさん
2011/11/01(火) 22:14:56.95定義しても、ゴミ定義とは言わないだろ。
単に、エラーを見つけやすい方法で書くか、
短いコードだから省略して書くかの違いでしか無い。
0150デフォルトの名無しさん
2011/11/01(火) 22:26:33.69Strategyパターンはファーストクラスの関数があれば
クラスを作る必要は無いな
0151デフォルトの名無しさん
2011/11/01(火) 22:28:50.74きっちりとしたアプリを作るかどうかの違い。
0152デフォルトの名無しさん
2011/11/01(火) 22:36:13.61静的型検査という意味なら勘違いも甚だしいぞ
0153デフォルトの名無しさん
2011/11/01(火) 22:41:00.77コード上に、インターフェースがちゃんと表現されているという意味。
インターフェースを守らない、間違ったコードは組み込めないという意味でもある。
0154デフォルトの名無しさん
2011/11/01(火) 23:28:25.82ファーストクラスの関数がなかったら？
0155デフォルトの名無しさん
2011/11/01(火) 23:53:30.12だから、それは静的型検査という意味じゃないのか？
>>154
無名クラスがあれば代用可能
無名クラスも無い？あきらめろ
0156デフォルトの名無しさん
2011/11/02(水) 00:43:25.84クラスが必要かどうかは違ってくるというのに、
設計書と呼ばれるものに、そこまでちゃんとクラスを書いているのか？
普通は書かないだろ。
だから、設計書と呼ばれているものは、実は設計書ではない。
コードこそが設計書そのものなんだ。
0157デフォルトの名無しさん
2011/11/02(水) 07:35:25.31>だから、設計書と呼ばれているものは、実は設計書ではない。
>コードこそが設計書そのものなんだ。
そりゃ違うだろ
設計書と呼ばれてるものも設計書
ただ、粒度が異なるだけ
0158デフォルトの名無しさん
2011/11/02(水) 21:53:07.67なぜこれが必要か
といった， 設計ポリシーとともに書かれているものは， ごく稀
で， 最後には
ソース読め
状態になると思ってるんだ
0159デフォルトの名無しさん
2011/11/03(木) 01:04:35.79なにをやるための機能なのか一発でわかる
対して仕様書は嘘、間違い、抜け、バージョン違い、勘違い
更新忘れ、認識間違いばっかりになってほとんど役に立たない
仕様書いらなくね？
っていうかテスト手順書でよくね？
ちなみにおそらくテスト手順書は仕様書を見て作られてはいないだろうな
やってみて「ふーん・・・これだろ？これが仕様だろ？な？」的な感じだと思う
0160デフォルトの名無しさん
2011/11/03(木) 11:16:22.26っていうレベルのもの以外は仕様書に書くな！！！！
0161デフォルトの名無しさん
2011/11/03(木) 19:08:42.55ショートカットとか本当にどうでもいいもののリスト作ってるひまあったら他のことやれよな
0162デフォルトの名無しさん
2011/11/04(金) 00:04:28.66> ゴミコード量産の現場でリファクタリングしようなんて、俺だって思わないな
なんかすごくよくわかる。発注しまくりでゴミコード量産しまくりで身動きが取れないわ
0163デフォルトの名無しさん
2011/11/04(金) 20:57:42.11リファクタとかいうレベルじゃねーだろ
0164デフォルトの名無しさん
2011/11/04(金) 22:40:52.09すごいな
まんこの部分だけ強調して三回ぐらいは口にしたいよね
0165デフォルトの名無しさん
2011/11/06(日) 10:59:30.750166uy
2011/11/06(日) 16:44:42.65１０万行のソースコードがあったとして、
その１０万行のソースコードを、読んだってレベルじゃなくて、そうとう熟知した状態で
１人で行わなきゃならない
ていうか、それできるレベルなら、多分最初から書き直したほうが綺麗に書ける
まぁそれは理想で
ＳＥ共のいってるりファクタリングは機能ごとに、ちょこっとずつ最適化していく程度のものを言ってるよね
自分の能力でソースコード全体を見渡せる範囲で何とかするリファクタリング
なんていうか、それはね
まず木で作られた線路を、途中から鉄にして、さらに途中から銅にしたようなもので、本当に器用に継ぎ接ぎをしてるだけ
その継ぎ接ぎ部分はとてもシビアになるし、バグが出ても特定不可能で、
「よくわかんないけど、○○にすると落ちるから☆☆にしといてｗｗｗｗｗｗｗｗｗｗｗｗｗっうぇｗｗｗｗなんで落ちてんのｗｗｗっうぇｗｗｗｗ」みたいな状況にもなりかねない
ソース全体を見渡しているわけでもないリファクタリング作業なんてのは、あまりやりすぎると
ゼロから書き直す以上の労力をいつの間にか注いでいる事にもなりかねないので
最低限以上はやっちゃいけない
0167デフォルトの名無しさん
2011/11/06(日) 16:52:16.13お前は、ただのコード修正をリファクタリングと言ってるだけだね。
リファクタリングは単なる「コード修正」とは違うもの。
リファクタリングは「既存の動きに影響を与えない方法を使ってコードを修正すること」
既存の動きに影響を与えない方法ってのがあるんだよ。
これを使わないとリファクタリングにはならない。
行き当たりばったりの思いつき修正とはわけが違う。
論理的に考えぬかれた体系化されたテクニック。
それカタログ化して解説した本が、世の中にでてるリファクタリング本
0168デフォルトの名無しさん
2011/11/06(日) 17:24:22.30＞１０万行のソースコードがあったとして、
＞その１０万行のソースコードを、読んだってレベルじゃなくて、そうとう熟知した状態で
＞１人で行わなきゃならない
＞ていうか、それできるレベルなら、多分最初から書き直したほうが綺麗に書ける
とてもじゃないが、まともに教育を受けた人間の書いた日本語には見えない。
0169デフォルトの名無しさん
2011/11/06(日) 21:45:33.79ここで仕様をリファクターする必要を考慮しないのがリファクタリング厨
0170デフォルトの名無しさん
2011/11/06(日) 22:13:45.01リファクタリングは仕様を変えないのが原則です。
仕様を変えたほうがいいこともあるが、
それは修正であってリファクタリングではありません。
あたまがわるーい。
0171デフォルトの名無しさん
2011/11/06(日) 22:17:40.890172デフォルトの名無しさん
2011/11/06(日) 23:12:56.73ちゃんと読め。
0173デフォルトの名無しさん
2011/11/07(月) 02:11:07.98はぁ？
んなもんリファクタリングじゃあなーいと言ってやれ。ドキュメントをリファクタリングしちゃるとか言ってる奴、それもリファクタリングじゃねーぞコラ。そういうのは、リストラクチャリング（再構築）というのだッ。
0174デフォルトの名無しさん
2011/11/07(月) 06:29:39.93いいと思ってるのは自分だけっていう典型だと思う
0175デフォルトの名無しさん
2011/11/07(月) 22:24:06.07しかも動作は変わらないとかね
0176デフォルトの名無しさん
2011/11/07(月) 22:56:57.01あんたたちに言いたいことは、全て本の最初に、
それは違うよって書いてあります。
つまり、そのレスはFAQで答えがバッチリ出てるので、
今更議論するような話ではないです。
0177デフォルトの名無しさん
2011/11/08(火) 00:14:11.06とかいって逃げたいから自分の言葉で説明しないで本に書いてあるとか言ってるんでしょ？
わかるよ
説明できない人ってみんなそうだもの
あんたもいっしょ
残念だけどここ本質なのよね
そもそもリファクタリングっていう行動自体意味がわからない
将来どう変わるか？の仕様もないのに汎用性？
何に対していってるの？あれほど仕様書に重点をおいてるのに
なんでコードレベルでソフトウェアの方向性がわかるの？
それと何度もいうけど全体の工数からいったら実装なんてすげー短い期間なのに
リファクタリングなんてしなくていいんだよ
馬鹿かよ
設計や仕様決めに時間割いたほうがいいの、わかった？御馬鹿ちゃん？
人件費みたって派遣ＰＧと正社員様様と比べて比較になるわけねーだろ
そんな糞みたいな脳みそしかないんだったら技術者なんてやめちゃえばいいのに
0178デフォルトの名無しさん
2011/11/08(火) 01:14:10.32コンプレックス刺激されすぎｗ
0179デフォルトの名無しさん
2011/11/08(火) 01:17:58.36それに仕様変更や機能追加をする"前"にリファクタリングしたり
えーちょっと何やってんのか分からなぁ〜いって時に、リファクタリングして今の動きを確認したりする鴨
さすがに何も用事が無いのにリファクタリングはしないぞw
0180デフォルトの名無しさん
2011/11/08(火) 06:35:51.23ローカルのＨＤＤの中で勝手にやってろレベルだなｗ
0181デフォルトの名無しさん
2011/11/08(火) 08:17:23.29どうしたの？
したくないならしなくていいんだよ？
別にお前のコードのことなんて知らないし
0182デフォルトの名無しさん
2011/11/08(火) 12:07:50.87・機能仕様書：ユーザの観点からシステムがどのように動くか記述する
・技術仕様書：プログラムの内部実装について記述する
に分けたとき、機能仕様書を変更しないのがリファクタリング
技術仕様書は変更する必要がある
と、俺は解釈してるんだけど
0183デフォルトの名無しさん
2011/11/08(火) 22:53:38.54そんな金になんない仕事やったらダメだよ
仕様どおりには動いているんだ
よほど現実からかけ離れた組み方でない限りはそんなところにお金を入れてはダメだ
0184デフォルトの名無しさん
2011/11/09(水) 00:34:09.76リファクタリングしたことによる将来のメンテナンスコストの低減分だと思うから、
純粋なリファクタリングをする意味ってあると思うけどね。
まあ、少なくとも、作ったコードを客に出すのが仕事の人は、
リファクタリングの価値を見出すのは難しいだろうね。
お客が腐ったコードをメンテナンスし続ける費用を負担してくれる限り、
工数がかかる方が、お金になるだろうから。
0185デフォルトの名無しさん
2011/11/09(水) 01:07:17.870186デフォルトの名無しさん
2011/11/09(水) 22:25:08.24でもドングリの背比べじゃない？
仕様にまで踏み込めないレベルの修正でなんか変わるの？
同じ人、もしくは似たようなレベルの人がやんでしょ？
0187デフォルトの名無しさん
2011/11/09(水) 23:19:04.89同じようなレベルの人がやったら対して変わらんだろうね。
時間がなくて小手先で直したのを時間が取れる時にまともに直すとかかしら。
あほなプログラマが書いた動くけどわけわらんプログラムを
レビューで突き返したりするのもリファクタリングになると思うけど、放置するの？
0188デフォルトの名無しさん
2011/11/10(木) 00:11:30.20でも設計レベルではなにも変わらないんしょ？
アホだろうがどうだろうが違いがでるレベルにならんのとちゃうか？
0189デフォルトの名無しさん
2011/11/10(木) 02:48:37.98> 仕様にまで踏み込めないレベルの修正でなんか変わるの？
お前コード書いたことないだろ？
0190デフォルトの名無しさん
2011/11/10(木) 02:49:24.36お前の言う「設計レベル」ってどういうことだ？
コードには設計があるのは知ってるよな？
それは機能のことじゃないぞ。
0191デフォルトの名無しさん
2011/11/10(木) 06:19:17.82あるけど
そこでそんなに違いが出るとは思えないんだよね
大手もそう考えるから（いや実際そうなんだろう）ＰＧは派遣ばかりなわけだしね
0192デフォルトの名無しさん
2011/11/10(木) 22:10:19.472.1 リファクタリングの歴史
リファクタリングの先駆け：1980年代以降Smalltalkの仕事をしていたWard CunninghamとKent Beckの2人
Smalltalkはリファクタリングに特に向いている環境
コンパイル、リンク、実行のサイクルが短く、コードを気軽に書き換えることができる
彼ら2人の考えはSmalltalk文化にリファクタリングの概念を定着させた
筆者「リファクタリング？そこまで重要ではないよ」→Kentと同じプロジェクトに携わり、
Kentのリファクタリングを目の当たりにする→ソフトウェアの生産性、品質に明らかな違いが…→筆者「！！」
上の経験からリファクタリングを重要視するようになった
0193デフォルトの名無しさん
2011/11/10(木) 23:19:30.99そのストーリーって重要な部分なの？ｗ
しかもそんな馬鹿みたいな長文書いて大事な要点がちっとも書いてないじゃん
>ソフトウェアの生産性、品質に明らかな違いが…
明らかに大事なのってこの部分の詳細だろ
何がよくて品質がどうよくなったのか？
だろ？
お前の国語の能力低すぎてリファクタリングまで怪しくなるわｗ
0194デフォルトの名無しさん
2011/11/11(金) 21:19:14.97そういう文句はオリジナルを書いた奴に言え。
0195デフォルトの名無しさん
2011/11/11(金) 23:32:49.890196デフォルトの名無しさん
2011/11/11(金) 23:58:46.500197デフォルトの名無しさん
2011/11/12(土) 01:34:54.40違いを理解できない能力なだけじゃないの？
0198デフォルトの名無しさん
2011/11/16(水) 20:57:29.42前にやった仕事で、ほんの一部を除いて同一の機能を持つモジュール２つが
別々の人によってそれぞれ実装されてて
目玉飛び出そうになったのを思い出した
0199デフォルトの名無しさん
2011/11/16(水) 21:30:50.10その２つをくっつけることで後に呼び出し先Ａの機能を修正したいだけなのに
その機能がわざわざまとめられてるために
もう一つの呼び出し先Ｂのソースまで洗わないといけなくなるかもしんないだろ
まとめるのは必ずしも正解ではない
0200デフォルトの名無しさん
2011/11/16(水) 22:33:28.29必ずしも正解ではないのは正しいけど
同じような修正が必要になったときに片方の修正が忘れられることの方が多いと思われ
共通で使われてるメソッドの参照元を調べることより
クラスもメソッドも違うけど実は中身が同じでなければならなかったのを探すほうが大変な気が
分ける理由がないうちは一緒にしといて
必要になったら分ける方のが正しいと思う
0201デフォルトの名無しさん
2011/11/17(木) 01:17:42.75その両方を移植する仕事だった
「工数儲けた」と思ってたら
両者をソース読んで同一機能であることを確認した上で
一つにすりあわせて、その承認もらう羽目になったとさ
当然まともな設計書なんてありゃしないし
0202デフォルトの名無しさん
2011/11/17(木) 22:48:38.78いや、お前の言ってることはGoogleやAppleでは正しいだろうな
だが、日本の工業製品ではＮＧ
もちろんいいたいことはわかるけど
それじゃ見積もりがとれないこの１点でＮＧ
色々な大手でたくさんのプロジェクトが走っていて
共通ライブラリなんて生まれないっつか生まれても消滅してしまう理由はここにある
修正の影響範囲が巨大すぎて見積もれない
また、修正時に全員が同じタイミングで対応できない
これも大きな問題だ
こっち動かなくなるのに「直したよ〜」とかメールくれられても困るだろ？
そっちに手がまわらないのにリリース前に真ライブラリでバグってリリース失敗であぼんとか話にならない
修正した本人は「いいんですーこれが本来あるべき姿なんです〜」って主張しようと
修正するほうは「糞が・・・」って思うっしょ？
まあ、ＭＳの出荷するもんにみんなが愚痴をこぼす瞬間だと思うけど
0203デフォルトの名無しさん
2011/11/17(木) 22:50:23.01で、その壁を超えられる所が勝ち組で
超えられないところはどんどんブラック会社化するわけだ。
仕事、つまらないだろう？ｗ
0204デフォルトの名無しさん
2011/11/17(木) 22:55:03.81でもいくらもないっしょ？
日本のＩＴって進化に失敗してて紙業務を電子化したような仕事のほうが多いよね？
韓国にもすっかり抜かれちゃったみたいで国内全員でｼｮﾎﾞｰﾝって感じじゃない？
研究開発分野と本当に極一部だけだろうね
まあ、いまそういう開発してても日本じゃいつ紙業務の電子化ＩＴにまわされるかわからないから
勝ち組って意味でいうと海外脱出組が勝ち組だろうね
0205デフォルトの名無しさん
2011/11/17(木) 22:58:57.20ごめんな。
うち自社で作ったウェブサービス提供する会社なんだわ
HTML5系とかそっち系。
選ぶ会社の時点で勝ち負けが決まるよね。
仕事、つまらないだろう？ｗ
0206デフォルトの名無しさん
2011/11/17(木) 23:01:51.10同じコードをいくつも書くとかそんな無駄なことやってられないんだよね。
テストも人海戦術で同じことを何度もやるとか、時間的に無理だし、
もちろん手動テストは極力減らすので、変更したって
影響があるならすぐ分かる。
0207デフォルトの名無しさん
2011/11/17(木) 23:02:59.45ウェブ系なんて工業製品とかわんねーけどな
あんなん汎用性見越して組む必要あるかね？
寿命が短いからどう組んでもどうとでも動くが正解だろ？
納期まで早い方が真
お前の世界こそプログラムを綺麗にまとめて褒める奴１人もいないと思うがな
0208デフォルトの名無しさん
2011/11/17(木) 23:38:17.66汎用性見越して組むとか言ってないんだが。
無駄にある重複コードをまとめると言ってるだけ。
0209デフォルトの名無しさん
2011/11/17(木) 23:39:39.61修正があると、重複コードの分
修正量が増えます。
少しの修正であっちこっち修正して、
あっちこっちテストして納期伸ばしてるのは誰ですか？ｗ
0210デフォルトの名無しさん
2011/11/18(金) 00:57:17.23それって何箇所？
１０箇所？２０箇所？程度なら貼ったほうが速いよね？
思いっきりまとめあげられてて難しい仕組みに頭ひねってソース解読しなきゃいけないぐらいだったら
単純コピーで貼ってあってくれたほうがまだソース読みやすいよね
っていうか件数が１００件いかない程度のコピペならお前が便所に席を立った間にやっておいてやるよ
この程度の件数だったらどう組んでも変わらない
0211デフォルトの名無しさん
2011/11/18(金) 01:28:11.79お前適性ないんじゃね？
ぶっちゃけ、仕事楽しくないでしょ？
0212デフォルトの名無しさん
2011/11/18(金) 01:48:53.370213デフォルトの名無しさん
2011/11/18(金) 06:57:57.33いや、楽しいよ
お前みたいな対象物のメリットとデメリットも判断できんようなの出し抜いて数字上げるのが何よりの快感だわ(笑)
結局、技術の上部だけしかすくえないひとって何も見えてないんだよね
新しいってだけである意味パニック状態になってる自分がなにより見えてない
0214デフォルトの名無しさん
2011/11/18(金) 07:32:36.75さぞかし楽しい人生だろうねぇ。
0215デフォルトの名無しさん
2011/11/18(金) 11:48:05.79お前性格屈折してるな
そうとういじめられたな
0216デフォルトの名無しさん
2011/11/18(金) 12:54:07.46> 思いっきりまとめあげられてて難しい仕組みに頭ひねってソース解読しなきゃいけないぐらいだったら
> 単純コピーで貼ってあってくれたほうがまだソース読みやすいよね
申し訳ありません
ifとforしか理解できない人もいるということを忘れていました
リファクタリングの過程でデザインパターンを適用してしまったことをお許しください
0217デフォルトの名無しさん
2011/11/18(金) 12:59:02.53コピペもできるしリファクタリングもできる俺がそれを言うならまだわかるけど、
お前はコピペしかできないんだからさ、取捨選択の上でコピペを採用したみたいな言い方はやめてよ
もっともらしい後付けをしたところで、お前のカードはコピペしかないわけで
0218デフォルトの名無しさん
2011/11/18(金) 12:59:57.09forすら理解してないかもよ
100回ループ廻すくらいならコピペするって言い出しかねん
0219デフォルトの名無しさん
2011/11/18(金) 15:50:01.61その時点で白旗あげてるっていうかなんていうか
0220デフォルトの名無しさん
2011/11/18(金) 19:16:21.49だってー
低レベルな人を教育してあげる気なんて毛頭ないですしー
0221デフォルトの名無しさん
2011/11/18(金) 23:06:02.19でも自分のやってることの説明できないってのは問題じゃない？
結局トレードオフの問題であって
やればやるほどとかどんな場面でもってわけじゃないってとこは否定できないわけでしょ
じゃあ、君のやり方は正しいの？また、他の人と差がでるのは何が決め手なの？
ってのは結局のところどこでも求められると思うんだけどね
それが説明できないなら君に用のある人なんていないと思うんだよね
みんな暇じゃないから(笑)
0222デフォルトの名無しさん
2011/11/19(土) 16:25:48.920223デフォルトの名無しさん
2011/11/19(土) 16:38:24.26やっぱりリファクタリングは必要ってことね
リファクタリング全否定って人はいるのかしら
0224デフォルトの名無しさん
2011/11/19(土) 17:14:49.53リファクタリングはまったく必要ないよ
そもそも意味わからないもん
次の仕様が決まってる中でのコード修正ならわかるけど
次になんの予定もないのに何に向けてどう修正してるのかまったく理解できない
その修正はいいの？悪いの？
オナニーで終わってない？
これらを判断できる材料すらわからない
単に金をドブに捨ててるだけだと思う
0225デフォルトの名無しさん
2011/11/19(土) 17:30:26.36ゴミ溜めが如くきったない部屋で過ごしてもなーんにも問題無い
↑
↓
チリ一つも落ちていないようなクリーンルームじゃないと過ごせない
綺麗なコード
って話だろ？ 何事もほどほどにしとけって事だよ
0226デフォルトの名無しさん
2011/11/19(土) 17:33:20.81人の話を良く聞かないで進めちゃって失敗するほうじゃない？
0227デフォルトの名無しさん
2011/11/19(土) 18:59:16.42キミがそのコードをずっとメンテナンスする責任者だとして、
どこかのプログラマが明らかにまとめるべきところまとめてこなかったり、
分けるべきところをを無理やりまとめてきたりした場合、
正しく動くという理由でそのままにしておくのかい？
0228デフォルトの名無しさん
2011/11/19(土) 19:28:32.54作るときに設計書にあわせてもらいます
ソースだけ弄るってことはしません
0229デフォルトの名無しさん
2011/11/19(土) 19:33:14.800230デフォルトの名無しさん
2011/11/19(土) 19:47:12.13底辺乙
0231デフォルトの名無しさん
2011/11/19(土) 19:51:09.79要するに仕様は変えずに設計を変えるんだろ
リファクタリングじゃないか
0232デフォルトの名無しさん
2011/11/19(土) 20:14:22.32↑ 汚いが動く
↓ 綺麗で動かない
最低 汚くて動かない
一番下のは捨ててよし
[動く／動かない] と [綺麗／汚い] の相関関係だお
汚いけど動くのは、綺麗だが動かないものより価値がある。
でも綺麗で動かないのを 動く にしやすいし、
汚いけど動くものも、後で何か変更するにあたって、動くのを保ちつつ綺麗にしておくと直しやすい。
「綺麗にする」のがリファクタリング。動かないものを動くようにすることとはイコールではない。関係はあるけど。
0233デフォルトの名無しさん
2011/11/19(土) 20:27:15.160234232
2011/11/19(土) 20:45:33.70↑
↓
綺麗な仕様は動かしやすい
って関係はあると思うけど、コードと仕様は直接関係しないんじゃねの？
0235デフォルトの名無しさん
2011/11/19(土) 20:55:13.83汚い仕様を何とか動かすために、 汚い姑息なコードを大量に入れてる
例なら山ほどあるよ
0236デフォルトの名無しさん
2011/11/19(土) 21:31:39.15リファクタリングって大なり小なり設計の問題の修正のことだと思うんだが。
オレがずれてるのか。
0237デフォルトの名無しさん
2011/11/19(土) 21:34:18.54おれもそう思うよ. 仕様も設計の内だとも思うけど...
0238デフォルトの名無しさん
2011/11/19(土) 21:49:35.63最初にきちんと設計をしたつもりでも、実装段階では想定したとおりに行かなかったり、抜けがあったりすることはよくあることです。
実際に書いているうちにいろいろ思いつくこともあります。ちょこっと例外的な処理を付け加えて、を繰り返し、コードは汚くなっていきます。
そうしてソースがスパゲッティ化し、メンテ不能のソースとなっていきます。
そうならないようにするためにリファクタリングがあります。
リファクタリングとは、仕様を変えることなく、ソースコードを改造することをいいます。
汚いソースコードでもプログラムは動きますが、メンテナンスするのは大変です。
汚いソースコードと綺麗なソースコードではメンテのしやすさが全く違います。
なのできるだけ綺麗なソースを書くように心がけ、汚くなったら速やかに書き直すことです。
後々のことを考えて、わかりやすいソースに直します。
0239デフォルトの名無しさん
2011/11/19(土) 22:15:38.43> そうならないようにするためにリファクタリングがあります。
そうならないように設計を見直す方が先じゃないか?
小手先でどれだけいじっても, 汚い設計は汚いソースを
再生産するだけじゃないのか?
それだったら, 設計をリファクターすべきだ
ぶっちゃけ, ユーザーインターフェースが変わらなきゃ
仕様の範囲内だ
0240デフォルトの名無しさん
2011/11/19(土) 23:03:54.10コピペはいらんよ。
汚い綺麗で語るとコードの可読性ばかりを問題にしてるように感じるって話。
だからリファクタリングがいらないとか言う奴がいるんじゃないの。
コードが綺麗であっても設計上の問題が存在することは当然あるよね。
コードの綺麗/汚いは設計の一部しか示していないと思うし、
その修正はリファクタリングの一部でしかないと思う。
0241デフォルトの名無しさん
2011/11/20(日) 07:43:51.29したらただの仕様変更だよねそれって
まあ、名称にこだわる必要もないけど
0242デフォルトの名無しさん
2011/11/20(日) 08:21:15.92システム全体の仕様は変わりません。
なので仕様変更にはあたりません。
0243デフォルトの名無しさん
2011/11/20(日) 08:21:59.020244デフォルトの名無しさん
2011/11/20(日) 12:07:12.15仕様変更を伴わないコード変更って存在するのか？
0245デフォルトの名無しさん
2011/11/20(日) 12:08:20.66意味がある変数名に変更するとか。
0246デフォルトの名無しさん
2011/11/20(日) 13:09:50.85ユーザに見える部分とか
担当者の異なるモジュール間とか
0247デフォルトの名無しさん
2011/11/20(日) 17:10:54.610248デフォルトの名無しさん
2011/11/20(日) 17:46:34.19外から見た目の振る舞いが変わるか/変わらないかがポイントで、
外から見た目の振る舞い＝仕様であって
内部構造≒設計は、リファクタリングの対象
って事でおｋ？
0249デフォルトの名無しさん
2011/11/20(日) 18:02:36.08個人的にはソレが正しいと思うけど
そう思ってない人がいる予感。
241とか
0250デフォルトの名無しさん
2011/11/20(日) 18:50:26.97じゃあ、リファクタリングってのは設計変更までを指すってことでいい？
何やんだかさっぱりわからないけど
0251デフォルトの名無しさん
2011/11/20(日) 18:53:49.64設計の範囲を定義しろ。
話はそれからだ。
0252デフォルトの名無しさん
2011/11/20(日) 21:17:25.23そっちにまかせる
>>248がえらそうに宣言してるから>>248に決めてもらうか
0253デフォルトの名無しさん
2011/11/21(月) 09:59:01.460254デフォルトの名無しさん
2011/11/21(月) 22:35:10.04お前だけだよｗ
0255デフォルトの名無しさん
2011/11/22(火) 10:39:05.000256デフォルトの名無しさん
2011/11/23(水) 00:32:21.88本の受け売りじゃなくて中身をちゃんと理解しろよ
0257デフォルトの名無しさん
2011/11/23(水) 01:19:14.75買っただけ
■ このスレッドは過去ログ倉庫に格納されています