0001仕様書無しさん
2018/04/15(日) 13:13:44.63いつもやってることじゃん
探検
ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくるやつの矛盾
■ このスレッドは過去ログ倉庫に格納されています
いつもやってることじゃん
0504仕様書無しさん
2018/04/22(日) 23:38:13.28それは設計ミスの言い訳になるの？
0505仕様書無しさん
2018/04/22(日) 23:55:15.440506仕様書無しさん
2018/04/22(日) 23:58:31.24テストコードのテスト？
0507仕様書無しさん
2018/04/23(月) 00:04:46.84じゃあリファクタリングなんてやる必要ないじゃん
0508仕様書無しさん
2018/04/23(月) 00:12:15.78ふくらんだクラスを分割して平行作業したり
後から出てきた概念と名前を調整したり
既存コードに手を入れなくても機能拡張できるようにしたり
0509仕様書無しさん
2018/04/23(月) 00:29:35.440510仕様書無しさん
2018/04/23(月) 00:32:08.58全部金になんないね
お前、仕事やって金稼いだことあんの？
0511KAC
2018/04/23(月) 00:49:44.07お前さんが「リファクタリングを理解していない」のは既に指摘したが、
まさかそこまで酷いとは驚きだよ。
もう一度リファクタリングとは何か調べてから出直してこい。
0512仕様書無しさん
2018/04/23(月) 01:09:41.41よっぽど信頼されていないんだなｗ
0513仕様書無しさん
2018/04/23(月) 01:34:52.95基本的にYAGNIでKISSだから。
機能追加する時初めてインターフェースを切り出したり、関数の所在を変えたりする場合も少なくない。
>>500
少なくとも20年前云々は、例として適切でない。
リファクタリング文化がある98年制のソースを触ったことなどない。
>>502
言葉そのものでなく、>>488、>>490の流れを受けての文脈。つまり(トータルコストを見て)効率的かどうか。という事。
0514仕様書無しさん
2018/04/23(月) 02:17:31.75外国人は新しいバグを埋め込んだり、仕様が変わってしまっても気にしない文化だから、日本人の感覚とは合わない。
0515仕様書無しさん
2018/04/23(月) 05:36:26.93テスト工数の削減が見込める場合はやるだろ
0516仕様書無しさん
2018/04/23(月) 06:14:50.48やらない
お前のやり方だとデグレが怖いから
0517仕様書無しさん
2018/04/23(月) 07:49:11.350518仕様書無しさん
2018/04/23(月) 08:18:26.16それは仕様がすべて文章化されていればな
実際はそんなこと不可能だし
変更した以上デグレは覚悟しなければならない
0519仕様書無しさん
2018/04/23(月) 09:45:42.62> 日本の場合はリファクタリングではなく、システムを作り替えるタイミングがリファクタリングにあたる。
それは仕様がすべて文章化されていればな
実際はそんなこと不可能だし
変更した以上デグレは覚悟しなければならない
0520仕様書無しさん
2018/04/23(月) 09:53:07.78仕様なんてソースコード読んで、
その動きが仕様なのでは？
0521仕様書無しさん
2018/04/23(月) 09:54:57.20一瞬システムリプレースの事だと勘違いするから、改修とか修正って単語使って欲しい
んで、何度も言うように、少なくともリファクタリングの時点でテストはされるし、バグがリファクタリング起因でない事は(メモリ起因やテスト自体の不備を除けば)確実だ、としておく。
なんで、外国人、日本人の下りは何かがおかしい
0522仕様書無しさん
2018/04/23(月) 10:53:40.380523仕様書無しさん
2018/04/23(月) 12:08:46.41外部的振る舞いが変わってないことを確認して満足してた奴がリファクタリング起因の障害を発生させてたわw
0524仕様書無しさん
2018/04/23(月) 13:27:15.16ただそれに関しちゃ、手動テストでも同じことが言えるからどっちもどっち。
0525仕様書無しさん
2018/04/23(月) 14:56:45.98手動でもテストコードはあるんだが？
0526仕様書無しさん
2018/04/23(月) 17:34:25.510527仕様書無しさん
2018/04/23(月) 19:31:15.43オワットルなジャップ
0528仕様書無しさん
2018/04/23(月) 20:11:50.92それがどれほど技術的に見えようとも
結局は人間の問題である
と偉い人が言ってた
0529仕様書無しさん
2018/04/23(月) 21:31:15.36気が滅入る
0530仕様書無しさん
2018/04/23(月) 21:37:25.89> 外部的振る舞いが変わってないことを確認して満足してた奴がリファクタリング起因の障害を発生させてたわw
それ普通に修正してもバグ入れ込むよね？
0531仕様書無しさん
2018/04/23(月) 21:38:22.86> 手動でもテストコードはあるんだが？
なら手動でバグを見つけられなかったことでは？
まあ手動によるテストは信頼性が低いからね
0532仕様書無しさん
2018/04/23(月) 21:46:49.18>>530
触らないならバグらないよ
0533仕様書無しさん
2018/04/23(月) 22:01:01.53客を丸め込んでデグレのリスクを飲ませられるかにかかってる気がしてきた
バージョンアップとかスピードアップとかなんかこじつけて
リファクタでデグレたら原因も無理やりそこに倒す
0534仕様書無しさん
2018/04/23(月) 22:09:44.65リファクタリングは効果的、これを開発社側が
正しく理解してないと、現状のコードの問題を
リファクタリングのせいにしてしまう。
0535仕様書無しさん
2018/04/23(月) 22:10:30.68仕様もテストコードもないんだが？とかそういうのなｗ
0536仕様書無しさん
2018/04/23(月) 22:14:41.53正しい知識があったらリファクタがプログラマーが楽するためのものだってばれるじゃないか！
0537仕様書無しさん
2018/04/23(月) 22:16:20.230538仕様書無しさん
2018/04/23(月) 22:16:42.65開発側が楽になれば、それは顧客にとってメリットしかないよね？
0539仕様書無しさん
2018/04/23(月) 22:17:49.19お前のその「開発中」は何ヶ月あるんだ？
お前の所は各モジュールごとに計画を立てて開発するんじゃなくて
全部いっぺんに作業してしまってるのか？
0540仕様書無しさん
2018/04/23(月) 22:21:41.39ユニットテストが壊れない程度のリファクタリング、つまり関数レベルのリファクタリングしかしない人にはわからないかも
0541仕様書無しさん
2018/04/23(月) 22:24:43.47なんでユニットテストを修正してはいけないと思ってるんだ？
リファクタリングでユニットテスト修正するだろ。
というだけじゃ意味が分からんのだろうな
テストは修正しないって言ったじゃないですか！って言いそうｗ
リファクタリングはテストに通るように修正するのであって、
それさえ守れば、テスト自体の修正もする。
テストのリファクタリングなんて言葉もある。
説明がほしいか？
0542仕様書無しさん
2018/04/23(月) 22:26:59.68勘違いしているリファクタリングだ
新装版 リファクタリング 既存のコードを安全に改善する
http://shop.ohmsha.co.jp/shopdetail/000000003881/
第6章 メソッドの構成
メソッドの抽出
メソッドのインライン化
一時変数のインライン化
問い合せによる一時変数の置き換え
説明用変数の導入
一時変数の分離
パラメータへの代入の除去
メソッドオブジェクトによるメソッドの置き換え
アルゴリズムの取り替え
第7章 オブジェクト間での特性の移動
メソッドの移動
フィールドの移動
クラスの抽出
クラスのインライン化
委譲の隠蔽
仲介人の除去
外部メソッドの導入
局所的拡張の導入
0543仕様書無しさん
2018/04/23(月) 22:31:31.09「実装クラス」があって
↑
「テストコード」がこの実装クラスを見ている時の
クラスを大きく書き換えるリファクタリングはな
「新しいクラス」を作って、
↑
「実装クラス」の処理を新しいクラスに移譲することで、
↑
「テストコード」から見るインターフェースを
まったく変えること無く、新しいクラスに移行するんだよ
そして「新しいクラス」のテストも書いて（もちろん一部は現在のテストコードを流用していい）
「実装クラス」を参照しているものを、新しいクラスを参照するように書き換え
どこからも使われなくなったら「実装クラス」をそのテストコードもろとも削除
というやり方が、>>542のリファクタリング本に書いている
だから「ユニットテストが壊れない程度のリファクタリング」と言われても
あー、分かってない人ねとしか思わないよ。
0544仕様書無しさん
2018/04/23(月) 22:36:31.59仕事中に遊んでんじゃねえ
0545仕様書無しさん
2018/04/23(月) 22:40:36.13遊んでるとか思うおっさんがいるらしいなw
0546仕様書無しさん
2018/04/23(月) 22:43:19.23バーンと書き換えて、やっちゃって
ミスったらリファクタリングのせいにすればいいだろ
↑こういうやつがリファクタリングのせいにするわけかｗ
リファクタリングは変更しても問題ない手順で変更することで、
たんなる変更、いつもお前らがやってるような手抜きの
無計画な変更を言い換えた言葉ではありません
0547仕様書無しさん
2018/04/23(月) 22:44:15.53やってる本人はよくても
他人はリファクタ前と後で変わってないことをどうやって確かめるんだ
0548仕様書無しさん
2018/04/23(月) 22:46:32.34ちゃんとよめや。
移行して使われなくなってから削除するんだよ
お前みたいに、なにも考えずに削除してるんじゃねーよｗ
> 他人はリファクタ前と後で変わってないことをどうやって確かめるんだ
なんのためにコミットログがあると思ってんの？
あ、もしかしてそこから？
レベルの差が2段階、3段階ありそう・・・
0549仕様書無しさん
2018/04/23(月) 22:48:18.58勿体ぶらずにちょっと具体的な確認手続き言ってみなさい
0550仕様書無しさん
2018/04/23(月) 22:54:04.641. リファクタリングする前にはテストがある。
2. 足りなければ追加する
3. テストが通る
4. リファクタリングする（コードを書き換える）
5. リファクタリングしてもテストが通る
それだけじゃん。
まだ補足が必要？
1. さらにコードを書き換える
2. コードを書き換えるうちに（テスト以外で）使われないモジュールが登場する
3. テストは通るがプロダクションコードでは使われてない
4. 使われてないコードは安全に削除できる
いわれないとわからないかなあ？ｗ
0551仕様書無しさん
2018/04/23(月) 22:58:29.810552仕様書無しさん
2018/04/23(月) 22:59:42.12他人が一連のリファクタリングの途中を
見るために決まってるじゃん？
なにかわからないところがあったの？
0553仕様書無しさん
2018/04/23(月) 22:59:49.36だからさ、「ガチガチに硬直化」って丁寧に言ってやってんじゃん
そりゃリファクタリングの過程でテストも書き換えるよ
ていうか書き換えるに決まってんじゃんアホか
開発中の日々形を変えるコードに対してガチガチのテストを書くなって言ってんだけど、
わかんない？アホだからわかんないの？もうちょっと精進しろよアホ
0554仕様書無しさん
2018/04/23(月) 23:00:16.48レベルの差が4段階、5段階あるからか・・・
0555仕様書無しさん
2018/04/23(月) 23:01:48.90> だからさ、「ガチガチに硬直化」って丁寧に言ってやってんじゃん
ガチガチに硬直化ってなに？
ファイルをリードオンリーにでもすんのか？
変更できないコードなんてないはずだけど？
どうやるのかはしらないが、
お前がガチガチに硬直化させたのなら、
それはお前の責任だよね？
0556仕様書無しさん
2018/04/23(月) 23:01:57.080557仕様書無しさん
2018/04/23(月) 23:02:23.37リリース済みのコードとそれに対する改修の文脈でばかり語ってるところを見ると、そうなんだろうな
0558仕様書無しさん
2018/04/23(月) 23:02:52.05> 開発中の日々形を変えるコードに対してガチガチのテストを書くなって言ってんだけど、
テスト＝仕様を元に決まるものなはずだけど、
仕様が日々変わりまくるのか？
ならそっちが問題だなｗ
0559仕様書無しさん
2018/04/23(月) 23:03:48.02経験が浅い人にはわかんないかも
リファクタ本に書かれてる話じゃなくてごめんね
0560仕様書無しさん
2018/04/23(月) 23:05:13.56> リファクタの途中よりリファクタの前と後で結果が変わらないことを保証してほしいんだけど
だからリファクタの前＝コミットログの修正前
リファクタの後＝コミットログの修正後だろ？
リファクタの前のテストコードを変更せずに
リファクタの後でもそのまま通れば
変わってないことが証明できる。
あー、これ↓を言っておかないとダメなんだろうなｗ
結果が変わってないと証明された後、
使われてないと判明したコードは削除できる
0561仕様書無しさん
2018/04/23(月) 23:05:28.65テストはクラスやメソッドの仕様であってシステムの仕様ではありませんが
0562仕様書無しさん
2018/04/23(月) 23:05:53.43そのうえで全体的な仕様が変わってないことを保証しないといけないわけだが
0563仕様書無しさん
2018/04/23(月) 23:06:32.49> リファクタ本に書かれてる話じゃなくてごめんね
じゃあどこに書かれてる話なの？
お前の想像の世界の話はいらないからｗ
どうも「自分がくそったれなやり方してます。
くそったれなやり方には使えないんですけど？」
って言ってるようにしか見えない。
お前のくそったれなやり方の問題だろとしか
0564仕様書無しさん
2018/04/23(月) 23:06:42.270565仕様書無しさん
2018/04/23(月) 23:07:05.91> テストはクラスやメソッドの仕様であってシステムの仕様ではありませんが
だから？
システムの仕様じゃなくても、クラスやメソッドの仕様でしょう？
0566仕様書無しさん
2018/04/23(月) 23:08:13.58> おまいがリファクタして部分的な仕様を変えまくってんじゃん
変えてないよ？
日々テスト変えなきゃならないどこかの誰かさんと違って、
テストは基本安定している。
テストコードを変えない状態でコードを書き換えてるので
リファクタしても仕様はまったく変わらない
0567仕様書無しさん
2018/04/23(月) 23:08:14.720568仕様書無しさん
2018/04/23(月) 23:10:19.92それユニットテストじゃない
ユニットテストはモジュールのインターフェースのテストだから
変わりまくることはあり得ない。
もしモジュールのインターフェースという概念がなくて、
単に長いから関数にまとめましたみたいな、
なんでかしらないけど、この関数テストしづらいです。
なんてことをしてるのならそいつの問題
0569仕様書無しさん
2018/04/23(月) 23:11:29.71でも今まさにそれを変えるときの話してたよな？
0570仕様書無しさん
2018/04/23(月) 23:12:22.55ガチガチに固まって、メンテナンスが大変です。
なんて状態になってるのか書いてみたら良いよ。
想像の世界の話じゃないなら書けるはず
0571仕様書無しさん
2018/04/23(月) 23:14:05.70外から見た時の動きが変わってなければ良い。
そして外から見た時の動きが変わってないが、
（テストコード以外で）使われていないメソッドを作ることは可能
そしたら使われてないコードは安全に消せる。
こういう話をしてます。
0572仕様書無しさん
2018/04/23(月) 23:18:32.85つまり今までの話は
低い階層の処理クラスの単体テストの話で
さらにそれを包含するクラスの単体テストは別途あって
そっちは変更ないと
0573仕様書無しさん
2018/04/23(月) 23:38:30.60【現在のクラス】をリファクタリングするとき
「新しいクラス」
↑
【現在のクラス】←「その他のクラス」←「その他のクラスのテストコード」
↑
「現在のクラスのテストコード」
こういう階層の時、「現在のクラスのテストコード」はそのままに、
「新しいクラス」に処理を移動していくことはできるだろ？
（移動だけじゃなくて新しく作ってもいいけど）
リファクタリングするのは【現在のクラス】だけ
「現在のクラスのテストコード」は書き換えない
【現在のクラス】を利用している「その他のクラス」も書き換えない
（当然「その他のクラスのテストコード」も）
コードの修正をすすめると【現在のクラス】は「新しいクラス」への移譲コードだけになる。
また「その他のクラス」は「新しいクラス」を参照するようにする。
「その他のクラスのテストコード」の修正はしないから、変わってないことは保証できる。
最終的に【現在のクラス】を「その他のクラス」は参照することはなくなる。
そして【現在のクラス】は「現在のクラスのテストコード」以外からは
どこからも使われてないクラスになるので安全に削除できる
これが関数レベルではない、クラスレベルのリファクタリングのやり方
それは>>542とかの本に書いてある基本だから、ほんと勉強してくれとしか
0574仕様書無しさん
2018/04/23(月) 23:43:44.16変えてしまうほどのリファクタリングの手順
メソッド一個だけとかならここまでやる必要はない。
その場合は、メソッド単体で、他のメソッドの委譲したりして
該当のメソッドを使われてない状態にしてから削除する
0575仕様書無しさん
2018/04/23(月) 23:58:55.58ユニットテストするときなんて下位クラスはモックになってること多い
その場合参照するクラス変わったらモック設定書き換えにゃならん
0576仕様書無しさん
2018/04/24(火) 00:11:44.400577仕様書無しさん
2018/04/24(火) 00:16:57.50あほ
0578仕様書無しさん
2018/04/24(火) 00:18:30.70テストにもいろんなレベルがあることに考えが至らない奴隷コーダー
0579仕様書無しさん
2018/04/24(火) 00:24:31.480580仕様書無しさん
2018/04/24(火) 00:42:19.080581仕様書無しさん
2018/04/24(火) 06:04:21.71リファクタリングなんぞ不要
数年後には業務変化の見直しと現在業務の確認のために、システムをまるごと作り直すから
0582仕様書無しさん
2018/04/24(火) 06:15:49.270583仕様書無しさん
2018/04/24(火) 08:16:15.86ダメ管理者はよくそういう妄想に浸りたがるよなあ。
0584仕様書無しさん
2018/04/24(火) 08:52:53.82こまめにリファクタリングしたら大損だよ
0585仕様書無しさん
2018/04/24(火) 09:48:46.57こまめにリファクタリングってことは、リファクタリング後の修正がこまめに発生してるんだから、そこでリファクタリングコストの半分以上は回収できてると思うの
0586仕様書無しさん
2018/04/24(火) 11:20:18.41一度作ったらあまり改修しないようなソフトウェアであればリファクタリングのデメリットが目立つ
つまり、アマゾンドットコムみたいに常に機能追加や改修が行われる投資対象であればリファクタリングで機動力を確保するのは理にかなってる
逆に家電に代表されるような組み込み系、もしくは制御系のような、機能追加や改修の頻度が低いものであればリファクタリングする意味は相対的に小さい
お金をつぎ込めばつぎ込むほどリターンがあるのであれば、CIの中にリファクタリングを入れてしまえばいいだろう
リファクタリングの結果がすぐに出やすく、デメリットであるリファクタリング起因の不具合についても
改修が多ければ多いほど、リファクタリング起因の不具合減産と相殺されるからだ
リファクタリングの問題でやはり難しいのは改修頻度が低く失敗が許されない分野だ
これらの分野は製造工数とテスト工数の比でいうとテスト工数の割合が大きい
つまり、リファクタリングによって過大なテスト工数が必要となってしまい、リファクタリングのメリットが吹き飛んでしまう
しかしながら動いている箇所はいじらない方針もいつまでも続くわけじゃない
いつかのタイミングで全面リプレースするか、リファクタリング（もはや資料もなく知っている人もいない）を行うことになる
0587仕様書無しさん
2018/04/24(火) 12:15:51.100588仕様書無しさん
2018/04/24(火) 13:06:03.44うちもそうだよ？
課レベルのシステム、部レベルのシステム、社レベルのシステム
があって、それぞれの長が変わったらシステムの仕様変更が最初の長の仕事になってる。
システムの見直しと再設計って、その部署の現在運用を把握するのに最適という理由で。
0589仕様書無しさん
2018/04/24(火) 13:34:56.47もはやマニュアルってレベルだろそれ
エンジニアしか理解できない仕事のマニュアル。
0590仕様書無しさん
2018/04/24(火) 13:49:15.67システムのあわせて業務を再構築するべきか ※欧米風
どっちがいいんだろうね
0591仕様書無しさん
2018/04/24(火) 14:48:59.76欧米は、システムに最初から経営方針や業務設計を盛り込んでるだけだよ？
日本と欧米に差はない。
あるのは、システム開発を速攻で内製で仕上げているか否か。
0592仕様書無しさん
2018/04/24(火) 15:14:51.24国内で内製やった7&iホールディングスが大コケしたけど
0593仕様書無しさん
2018/04/24(火) 18:11:05.66セブンミール時代からたまに使ってるけど、たしかに使いづらくなった。
けど、冷静に考えると。今のレベルのシステムを一応作れたなら。元々のシステムも実装できる。
運用方針を新システム化した際に「顧客のニーズ」を取り入れるために店長に聞いたら。
「店長のニーズ」を取り入れちゃったんだろうｗｗｗ
ただ、「店長のニーズ」も旧システムで現実に起こってる問題の結果で、
さらに、現在、店舗自体が人手不足に陥ってるから配達要員、商品供給ライン等で
旧システムであっても実際には様々な遅延等々があったんだろう。
おそらく、システムの使いづらさの原因は、まさかのアナログな「現場の配達に要する人手不足」だと思うわｗ
0594KAC
2018/04/24(火) 18:20:09.23本来なら日本風がいいんだけど、
パッケージ売りの欧米風の方が格段に安いから。
0595仕様書無しさん
2018/04/24(火) 18:32:53.31ガチガチに変更管理してる
現場ってあんの？
0596仕様書無しさん
2018/04/24(火) 19:13:54.37は？折角テスト終わったのに変更すんな
殺すぞ
0597仕様書無しさん
2018/04/24(火) 19:16:58.60は？
ボタン押すだけだろ
0598KAC
2018/04/24(火) 19:17:09.86リリース前も後も管理するのは当たり前
0599KAC
2018/04/24(火) 19:19:03.12お前さんが試験したこと無いのはよく分かった
0600仕様書無しさん
2018/04/24(火) 19:22:18.29今はもうpushするだけの時代だぞ爺さん
0601仕様書無しさん
2018/04/24(火) 20:26:27.79変更中で清書する前のコードならpushしねえよ
0602仕様書無しさん
2018/04/24(火) 20:45:57.41> 常に機能追加や改修しているようなソフトウェアであればリファクタリングは有効
> 一度作ったらあまり改修しないようなソフトウェアであればリファクタリングのデメリットが目立つ
やっぱりまだ勘違いしてる。
リファクタリングが、一度作った後に行うものだと、まだ勘違いしている。
一度目であっても、作ってる最中に、こまめにリファクタリングしていくもの
という考えがどうしても理解できないらしい
それとも詳細設計というものがあって、そこに最初から
すべてのクラス、関数、引数がプライベートのものまで
全部網羅されてるとでもいうのか？
0603仕様書無しさん
2018/04/24(火) 20:48:25.79> 変更中で清書する前のコードならpushしねえよ
書きかけではなく本当に清書？
清書前でも理解しにくいだけで動くが、
理解しやすくために清書するってこと？
ならそれはリファクタリングに相当するね
もちろんちゃんとした手順でやらないといけないが
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【貧困】「もうオシマイだよ、この国」お金ないから夏休み廃止して!悲しき調査結果に広がる首相批判「お前のメガネには何が映ってる」★4 [ぐれ★]
- 「もっとも失望した」炎上アーティストは誰？3位"コロンブス騒動"ミセス、2位Ado、「プロ意識に欠ける」圧倒的1位は [Ailuropoda melanoleuca★]
- 【沖縄】米兵性犯罪、県への連絡遅れ相次ぐ…「被害者のプライバシーを配慮」政府の釈明に県反発 [nita★]
- 【漫画】日本の野球漫画の「台湾料理がまずい」描写に台湾で驚きの声「日本人は台湾グルメが好きだとばかり…」★3 [ネギうどん★]
- 【沖縄】辺野古埋め立てに抗議する女性がダンプトラックの前に飛び出し 死亡した警備員は巻き込まれたか ★3 [nita★]
- 非正規公務員「再採用2回まで」の制限を撤廃 人事院 雇用安定に前進、でも「いつでも切られる」不安残る [蚤の市★]
- 推しのvtuberが男とコラボしてて嫌だ
- 石丸陣営の選挙プランナー三浦瑠麗起用これは勝てる [258663303]
- 世界で売れたゲーム1位マインクラフト 2位GTA5 3位は？
- 【動画】渋野日向子、米国ツアーでホールインワン⛳ [786835273]
- TIME誌「バイデン陣営はパニックに陥っている」トランプとの討論会でバイデン大統領、ド派手にやらかす [666250534]
- 女子バスケ成立しなくなり日本代表、咽び泣く「中国の220センチの崩し方なんてない。」