ﾘﾌｧｸﾀﾘﾝｸﾞすると全部ﾃｽﾄしろと言ってくるやつの矛盾

■ このスレッドは過去ログ倉庫に格納されています
2018/04/15(日) 13:13:44.63
機能追加や変更した時に、全部テストしてるでしょ？
いつもやってることじゃん
2018/04/23(月) 22:46:32.34
> 結局テストコード削除してたらだめじゃん

ちゃんとよめや。
移行して使われなくなってから削除するんだよ

お前みたいに、なにも考えずに削除してるんじゃねーよｗ


> 他人はリファクタ前と後で変わってないことをどうやって確かめるんだ

なんのためにコミットログがあると思ってんの？
あ、もしかしてそこから？

レベルの差が2段階、3段階ありそう・・・
2018/04/23(月) 22:48:18.58
>>548
勿体ぶらずにちょっと具体的な確認手続き言ってみなさい
2018/04/23(月) 22:54:04.64
>>549
1. リファクタリングする前にはテストがある。
2. 足りなければ追加する
3. テストが通る
4. リファクタリングする（コードを書き換える）
5. リファクタリングしてもテストが通る

それだけじゃん。

まだ補足が必要？

1. さらにコードを書き換える
2. コードを書き換えるうちに（テスト以外で）使われないモジュールが登場する
3. テストは通るがプロダクションコードでは使われてない
4. 使われてないコードは安全に削除できる

いわれないとわからないかなあ？ｗ
2018/04/23(月) 22:58:29.81
コミットログは？ｗ
2018/04/23(月) 22:59:42.12
>>551
他人が一連のリファクタリングの途中を
見るために決まってるじゃん？

なにかわからないところがあったの？
2018/04/23(月) 22:59:49.36
>>541
だからさ、「ガチガチに硬直化」って丁寧に言ってやってんじゃん
そりゃリファクタリングの過程でテストも書き換えるよ
ていうか書き換えるに決まってんじゃんアホか
開発中の日々形を変えるコードに対してガチガチのテストを書くなって言ってんだけど、
わかんない？アホだからわかんないの？もうちょっと精進しろよアホ
2018/04/23(月) 23:00:16.48
やっぱり話が通じないのは
レベルの差が4段階、5段階あるからか・・・
2018/04/23(月) 23:01:48.90
>>553
> だからさ、「ガチガチに硬直化」って丁寧に言ってやってんじゃん

ガチガチに硬直化ってなに？
ファイルをリードオンリーにでもすんのか？
変更できないコードなんてないはずだけど？


どうやるのかはしらないが、
お前がガチガチに硬直化させたのなら、
それはお前の責任だよね？
2018/04/23(月) 23:01:57.08
リファクタの途中よりリファクタの前と後で結果が変わらないことを保証してほしいんだけど
2018/04/23(月) 23:02:23.37
スクラッチでシステム作ったことないんだろうか
リリース済みのコードとそれに対する改修の文脈でばかり語ってるところを見ると、そうなんだろうな
2018/04/23(月) 23:02:52.05
>>553
> 開発中の日々形を変えるコードに対してガチガチのテストを書くなって言ってんだけど、

テスト＝仕様を元に決まるものなはずだけど、
仕様が日々変わりまくるのか？

ならそっちが問題だなｗ
2018/04/23(月) 23:03:48.02
>>555
経験が浅い人にはわかんないかも
リファクタ本に書かれてる話じゃなくてごめんね
2018/04/23(月) 23:05:13.56
>>556
> リファクタの途中よりリファクタの前と後で結果が変わらないことを保証してほしいんだけど

だからリファクタの前＝コミットログの修正前
リファクタの後＝コミットログの修正後だろ？

リファクタの前のテストコードを変更せずに
リファクタの後でもそのまま通れば
変わってないことが証明できる。




あー、これ↓を言っておかないとダメなんだろうなｗ
結果が変わってないと証明された後、
使われてないと判明したコードは削除できる
2018/04/23(月) 23:05:28.65
>>558
テストはクラスやメソッドの仕様であってシステムの仕様ではありませんが
2018/04/23(月) 23:05:53.43
おまいがリファクタして部分的な仕様を変えまくってんじゃん

