リファクタリングすると全部テストしろと言ってくるやつの矛盾
■ このスレッドは過去ログ倉庫に格納されています
機能追加や変更した時に、全部テストしてるでしょ?
いつもやってることじゃん >>597
お前さんが試験したこと無いのはよく分かった ボタン押すだけとか前時代的すぎるwww
今はもうpushするだけの時代だぞ爺さん >>600
変更中で清書する前のコードならpushしねえよ >>586
> 常に機能追加や改修しているようなソフトウェアであればリファクタリングは有効
> 一度作ったらあまり改修しないようなソフトウェアであればリファクタリングのデメリットが目立つ
やっぱりまだ勘違いしてる。
リファクタリングが、一度作った後に行うものだと、まだ勘違いしている。
一度目であっても、作ってる最中に、こまめにリファクタリングしていくもの
という考えがどうしても理解できないらしい
それとも詳細設計というものがあって、そこに最初から
すべてのクラス、関数、引数がプライベートのものまで
全部網羅されてるとでもいうのか? >>601
> 変更中で清書する前のコードならpushしねえよ
書きかけではなく本当に清書?
清書前でも理解しにくいだけで動くが、
理解しやすくために清書するってこと?
ならそれはリファクタリングに相当するね
もちろんちゃんとした手順でやらないといけないが >>596
> は?折角テスト終わったのに変更すんな
それなら、テストする前にリファクタリングすればいいんだよ >>587
> リファクタリングによって設計が改善されたと思ってるのはやった本人だけとかありがち
そういうレベルの人たちしかいないなら、
コードメトリクスを測定するツールで客観的に
判断したほうがよいだろう。 >>602
ちゃんとした手順がなにを指してるか知らんが、ファウラーのリファクタ本だとしたら
リリース前のコードに対してあんなまどろっこしいことせんよ >>605
ツールで測定できるレベル(抽象度的な意味で)じゃ設計の善し悪しは測れないんで >>586
> リファクタリングの問題でやはり難しいのは改修頻度が低く失敗が許されない分野だ
そういう分野で、循環的複雑度100オーバーの関数1000個のソフトウェアを
修正させたらどんなにテストしていたとしても修正のたびにバグ入れると思うよ。
どうやってこの問題を解決する?
何十回、何百回もテストするかい?それこそ過大なテスト工数だよね。
テストを一回やったらバグが全て見つかり一回の修正で全部直る。
修正後の再テストはバグが見つかった所だけでOK。とか思ってないか?
参考 循環的複雑度は
50以上でテスト不可能 バグ混入確率70%
75以上でいかなる変更も誤修正を生む バグ混入確率98%
と言われている。10以下にするのが普通
とここまで書いて思ったが、どんなコードが良いコードなのかわからない人は
実際にダメなコードの複雑度がどれくらいなのか具体的な数値を示さないと
わからないだろうな。どこかにサンプルないだろうか >>607
> ツールで測定できるレベル(抽象度的な意味で)じゃ設計の善し悪しは測れないんで
だから自分たちで、判断できないレベルの人ばっかりなところだって、
ツールは測定するため物で、ちゃんと測定できますってw
完璧なものはわからないかもしれないけど、少なくともツールで
大きくだめだって言われた所は、マジでだめ >>606
> リリース前のコードに対してあんなまどろっこしいことせんよ
しないから、エンバグするんでしょ? >>609
そういうことじゃないです
ツールには文脈がわからないと言っています
コーディングじゃなくて設計の話です >>610
開発中の話だからエンバグしたっていいんだよ、どうせすぐに検知できるし
開発中のテストと品質のためのテストは目的が違うので リファクタリングとかやっちゃうお前らだと、給料っていくらぐらい? >>602
そうだよ
トップクラスの企業になると詳細設計で全てが完全に定義されててコーディングは規則に従い変換して写すだけ
なのでリファクタリングの出る幕はない トップクラスの企業ってGoogleとかじゃないの? トップクラスの企業って言葉で連想するのはメーカー子会社の協力企業あたりだな
GoogleやAmazonを表現するのにトップクラスの企業って言葉じゃ足りない >>602
リリース前のアルファ版未満モック以上版なら、デグレ上等でノリと勢いでガンガン変わってくだろ。
わざわざリファクタリング手順など踏まんで、テスターとペアになって開発した方が良い 組織と自分の履歴サーバを別けている
日本のリファクタリングあるある 人気グループ「TOKIO」の山口達也メンバーが、自宅マンションの部屋で女子高校生に無理やりキスをするなどの行為をしたとして、警視庁は強制わいせつの疑いで書類送検しました。
全文は以下
https://www3.nhk.or.jp/news/html/20180425/k10011417181000.html >>628
メリットなんてないよ
PUSHに上司の承認が要る部署とか以外は ここで一部の人に衝撃的な事実を言っておきますね。
レビューができるコードっていうのは1関数あたりだいたい10〜20行程度までです。
50行なんて超えたらぜったいにレビューできません。
人の能力の問題じゃなくて、レビューできないコードです。
解析が必要になったら、それはレビューとは言えません。
だから1関数当たり10〜20行になっていなければいけません。
これを超えるものがざらにあるようなプロジェクトは失格です 10行って引数の多いメソッドの前準備してるだけで終わるレベル
俺は200行程度まで許容範囲 >>633
レビューできない根拠が
理由にすらなってない訳だが… レビューは通過儀礼だから
コードなんて誰も見てない
見てるのは担当者の活舌 Web業務なら少々長くても大丈夫
帳票とかDBとかでっかい構造体にいっこずつ値入れてるだけだから
長くても込み入ってないことおおい
組み込みとかどうだろう >>634
許容とかそういうレベルじゃない。
どんだけヘボならそんな長いコードができるんだ?レベルだよ。
これは本当の話
>>635
マジレビューできないってw >>636
> コードなんて誰も見てない
だろ?
長いコードは読まない。
レビューできないから
>>637
ウェブ系でもありえないな。
ほんとね、一人前のプログラマか、ゴミかどうかは
1関数10〜20が普通って聞いて信じられるかどうかでわかるよ
比較的大規模なウェブアプリの例。みてみろ。コレがレビュー可能なコードってもんだ
https://github.com/gitlabhq/gitlabhq/tree/master/app
50行とか超えてるコードばかり見てる人、↑これみれば、
50行なんて長いコードはレビューできないのが当たり前ってわかるよ。 小さなクラスやメソッドにするのはいいことだけど、適切な命名ができるのが大前提
英語が苦手な奴はデタラメな名前をつけるから余計わかりづらくなる
形だけ小さくして満足してるバカが多い >>641
それは当然だけど、50行とか平気で超えてるようなコードを書く人たちに
現実ってものを突きつけたいと思ってね。 リファクタリングするとバグがーとか言ってるのは
おそらく50行とか平気で超えてるような所だろう
レベルに大きな差があるから話が通じない。
1関数たったのこれだけしかないから、
この関数が動くかどうかテストするのは簡単なんだ >>645
それを見つけるまで、何ファイル探したかな?
ものすごくレアだってのがわかるだろう。
長いそれであっても50行は超えていない コードの優劣は、そのコードが生み出す経済的価値によって決まる
ただ綺麗なコードより汚くても利益を生むコードの方が価値がある
大して価値のないコードを一生懸命リファクタリングしてる奴には、そんなゴミ捨てて意味のあるコードを書けと言いたいね 英検1級レベルに満たない奴はローマ字でコードを書け くり返し言うが、俺が言いたいのは、技術力高い所は
本当にこれぐらいのレベルなんだよ、
ありえない話はしていない。その証拠 >>646
そんなに探してない
DBとかHTMLに値入れてるとことか長くなりがちなとこ探したけどなかったんで
helperっていう割とやばめの文字列が目に入ったんで開いたらあった
やっぱり扱うものによる
一番下のやつ50行超えてるぞアウトだアウトだ
https://github.com/gitlabhq/gitlabhq/blob/master/app/helpers/application_settings_helper.rb >>651
今までに何ファイル探した?
少ないのがわかるだろう? >>651
よくそんなの見つけてくるねw
ただの配列定義だった >>640
でもよ
それって設計書書くの大変じゃない?
200行のメソッドって10個〜20個になんだろ?
クラス図だって10倍か20倍にデカくなんだぞ
トレードオフの問題ちゃうんか?
たくさん仕事してるようで大半がメソッド名決めてるだけみたいな >>652
いや、自分も同じレベルだけど、自分のコードは出せないだろう?
オープンソースで参考にできるもの。
あの関数の短さで大規模なエンタープライズ向けの開発ツールが作れる。
そういう事実がそこにある。 >>656
> それって設計書書くの大変じゃない?
設計書書くの大変なんだよ?
ようするに設計書はこのぐらいのものを作って
一人前ってことなんだよ。
普段どれだけ適当な仕事しているかってのを
わかってほしい。それだけのレベルの差がある メソッドの仕様まで設計書に起こす奴って脳死しすぎやろw 設計書書くの大変かどうかは知らんが
事実としてあのコードは存在する。
あのコードを作るにはどうすればいいかを考えたほうが良い >>662
そうだな
リファクタする時間をプログラマにくれればいいんじゃないかな? >>660
作れるかどうかという理論上の話ではなく
実際に作られたシステムが、あれだけ関数の長さが短いという事実 >>663
その分、設計してる人の時間をとるんだろ? >>665
役に立たない設計書を書いてるような
やつに時間はいらない >>665
コードの奇麗さが価値なら
客からリファクタ用の時間をたっぷりふんだくれるはず >>667
別にいらんよ。コードが綺麗なら
同じ時間でより多くのものが作れる。
言い換えると技術力が高ければ、
同じ時間でより多くのものが作れる
という当たり前の話だ >>667ってなんか発想がおかしくね?
客から作業代をどうやってむしり取ろうかって発想になってる。 >>664
Jenkinsは至るところで使われてるけど50行以上のメソッドなんていくらでもある事実 >>659
原点回帰が必要だよお前
人間が見てわかりやすい範囲を明らかに逸脱してるだろ
概算で役に立たない
2000行規模のコードでメソッド200個近く作るんだろ
どうやって表現すんの?お前
なんもドキュメント作らない前提じゃないと成り立たない
つっかえねーw われながら途中で投げ出してわかるからと適当に書いた設計書がやばい
自分はわかるがテスターが
どうしよ >>668
当たり前とはつまり自分の思い込みで根拠がないことを指す
このコードだって最初からきれいに書いてちゃっちゃと作ったのか
時間をかけてレビューして整頓したのかどうかなんてわかんないじゃん >>674
> 2000行規模のコードでメソッド200個近く作るんだろ
> どうやって表現すんの?お前
でもさ、コードでは実際にそう表現されてるよ?
そこの矛盾に、君が気づかないといけない 面白いのを見つけてきた
【読者参加型企画】2,000行のJavaソースコードを読むのに何分かかりますか?
https://codezine.jp/article/detail/4388
コードレビュー速度 (1時間あたり)
IEEE: IEEE Standard for Software Reviews and Audits(1028-2008) によると
100〜200行(Technical reviews)らしい。
つまり2000行だと10〜20時間、1日〜3日、コードレビューにかかる
いいですか?
2000行にかかるコードレビューの時間です。 https://gigazine.net/news/20150918-google-2billion-code/
> 2015年1月時点で、総ファイル数は10億、ソースファイルの数は900万、
> コードは20億行あり、3500万回のコミットがあって、内容は86TBあるとのこと。
> そして、営業日1日に対してのコミット回数は4万5000回。
1ファイルの平均は20億÷900万=222行でした。
2000行規模なら10ファイル程度
俺は妥当なところだねと思うが、
そう思わない人がいる。
そこにレベルの差を感じる トレードオフって言葉を覚えた方がいいよ
この機能を実現するために必要な処理は何?
って聞かれても何も答えられないっしょ?
さらにドキュメントを書かせる現場で君は役に立たない
たった2000行程度で200個もメソッド作るようなカスはどこ行っても
使えねーからオープンソースでも
組んでろよ > この機能を実現するために必要な処理は何?
> って聞かれても何も答えられないっしょ?
「この機能」って?
この機能だけで見積もりできるの?設計できるの? >>678
で、なにが言いたいの?
スレの流れは関数の長さとそのレビューにかかる時間だったけど、その引用のレビュー時間は
関数の長さとどう関係があんの?
まさか、2000行のコードっていうのを、2000行のひとつの関係って解釈した? >>680
2000行なら100メソッドだろ?
何勝手に水増ししてんだw
普通に作れば100個のメソッドなんて普通にできる
1関数10〜20行にしないとテスト不可能
テスト可能にするとだいたいコレぐらいになる。
そこから逆算すれば100個のメソッドは
普通に作ればできる
トレードオフの話をするのであれば、
トレードオフした結果が100個だ
って、やっぱりマジ1関数10〜20なんてありえない
50行超えるのがザラなの? レベルに大きな差があるよ。
自覚だけはしておこう トレードオフって何と何のトレードオフなんだろう?
最初から短い関数で書けばいいと思うけど、
関数を長くすることで、何のメリットがあるの? >>678
そもそもテクニカルレビューってなに?
どういう目的でどういうレビューをしてるかによってかかる時間はいくらでも変わると思うけど、
テクニカルレビューがなんなのかわからないから10〜20時間が長いのか短いのか評価できないんだけど ふつうだのレベルだの漠然としたことしか言わんやっちゃ 例えばプロだと間違えずにキーを打つことが高速にできる。
だけど素人だと間違えずにキーを打たなければいけないという
条件をつけると途端にタイプするのが遅くなる。
それと一緒でプロだと普通に作っても関数は10〜20行にできるが
そうでない素人だと頑張らないと達成できない
そう、素人 >>688
わかんないままドヤ顔で引用しちゃったんだな 技術的難易度が低いただのCRUDアプリみたいなものしか作れない人は、いかに綺麗にコードを書くかとか
そういう話題でしか技術っぽい話ができないから、ここぞとばかりに語るよな >>683
それって20行換算じゃん
最大行で見積もるなんて心苦しいから10行にしてやったんじゃん
2000行でメソッドが200個できて
20000行で2000個だ
100000行で10000個じゃん
この間やったプロジェクトのコードがそんなもんだったけど
メソッド10000個とか明らかに
茶碗が小さすぎる
おちょこに飯もってるみたいにアンバランスだろ >>689
> わかんないままドヤ顔で引用しちゃったんだな
いや、普通にリンク貼ってるじゃん? >>691
> この間やったプロジェクトのコードがそんなもんだったけど
お? ちょうどいいやん。
何ファイルで何クラスで何行ぐらい? >>693
いいや、コードは100000行でメソッド数は2000ってとこだね
10000とかドキュメント工数単純に5倍になんじゃねーか? そもそも設計書からしてそんなに大量のメソッド作成するように書いてるのか?
設計書に書いた処理とソースの処理を一致させないと説明が面倒だろ >>691
> 100000行で10000個じゃん
数を大きくして、多く見せたいようだけど無駄w
10万行だろ? 1ファイル(=1クラス相当)が200行ぐらいなので
500個もファイルがある。メソッド1万個は1ファイル(クラス)20個のメソッド
これは普通の規模だ
そもそもお前、ちゃんとモジュール化できてないだろ?
役割ごとにちゃんとファイル(クラス)分けろ >>695
> そもそも設計書からしてそんなに大量のメソッド作成するように書いてるのか?
実際にコードはそれぐらいになるんだから、
それに相当するメソッドは誰が作り出してるかってことだよ。
設計書にこの程度の数のメソッドが書いてないなら、
その設計書通りに作ると破綻するということを意味する
きちんとレビューしてテストするためには、
実際にそれだけの小ささのメソッドでなければいけないのだからね ■ このスレッドは過去ログ倉庫に格納されています