そのうえで全体的な仕様が変わってないことを保証しないといけないわけだが
2018/04/23(月) 23:06:32.49
>>559
> リファクタ本に書かれてる話じゃなくてごめんね

じゃあどこに書かれてる話なの？
お前の想像の世界の話はいらないからｗ

どうも「自分がくそったれなやり方してます。
くそったれなやり方には使えないんですけど？」
って言ってるようにしか見えない。
お前のくそったれなやり方の問題だろとしか
2018/04/23(月) 23:06:42.27
偉そうな口をきいてるわりに視野が狭い
2018/04/23(月) 23:07:05.91
>>561
> テストはクラスやメソッドの仕様であってシステムの仕様ではありませんが

だから？
システムの仕様じゃなくても、クラスやメソッドの仕様でしょう？
2018/04/23(月) 23:08:13.58
>>562
> おまいがリファクタして部分的な仕様を変えまくってんじゃん

変えてないよ？

日々テスト変えなきゃならないどこかの誰かさんと違って、
テストは基本安定している。

テストコードを変えない状態でコードを書き換えてるので
リファクタしても仕様はまったく変わらない
2018/04/23(月) 23:08:14.72
日々コードの形が変わっていくのをイメージできない初心者はIDDDでも読んでみたらー
2018/04/23(月) 23:10:19.92
もしかしてプライベートメソッドのテストをしてるとかかな？ｗ
それユニットテストじゃない

ユニットテストはモジュールのインターフェースのテストだから
変わりまくることはあり得ない。

もしモジュールのインターフェースという概念がなくて、
単に長いから関数にまとめましたみたいな、
なんでかしらないけど、この関数テストしづらいです。
なんてことをしてるのならそいつの問題
2018/04/23(月) 23:11:29.71
>>566
でも今まさにそれを変えるときの話してたよな？
2018/04/23(月) 23:12:22.55
具体的にどんなコードとどんなテストをかいて
ガチガチに固まって、メンテナンスが大変です。
なんて状態になってるのか書いてみたら良いよ。
想像の世界の話じゃないなら書けるはず
2018/04/23(月) 23:14:05.70
>>569
外から見た時の動きが変わってなければ良い。
そして外から見た時の動きが変わってないが、
（テストコード以外で）使われていないメソッドを作ることは可能
そしたら使われてないコードは安全に消せる。

こういう話をしてます。
2018/04/23(月) 23:18:32.85
>>571
つまり今までの話は
低い階層の処理クラスの単体テストの話で
さらにそれを包含するクラスの単体テストは別途あって
そっちは変更ないと
2018/04/23(月) 23:38:30.60
低い階層がなんののか知らんが、
【現在のクラス】をリファクタリングするとき

「新しいクラス」
↑
【現在のクラス】←「その他のクラス」←「その他のクラスのテストコード」
↑
「現在のクラスのテストコード」


こういう階層の時、「現在のクラスのテストコード」はそのままに、
「新しいクラス」に処理を移動していくことはできるだろ？
（移動だけじゃなくて新しく作ってもいいけど）

リファクタリングするのは【現在のクラス】だけ
「現在のクラスのテストコード」は書き換えない
【現在のクラス】を利用している「その他のクラス」も書き換えない
（当然「その他のクラスのテストコード」も）


コードの修正をすすめると【現在のクラス】は「新しいクラス」への移譲コードだけになる。

また「その他のクラス」は「新しいクラス」を参照するようにする。
「その他のクラスのテストコード」の修正はしないから、変わってないことは保証できる。
最終的に【現在のクラス】を「その他のクラス」は参照することはなくなる。

そして【現在のクラス】は「現在のクラスのテストコード」以外からは
どこからも使われてないクラスになるので安全に削除できる

これが関数レベルではない、クラスレベルのリファクタリングのやり方
それは>>542とかの本に書いてある基本だから、ほんと勉強してくれとしか
2018/04/23(月) 23:43:44.16
一応言っておくけど、これは、クラス根本的に
変えてしまうほどのリファクタリングの手順

メソッド一個だけとかならここまでやる必要はない。
その場合は、メソッド単体で、他のメソッドの委譲したりして
該当のメソッドを使われてない状態にしてから削除する
2018/04/23(月) 23:58:55.58
下位クラスの結果も検証するように緻密に単体テスト作られてればいいが

ユニットテストするときなんて下位クラスはモックになってること多い
その場合参照するクラス変わったらモック設定書き換えにゃならん
2018/04/24(火) 00:11:44.40
既にあるロジックをどこか別の場所に移動する以外にネタねえのかよw
2018/04/24(火) 00:16:57.50
>>547
あほ
2018/04/24(火) 00:18:30.70
>>561
テストにもいろんなレベルがあることに考えが至らない奴隷コーダー
2018/04/24(火) 00:24:31.48
結局単体テストは個人のテスト証跡以上の意味はないのだろうか
2018/04/24(火) 00:42:19.08
あるよ
581仕様書無しさん
垢版 |
2018/04/24(火) 06:04:21.71
だから
リファクタリングなんぞ不要

数年後には業務変化の見直しと現在業務の確認のために、システムをまるごと作り直すから
2018/04/24(火) 06:15:49.27
出社めんどくせえ
2018/04/24(火) 08:16:15.86
>>581
ダメ管理者はよくそういう妄想に浸りたがるよなあ。
2018/04/24(火) 08:52:53.82
定期的なリプレースでは使う言語が変わる可能性が結構高い確率である
こまめにリファクタリングしたら大損だよ
2018/04/24(火) 09:48:46.57
>>584
こまめにリファクタリングってことは、リファクタリング後の修正がこまめに発生してるんだから、そこでリファクタリングコストの半分以上は回収できてると思うの
2018/04/24(火) 11:20:18.41
常に機能追加や改修しているようなソフトウェアであればリファクタリングは有効
一度作ったらあまり改修しないようなソフトウェアであればリファクタリングのデメリットが目立つ

つまり、アマゾンドットコムみたいに常に機能追加や改修が行われる投資対象であればリファクタリングで機動力を確保するのは理にかなってる
逆に家電に代表されるような組み込み系、もしくは制御系のような、機能追加や改修の頻度が低いものであればリファクタリングする意味は相対的に小さい

お金をつぎ込めばつぎ込むほどリターンがあるのであれば、CIの中にリファクタリングを入れてしまえばいいだろう
リファクタリングの結果がすぐに出やすく、デメリットであるリファクタリング起因の不具合についても
改修が多ければ多いほど、リファクタリング起因の不具合減産と相殺されるからだ

リファクタリングの問題でやはり難しいのは改修頻度が低く失敗が許されない分野だ
これらの分野は製造工数とテスト工数の比でいうとテスト工数の割合が大きい
つまり、リファクタリングによって過大なテスト工数が必要となってしまい、リファクタリングのメリットが吹き飛んでしまう
しかしながら動いている箇所はいじらない方針もいつまでも続くわけじゃない
いつかのタイミングで全面リプレースするか、リファクタリング（もはや資料もなく知っている人もいない）を行うことになる
2018/04/24(火) 12:15:51.10
リファクタリングによって設計が改善されたと思ってるのはやった本人だけとかありがち
588仕様書無しさん
垢版 |
2018/04/24(火) 13:06:03.44
>>583
うちもそうだよ？
課レベルのシステム、部レベルのシステム、社レベルのシステム
があって、それぞれの長が変わったらシステムの仕様変更が最初の長の仕事になってる。
システムの見直しと再設計って、その部署の現在運用を把握するのに最適という理由で。
2018/04/24(火) 13:34:56.47
それはそのシステムで業務効率化はされてるんか...?
もはやマニュアルってレベルだろそれ
エンジニアしか理解できない仕事のマニュアル。
2018/04/24(火) 13:49:15.67
まず業務があってシステムを作るべきか　※日本風
システムのあわせて業務を再構築するべきか　※欧米風

どっちがいいんだろうね
591仕様書無しさん
垢版 |
2018/04/24(火) 14:48:59.76
>>590
欧米は、システムに最初から経営方針や業務設計を盛り込んでるだけだよ？
日本と欧米に差はない。
あるのは、システム開発を速攻で内製で仕上げているか否か。
2018/04/24(火) 15:14:51.24
>>591
国内で内製やった7&iホールディングスが大コケしたけど
2018/04/24(火) 18:11:05.66
>>592
セブンミール時代からたまに使ってるけど、たしかに使いづらくなった。
けど、冷静に考えると。今のレベルのシステムを一応作れたなら。元々のシステムも実装できる。

運用方針を新システム化した際に「顧客のニーズ」を取り入れるために店長に聞いたら。
「店長のニーズ」を取り入れちゃったんだろうｗｗｗ

ただ、「店長のニーズ」も旧システムで現実に起こってる問題の結果で、
さらに、現在、店舗自体が人手不足に陥ってるから配達要員、商品供給ライン等で
旧システムであっても実際には様々な遅延等々があったんだろう。

おそらく、システムの使いづらさの原因は、まさかのアナログな「現場の配達に要する人手不足」だと思うわｗ
594KAC
垢版 |
2018/04/24(火) 18:20:09.23
>>590
本来なら日本風がいいんだけど、
パッケージ売りの欧米風の方が格段に安いから。
2018/04/24(火) 18:32:53.31
リリース前のコードまで
ガチガチに変更管理してる
現場ってあんの？
2018/04/24(火) 19:13:54.37
>>595
は？折角テスト終わったのに変更すんな
殺すぞ
2018/04/24(火) 19:16:58.60
>>596
は？
ボタン押すだけだろ
598KAC
垢版 |
2018/04/24(火) 19:17:09.86
>>595
リリース前も後も管理するのは当たり前
599KAC
垢版 |
2018/04/24(火) 19:19:03.12
>>597
お前さんが試験したこと無いのはよく分かった
2018/04/24(火) 19:22:18.29
ボタン押すだけとか前時代的すぎるwww
今はもうpushするだけの時代だぞ爺さん
2018/04/24(火) 20:26:27.79
>>600
変更中で清書する前のコードならpushしねえよ
2018/04/24(火) 20:45:57.41
>>586
> 常に機能追加や改修しているようなソフトウェアであればリファクタリングは有効
> 一度作ったらあまり改修しないようなソフトウェアであればリファクタリングのデメリットが目立つ

やっぱりまだ勘違いしてる。

リファクタリングが、一度作った後に行うものだと、まだ勘違いしている。

一度目であっても、作ってる最中に、こまめにリファクタリングしていくもの
という考えがどうしても理解できないらしい

それとも詳細設計というものがあって、そこに最初から
すべてのクラス、関数、引数がプライベートのものまで
全部網羅されてるとでもいうのか？
2018/04/24(火) 20:48:25.79
>>601
> 変更中で清書する前のコードならpushしねえよ

書きかけではなく本当に清書？
清書前でも理解しにくいだけで動くが、
理解しやすくために清書するってこと？

ならそれはリファクタリングに相当するね
もちろんちゃんとした手順でやらないといけないが
2018/04/24(火) 20:49:37.09
>>596
> は？折角テスト終わったのに変更すんな

それなら、テストする前にリファクタリングすればいいんだよ
2018/04/24(火) 20:52:29.27
>>587
> リファクタリングによって設計が改善されたと思ってるのはやった本人だけとかありがち

そういうレベルの人たちしかいないなら、
コードメトリクスを測定するツールで客観的に
判断したほうがよいだろう。
2018/04/24(火) 21:01:28.79
>>602
ちゃんとした手順がなにを指してるか知らんが、ファウラーのリファクタ本だとしたら
リリース前のコードに対してあんなまどろっこしいことせんよ
2018/04/24(火) 21:10:16.77
>>605
ツールで測定できるレベル（抽象度的な意味で）じゃ設計の善し悪しは測れないんで
2018/04/24(火) 21:15:31.28
>>586
> リファクタリングの問題でやはり難しいのは改修頻度が低く失敗が許されない分野だ

そういう分野で、循環的複雑度100オーバーの関数1000個のソフトウェアを
修正させたらどんなにテストしていたとしても修正のたびにバグ入れると思うよ。
どうやってこの問題を解決する？

何十回、何百回もテストするかい？それこそ過大なテスト工数だよね。
テストを一回やったらバグが全て見つかり一回の修正で全部直る。
修正後の再テストはバグが見つかった所だけでOK。とか思ってないか？



参考 循環的複雑度は
　50以上でテスト不可能 バグ混入確率70%
　75以上でいかなる変更も誤修正を生む バグ混入確率98%
と言われている。10以下にするのが普通


とここまで書いて思ったが、どんなコードが良いコードなのかわからない人は
実際にダメなコードの複雑度がどれくらいなのか具体的な数値を示さないと
わからないだろうな。どこかにサンプルないだろうか
2018/04/24(火) 21:16:39.31
>>607
> ツールで測定できるレベル（抽象度的な意味で）じゃ設計の善し悪しは測れないんで

だから自分たちで、判断できないレベルの人ばっかりなところだって、
ツールは測定するため物で、ちゃんと測定できますってｗ

完璧なものはわからないかもしれないけど、少なくともツールで
大きくだめだって言われた所は、マジでだめ
2018/04/24(火) 21:17:39.58
>>606
> リリース前のコードに対してあんなまどろっこしいことせんよ

しないから、エンバグするんでしょ？
2018/04/24(火) 21:21:24.00
>>609
そういうことじゃないです
ツールには文脈がわからないと言っています
コーディングじゃなくて設計の話です
2018/04/24(火) 21:24:58.14
>>610
開発中の話だからエンバグしたっていいんだよ、どうせすぐに検知できるし
開発中のテストと品質のためのテストは目的が違うので
2018/04/24(火) 21:26:26.40
リファクタリングとかやっちゃうお前らだと、給料っていくらぐらい？
2018/04/24(火) 21:34:10.80
>>602
そうだよ
トップクラスの企業になると詳細設計で全てが完全に定義されててコーディングは規則に従い変換して写すだけ
なのでリファクタリングの出る幕はない
2018/04/24(火) 21:54:55.03
>>614
証拠見せて
2018/04/24(火) 21:57:22.40
トップクラスの企業ってGoogleとかじゃないの？
2018/04/24(火) 22:10:14.59
自分の書いたコードが汚すぎて死ぬ
2018/04/24(火) 22:21:22.68
>>615
転職
2018/04/24(火) 22:23:41.34
>>618
今より落ちるのはちょっとｗ
2018/04/24(火) 22:40:05.38
>>614
（奴隷度）トップクラス
2018/04/25(水) 00:01:43.85
トップクラスの企業って言葉で連想するのはメーカー子会社の協力企業あたりだな
GoogleやAmazonを表現するのにトップクラスの企業って言葉じゃ足りない
2018/04/25(水) 00:12:23.85
株式会社トップクラス
2018/04/25(水) 00:27:05.94
FAMGAは企業を超えたよくわからないシステム
2018/04/25(水) 01:31:18.64
>>602
リリース前のアルファ版未満モック以上版なら、デグレ上等でノリと勢いでガンガン変わってくだろ。
わざわざリファクタリング手順など踏まんで、テスターとペアになって開発した方が良い
2018/04/25(水) 01:43:42.64
>>613
手取り35
2018/04/25(水) 08:41:32.66
組織と自分の履歴サーバを別けている
日本のリファクタリングあるある
627仕様書無しさん
垢版 |
2018/04/25(水) 17:33:16.56
人気グループ「ＴＯＫＩＯ」の山口達也メンバーが、自宅マンションの部屋で女子高校生に無理やりキスをするなどの行為をしたとして、警視庁は強制わいせつの疑いで書類送検しました。

全文は以下
https://www3.nhk.or.jp/news/html/20180425/k10011417181000.html
628KAC
垢版 |
2018/04/25(水) 18:02:35.15
>>626
分けるメリットがなんかあるの？
2018/04/25(水) 18:20:49.80
>>628
メリットなんてないよ

PUSHに上司の承認が要る部署とか以外は
2018/04/25(水) 18:43:41.61
レビューしないのかな？
2018/04/25(水) 20:35:48.01
ぬおーん
2018/04/25(水) 22:46:40.90
コード読めないからレビューできないんじゃね？ｗ
2018/04/25(水) 22:49:39.16
ここで一部の人に衝撃的な事実を言っておきますね。

レビューができるコードっていうのは1関数あたりだいたい10〜20行程度までです。
50行なんて超えたらぜったいにレビューできません。

人の能力の問題じゃなくて、レビューできないコードです。
解析が必要になったら、それはレビューとは言えません。

だから1関数当たり10〜20行になっていなければいけません。
これを超えるものがざらにあるようなプロジェクトは失格です
2018/04/25(水) 22:54:58.77
10行って引数の多いメソッドの前準備してるだけで終わるレベル
俺は200行程度まで許容範囲
635KAC
垢版 |
2018/04/25(水) 22:57:37.78
>>633
レビューできない根拠が
理由にすらなってない訳だが…
2018/04/25(水) 23:02:01.36
レビューは通過儀礼だから
コードなんて誰も見てない
見てるのは担当者の活舌
2018/04/25(水) 23:02:22.78
Ｗｅｂ業務なら少々長くても大丈夫
帳票とかＤＢとかでっかい構造体にいっこずつ値入れてるだけだから
長くても込み入ってないことおおい

組み込みとかどうだろう
2018/04/25(水) 23:03:22.71
>>634
許容とかそういうレベルじゃない。
どんだけヘボならそんな長いコードができるんだ？レベルだよ。
これは本当の話

>>635
マジレビューできないってｗ
2018/04/25(水) 23:03:29.06
関数の行数よりネストの深さとスコープの方が大事
2018/04/25(水) 23:07:40.35
>>636
> コードなんて誰も見てない
だろ？
長いコードは読まない。
レビューできないから

>>637
ウェブ系でもありえないな。

ほんとね、一人前のプログラマか、ゴミかどうかは
1関数10〜20が普通って聞いて信じられるかどうかでわかるよ

比較的大規模なウェブアプリの例。みてみろ。コレがレビュー可能なコードってもんだ
https://github.com/gitlabhq/gitlabhq/tree/master/app

50行とか超えてるコードばかり見てる人、↑これみれば、
50行なんて長いコードはレビューできないのが当たり前ってわかるよ。
2018/04/25(水) 23:10:26.57
小さなクラスやメソッドにするのはいいことだけど、適切な命名ができるのが大前提
英語が苦手な奴はデタラメな名前をつけるから余計わかりづらくなる
形だけ小さくして満足してるバカが多い
2018/04/25(水) 23:12:13.47
>>641
それは当然だけど、50行とか平気で超えてるようなコードを書く人たちに
現実ってものを突きつけたいと思ってね。
2018/04/25(水) 23:16:39.06
どうせ携帯のちっこい画面用だろ
2018/04/25(水) 23:17:41.01
リファクタリングするとバグがーとか言ってるのは
おそらく50行とか平気で超えてるような所だろう

レベルに大きな差があるから話が通じない。

1関数たったのこれだけしかないから、
この関数が動くかどうかテストするのは簡単なんだ
2018/04/25(水) 23:23:52.25
ほう
https://github.com/gitlabhq/gitlabhq/blob/master/app/helpers/submodule_helper.rb
2018/04/25(水) 23:25:40.51
>>645
それを見つけるまで、何ファイル探したかな？
ものすごくレアだってのがわかるだろう。

長いそれであっても50行は超えていない
2018/04/25(水) 23:25:41.82
コードの優劣は、そのコードが生み出す経済的価値によって決まる
ただ綺麗なコードより汚くても利益を生むコードの方が価値がある
大して価値のないコードを一生懸命リファクタリングしてる奴には、そんなゴミ捨てて意味のあるコードを書けと言いたいね
2018/04/25(水) 23:26:50.34
はい、言い訳きたーｗ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況