いつもやってることじゃん
あと、リファクタリングするとお前責任取れるのかとか言ってくるが
機能修正でバグった時の責任はリファクタリングじゃないんだから
全部あんたがとれよって言うと顔真っ赤になるｗ
なんでもかんでも一緒にするな
テスト粒度とかリスクとか理解できないの？
論理的におかしくならないと判明している
決められたやり方でやるので
リスクは低いしテストは自動化されています。
その前提ぐらい知らないんですか？
だからテストやらなくていいって？
そもそもクラスまで作り変えてるならテスト免除どころか設計書のレビューからだよね
リファクタリングは「テストをやってる」ことが
前提なので、
あんたが言ってるのは別のものでは？
そうですね？ なんでレビューせずに
リファクタリングするなんて思い込んでんの？
って書いてあるのに
↓
9 返信：仕様書無しさん[sage] 投稿日：2018/04/15(日) 14:45:55.12
だからテストやらなくていいって？
これもう頭が悪いレベルだろｗ
困る人がいるんですよｗ
改修作業の中身の違い
1. 無計画に適当に修正して手動でテストしてそれでもバグでて苦労するのと
2. リファクタリングの手法を使ってテストコード書いて低リスクで修正するかの違い
具体的にどう違うの？
TDDでリファクタリングした場合、
1、初歩的なミスにすぐ気付ける
2、作業者が精神的に安心できる
なお、開発者目線の開発体制の優先順位は
バージョン管理 > コードレビュー > 自動テスト > リファクタリング
なので、必ずリファクタリングとTDDはセットになる
リファクタリングの手法では先に自動化されたテストコードを書く
もしくはすでに存在していなければならない
だから、リファクタリングしたらテストしろよっていうのは意味不明。
リファクタリングの中にテストすることが条件として含まれており
修正前と修正後の両方、それどころか修正のたびにテストすると言ってるのに
なんでそんな当たり前ことを、それも最後だけテストするような質問をするんだ？と
疑問になる
おそらく修正とテストが分離した考え方しか持って無くて
修正後に手動でテストを行うというやり方しか知らないのだろう
そんな再現性がなくてテスト回数もすくないんじゃ、
バグがなかなか取れずにデスマになるのは必死だろう
工数も削減できないし
品質も上がらないんだ？ｗ
というか、責任あるポジションの経験がないやつが語ってるだけだからな
ちゃんと決定権を持つやつを納得させるだけの説明ができればいいだけだが、
それすらできていないっつーね
責任とって辞めます。
そこらへんの話でいうと、
売上や品質が上がった客観的なデータが示せりゃ、どの会社でも自動テストやリファクタリングは採用されるんよ
そこまでしてないなら、その議論は語るに値しない
んで、殆どの会社はそこを検証していない
そんなもん、やってみりゃ肌で感じ取れること
数値にしなきゃ理解できないよぉとかバカみたいなこと言ってると腕のいい職人にはなれませんよ？？
数値にできる学がねぇんだろｗ
数値化しろよ
仕事を規定の時間内に許容できる品質のものを上げるのが実装者に求める要求で、それに付随する手段は手段でしかない。
で、手段は自由にやればいいし、基本介入しないし、結果しか見る気は無い。
だからやりたければやれば？としか自分は言わない
工数増えるのは論外
> そこまでしてないなら、その議論は語るに値しない
> んで、殆どの会社はそこを検証していない
検証しろっていうのはわかるが、それは世間一般には
すでに検証されていてすでに品質が上がったというデータは出てるんだよな
それも検証するコストも出せないような会社がやるような中途半端な
方法じゃなくて、もっと大規模で信頼できる方法で検証した結果がすでにある。
で、それを参考にすりゃいいのに、参考にしないんだろう。
つまり他人を信用してない。だから他人がなにやってもどんなデータを出しても
そういう会社は信用しないんだろう。
検証してやるよ。コスト？そりゃ当然かかるよ
ここで嫌がる会社が多い
重要なのは、失敗するかもしれないがやってみよう
という考えが通じる会社かどうかなんだろうな
コストメリットどころかリスクしかない。
「リファクタリングの為の工数ください」
うん。意味不明だね。
誰もそんなこと言ってないけど？
が言ってること勘違いした？
リファクタリングが有効かどうかの検証の話だよ。
検証するには、同じことをリファクタリグをするのと
しないので2回やらないといけない。
検証にはコストがかかる。
俺の筋肉量でリファクタリングの効果を説明できる
いや、リファクタリングで総工数が減るなら勝手にやればいいだけじゃね？
リファクタリングで品質下がるなんて聞いた事無いわけだし。それとも単体テストレベルまでがっちり管理されてんの？
詳細設計省かずやる巨大案件でも無い限り、実装者に委ねられる部分やん。
ともすれば、やりたきゃやれって回答にしかならん。
> いや、リファクタリングで総工数が減るなら勝手にやればいいだけじゃね？
俺はやってるよ。リファクタリングで工数減るから
そもそも修正作業の中に自動的に組み込まれるものだから
あえて "リファクタリング単体で" 工数を取るなんてことはしない
だからリファクタリングのために工数くださいっていう発想が
そもそも間違ってるわけ。修正に伴う追加作業じゃない。
修正作業そのものなんだから
正常に動いていると証明するテストをしてないってこと？
正常に動いていることを証明するテストを修正後にもやれば、
正常に動くと証明できるでしょう？
修正許可与えてるなら、どんな修正をしたとしても
許されるはずだけど？
修正が発生したときにしかリファクタしないの？
機能追加だろうがなんでも修正って言う奴は素人でしょ
イカ臭いプログラム書いてろ
と言ってるようなもの
なんどもリファクタリングは修正の一部だって言ってるじゃん
一部ってことはそれ以外も有るってことだよ
複雑なコードを読み解いて、リファクタリングしないで複雑なまま修正するのと
複雑なコードを読み解いて、リファクタリングしてから修正するのと
どっちがリスクが少ないかって話だ
前者だと、複雑なコードを読み解いた人（修正担当者）がいるにもかかわらず
別の人が、また大変な思いをして読み解いてレビューしなければいけない
そして、次同じところを修正する時、また複雑なコード読み解かなければいけない
素人はおとなしくExcel方眼紙でセル結合の練習でもしておけ。
そんな入門書の1章に書いてあるような話はいいよ、面白くないから
入門未満の人がいるんでね
テストの品質が後工程に無関係ならな。
まあそんな現場が多いのは事実だが。
リファクタリングするときのレビューとかどうしてる？
設計レビューもだし、コードレビューもだけど
お前さん、理想通りに開発が進めば
自動試験だけで完璧なものができるとか信じてる？
見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか
このスレには本当のリファクタリングが出来る奴はいない
elseなしに書き換えるのが精一杯のFラン説教野郎みたいなのがいるだけ
お前のプロジェクトはもう死んでいる
> リファクタリングするときのレビューとかどうしてる？
リファクタリングではないときはどうしてる？
それと同じなんだが。
まあそういう質問するってことはリファクタリングに限らず
そもそも設計もコードもレビューしてないってことなんだろうけど
まずはそこからやねｗ
> 自動試験だけで完璧なものができるとか信じてる？
だからレビューするんでしょ？
自動試験はバグがないことを証明する手段
その手段が正しいかどうかはレビューでみる。
人手でレビューして、テストした内容も記録されて
後なにがあれば完璧なものができると思います？
> テストしづらいとか、クラスが肥大化しすぎて開発に支障があるとかならまだしも
> 見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか
機能追加とか修正するという前提なんだから、どちらにしろ変更するしかないでしょｗ
自動試験してレビュー通ったらシステムインしてサービス開始すんの？
体験から語ってると思えるような発言もないし、こいつ多分そんなにノウハウないよ
レビューもするし自動以外のテストもする
そこは普通の機能変更のときとなにも変わらない
ただその時のやり方が、複雑なコードを頑張って解析して
無理やりパッチを当てるような、あとから見た時に
なんでこんな面倒なことしてんの？と思われるような変更をするやり方から、
次回は複雑なコードを読まなくて良いように、複雑なコードを
シンプルに修正しつつ、まるで0からコードを書いた時のように
こういう機能を実現するなら、普通こう書くよねという
当たり前の形にするやり方に変わるだけ
変更するたびに複雑になっていくやり方をやめて
変更しても複雑にならない、むしろシンプルになるような
やり方をしましょうってこと
その後にやるテストうんぬんは、もともと機能変更でやる予定だったんだろ？
なら最初からやるって決まってることじゃないか
> 具体的な話からは煽りで逃げるし、
ん？ どのレス？
もう儀式になってない？
組織的にガチガチにやるもんじゃなくて
設計者の間で守るべき密やかな秘密程度で
やったほうが良い気がすんのね。
それはどんなコード変更のときでもやるべきことだから
リファクタリングの話とは関係ないという注意だけしておくね
ようは、リファクタリング前に存在するテストコードが
リファクタリング後でも通ることで動きを変えてないことが
証明できれば良いのでTDDである必要はないよ。
具体的にはgit使えば歴史変えられるんで、
コード変更しつつテストコード書いて、
コード変更とテストコードでコミット分けて
あとでrebaseしてテストコードのコミットをコード変更の
コミットより前に持ってくれば良い
TDDは保護するためのテストじゃないから
レビューのつもりで儀式やってるだけのところが多いね。
> TDDは保護するためのテストじゃないから
TDDはテストではなく開発手法ですよ？
TDDという開発手法ではリファクタリングの前にテストを書き
書いたテストが、その後に行うリファクタリングが問題ないことを証明するんですよ
つまり
× TDD = 保護するためのテスト
○ TDD =「保護するためのテスト」を用いた開発手法
（あんたの言った「保護」がリファクタリングで壊さないように守るという意味である前提）
俺がで言ったことは、TDDでやらなくてもテストで保護できると言ったんです。
ttps://postd.cc/test-driven-development/ > 簡単に言うと、TDDは機能を記述する前に自動テストを書く行為です。
> 例えば、Bobが素晴らしい新たなソーシャルネットワークのアイデアの
> ために新しい機能を開発する必要があるとしましょう。
>
> Bobは自動テストを書くことから始めますが、機能を正しく実装せずに、
> テストを失敗（赤色表示）させます。次に、Bobはテストを成功（緑色表示）
> させるための最小限のコードを記述します。緑色表示になったら、
> Bobはコードをきれいにし、テストを実行して機能が正しく
> 実装されたままであることを確認します（コードのリファクタリング）。
> 重複することなく、コードと自動テストは他の人も簡単に保守できます。
えーと、まずはスレタイの
「リファクタリングすると全部テスト」については、
「全部テストするのは当たり前」という理解でOK？
それなら、大筋では意見に違いは無い。
before（リファクタリングしない場合）
1. 機能追加やバグ修正などの変更依頼が来る
2. 変更する
3. 変更したので全部テストをする
after（リファクタリングする場合）
1. 機能追加やバグ修正などの変更依頼が来る
2. 変更する（リファクタリングもする）
3. 変更したので全部テストをする
afterに対して、余計なことするな！
リファクタリングしたなら全部テストしろ！
と言われましても、beforeでも全部テストしてますよね？という話です。
まあ普通やるけど。
いやぁ、違うなぁ
リファクタリングさせないための方便として使ってるので
お前がリファクタリングするとテストする人が迷惑するんだぞ
だから余計なことするなという意味だろう。
だがもともとテストするわけで矛盾になるんだよな
そういうことじゃないんだよなぁ
違うよ
デグレしたときの徹底的なイジメがヤバイ
じゃあどういうことか書けよｗ
でもどっちみちコード変更するんでしょ？
リファクタリングしない方がデグレさせる可能性高いし
だからリファクタリングする気もない
いやリファクタリングすると触らなくていいとこまで変更するじゃん
既存コードを変更するって時点でまずい
触らなくていいかどうかが重要なんですか？
重要なのはテストする所かどうかでしょう？
触った所でテストするなら、なにも問題ないはずですが？
そうはいかねぇだろ
文章化されてないけど
クリアしてるいろんな仕様があんだからよ
長い間運用してるとそういうのあるわけよ
触らなければテストもしなくていい
プロは余計なコードも書かないし、余計なテストもしない
イメージはあってそう（スレ建てた奴とは違う意見）に読めたので、
具体的な内容を書いてみる。
大規模で難解なプロジェクトの一部機能で、
一カ所の編集バッファの数が足りず、
長い氏名の編集に失敗する仕様となっていた。
メモリの使用率なども調査済みで、編集文字数を増やすという仕様変更案件の場合。
バッファサイズを増やして関連箇所の試験して完了。
リファクタリングしたら、統べての試験をやり直し。
リファクタリングの有無でどちらが安いのか、
時と場合によるって認識はあってる？
リファクタリングできる設計になってるの？
も大きな要素だが
動いているなら弄るなよは永遠の真理
そのレベルの現場が多いもんな。
文字編集がややこしいから途中量の計算が難しいから処理変更とか？
リファクタリングの話は一旦おいておきましょう。
> そうはいかねぇだろ
> 文章化されてないけど
> クリアしてるいろんな仕様があんだからよ
それでどうやってコードを正しく変更できるんですか？
コードを変更する時に文書化されてない仕様を
間違って変えてしまうことがありますよね？
文書化されてない仕様をテストでどうやって
見つけるんですか？
> バッファサイズを増やして関連箇所の試験して完了。
>
> リファクタリングしたら、統べての試験をやり直し。
え？なんで？先に修正して試験するのがいけないんじゃん
1. リファクタリングをする
2. バッファサイズを増やす
3. 関連箇所の試験して完了
基本はこうですよ？
実際にはこんな大雑把作業じゃなくもう少し細かく
（ユニットテストと）リファクタリングと修正を何回か繰り返しますが
コードの変更とリファクタリングは切り離せません
コードの変更とリファクタリングの間に「関連箇所の試験して完了」
なんてものは入らないし入れたらダメです。
まさにそのスレでその話してるんだからおいとくなよ…
現に存在するものに文句言ったってしょうがないだろ
あるんだから
非機能要件のないソフトなんてない
改修部分が少なければ少ないほど踏んじゃうリスクは減るだろう
そりゃリファクタリングの必要がない場合にはリファクタリングしませんよｗ
前提として、リファクタリングの必要があるコードだって
ちゃんと書きましょうか？ そうすればもっとわかりやすくなりますね。
・リファクタリングをしない場合
1. ちゃんとした設計になっていない
2. そのままで無理やりバッファサイズを増やす
3. やってることが意味不明。変更に自信が持てない。コードレビューも大変。
4. 変更で問題が出やすい。そのたびに意味不明なコードと格闘する。
5. 関連箇所の試験して完了。
・リファクタリングをする場合
1. ちゃんとした設計になっていない
2. 設計を修正する（リファクタリング）
3. ちゃんとした設計に自然な形でバッファサイズを増やす
4. やってることが明確。変更に自信が持てる。コードレビューも簡単。
5. 変更に問題が出にくい。仮に出たとしてもちゃんとした設計になってるのですぐに修正できる
6. 関連箇所の試験して完了。
リファクタリングしたことで1工程増えたように見えますが、
ちゃんとした設計になってないものを無理やり修正した複雑なコードは
バグが出やすく、修正も大変になって時間がかかります。
それはわかるでしょう？
> 改修部分が少なければ少ないほど踏んじゃうリスクは減るだろう
改修部分をリファクタリングするんだから、
改修部分の量は同じですが？
具体的なイメージがわからない
本当に改修部分だけ改修だったらリファクタ部分消えちゃうじゃない
それってただの改修では
ちょっとなにかいいサンプルないか探したんだが
見つからなかったので、軽く例を書くわ
ある関数を改修部分することになった。これが100行を超える複雑なコード。
これをリファクタリングすると10行にできるとする
（ライブラリ使用の有無とかで、これぐらいざらにあるからｗ）
リファクタリングしない場合は無駄なコードで処理が入り組んでおり
入り組んだコードを時間をかけて頑張って解析し
そのまま修正するとなると数箇所を変更しなければいけなくなることが判明した
だが本当にその数箇所の変更で問題ないのか？ コードが複雑なのでよくわからない
レビュー依頼した所で時間をかけて解析したものを他の人がすぐに分かるはずもない
多くの時間を費やすることになった。
リファクタリングして10行にまで減らすと、コードはシンプルになりなにやってるのか一目瞭然になった。
テストコードがあるのでリファクタリングの前後でコードが壊れてないことはわかる。
リファクタリングしたため修正箇所もたったの一行になった。
他の人も何の修正をしたのかすぐに分かる
おまいのレスが長すぎてリファクタリングしないと読めない
バイバイ
リファクタリングの必要性をそこまで感じないってことは、俺の設計ってちゃんとしてるんだろうなぁ
あと仕様変更がないってことだろうね。
仕様変更があれば、少なからず設計を変更することになるから
OCPができてないから仕様の変更がいろんなところに波及するんだよ
あとから直せばいいやじゃなくて、もう少し基本を身に付けよう
最初から何でも考慮した過剰な設計は止めましょう
こっちが基本ですよ？ｗ
バグも無限
リファクタの状況的にはありだけど
それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
テストで検出できない非機能要件を踏んじゃうリスクは明らかに増えてるよね？
未だに賛同者が現れないｗｗｗｗ
しかも、リファクタリングそのものではなく、リファクタバカに対する非賛同が増殖ｗ
かたやリファクタすら許してもらえない信用と立場のリファクタバカが相変わらずの状態
かたや５年以上で完全に新規で作り直しの許可を与えられるようになった俺
技術書に溺れなくてよかった・・・。
あぁ、そういう事か。
「リファクタリング」という範囲のイメージが合ってなかったんだな。
関数単位のリファクタリングならそのイメージでだいたい合ってる。
「外部インタフェース変えずに内部の設計から見直す」事を前提に話してたよ。
それはそうとして、
関数の処理削減などで処理速度が変わったのなら、同期など含めてその観点での試験はちゃんとやれよ？
意味がわからない
お前、どっち派？
> それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
> テストで検出できない非機能要件を踏んじゃうリスクは明らかに増えてるよね？
関数の中の1行を変えたとして、
その1行だけをテストして関数全体OKってできるんですか？
そもそも関数の中の1行だけをテストすることは不可能だと思います。
結局関数全体をテストするわけでしょう？
> 関数の処理削減などで処理速度が変わったのなら、同期など含めてその観点での試験はちゃんとやれよ？
もともと修正すべき関数なんだから、リファクタリングしなくても
テスト必須でしょう？ なにを言ってるんでしょうか
でもさ
ソースで見たとき処理の下の方をちょっと修正すればいいところで
上の方の関係なさ気な箇所がバグったら言い訳できねぇよ
差分見て
何でここ弄ったの？今回の修正と関係ないじゃん
って言われたらちょっと嫌な空気流れるよ
> それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
「可読性」って言葉ご存知ですか？
「可読性」の二番目の文字は「読」です。
「書」ではないのです。
改修は「書く」ことですが、改修前には「読む」こと必須です。
では書く時間と読む時間、どちらが多くかかりますか？
もちろん読む方ですよね？
タイピングなんて1分間に200～300なんて軽く行く
改修の書く量だけを見ても正解にはたどり着けませんよ。
改修量ではなく作業始めてからの改修時間を見るのが筋じゃないですかね？
リファクタリングは改修時間を短くします。
関係ない所を修正するのがいけないのでは？ｗ
具体的なシナリオをいうとだ
日付をこりこり自前でデコードして値つくってる１００行近いまぬけコードを
Ｊａｖａのライブラリつかって数行にしてホルホルしてたら
ついうっかり見たことないようなフォーマットも受け入れちゃうようになってて
そんなん存在もわかんないからテストしてるわけなくて
でもユーザーは何の気なしに入れちゃうと入るからそのまま入れて、想定と異なるへんなデータが蓄積していって
集計バッチの演算とかにちょっとづつ毒虫のように影響を与え続けて
気が付いたらえらいことになってたりとか
理解できたらもとに戻してもいいのよ？
修正内容に応じてテスト観点増やさないの？
費用対効果考えながらテスト計画立てないと破綻するぞ？
それはリファクタリングしなくても起こる話ですね。
何度も言うように、そこが修正箇所です。
リファクタリングしなかったとしても修正する場所です。
修正して、ついうっかり見たことないようなフォーマットも受け入れちゃうようになってて
そんなん存在もわかんないからテストしてるわけなくて
でもユーザーは何の気なしに入れちゃうと入るからそのまま入れて、想定と異なるへんなデータが蓄積していって
リファクタリングと何の関係もない話ですよね
> 理解できたらもとに戻してもいいのよ？
次修正する時、また改修時間（読む時間）がかかりますよね？
もとに戻すと改修時間（読む時間）が無駄になるだけですね。
次回修正するときも、また改修時間がかかります。
バグが見つかったら、また改修時間がかかります。
> 修正内容に応じてテスト観点増やさないの？
少ししか修正してないから、テスト減らしていいとでも？
変更したコードの量は少しでも、その影響範囲は
修正の量とは無関係です。
どれくらい影響があるか、それはコードが複雑であれば
有るほど不明です。
テスト計画建てたこと無いの？
「全ての条件を網羅したらバグは無くなる」
は真だけど、それができないからみんな工夫してるんだよ。
バグのないものは存在しない
なんてのは、この業界の常識。
リファクタだけの問題じゃないが、リファクタも修正のうち
修正する以上人間がやらかすリスクはある
だったら修正は極力限定されているほうがいいだろ
>次修正する時、また改修時間（読む時間）がかかりますよね？
そしてリファクタ最大の問題
コードの読みやすさや理解しやすさは人の主観に大きく依存する
else取っ払ってタプル戻り値の関数に変えようとするやつもいるんだぞ
リファクタ後に修正したほうがテスト工数が削減できるとか、規約が新たにできたから合わせるとか
なにかしら明白な理由がないと
単なるコードの修正の意味で使ってるように見えるんだよねｗ
リファクタリングは、コードの修正、コードを綺麗にするを
英語にした言葉じゃないよ？
リファクタリングっていうのはやり方が決まってる。
スタート（修正前）とゴール（修正後）は自分で決めるけど
スタートからゴールへ至る道へは、決まったやり方を使って修正する
その決まったやり方っていうのは、動きを変えないための方法
数学の等式の変形みたいなもんだ
x - 2 = 8 を「移行」して
x = 8 + 2 に変形しても意味は変わらない
こういう「移行」みたいに変形しても意味が変わらないやり方に
ご丁寧に名前までつけてカタログ化されてる。
テスト書いて決められたやり方で式を変形するんだから
無計画なコードの修正なんかよりもずっと安全に変形できる
いや、だから、一行の変更なら
テスト減らせるってわけじゃないよって言ってるんだが？
> コードの読みやすさや理解しやすさは人の主観に大きく依存する
じゃあ主観に依存しないものを採用すればいいだけでは？
コードメトリクスを計測せよ
そうだね
リスクはひくいよ
Eclipseのリファクタ機能使うならなおさらだ
それでもたまにやらかすだろ！
メトリクスのどれ見んの？
> それでもたまにやらかすだろ！
複雑なコードをそのまま修正するほうが
やらかします。
その場合、いくら修正してもバグはなおらないし
直したそばから別のバグが発生するし、
時間もかかるしで、良いことはまったくありません。
重要なのは改修量ではなく改修時間な
現実的には既存のユニットテストのコードを信用して
手続きを頭に置きつつ直観でつくり変えていくことになる
そんで流して結果変わってなきゃＯＫと
理想が定義されているからといって現実に耐えうるかというと
基本的にメトリクス測定ツールは、基準値超えたら
アラート出してくれるはずだからそれに従えばいいと思うけど、
俺はCyclomatic複雑度を重視するね。
改修による単体工数の削減はあるかもしらんが
時間重視ならなおのことリファクタやってるひまなんかないだろ
あれほどの時間泥棒もない
よく考えたら書くほうが早いっつったって
結局その前に理解しないと書き直せないんだから一緒じゃねーか！
だまされるとこだった
> 結局その前に理解しないと書き直せないんだから一緒じゃねーか！
だから、たった一行の修正とか言っても、
その修正にかかる時間は、理解する時間が大半を占めるんだから
リファクタリングしても大差ないって話だよ。
大差ないどころか、複雑なものを複雑なまま、頭の中で理解するほうが
時間かかると思うがね
そして理解した結果をコードに反映させないで、レビューにかかる時間
次に修正する時間、バグ出た時に読み返す時間を費やするか
コードに反映させて、その後にある時間を減らすかどうか
で？結局リファクタやると具体的に何がいいんだっけ？
色々話してるとメリットが全く見えなくなっちゃう
思うのは勝手だが最初にしてた変更リスクの話を忘れてないか
> で？結局リファクタやると具体的に何がいいんだっけ？
まず改修時間はさほど変わらない。
変更リスクもどちらにしろテストする場所なので変わらないし
行数が少ないほうが影響範囲が小さいってこともない
リファクタリングでバグ入れそうなコードは
リファクタリングしなかったらもっとバグを入れやすい
そして、レビューやバグがあったときの読み返し時間の削減
修正内容に自信が持てる。今後の修正の時の改修時間の減少
いや全然わからない
普通に改修する場合と比べて何がいいの？
っていう顧客の声がまんまリファクタリングしない場合にあてはまるな
1行の修正だからリスクが少ないとお考えか！？
1行の修正でもお金がかかるってことは、1行だからって
なにかを減らせるわけじゃないんですよ。
そこで普通に改修っていうのは
リファクタリングをしないってこと
リファクタリングが「理解や修正が簡単になるように、内部構造を改善すること」
なのだからリファクタリングしないってこうのは
理解や修正が簡単になるように改善をしないってこと
元からすでに改善済みのものをリファクタリングしろとは言ってない
理解や修正が難しいコードであることは大前提
で「普通に改修」というのは改善なしに複雑なまま修正ということになるのだから
で言ったようなメリットが有る
複雑なものをそのままにして手を入れたら
もっと複雑になるよ。
簡単なコードは意味がないからリファクタできない
重要なのは手遅れになる前にこまめにやることだよね
大規模リファクタリングなんてのはあってはだめ
リファクタリングだけのための作業なんて持っての他
そうやって手遅れにするから、リファクタリングのための
工数なんて取れるかーみたいな話になる
リファクタリングは、機能追加や変更に伴う作業に
含まれているべきものですよ
今どきリファクタリングするのは機能追加や変更のタイミングに限らないよ
DDDやってる？機能の変更がなくても、業務にモデルを合わせるために日々リファクタリングするのが常識
ttp://hideoku.hatenablog.jp/entry/2013/03/07/223727 変更を完全に正当化できるまで待つのは、待ちすぎというものである。
プロジェクトはすでに重いコストを負っていて、先延ばしにすると変更するのがより
困難になる。対象となるコードには今より手が入り、さらに多くの他のコードに組み込まれることになるからだ。
継続的なリファクタリングは「ベストプラクティス」と考えられるようになってきたが、
ほとんどのプロジェクトチームは依然として慎重すぎる。コードを変更するリスクと、変更にかかる開発者の時間のコストを見込んでいるためだ。
しかし、それほど簡単に見抜けないのが、設計をぎこちないままにしておくリスクと、
その設計を何とかするためのコストである。
リファクタリングを行いたい開発者は、その決定が正統なものであると証明するよう求められることが多い。
こうした要求は理にかなっているように見えるが、もともと難しいものを不可能なほど難しくして、
リファクタリングを抑制する（または見えない所で行わせる）傾向がある。
ソフトウェア開発は、変更することで得られる利益や変更しないことで生じるコストを
正確に割り出せるような、予測可能なプロセスではない。
おまえらがやるからだめなのだ
駄目コード（ウィルスみたいなもん）をばら撒いてから治療なんて無理だからねえ。
デグレなんて起きなかったな
だからデグレは複雑なコードのまま変更するほうが
リスク高いんですってばw
リファクタリングは処理の内容を変えないで
コードをわかりやすく再配置するだけだから
デグレのリクスはすごく低いんだよね
リファクタリングがだめなのではなく
闇雲に修正するのがだめなのだ
> リファクタリングは処理の内容を変えないで
> コードをわかりやすく再配置するだけだから
外側は変えないけど内容は変えますよ
なに言ってるんですか
難解なコードを読み解いて修正前に正しく把握するのは難しいという主張？
正反対のことを平気でメリットとして主張してくる
わからないことや見えないことを逆に肯定理由にする
宗教家と同じ手口だな！
リファクタなんぞせず。
さらにある程度経過したシステムは捨てろ。
リファクタなんぞせず。
実装は変えるけど、処理の内容は変えませんよｗ
処理の内容っていうのは、1から1000までの数を足すとかいうことです。
forループを使うとか、計算式を使うっていうのは
実装であって処理の内容じゃありません
> 難解なコードを読み解いて修正前に正しく把握するのは難しいという主張？
違う。時間がかかるという主張
解読せずにリファクタリングすると酷いことになるだけだぞ？
どのように実装するかというのが処理の内容だから
リファクタリングで変更しないのは外部仕様な
内側は変えていいんですよ
今さら熱く語るようなトピックでもない
> 解読せずにリファクタリングすると酷いことになるだけだぞ？
リファクタリングする時に解読しないなんて誰が言ったの？
そもそも解読が必要になってるのはリファクタリングしてなかったからなんだが、
まあそんなこと言ってもしょうがない。過去の話だ。
今手元にあるのは解読が必要なほど複雑なコード
リファクタリングをしないということは、複雑なコードをそのままに
さらに複雑にする行為。それをレビューしてもらったって、できるわけがない。
なにせ解読が必要なほど複雑なコードなんだから、
そして、せっかく時間を書けて解読しても、その解読をコードに反映させないなら
次回修正する時にまた時間がかかる。そして次回修正はそんなに先のことじゃないかもしれない
なぜなら複雑なコードをさらに複雑にしたのだから、デグレのリスクも高い
せっかく時間かけて解読したのだから、それをコードに反映（リファクタリング）させましょう。
読むのは時間かかるが、書くのは大して時間はかからない。
そうすれば、リファクタリングしなかった場合の時間がかかるという問題が解決できる。
何回も同じこと言ってるんだけどなｗ
簡単なところから一歩ずつやったほうがいいよ
リファクタ病患者の闘病のために必要
君みたいに突っかかってるやつのためだよｗ
複雑な処理もリファクタリングすればシンプルになると信じてる奴は、まあ本質的には簡単なことしかやってないんだろう
例えば、SQLがわからないユーザーのために、DBにUIを提供するだけのCRUDアプリとか
やらないよりはやった方がいいけど、まぁ趣味の話だな
> 例えば、SQLがわからないユーザーのために、DBにUIを提供するだけのCRUDアプリとか
あんたは複雑なことをしたいのかもしれないけど
仕事なんだから客が求めるものを作るべきでは？
客は本質的に複雑なものばかり、求めてるんですか？
客が求めてるものは簡単なものばかりですよ。
設計ってどこまで含んでいってる？
クラス設計は？ どういうメソッドが有るとか
どういう階層をしているかとか
本があるけどもう売ってないな
本質的に簡単なことって、頑張れば誰にでもできるじゃん？
実際、キャリアの少ない若手プログラマだって、先輩やらの手助けを受けつつもちゃんと動くコードを書いて納品してるわけで
たかだか数年の経験しかないプログラマにでもやれなくはない程度の仕事を、ああだこうだいって多少整理された状態に
持っていくのがお前の言うリファクタリングでしょ？
まぁ誰かがやらなきゃいけない仕事なんだろうけど、それって汚いコードを書く奴の尻拭い以上のものではないし、
ドヤって語るほどのもんでもないように思うけどなー
ひとつの答えのようにおもえる
あとはリファクタしたほうが本当にましになってるのかという問題
> 本質的に簡単なことって、頑張れば誰にでもできるじゃん？
本質的に簡単なことって、頑張れば（＝コストと時間をかければ）誰にでもできるよ？
でもそれじゃだめだよね
コストと時間がかかってるんだから
関数抽出して使いまわしたいんだけど
やっていいもんじゃろか？
将棋でも自分の指した手がいい手かどうかわからない人いるよね。
初心者？上級者？
マシになってるかどうかわからない？
将棋で言えばどっちかな？
自分の指した手が良いかどうかわからないってことは
恥ずかしいことだと思ったほうが良い。
まあ、初心者なら仕方ないけど、そういう人は
コードメトリクスを計測したら良いよ。
客観的に良いか悪いかを判断してくれる。
>自分の指した手が良いかどうかわからないってことは
>恥ずかしいことだと思ったほうが良い。
やっぱりやらないに越したことはないな！
なんで？
そういう人はコード書いたらダメだって言ってるんだけど？
その区別ぐらいはできるだろうけどな
俺が運転すると事故るから
車はだめだみたいな。
改造するのは解読に時間がかかる
リファクタリングすると解読に時間がかかる
で、何がメリットだって主張？
二行目が繋がってない、つまらんからやり直して。
コピペしろって言ってる？
162 自分：仕様書無しさん[sage] 投稿日：2018/04/19(木) 21:57:46.81
> 解読せずにリファクタリングすると酷いことになるだけだぞ？
リファクタリングする時に解読しないなんて誰が言ったの？
そもそも解読が必要になってるのはリファクタリングしてなかったからなんだが、
まあそんなこと言ってもしょうがない。過去の話だ。
今手元にあるのは解読が必要なほど複雑なコード
リファクタリングをしないということは、複雑なコードをそのままに
さらに複雑にする行為。それをレビューしてもらったって、できるわけがない。
なにせ解読が必要なほど複雑なコードなんだから、
そして、せっかく時間を書けて解読しても、その解読をコードに反映させないなら
次回修正する時にまた時間がかかる。そして次回修正はそんなに先のことじゃないかもしれない
なぜなら複雑なコードをさらに複雑にしたのだから、デグレのリスクも高い
せっかく時間かけて解読したのだから、それをコードに反映（リファクタリング）させましょう。
読むのは時間かかるが、書くのは大して時間はかからない。
そうすれば、リファクタリングしなかった場合の時間がかかるという問題が解決できる。
何回も同じこと言ってるんだけどなｗ
冗長な文章だな
リファクタリングに時間がかかるって主張だよな？
どんなに技術的に見えようとも
人間の問題である
って偉い人が言ってた
(底辺ではなwww)
が抜けてる
人間の問題でない問題などというものがあろうか？
> リファクタリングに時間がかかるって主張だよな？
なんでそう何度も曲解するの？
わざとだよね？
時間がかかるのは、コードの修正。
リファクタリングしなくても時間がかかる
コードを解析している時間だな
たった一行の修正なのにこんなにするんですか！？って
言われるぐらいの費用になるのは、"コードのタイピング"には
含まれない部分がたくさんある
で、コードを解析する時間は
リファクタリング ＞ 一部修正
だって理解できないの？
「リファクタリング終わったコードを修正する時間は短い」
という主張に誤りは無いが、
リファクタリングする時間を無視してどうする。
そういうレベルの人はコードメトリクスを計測するツールを使ったほうが良い
ツールで問題が有るとされたコードはほぼ確実に問題が有る
> で、コードを解析する時間は
解析する時間って言ったのに、お前
↓
> リファクタリング ＞ 一部修正
修正する時間に話がすり替わってるじゃんｗ
解析する時間、すなわち複雑なコードをよんで
それがなにを意味しているか、どう書換えれば
正しく動くかを、考える時間は
リファクタリングしながら解析する時間 ＜ 一部修正のために解析する時間
こうだからな。
ぐちゃぐちゃに絡み合った紐の束から、少しづつ結び目をときながら、
適切な一本を抜き出すのと、結び目をとかずに適切な一本だけを抜き出すの
どちらが簡単なのかを考えればわかるだろ
スパゲティコードとはよく言ったものだｗ
それはそれでわかったが
言ったことの返答にもなってない
話のつながりが見えない
レベルが何を指すのかわからない
問題が何を指すのかわからない
リファクタする奴は思考が支離滅裂だな
客観的な問題も有るよっていったのが通じてないのか
話が分からんやつは困るな
お前さん、開発したこと無いの？
一部の修正の為に必要な解析情報量と
リファクタリングに必要な解析情報量の
違いすらわからないなら
解析の仕方がおかしいか、
内容を十分理解せずにリファクタリングしてるって事。
個人的経験から断固として異議を唱えたい
もしかしてリファクタリング、溜まってるんですか？
リファクタ厨は毎回そんなもんだよ
リファクタリングしろなんていってないんだよ。
修正する所、どちらにしろテストが必要な所
関係がある所を、少しづつやればいい。
時間がかかるっていうのは、それはいつも手遅れの
コードばかりだって自覚有るからじゃねーの？
リファクタリング＝大規模なものしかイメージできてないって
状態がそもそもやばいよ
142 自分：仕様書無しさん[sage] 投稿日：2018/04/19(木) 00:37:19.05
重要なのは手遅れになる前にこまめにやることだよね
大規模リファクタリングなんてのはあってはだめ
リファクタリングだけのための作業なんて持っての他
そうやって手遅れにするから、リファクタリングのための
工数なんて取れるかーみたいな話になる
リファクタリングは、機能追加や変更に伴う作業に
含まれているべきものですよ
何度も書いた。コピペしかしないよ？
え？説明になってないじゃん
そういう実例が書いてある本を紹介すればいいの？
ん？ すでに過去レスで書いたって言ってるんだけど、
お前はどのレスが「説明」だと思ったの？
リファクタでも同じように処理をちょっとずつゆがめて気が付かずにいるにちがいない
いや、ここまでそんなレス1つも無いから
ttps://blogs.yahoo.co.jp/mathweather4067/5819997.html > 指導のポイント
> ここの指導は、難しい。なかなか理解されないのが、現状です。
>
> まずは、「等式の性質」を思い出させることが必要でしょう。
>
> 次に、「１次方程式の解法」も思い出させます。
>
> その後、１次方程式の解法と対比させながら、進めていきます。
>
> 「等式の変形」は、等式をその目的に応じて変形することの良さが理解できていないと、
> 何のためにするのかがわからないまま、機械的に進めてしまいます。
>
> 導入部分を大事にしたいですね。
まさにコレだな
でも説明なってないと判断したレスがあるわけでしょう？
自分の都合のいいように捏造と曲解ばっかりしてるよね
一度もまともな実績がないくせに何で役に立つって言うんだろうね
どうせ数字も捏造してんだろう
曲解って俺が先に指摘したんだけど、
言われて悔しかったからって自分も使おうとしないでよｗ
どれが曲解かを指摘してない以上意味ないよ
そいつの説明が悪すぎる、良さってなんやねん
理解してもらえないのではない
自分が理解もせずに良いものだと思い込んでいるだけだ
本当に理解してたら必要性や可能になることを明確に説明できるはず
十分以上に説明してるんだけどなぁ
リファクタリングってほぼ全域書き換えでしょ？
そりゃ影響範囲が違いすぎるよ
142 自分：仕様書無しさん[sage] 投稿日：2018/04/19(木) 00:37:19.05
重要なのは手遅れになる前にこまめにやることだよね
大規模リファクタリングなんてのはあってはだめ
リファクタリングだけのための作業なんて持っての他
こまめにって言ってるのは、せいぜい関数レベルのリファクタリングの話でしょ
まだそれぐらいしか任せてもらえない立場なのかもしれないが、リファクタリングってそれだけじゃないから
リファクタリングは
テストコードのデバッグ
あほすｗｗｗ
基地外に何言っても無駄だよ。
相手の言葉を聞く能力がないからキチガイにして派遣すら首になってんだから。
214のどこを読めばそのレスとつながるのか
ＩＤ出ない板で自分がわかれば相手もわかるとか思ってるとか
なぜに対してのレスだと思ったのか？
それって
リファクタリングじゃなくて
リプレース
プログラムから仕様を起こすのは大変
だから現場が仕様を忘れる前に、再開発をするのが正しい
つまり、リファクタリングなんぞ不要
日本人のソフト開発って
土木工事想定なのな
世界は基本的に内製
リプレースとリファクタリングを混同するな
区別の仕方は？
コード周りの文脈でリプレースなんて表現するのか？
大規模リファクタリングとは
リプレイスの事ではないかと言う主張だよ
5年ごとにハードウェアを最新にして、ついでにソフトウェアも新ハード新OS向けにテストしますよと
で、ほとんどはリビルドで済む話だけど
どさくさにまぎれてちょっと不具合修正しましょうとか機能追加して欲しいとなる
そこにリファクタリングする余地は確かに出てくる
本来必要ないのに修正するという意味ではいかにもリファクタリングだ
ずいぶん狭い世界で生きてるんだね
転職経験2桁だけど何かいいたいことある？
リプレースでもなんでもいいけどリファクタリング以外のなにかでないと困るんだもんね
狭いね
ただのクズやんｗｗｗ
リファクタリングの定義は、外部的振る舞いを変えずに
理解や修正が簡単になるように内部構造を改善することなんだが
お前の言うリプレースっていうのは、外部的振る舞いを変えないものってことか？
普通にバージョンアップでは？
ｗｗｗ
> 大規模リファクタリングなんてあってはならないと言っちゃった以上
お前意味分かってんのか？
大規模リファクタリングなんてあってはいけないっていうのは
許されるのは小規模（せいぜい中規模）リファクタリングまでで
リファクタリングだけを大規模にやってはいけないないってことなんだが？
リファクタリングは、機能変更の中に含まれる、
通常のソースコード変更時に、こまめに行うものだから
大規模リファクタリングが必要になるのは、こまめにリファクタリングしてないで
ソースコードをどんどん劣化させ、限界がきたから作り直す
（それもリファクタリングではない手法で）となってる場合が多い。
大規模リファクタリングのほとんどは単なる改修という意味になっていて
リファクタリングとなってない事が多い
> 本来必要ないのに修正するという意味ではいかにもリファクタリングだ
何だその定義？
外部的振る舞いを変えずに理解や修正が簡単になるように
内部構造を改善することだけが「いかにもリファクタリング」って
言って良いんだよ。
必要ないのに修正するのがリファクタリングなんて定義初めて聞いたわw
どーこーの、定義ですか？ソースくださいｗ
> で、ほとんどはリビルドで済む話だけど
> どさくさにまぎれてちょっと不具合修正しましょうとか
それは不具合修正であってリファクタリングではない
（外部的振る舞いが変わっている）
> 機能追加して欲しいとなる
それは機能追加であってリファクタリングではない
（外部的振る舞いが変わっている）
リファクタリングというのは、不具合修正や機能追加を行う際に
行うもので、不具合修正や機能追加でやる内容の一部
リファクタリング or 不具合修正 or 機能追加 ではない
不具合修正（リファクタリング含む） or 機能追加（リファクタリング含む）
である
そんなことないと思うけど
そんなことないと思うけど
一社童貞のやつよりよっぽどマシ
俺自身は発言の中でリプレースとはどういうものかとはなにも規定してませんが
まぁ外部的振る舞いという面で考えると、変わる場合もあれば変わらない場合もあるよね当然
で、たまたま外部的振る舞いが変わらなかったとしても、それをリファクタリングとは呼ばないよね
中規模って具体的には？
なぜ？
そりゃそうだろうね。
リファクタリングは動きを変えないために、
特定の手順にしたがってソースコードを修正する
ttp://shop.ohmsha.co.jp/shopdetail/000000003881/ ここの詳細目次の、5章（は解説なので正確には6章）から
その手順がリファクタリング･カタログとしてまとめられてる。
これを読むと、このやり方なら動きが変わるわけないなってわかるはず。
そしてもう一つ重要なのはテスト。テストによって
外部的振る舞いが変わらないことを保証する
だから、たまたま外部的振る舞いが変わらないっていうのは
テストを実行してないんじゃないかと思われる
テストを実行して、外部的振る舞いが変わらないのを確認するのが
リファクタリングだから、修正のたびに何度も "意図的に" 外部的振る舞いが
変わってないことを確認してる（だからたまたまなんて思わない）
普段の改修の中でこまめに行うものだけがリファクタリングじゃないよ
プログラム全体に波及するような設計の変更は、ボーイスカウトルールに則ってるだけじゃやれないからね
確認するのがリファクタリングだから、
たまたま動きが変わらないのは、単なるソースコードの変更ってことか
多いんだよな、単なるソースコードの変更をリファクタリングとか言ってるやつ
プログラム全体に波及するような設計の変更を
こまめにやるってだけですが？
こまめにやるためのテクニックも↓に書いてありますよ。
>
ttp://shop.ohmsha.co.jp/shopdetail/000000003881/ > ここの詳細目次の、5章（は解説なので正確には6章）から
> その手順がリファクタリング･カタログとしてまとめられてる。
> これを読むと、このやり方なら動きが変わるわけないなってわかるはず。
えいやってやるしかないと思ってるのは
単にその力がないだけ
あまりにも悲惨なコードに短時間で多数の機能を追加しなきゃならん時とかね
多少のミスは割り切ってリファクタリングして機能追加して全体を手動テストして納品する
俺はこれをエクストリームリファクタリングと呼んでる
厳密なリファクタリング信者からすると気持ちわるいかもしれないが生産性は高い
ド素人か？
この業界で中規模と言ったら1000行以上、1万行未満のことだ
そういう場面も多々あるもんだけどね
井の中の蛙と大海の大ウミガメの違いと言えばおわかりになるでしょうか
うん。だから動きが変わるかもしれないわけでしょ？
それは単なる修正って言えば良いんだよ。
リファクタリングと呼ばなければいい
> 経験が少ないと、大規模リファクタリングの必要性に直面する状況が想像できないかもしれない
想像してるぞ？
こまめにリファクタリングしなかったから、
ソースコードに限界が来てしまった場合に
大規模リファクタリングになるって言ってるじゃないか
（そういう自体になる前にこまめにリファクタリングしよう）
そんなのファウラーの本に書いてあるか？
あの基本書の内容を踏襲していない行為をリファクタリングとは呼びませんよ？
× 経験が少ないと、大規模リファクタリングの必要性に直面する状況が想像できないかもしれない
○ 経験が少ないと、大規模 改修 の必要性に直面する状況が想像できないかもしれない
なんでリファクタリングじゃないものを
リファクタリングって呼ぶんですか？
リファクタリングを単なる改修の意味で使わないでください
> あの基本書の内容を踏襲していない行為をリファクタリングとは呼びませんよ？
そうですね。基本書の内容を踏襲していない行為は
リファクタリングと呼んではいけません。
ただの改修と言いましょう
かっこつけたいのかな？
グローバル変数(public static 変数も含む)を安全に排除するリファクタリングテクニックについて議論しよう
リファクタリングするときいつもこれだけはスマートに解決できない
リスクを背負って修正するしかなくなる
> なんでリファクタリングじゃないものを
> リファクタリングって呼ぶんですか？
お前にとっての「僕のリファクタリング」なんて知らんがな
俺にとってのとかじゃなくて
リファクタリングの正しい定義だ
ちゃんと調べてこいよ。
単なる改修の意味で使うな
壊れたテストを書き直すのもリファクタリングの一部
意味不明
大規模なものは改修で、小規模なものはリファクタリング？
なんでまた曲解するの？
２つの別々の話を混ぜないように
1. 大規模なものも小規模なものも外部的振る舞いが
変わらないようにちゃんとした手順で行って
テストで確認してるならリファクタリング
そうでないなら、単なる改修
2. 大規模リファクタリングが必要になるのは
普段からこまめにリファクタリングしてないから。
普段の改修の中でこまめにリファクタリングしていれば大規模なんて必要ない。
必要になるのは普段からリファクタリングしてなくて、
手遅れ状態になってる証拠。そういうのはあってはだめ
ある程度たまってから行うべきか？
結論：リファクタリングが不要になるように書け！
つまりソースの修正が必要なくなればいい
データベースでいうところの、UPDATEではなくINSERTになるようにすればいい
つまり、適切な粒度で関数（メソッド）を適切に作成すれば
リファクタリングは不要なのではないか？
例えば、1関数20行という教えはそういう意味も内包しているのではないか？
今までリファクタリングが必要になった場面を思い出して欲しい
やたら長い関数、スコープが不適切な変数、マジックナンバーやあり得ないelseの使い方などがほとんどではないだろうか？
本当にリファクタリングが必要な場面などほぼ無いはずである
もしリファクタリングが必要だというのであれば、それは清書を後回しにして適当に書きなぐることを優先した結果であり
そもそも「ソースを書いていない」わけである
漫画であればペン入れをしていない下書きやネームの状態、ガンプラでいえば接着剤を使わず仮組をした状態だ
もちろん、「正しく作る」ことよりも「とりあえず動く」ものを何よりも時間を優先して作ることが至上命題であることもあるだろう
それでも書道の名家は一発で何度でも美しい書体を生み出す
プログラマであっても一発で完全に美しいソースコードを生み出すスキルは必要なのではないだろうか？
以上のことから、「リファクタリングが不要になるように書け！」というのは正しいと言える
意味明瞭
あー、いや、テストファーストでは
最初にテストコードを書いて、
テストに通る最低限のコードを書いて
そのあとリファクタリングして
完成だから
つまりあんたの言う「ソースを書いている」状態にするまでに
リファクタリングをする。
ちょっと勉強し直してきて
先に実装しても、その後テストコードを書いて、それが通るのを維持しながら
ソースコードを読みやすくする。これもリファクタリング
リファクタリングを内包するわけじゃないですよ
テストファーストの手順の中に含まれるものだって話をしてるんだから
テストファースト＝リファクタリングなわけないでしょｗ
お前の日本語の理解力の問題だ
ttp://www.itmedia.co.jp/im/articles/0602/24/news137.html > 実行したテストコードが通らなければ『レッド』という状態になり、
> 実装コードを修正する。一方、テストが通った状態は『グリーン』と呼ぶ。
> ただしテストが通っても、可読性を考えてコードをきれいに整えることも多い。
> テストファーストではこの修正作業を『リファクタリング』と呼んでいる。
へー、このスレ勉強になるな
テストファーストとリファクタリングは根本的に異なり
完全に独立して成り立つものですよ
むしろテストファーストの目的を没却する悪手と言っていいでしょう
意味不明
テストの粒度が間違っている証拠です、にわかがよくやります
そりゃそうだろｗ
だからこそ、テストファーストしてから
リファクタリングするって話になる
意味明瞭
ではテストファーストとリファクタリングを一緒に語るのをやめるべきです
でも、ぐぐったけど、そんな事ないてないよ
ニワカはお前では？
ググらないとわからないならお前がにわかです
意味不明
意味明瞭
はい。だからリファクタリングだけでも話をしています。
でもそう書いたでしょう？
> もちろんテストファーストをしないならリファクタリングはしないってことじゃないよ。
テストファースト（開発の前にテストを書く）をしなくても、
リファクタリングは独立したものなので、
開発→テストコードを書く→リファクタリングという手順で、
リファクタリングをすることがあります。
開発の前にテストコードを書いてないのでこれはテストファーストではありません。
でもお前はググってないで、自分の意見を主張しているわけだよね？
そしてそれが世間で言われてないことがバレたよね？
はいじゃないが
バレてません、グーグルがなんでも知ってると思うな
情報の出どころは教えられないが
俺を信じてくれるよね？
はい
意味不明
意味明瞭
意味不明
意味明瞭
コードをいじってばかりのやつは、手段と目的が逆転している。
意味不明
意味明瞭
お前「意味明瞭」でググってみろｗｗｗ
意味不明
日本人じゃないんだろ
意味明瞭
> コードをいじってばかりのやつは、手段と目的が逆転している。
いや、だからリファクタリングだけやるのは論外って言ってるんだが？
目的は機能追加などの改修で、その手段（の一つ）がリファクタリング
目的を実行する時にこまめにやる手段で、手段そのものが目的になってるような
リファクタリングだけの作業とか大規模リファクタリングはおかしいって
言ってるんだが？
意味明瞭をわからない人間の方がブラジル人じゃないだろ
意味がはっきりわかること
意味不明
日本人なら普通そんな使い方しない
ブラジル人ではないだろうな
で、これの理由は？
お前は普通じゃないし日本人のこと1ミリも理解してない
史実に登場する最初の天皇の名前を言ってみろ
ググってみろ
はい知らないのな、お前日本人のこと1ミリも理解できてない
「意味不明」と「意味明瞭」がちゃんと対照的に使われている例を教えてよ先生
キチガイおつ
それ理由になってねーよ
ググってみろ
在日おつ
うっわ
キチガイ
「意味不明」とは意味がはっきりしないという意味です
「意味明瞭」とは意味がはっきりしてるという意味です
ゆえにこれらの言葉は対称の関係にあるわけです
統合失調症ですねわかります
ソース
対称と対照の違いもわからないカスがこちら
世の中一般の使用例あげろよ、あるんならな
対照は文脈的に大間違いだったので訂正しました
わかってないのはお前です、お前がカス
やっぱ日本人じゃないな
なぜ間違いなの？
意味がはっきりわかるときに、意味明瞭と言います
これが一般的な使用例です
あなたはただの世間知らずというか無知です
無知な人間は自分が賢いと思いこむ傾向にあることが
認知心理学の研究の結果明らかになっています
あなたは自分が無知であるがゆえに意味明瞭という
自分が知らない言葉を使いこなしている僕に嫉妬しています
無知を自覚してください
そう言われている具体的な例が未だに出てこない点でアレ
対照ではないからです
なぜならば対称しているからです
対照関係と対象関係は明らかに異なります
だからその一般的に使用されている例を出してみろよ
説明できていないｗｗｗ
これ統合失調症やろ
対象も出てきたｗｗｗ
それでは具体的な例を上げます
意味がはっきりわかったときに
意味明瞭と言います
この上なく具体的で一般的な例を提示しました
あなたはそれでもわからないと言いはるでしょう
しかし、それは自分が知らない事柄が存在することを認められないだけです
無知であるがゆえにあなたのプライドはとても高いのです
お前の頭の中を書き出してもそれは一般的とは言わない
ただの書き間違いですよ、残念でしたね
そら対象は違うやろ
妄想おつ
一般的に意味がはっきりわかる場面というのはあるでしょう？
無いんですか？ ありますよね、ありますよ
完全に一般的です
病院行きなさい
ただの書き間違いに一生懸命レスしても意味ないですよ
はい統合失調症
お前がODAに行けよ、万年引きこもり
漢字の違いがミソなのにそれを間違える時点でもうねｗｗｗ
うっわ
使用例
自分が医者だと錯覚してる人の方があれだと思います
妄想と現実の区別がつかない状態がこれです
それも妄想
医者なんて単語一言も出てきてないのに…これが統合失調症
打ち間違いなんてよくあることです
校正する人なんて居ないですしここ5chですし
正確さにこだわったところで1紋の得にもならないですし
一生懸命書き間違いを攻めようとしている様、とても滑稽です
統合失調症と診断できるのは医者だけですよん
想像力足りてなくないですか？
対称と対照の話で対象は書かねーよ
キチガイ以外は
だれも診断してない
妄想おつ
実際に病気かどうかは関係ないよ
世の中で統合失調症って言われてる人で実際に医師の診断受けた人ほとんどいないでしょ？
よう統合失調症
キチガイとも言う
変換ミスっただけだよ
変換ミスっただけでキチガイ呼ばわりとは
そっちの方がむしろあれじゃないですか
はい統合失調症って断定してた人いましたよ
妄想じゃないですよ、スレを検索してください
そんな人居ないというあなたの方が妄想乙です
変換ミスの話ではない
よおキチガイ
キチガイ
妄想おつ
対称を対象と変換ミスった話ですよ
それを変換ミスの話ではないと思ってるなら
それこそ妄想があれですよね
漢字の違いが主張のポイントなのにその漢字を間違えるなんてありえない
言うに事欠いてそれですかｗ
対象の意味を理解してないからそんなことが起こる
いうにことかいて
間違いは誰にでもありますし
僕は自分のミスを素直に認めていますよ
変換ミスだって、それを一生懸命攻めようとするのは野暮だと思いますし
本来の議論を見失ってると思います
リファクタリングの話をしてましたよね
じゃあ何？
誰もミスを責めてるんじゃない
統合失調症やな
だからミスじゃねーよｗｗｗ
意味を理解していようといまいと変換ミスは起こるものですよ
だからそこじゃないってｗｗｗ
ミスった本人がミスだと言ってるわけですからミスですよ
いいやお前はミスターだとかそんな寒いこと言おうとしてるんですか？
やめてください
そこですよ、僕の些細な変換ミスを針小棒大に大問題だと
大騒ぎしてYahoo!のトップを飾ろうと画策してる人はいないにしても
そこですよ
統合失調症やべーな
統合失調症こっわ
もう何回も言いましたよ
あなたがそれを受け入れられないことも予測してみせました
無知な人間というのは知を拒絶するものなのです
あなたは、意味明瞭という言葉を知らない
僕は、意味明瞭という言葉を知っている
この現実を受け入れられないのです
自分より賢い人間がいることを、自分が知らないことが
世の中にあることを受け入れることができず
自分だけの小さい世界の中に閉じこもって心の平穏を望むのです
僕はそれを悪いことだとは思いませんが無知な人だなって思います
お前の妄想じゃなくて、現実世界での使用例を
ソース
使用例のリンクをいくつか貼るだけなのに何言ってんのこいつ？
対称でも対照でもなくて
意味がはっきりわかることってありますよね？
現実であなたはそういう経験ないんですか？
僕の妄想の話ではありません、現実にそういうことあるでしょう
そういうときに使います
意味明瞭と言って意味がとてもよくわかりましたと相手に伝えるのです
リンク
リンクが貼りたいならあなたが貼りなさいよ
何でもかんでも他人に頼ろうとするな
頑張ってググるんだ
俺はそんな使用例知らないから貼れない
存在しないものは貼れない
ttp://medaka.5ch.net/test/read.cgi/prog/1523765624/417 死ね
妄想から出られないんですね
ないんですねわかります
自己引用わろた
知らないのなら覚えよう
知らないことを自覚したなら
自分の世界を広げよう
意味がはっきりわかるときに、意味明瞭と言います
そういう言葉があります
明瞭というのははっきりわかるという意味です
ゆえに意味明瞭というのは意味がはっきりわかるという意味です
リンク
ソース
また妄想かよ
長文はキチガイ
ソース
国語辞典には日本書紀のリンクが載ってるが
日本書紀にはリンクなんて存在しないからな
だからといって日本書紀の日本語はデタラメだと言う人は居ないだろ
リンクというのはそもそもインターネットが普及してグーグルという
営利企業がそれによってランク付けをするように成ってから
重要視されるようになっただけで、それがなくても言葉っていうのは
作られていくし伝わっていくし話されていくんだよ、僕はその言葉の
大切さを少しでも伝えられたらと思います
ソース
オレオレ用語なんですね
ソースは一般社会だ
意味がはっきりわかったときに意味明瞭！と言ってみろ
それで相手に伝わらなかった経験があるわけ？
ないだろうが、意味明瞭というのは完全に一般的な言葉なわけ
オレオレ用語ってなんすか？
国語辞典10冊見ても載ってないんすけど、なんすかそれ？
完全に一般的な言葉の使用例をいまだに出せないのはなぜ？
どの十冊？
いやマジ、そういうの見たことないんでー、この人日本語苦手なのかなってマジそう思うっすー
春の休日にふさわしいバトルやなww
バトルになってなくね？
明鏡、明解、日本、現国、基準、共明、共立、新日国、現銘、金田一
の10冊
すごーい君は国語辞典たくさん持ってるフレンズなんだね
IT社会だから、紙の本は殆どないけどね
いつでも検索できるようにしてる
すげえそんなにあるんやな
写真見せて
その十冊に「意味明瞭」は載ってるのかい？
著作権的にアウトだからムリ
漫画村とかも見たらアカンで
5chで無茶言ってもそういうところはきちんとしないと
意味明瞭の四字熟語は載ってないけど
意味、明瞭では載ってるよ
なぜ無理？
漢字は表意文字だからそういうことが可能なんだよ
オレオレ用語も、オレオレ、用語という単語が合わさってできてるんだ
オレオレの意味と用語の意味がわかれば、オレオレ用語は辞書に載ってなくても
自分で定義した用語のことなんだなってわかるっしょ
オレオレ用語だという人間が意味明瞭をわかりませんというのは
完全に道理に反してる卑劣な行為だと知ってほしい
誰もそれは否定してないやろ
だからその使用例を出してみなって
出せないのは普通そんな使い方しないからやろ
そらそうだｗｗｗ
著作権法的に違法行為にあたるからムリなんだ
僕は法律は守りたい、なぜならば法律は社会を成り立たせる
ためにあるものだし、一人ひとりがそれを尊重することによって
法律は成り立つし、それによって社会が成り立つから
法律に違反するというのは社会を否定することであるし
社会を否定して生きていけるほど僕は強くないから
使用例
なぜ？
誰も辞書の中身を写せなんて言ってなくね？持ってる辞書のパッケージ写すだけなら何が問題なの？
使用例は
意味がはっきりわかったときに「意味明瞭だ」と言うんだよ
これが使用例です、普通というのはあなたの日常では使いませんという
意味ですよね、それはあなたの語彙が足りてないから使えてないだけで
このスレであなたは新たな語彙を獲得したんだから、是非使っていって欲しい
と僕は思うわけです
正式名称教えておくれ
ソース
妄想おつ
IT社会だから辞書はコンピュータから検索できるようにしていて
そのUIは独自のもので秘匿が原則であることが記されているから
お示しすることはできないというわけです
典型的な嘘やな
この古臭さはどこから？
IT社会
コンピュータ
うーん
仮にそれが嘘だとしても、意味明瞭が「意味がはっきりわかること」
に変わりはないんだからね!?
仮にそれが古臭いとしても意味明瞭が「意味がはっきりわかること」
を意味することに異論はないでしょ？
ソース
意味明瞭と言って本当にその言葉の意味がわからない人っていますか？
そんな人が本当に居るとしたら、その人はオレオレ用語の意味さえわかりませんよ
言葉は単語のつながりですし、単語の元々の意味が変わることなんてありません
元の単語の意味がつながるだけです
無知な人はわからないわからないと言っていれば良いので
議論において最強と言われることがありますが
そういうことで最強の名を手中に収めて満足できますか？
僕はできませんね、なぜならば無知なだけだからです
ものを知らないだけだからです、知らないことを武器に
偉そうに振る舞って相手を黙らせて何が嬉しいのでしょうか
自分の無知に気づかない本当のバカですよ
ソース
長文はキチガイ
短文は知恵遅れ
みたいな
やめましょうよそういう煽り合いみたいなの
知性ある議論がしたいです
ソースが必要な部分あるか？ｗ
長文はキチガイ
ソース？
大東亜会議の真実: アジアの解放と独立を目指して - Google ブック検索結果
ttps://books.google.co.jp/books?isbn=4569634958 > 東條も土壇場になると、日本の古歌、諺を引用する癖があり、いずれの場合も意味明瞭でない。
上司になってはいけない人たち - Google ブック検索結果
ttps://books.google.co.jp/books?isbn=4569819184 >一塁離明瞭かつ意味明瞭な指示を心がけることによって、
>自分は何を知っていて何を知っていないかが明らかになる。
瀬戸内－道後殺人事件 - Google ブック検索結果
ttps://books.google.co.jp/books?id=K_n6DAAAQBAJ > 塔本によって、広島のどこかで麻薬漬けにされているという意味なんでしょうか」
> 「最初の書き込みは意味明瞭だが、問題はあとのほうだ」
経営理念 - TEC予備校
ttps://tec-yobiko.co.jp ? TECの取り組み > つまり、あくまで言語明瞭・意味明瞭に徹した世界なのです。言うまでもなく、
> その後の人生において生徒達も、“言語明瞭・意味不明”な話術を身につけていく
> 可能性はありますが、私たちの教室ではその技術を教えることも利用を推奨することもありません。
> 「言語明瞭・意味明瞭」一点張りです。
出版物のご案内 - 株式会社ビジネスサポート
www.bizsupport.co.jp/book.html
> シート⑩ 意味明瞭化シート
災害医療センター がん疼痛相談外来 患者情報提供書 - 独立行政法人 ...
www.nho-dmc.jp/treatment/department/pdf/gantoutuujyouhou2017.pdf
> コミュニケーション □ 0 意味明瞭・複雑な表現. □ 1 意味明瞭・単純な表現.
ttps://blog.goo.ne.jp/tenyumineo/e/114c240601bdf83d4bf09e77b5f65356 > 大平正芳：鈍牛、言語不明瞭・意味明瞭
ttps://blog.goo.ne.jp/shima1946/m/201001 > 往年の総理・大平正芳さんは「言語不明瞭 意味明瞭」といわれたものでした。
> コードをいじってばかりのやつは、手段と目的が逆転している。
いや、だからリファクタリングだけやるのは論外って言ってるんだが？
目的は機能追加などの改修で、その手段（の一つ）がリファクタリング
目的を実行する時にこまめにやる手段で、手段そのものが目的になってるような
リファクタリングだけの作業とか大規模リファクタリングはおかしいって
言ってるんだが？
実は自分らが普段やっている、いろんな問題が発生している
信頼性の低い行き当たりばったりの改修方法に
文句言ってるだけだろ？
リファクタリングをただの改修と勘違いして、
いつもの自分らを批判してるだけ
リファクタリングは、利用者から見て全く振る舞い=挙動が変わらんやつのことだ。シンプルな定義じゃないか。
その性質上、リファクタリングのみで直接利益の上がる作業なんて(ほぼ)ないし、他の修正とセットになることが多い。が、ちゃんとリファクタリングとそれ以外は明確に別れる必要もある。
何も難しくない
どういう意味で言ってるのか知らんが、これを読めばわかると思う
Martin Fowler氏によるリファクタリングのワークフロー
ttps://www.infoq.com/jp/news/2014/03/fowler-workflows-refactoring > 機能を追加するとき
> バグを修正するとき
> コードレビューと共に
> Fowler氏は「二つの帽子」の比喩を引きあわせて、プログラミングのタスクをこなす際の、
> 新しい機能の追加（ファンクションの帽子をかぶること）と、
> コードの品質向上（リファクタリングの帽子をかぶること）について説明している。
> そして、「プログラミング中は、頻繁に、ことによると数分毎に2つの帽子を
> 取り替えることになるだろう。しかし、一度にかぶれる帽子はどちらか1つだけだ。」と彼は述べている。
一つのタスクの中でこれらは混ざるが、同時に二つを行うことはない。
その意味で明確に分かれるといってるのならそれはそのとおり
もう少し具体的に言えば、ある機能実装のブランチがあって
そのブランチの中でこれらは混ざることはあるが、コミットは別れている
それはコードのメンテナンス性や可読性を上げても
直接利益に上がらないと言ってるのと同じことで
他の業界で言えば、作業を効率化しても客の数が変わらければ
利益は上がらないと言ってるのと同じことだろう
たしかにそのとおりだが作業を効率化させないと
客の数を増やしたら忙しすぎて破綻するし、
余裕がなければ疲れるだろう。利益ではなく
作業効率に直接影響するのがリファクタリングなんだよ。
あってるあってる。俺もそんなこと言おうとしてた。
もっと言うと、リファクタリングコミットでテスト回してないなら、ただのedit and prayやろって奴やな
効率化云々を否定するつもりはない。効率化するならいいじゃないか。
ただ俺はの通りの主張。
コストの前借りは基本通らねえよ、とだけ。
コードを改修する時の作業に含まれてるんだから
現在のコードの品質（理解しやすさ）によって
改修にどれくらい時間がかかるかは変わるのだから
見積もりには現在のコードの品質を反映させる必要がある。
これは改修でやらなければいけないことで、前借りではない
他の作業と置き換えて効率化できるならOK
リファクタリングコストないじゃんとかわけわからないこと言わなきゃいい
だから、それが間違いだと指摘してるのにまだ気付かないのか？
現状のコードが複雑なら解析に時間がかかるので、
あとはその解析結果をコードに反映して次回はもちろんのこと
今回のレビューやエンバグした時の修正を楽にするか
今のままより複雑にして大変にするかの違いなんだよな
そんなに複雑じゃないならリファクタリングも大したことない
すごく複雑なら、それリファクタリングしないと近い内に苦労するよってこと
こまめなリファクタリングが重要
100%完璧にしろなんて言ってない。修正する前よりも良くなっていればいい
お前のその指摘が間違いなんだよｗ
それが事実なら、指摘内容にちゃんと反論しろよ。。。
つ～か「間違ってる」というだけじゃ
それは指摘じゃない。
地球が太陽の周りを回ってるのは間違いなんだ！
って言っても、それは指摘じゃないのと同じこと
なんかすでにおかしくね？
つまり、リファクタリングっていうのは設計が腐ってるから発生した不具合ってことだよね
最初から最後まで自分の主観から一歩も出ていない
立場をかさにきてるだけ
バットで頭なぐるか車でひき殺すかしたい
客が仕様変更しないとでも思ってるのかな？
状況は刻々変わってるし、やってみなければわからないこともある
20年以上前のアプリがクラウド対応の設計していたらびっくりだわ
ソフトウェアは同じものを作ることはなく、はじめての道ばかりなんだから
軌道修正しながら進むしかないんだよ。
その軌道修正っていうのがリファクタリングでもある。
はあ、都合の悪いものは見えない人か。
なら、お前の主観ではさぞかしリファクタリングは効率的なんだろうな。
いわないな。言葉の使い方が変だ
リファクタリングは効果的ならわかるが
それは設計ミスの言い訳になるの？
テストコードのテスト？
じゃあリファクタリングなんてやる必要ないじゃん
ふくらんだクラスを分割して平行作業したり
後から出てきた概念と名前を調整したり
既存コードに手を入れなくても機能拡張できるようにしたり
全部金になんないね
お前、仕事やって金稼いだことあんの？
お前さんが「リファクタリングを理解していない」のは既に指摘したが、
まさかそこまで酷いとは驚きだよ。
もう一度リファクタリングとは何か調べてから出直してこい。
よっぽど信頼されていないんだなｗ
基本的にYAGNIでKISSだから。
機能追加する時初めてインターフェースを切り出したり、関数の所在を変えたりする場合も少なくない。
少なくとも20年前云々は、例として適切でない。
リファクタリング文化がある98年制のソースを触ったことなどない。
言葉そのものでなく、、の流れを受けての文脈。つまり(トータルコストを見て)効率的かどうか。という事。
外国人は新しいバグを埋め込んだり、仕様が変わってしまっても気にしない文化だから、日本人の感覚とは合わない。
テスト工数の削減が見込める場合はやるだろ
やらない
お前のやり方だとデグレが怖いから
それは仕様がすべて文章化されていればな
実際はそんなこと不可能だし
変更した以上デグレは覚悟しなければならない
> 日本の場合はリファクタリングではなく、システムを作り替えるタイミングがリファクタリングにあたる。
それは仕様がすべて文章化されていればな
実際はそんなこと不可能だし
変更した以上デグレは覚悟しなければならない
仕様なんてソースコード読んで、
その動きが仕様なのでは？
一瞬システムリプレースの事だと勘違いするから、改修とか修正って単語使って欲しい
んで、何度も言うように、少なくともリファクタリングの時点でテストはされるし、バグがリファクタリング起因でない事は(メモリ起因やテスト自体の不備を除けば)確実だ、としておく。
なんで、外国人、日本人の下りは何かがおかしい
外部的振る舞いが変わってないことを確認して満足してた奴がリファクタリング起因の障害を発生させてたわw
ただそれに関しちゃ、手動テストでも同じことが言えるからどっちもどっち。
手動でもテストコードはあるんだが？
オワットルなジャップ
それがどれほど技術的に見えようとも
結局は人間の問題である
と偉い人が言ってた
気が滅入る
> 外部的振る舞いが変わってないことを確認して満足してた奴がリファクタリング起因の障害を発生させてたわw
それ普通に修正してもバグ入れ込むよね？
> 手動でもテストコードはあるんだが？
なら手動でバグを見つけられなかったことでは？
まあ手動によるテストは信頼性が低いからね
触らないならバグらないよ
客を丸め込んでデグレのリスクを飲ませられるかにかかってる気がしてきた
バージョンアップとかスピードアップとかなんかこじつけて
リファクタでデグレたら原因も無理やりそこに倒す
リファクタリングは効果的、これを開発社側が
正しく理解してないと、現状のコードの問題を
リファクタリングのせいにしてしまう。
仕様もテストコードもないんだが？とかそういうのなｗ
正しい知識があったらリファクタがプログラマーが楽するためのものだってばれるじゃないか！
開発側が楽になれば、それは顧客にとってメリットしかないよね？
お前のその「開発中」は何ヶ月あるんだ？
お前の所は各モジュールごとに計画を立てて開発するんじゃなくて
全部いっぺんに作業してしまってるのか？
ユニットテストが壊れない程度のリファクタリング、つまり関数レベルのリファクタリングしかしない人にはわからないかも
なんでユニットテストを修正してはいけないと思ってるんだ？
リファクタリングでユニットテスト修正するだろ。
というだけじゃ意味が分からんのだろうな
テストは修正しないって言ったじゃないですか！って言いそうｗ
リファクタリングはテストに通るように修正するのであって、
それさえ守れば、テスト自体の修正もする。
テストのリファクタリングなんて言葉もある。
説明がほしいか？
勘違いしているリファクタリングだ
新装版 リファクタリング 既存のコードを安全に改善する
ttp://shop.ohmsha.co.jp/shopdetail/000000003881/ 第6章 メソッドの構成
メソッドの抽出
メソッドのインライン化
一時変数のインライン化
問い合せによる一時変数の置き換え
説明用変数の導入
一時変数の分離
パラメータへの代入の除去
メソッドオブジェクトによるメソッドの置き換え
アルゴリズムの取り替え
第7章 オブジェクト間での特性の移動
メソッドの移動
フィールドの移動
クラスの抽出
クラスのインライン化
委譲の隠蔽
仲介人の除去
外部メソッドの導入
局所的拡張の導入
「実装クラス」があって
↑
「テストコード」がこの実装クラスを見ている時の
クラスを大きく書き換えるリファクタリングはな
「新しいクラス」を作って、
↑
「実装クラス」の処理を新しいクラスに移譲することで、
↑
「テストコード」から見るインターフェースを
まったく変えること無く、新しいクラスに移行するんだよ
そして「新しいクラス」のテストも書いて（もちろん一部は現在のテストコードを流用していい）
「実装クラス」を参照しているものを、新しいクラスを参照するように書き換え
どこからも使われなくなったら「実装クラス」をそのテストコードもろとも削除
というやり方が、のリファクタリング本に書いている
だから「ユニットテストが壊れない程度のリファクタリング」と言われても
あー、分かってない人ねとしか思わないよ。
仕事中に遊んでんじゃねえ
遊んでるとか思うおっさんがいるらしいなw
バーンと書き換えて、やっちゃって
ミスったらリファクタリングのせいにすればいいだろ
↑こういうやつがリファクタリングのせいにするわけかｗ
リファクタリングは変更しても問題ない手順で変更することで、
たんなる変更、いつもお前らがやってるような手抜きの
無計画な変更を言い換えた言葉ではありません
やってる本人はよくても
他人はリファクタ前と後で変わってないことをどうやって確かめるんだ
ちゃんとよめや。
移行して使われなくなってから削除するんだよ
お前みたいに、なにも考えずに削除してるんじゃねーよｗ
> 他人はリファクタ前と後で変わってないことをどうやって確かめるんだ
なんのためにコミットログがあると思ってんの？
あ、もしかしてそこから？
レベルの差が2段階、3段階ありそう・・・
勿体ぶらずにちょっと具体的な確認手続き言ってみなさい
1. リファクタリングする前にはテストがある。
2. 足りなければ追加する
3. テストが通る
4. リファクタリングする（コードを書き換える）
5. リファクタリングしてもテストが通る
それだけじゃん。
まだ補足が必要？
1. さらにコードを書き換える
2. コードを書き換えるうちに（テスト以外で）使われないモジュールが登場する
3. テストは通るがプロダクションコードでは使われてない
4. 使われてないコードは安全に削除できる
いわれないとわからないかなあ？ｗ
他人が一連のリファクタリングの途中を
見るために決まってるじゃん？
なにかわからないところがあったの？
だからさ、「ガチガチに硬直化」って丁寧に言ってやってんじゃん
そりゃリファクタリングの過程でテストも書き換えるよ
ていうか書き換えるに決まってんじゃんアホか
開発中の日々形を変えるコードに対してガチガチのテストを書くなって言ってんだけど、
わかんない？アホだからわかんないの？もうちょっと精進しろよアホ
レベルの差が4段階、5段階あるからか・・・
> だからさ、「ガチガチに硬直化」って丁寧に言ってやってんじゃん
ガチガチに硬直化ってなに？
ファイルをリードオンリーにでもすんのか？
変更できないコードなんてないはずだけど？
どうやるのかはしらないが、
お前がガチガチに硬直化させたのなら、
それはお前の責任だよね？
リリース済みのコードとそれに対する改修の文脈でばかり語ってるところを見ると、そうなんだろうな
> 開発中の日々形を変えるコードに対してガチガチのテストを書くなって言ってんだけど、
テスト＝仕様を元に決まるものなはずだけど、
仕様が日々変わりまくるのか？
ならそっちが問題だなｗ
経験が浅い人にはわかんないかも
リファクタ本に書かれてる話じゃなくてごめんね
> リファクタの途中よりリファクタの前と後で結果が変わらないことを保証してほしいんだけど
だからリファクタの前＝コミットログの修正前
リファクタの後＝コミットログの修正後だろ？
リファクタの前のテストコードを変更せずに
リファクタの後でもそのまま通れば
変わってないことが証明できる。
あー、これ↓を言っておかないとダメなんだろうなｗ
結果が変わってないと証明された後、
使われてないと判明したコードは削除できる
テストはクラスやメソッドの仕様であってシステムの仕様ではありませんが
そのうえで全体的な仕様が変わってないことを保証しないといけないわけだが
> リファクタ本に書かれてる話じゃなくてごめんね
じゃあどこに書かれてる話なの？
お前の想像の世界の話はいらないからｗ
どうも「自分がくそったれなやり方してます。
くそったれなやり方には使えないんですけど？」
って言ってるようにしか見えない。
お前のくそったれなやり方の問題だろとしか
> テストはクラスやメソッドの仕様であってシステムの仕様ではありませんが
だから？
システムの仕様じゃなくても、クラスやメソッドの仕様でしょう？
> おまいがリファクタして部分的な仕様を変えまくってんじゃん
変えてないよ？
日々テスト変えなきゃならないどこかの誰かさんと違って、
テストは基本安定している。
テストコードを変えない状態でコードを書き換えてるので
リファクタしても仕様はまったく変わらない
それユニットテストじゃない
ユニットテストはモジュールのインターフェースのテストだから
変わりまくることはあり得ない。
もしモジュールのインターフェースという概念がなくて、
単に長いから関数にまとめましたみたいな、
なんでかしらないけど、この関数テストしづらいです。
なんてことをしてるのならそいつの問題
でも今まさにそれを変えるときの話してたよな？
ガチガチに固まって、メンテナンスが大変です。
なんて状態になってるのか書いてみたら良いよ。
想像の世界の話じゃないなら書けるはず
外から見た時の動きが変わってなければ良い。
そして外から見た時の動きが変わってないが、
（テストコード以外で）使われていないメソッドを作ることは可能
そしたら使われてないコードは安全に消せる。
こういう話をしてます。
つまり今までの話は
低い階層の処理クラスの単体テストの話で
さらにそれを包含するクラスの単体テストは別途あって
そっちは変更ないと
【現在のクラス】をリファクタリングするとき
「新しいクラス」
↑
【現在のクラス】←「その他のクラス」←「その他のクラスのテストコード」
↑
「現在のクラスのテストコード」
こういう階層の時、「現在のクラスのテストコード」はそのままに、
「新しいクラス」に処理を移動していくことはできるだろ？
（移動だけじゃなくて新しく作ってもいいけど）
リファクタリングするのは【現在のクラス】だけ
「現在のクラスのテストコード」は書き換えない
【現在のクラス】を利用している「その他のクラス」も書き換えない
（当然「その他のクラスのテストコード」も）
コードの修正をすすめると【現在のクラス】は「新しいクラス」への移譲コードだけになる。
また「その他のクラス」は「新しいクラス」を参照するようにする。
「その他のクラスのテストコード」の修正はしないから、変わってないことは保証できる。
最終的に【現在のクラス】を「その他のクラス」は参照することはなくなる。
そして【現在のクラス】は「現在のクラスのテストコード」以外からは
どこからも使われてないクラスになるので安全に削除できる
これが関数レベルではない、クラスレベルのリファクタリングのやり方
それはとかの本に書いてある基本だから、ほんと勉強してくれとしか
変えてしまうほどのリファクタリングの手順
メソッド一個だけとかならここまでやる必要はない。
その場合は、メソッド単体で、他のメソッドの委譲したりして
該当のメソッドを使われてない状態にしてから削除する
ユニットテストするときなんて下位クラスはモックになってること多い
その場合参照するクラス変わったらモック設定書き換えにゃならん
あほ
テストにもいろんなレベルがあることに考えが至らない奴隷コーダー
リファクタリングなんぞ不要
数年後には業務変化の見直しと現在業務の確認のために、システムをまるごと作り直すから
ダメ管理者はよくそういう妄想に浸りたがるよなあ。
こまめにリファクタリングしたら大損だよ
こまめにリファクタリングってことは、リファクタリング後の修正がこまめに発生してるんだから、そこでリファクタリングコストの半分以上は回収できてると思うの
一度作ったらあまり改修しないようなソフトウェアであればリファクタリングのデメリットが目立つ
つまり、アマゾンドットコムみたいに常に機能追加や改修が行われる投資対象であればリファクタリングで機動力を確保するのは理にかなってる
逆に家電に代表されるような組み込み系、もしくは制御系のような、機能追加や改修の頻度が低いものであればリファクタリングする意味は相対的に小さい
お金をつぎ込めばつぎ込むほどリターンがあるのであれば、CIの中にリファクタリングを入れてしまえばいいだろう
リファクタリングの結果がすぐに出やすく、デメリットであるリファクタリング起因の不具合についても
改修が多ければ多いほど、リファクタリング起因の不具合減産と相殺されるからだ
リファクタリングの問題でやはり難しいのは改修頻度が低く失敗が許されない分野だ
これらの分野は製造工数とテスト工数の比でいうとテスト工数の割合が大きい
つまり、リファクタリングによって過大なテスト工数が必要となってしまい、リファクタリングのメリットが吹き飛んでしまう
しかしながら動いている箇所はいじらない方針もいつまでも続くわけじゃない
いつかのタイミングで全面リプレースするか、リファクタリング（もはや資料もなく知っている人もいない）を行うことになる
うちもそうだよ？
課レベルのシステム、部レベルのシステム、社レベルのシステム
があって、それぞれの長が変わったらシステムの仕様変更が最初の長の仕事になってる。
システムの見直しと再設計って、その部署の現在運用を把握するのに最適という理由で。
もはやマニュアルってレベルだろそれ
エンジニアしか理解できない仕事のマニュアル。
システムのあわせて業務を再構築するべきか ※欧米風
どっちがいいんだろうね
欧米は、システムに最初から経営方針や業務設計を盛り込んでるだけだよ？
日本と欧米に差はない。
あるのは、システム開発を速攻で内製で仕上げているか否か。
国内で内製やった7&iホールディングスが大コケしたけど
セブンミール時代からたまに使ってるけど、たしかに使いづらくなった。
けど、冷静に考えると。今のレベルのシステムを一応作れたなら。元々のシステムも実装できる。
運用方針を新システム化した際に「顧客のニーズ」を取り入れるために店長に聞いたら。
「店長のニーズ」を取り入れちゃったんだろうｗｗｗ
ただ、「店長のニーズ」も旧システムで現実に起こってる問題の結果で、
さらに、現在、店舗自体が人手不足に陥ってるから配達要員、商品供給ライン等で
旧システムであっても実際には様々な遅延等々があったんだろう。
おそらく、システムの使いづらさの原因は、まさかのアナログな「現場の配達に要する人手不足」だと思うわｗ
本来なら日本風がいいんだけど、
パッケージ売りの欧米風の方が格段に安いから。
ガチガチに変更管理してる
現場ってあんの？
は？折角テスト終わったのに変更すんな
殺すぞ
は？
ボタン押すだけだろ
リリース前も後も管理するのは当たり前
お前さんが試験したこと無いのはよく分かった
今はもうpushするだけの時代だぞ爺さん
変更中で清書する前のコードならpushしねえよ
> 常に機能追加や改修しているようなソフトウェアであればリファクタリングは有効
> 一度作ったらあまり改修しないようなソフトウェアであればリファクタリングのデメリットが目立つ
やっぱりまだ勘違いしてる。
リファクタリングが、一度作った後に行うものだと、まだ勘違いしている。
一度目であっても、作ってる最中に、こまめにリファクタリングしていくもの
という考えがどうしても理解できないらしい
それとも詳細設計というものがあって、そこに最初から
すべてのクラス、関数、引数がプライベートのものまで
全部網羅されてるとでもいうのか？
> 変更中で清書する前のコードならpushしねえよ
書きかけではなく本当に清書？
清書前でも理解しにくいだけで動くが、
理解しやすくために清書するってこと？
ならそれはリファクタリングに相当するね
もちろんちゃんとした手順でやらないといけないが
> は？折角テスト終わったのに変更すんな
それなら、テストする前にリファクタリングすればいいんだよ
> リファクタリングによって設計が改善されたと思ってるのはやった本人だけとかありがち
そういうレベルの人たちしかいないなら、
コードメトリクスを測定するツールで客観的に
判断したほうがよいだろう。
ちゃんとした手順がなにを指してるか知らんが、ファウラーのリファクタ本だとしたら
リリース前のコードに対してあんなまどろっこしいことせんよ
ツールで測定できるレベル（抽象度的な意味で）じゃ設計の善し悪しは測れないんで
> リファクタリングの問題でやはり難しいのは改修頻度が低く失敗が許されない分野だ
そういう分野で、循環的複雑度100オーバーの関数1000個のソフトウェアを
修正させたらどんなにテストしていたとしても修正のたびにバグ入れると思うよ。
どうやってこの問題を解決する？
何十回、何百回もテストするかい？それこそ過大なテスト工数だよね。
テストを一回やったらバグが全て見つかり一回の修正で全部直る。
修正後の再テストはバグが見つかった所だけでOK。とか思ってないか？
参考 循環的複雑度は
50以上でテスト不可能 バグ混入確率70%
75以上でいかなる変更も誤修正を生む バグ混入確率98%
と言われている。10以下にするのが普通
とここまで書いて思ったが、どんなコードが良いコードなのかわからない人は
実際にダメなコードの複雑度がどれくらいなのか具体的な数値を示さないと
わからないだろうな。どこかにサンプルないだろうか
> ツールで測定できるレベル（抽象度的な意味で）じゃ設計の善し悪しは測れないんで
だから自分たちで、判断できないレベルの人ばっかりなところだって、
ツールは測定するため物で、ちゃんと測定できますってｗ
完璧なものはわからないかもしれないけど、少なくともツールで
大きくだめだって言われた所は、マジでだめ
> リリース前のコードに対してあんなまどろっこしいことせんよ
しないから、エンバグするんでしょ？
そういうことじゃないです
ツールには文脈がわからないと言っています
コーディングじゃなくて設計の話です
開発中の話だからエンバグしたっていいんだよ、どうせすぐに検知できるし
開発中のテストと品質のためのテストは目的が違うので
そうだよ
トップクラスの企業になると詳細設計で全てが完全に定義されててコーディングは規則に従い変換して写すだけ
なのでリファクタリングの出る幕はない
証拠見せて
転職
今より落ちるのはちょっとｗ
（奴隷度）トップクラス
GoogleやAmazonを表現するのにトップクラスの企業って言葉じゃ足りない
リリース前のアルファ版未満モック以上版なら、デグレ上等でノリと勢いでガンガン変わってくだろ。
わざわざリファクタリング手順など踏まんで、テスターとペアになって開発した方が良い
手取り35
日本のリファクタリングあるある
全文は以下
ttps://www3.nhk.or.jp/news/html/20180425/k10011417181000.html 分けるメリットがなんかあるの？
メリットなんてないよ
PUSHに上司の承認が要る部署とか以外は
レビューができるコードっていうのは1関数あたりだいたい10～20行程度までです。
50行なんて超えたらぜったいにレビューできません。
人の能力の問題じゃなくて、レビューできないコードです。
解析が必要になったら、それはレビューとは言えません。
だから1関数当たり10～20行になっていなければいけません。
これを超えるものがざらにあるようなプロジェクトは失格です
俺は200行程度まで許容範囲
レビューできない根拠が
理由にすらなってない訳だが…
コードなんて誰も見てない
見てるのは担当者の活舌
帳票とかＤＢとかでっかい構造体にいっこずつ値入れてるだけだから
長くても込み入ってないことおおい
組み込みとかどうだろう
許容とかそういうレベルじゃない。
どんだけヘボならそんな長いコードができるんだ？レベルだよ。
これは本当の話
マジレビューできないってｗ
> コードなんて誰も見てない
だろ？
長いコードは読まない。
レビューできないから
ウェブ系でもありえないな。
ほんとね、一人前のプログラマか、ゴミかどうかは
1関数10～20が普通って聞いて信じられるかどうかでわかるよ
比較的大規模なウェブアプリの例。みてみろ。コレがレビュー可能なコードってもんだ
ttps://github.com/gitlabhq/gitlabhq/tree/master/app 50行とか超えてるコードばかり見てる人、↑これみれば、
50行なんて長いコードはレビューできないのが当たり前ってわかるよ。
英語が苦手な奴はデタラメな名前をつけるから余計わかりづらくなる
形だけ小さくして満足してるバカが多い
それは当然だけど、50行とか平気で超えてるようなコードを書く人たちに
現実ってものを突きつけたいと思ってね。
おそらく50行とか平気で超えてるような所だろう
レベルに大きな差があるから話が通じない。
1関数たったのこれだけしかないから、
この関数が動くかどうかテストするのは簡単なんだ
ttps://github.com/gitlabhq/gitlabhq/blob/master/app/helpers/submodule_helper.rb それを見つけるまで、何ファイル探したかな？
ものすごくレアだってのがわかるだろう。
長いそれであっても50行は超えていない
ただ綺麗なコードより汚くても利益を生むコードの方が価値がある
大して価値のないコードを一生懸命リファクタリングしてる奴には、そんなゴミ捨てて意味のあるコードを書けと言いたいね
本当にこれぐらいのレベルなんだよ、
ありえない話はしていない。その証拠
そんなに探してない
ＤＢとかＨＴＭＬに値入れてるとことか長くなりがちなとこ探したけどなかったんで
helperっていう割とやばめの文字列が目に入ったんで開いたらあった
やっぱり扱うものによる
一番下のやつ５０行超えてるぞアウトだアウトだ
ttps://github.com/gitlabhq/gitlabhq/blob/master/app/helpers/application_settings_helper.rb 他人のふんどし
そもそもrubyがカス
今までに何ファイル探した？
少ないのがわかるだろう？
よくそんなの見つけてくるねｗ
ただの配列定義だった
でもよ
それって設計書書くの大変じゃない？
200行のメソッドって10個～20個になんだろ？
クラス図だって10倍か20倍にデカくなんだぞ
トレードオフの問題ちゃうんか？
たくさん仕事してるようで大半がメソッド名決めてるだけみたいな
いや、自分も同じレベルだけど、自分のコードは出せないだろう？
オープンソースで参考にできるもの。
あの関数の短さで大規模なエンタープライズ向けの開発ツールが作れる。
そういう事実がそこにある。
コードが設計書
> それって設計書書くの大変じゃない？
設計書書くの大変なんだよ？
ようするに設計書はこのぐらいのものを作って
一人前ってことなんだよ。
普段どれだけ適当な仕事しているかってのを
わかってほしい。それだけのレベルの差がある
1関数100行でも作れるよ
事実としてあのコードは存在する。
あのコードを作るにはどうすればいいかを考えたほうが良い
そうだな
リファクタする時間をプログラマにくれればいいんじゃないかな？
作れるかどうかという理論上の話ではなく
実際に作られたシステムが、あれだけ関数の長さが短いという事実
その分、設計してる人の時間をとるんだろ？
役に立たない設計書を書いてるような
やつに時間はいらない
コードの奇麗さが価値なら
客からリファクタ用の時間をたっぷりふんだくれるはず
別にいらんよ。コードが綺麗なら
同じ時間でより多くのものが作れる。
言い換えると技術力が高ければ、
同じ時間でより多くのものが作れる
という当たり前の話だ
客から作業代をどうやってむしり取ろうかって発想になってる。
Jenkinsは至るところで使われてるけど50行以上のメソッドなんていくらでもある事実
これ？ なかなか見つからなくて苦労している
ttps://github.com/jenkinsci/jenkins/tree/master/core/src/main/java/jenkins/model 原点回帰が必要だよお前
人間が見てわかりやすい範囲を明らかに逸脱してるだろ
概算で役に立たない
2000行規模のコードでメソッド200個近く作るんだろ
どうやって表現すんの？お前
なんもドキュメント作らない前提じゃないと成り立たない
つっかえねーｗ
自分はわかるがテスターが
どうしよ
当たり前とはつまり自分の思い込みで根拠がないことを指す
このコードだって最初からきれいに書いてちゃっちゃと作ったのか
時間をかけてレビューして整頓したのかどうかなんてわかんないじゃん
> 2000行規模のコードでメソッド200個近く作るんだろ
> どうやって表現すんの？お前
でもさ、コードでは実際にそう表現されてるよ？
そこの矛盾に、君が気づかないといけない
【読者参加型企画】2,000行のJavaソースコードを読むのに何分かかりますか？
ttps://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行にかかるコードレビューの時間です。
ttps://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個もメソッド作るようなカスはどこ行っても
使えねーからオープンソースでも
組んでろよ
> って聞かれても何も答えられないっしょ？
「この機能」って？
この機能だけで見積もりできるの？設計できるの？
で、なにが言いたいの？
スレの流れは関数の長さとそのレビューにかかる時間だったけど、その引用のレビュー時間は
関数の長さとどう関係があんの？
まさか、2000行のコードっていうのを、2000行のひとつの関係って解釈した？
2000行なら100メソッドだろ？
何勝手に水増ししてんだｗ
普通に作れば100個のメソッドなんて普通にできる
1関数10～20行にしないとテスト不可能
テスト可能にするとだいたいコレぐらいになる。
そこから逆算すれば100個のメソッドは
普通に作ればできる
トレードオフの話をするのであれば、
トレードオフした結果が100個だ
って、やっぱりマジ1関数10～20なんてありえない
50行超えるのがザラなの？ レベルに大きな差があるよ。
自覚だけはしておこう
最初から短い関数で書けばいいと思うけど、
関数を長くすることで、何のメリットがあるの？
そもそもテクニカルレビューってなに？
どういう目的でどういうレビューをしてるかによってかかる時間はいくらでも変わると思うけど、
テクニカルレビューがなんなのかわからないから10～20時間が長いのか短いのか評価できないんだけど
だけど素人だと間違えずにキーを打たなければいけないという
条件をつけると途端にタイプするのが遅くなる。
それと一緒でプロだと普通に作っても関数は10～20行にできるが
そうでない素人だと頑張らないと達成できない
そう、素人
リンク先読めば？
わかんないままドヤ顔で引用しちゃったんだな
そういう話題でしか技術っぽい話ができないから、ここぞとばかりに語るよな
それって20行換算じゃん
最大行で見積もるなんて心苦しいから10行にしてやったんじゃん
2000行でメソッドが200個できて
20000行で2000個だ
100000行で10000個じゃん
この間やったプロジェクトのコードがそんなもんだったけど
メソッド10000個とか明らかに
茶碗が小さすぎる
おちょこに飯もってるみたいにアンバランスだろ
> わかんないままドヤ顔で引用しちゃったんだな
いや、普通にリンク貼ってるじゃん？
> この間やったプロジェクトのコードがそんなもんだったけど
お？ ちょうどいいやん。
何ファイルで何クラスで何行ぐらい？
いいや、コードは100000行でメソッド数は2000ってとこだね
10000とかドキュメント工数単純に5倍になんじゃねーか？
設計書に書いた処理とソースの処理を一致させないと説明が面倒だろ
> 100000行で10000個じゃん
数を大きくして、多く見せたいようだけど無駄ｗ
10万行だろ？ 1ファイル（=1クラス相当）が200行ぐらいなので
500個もファイルがある。メソッド1万個は1ファイル（クラス）20個のメソッド
これは普通の規模だ
そもそもお前、ちゃんとモジュール化できてないだろ？
役割ごとにちゃんとファイル（クラス）分けろ
> そもそも設計書からしてそんなに大量のメソッド作成するように書いてるのか？
実際にコードはそれぐらいになるんだから、
それに相当するメソッドは誰が作り出してるかってことだよ。
設計書にこの程度の数のメソッドが書いてないなら、
その設計書通りに作ると破綻するということを意味する
きちんとレビューしてテストするためには、
実際にそれだけの小ささのメソッドでなければいけないのだからね
それにたいして、こんなに大量の関数なんて設計できない。
予め想定することなんてできない
っていうのなら、そういうことだよ。
お前らがやってる設計とやらの仕事は、
現場には通用しない仕事だということ
Sヨとか言われてバカにされてるじゃん。
それが事実だってことだよ。
これが実際の優れた開発の現場だから、最初に全部設計して
最初に考えた関数だけで作るなんて不可能なわけさ
関数の数が多すぎる！って叫んでるアイツ見りゃわかるだろ？
でも実際のコードはそれだけの数の関数がある
この差をどうやって埋めるよ？
最初は設計に書いたとおりの形から始める
実装が進んで次第にコードが膨れ上がっていく
テストできなくなってしまうから、再設計が必要
といっても大きなものじゃない。こまめにやる。
これが開発の中に自然に含まれているリファクタリングだ。
リファクタリングは開発に含まれるもので
別の作業として分離してやるもんじゃない。
そのまま売りまっくて最終的には極悪に肥大したクソコードのリファクタリングしろという
まずその事実を知っていて売り続けた開発部長やら上層の誰かに責任取らせろやハゲが
リファクタリングは「改修」に含まれるものっていう主張はやめたんだねw
視野が狭かったことに気づいてくれて嬉しいよ
改修をしない開発会社なんてないんだから
ソースレベルの設計書なんて書くわけないやろ
1. テスト可能なメソッドは十分短いものである
2. 設計でそれらを全て洗い出すのは無理
ってことなんだよね
これは重要な大前提では？
世の中には、設計で洗い出した関数しか作らない
作れないプロジェクトがあるらしい
そういうプロジェクトが破綻するのは目に見えてる
アセンブラ時代のフローチャートはほぼソースとイコールだったけど
それくらいで破綻しないよ、昔の人の多くはそれでやってたんだから
破綻するなんてのは、誰にでもできるがゆえに参入障壁が低く競争過多な世界で納期に追われてる奴の発想笑
ソースは完全にプログラマに任せるスタイルなのか、ある程度は監視するスタイルなのかの差だと思うよ
個人の技量に任せたら関数の切り出しするやつとしないやつで差がですぎてソースが混乱する
少なくともインターフェースとスタブは書けるだろ
それをやることになんの意味が？
無駄な工数を省いた上に戻りも減らせる
コードを書かなきゃ必要な関数を洗い出すこともできないのは最近の風潮だよな
大規模なチームで設計するときにも、
各自が関数洗い出したのを持ちよって全体最適化とかしてないだろ？
普及している手法にはメリットやデメリットがあるのは当たり前
色々な開発手法知らないと最善策見つけられんだろ
CollectionやらThreadやらStringやら
大体コアになるもんはありものが揃ってるし
そんなものを未だに盲信してるなんて滑稽だ
そうやってすぐコード以外のなにかに逃げようとすんなよSEさんよ
メモリからデータを取り出して画面に表示するだけのアプリばかりでは？
宇宙ロケットのネジだって高卒が締めてるにちがいない
そんな理屈で仕事の難しさがわかるものか
そのコードを最初に、どうやって書く訳？
そんなことも言われなきゃわからん？
お子ちゃま？
それ辿るとBIOSまで行くぞいいのか
この工数がなければ休めたのに
ふつうの開発（改修含む）に含まれているものだ。
と言ってるのに、やっぱり理解できていない
完全に間違いが身にしみてるんだろうな
視野が狭い方には思いもよらないでしょうけど。
howだけじゃなく、why for why考えれるかが分岐点。
お前さん、純粋なリファクタリングやったこと無いのな。
どおりで作業量とかリスクとか全く理解していない訳だ。
どこ出典ですかねそれ
お前の最強の純粋なリファクタリングみしてみろよｗ
お前は「リファクタリングを改修と併せてやる」事しか知らないんだろ？
「リファクタリングのみ」の評価知らないのに正しく評価できないだろ。
宇宙誕生まで調べるだろフツー
調査分析
自動テスト作成
負債返済
利便性向上
少なくともこの5種のリファクタリングを日常的に行う
改修前のリファクタリングしか知らないならまだまだだね
リファクタリングしちゃだめよ
たとえばガス室はなかったとか
強制連行でなく移民だとか
そういうことを言うとリファクタだと侮蔑的レッテルを張られ非難された
あんまり面倒なのでえらい人が別の意味で単語を上書きすることにした
そのあおりをくらってＩＴ従事者は楽しいが不毛な作業に邁進している
ト(自動化)って同時に行って、工数も含めるよな？
自動化するのに別途工数くださいって言われるんだが・・・
こっちとしてはバッファ含んでも余裕ある日数でお願いしているのに
工数が無いって言うくせに遅刻は半分くらいするし、たばこプカプカで手を動かさない
首切りたい。
それどうするか決めるのおまえの仕事じゃねーか
そいつは工数が必要だって言ってるんだからいるんだろ
いくらコーディングだけなら余裕のある日数っつったって
最初お前の頭になかったんなら、全体的な工数がどうなるかは見直すしかない
行けるはずだから頑張れっていうかちょっと工数伸ばすか管理見直すか決断しろ
おまえがやるべきことだ
契約ではどうなっているの？
請負の成果物になければんなもんつくんねーよ
単体テスト仕様書はコーディングの１．５倍、
ユニットテストは３倍ぐらい工数かかります
ご愁傷様
せいぜい5割り増し程度
自動テスト書くとエビ撮りはもちろん実験やデバッグが爆速になるから総合するとむしろ工数が減る
その仕様じゃ動かんのよ
まあキチンとやってればそんなもんだね。
ただし、禄に設計されてない（抜け漏れ、重複、矛盾多数）プロジェクトだと、テスト時に発覚ーーー＞設計修正工数認めない！ーーー＞テストケースが歪なのを何とかしようと無駄な作業、で数倍に膨らんだりするが。
それテストじゃなくて別の問題だよね
テストしっかり書いたから抜け漏れに気が付いた
気がついてよかったじゃん
悪いのは静的解析もテストもしないで設計して抜け漏れ発生させた設計チームだろ？
だから設計書は役立たずのゴミなんだよな
この言い草にやばいＳＥのにおいがしてトラウマが刺激された
自分の作業の考慮抜けを無視したり、いらない仕事山ほど詰め込んだ挙句に結果工期伸びてるのに
この認識を修正できずに
「案だけ余裕あったのに何で間に合わないの？」みたいなこと言ってくる奴の多いこと…
スーパープログラマを投入されてたまるか
万倍以上の差が出る
500人月を1人日か
そんな事例知らないくせに、ぼくのかんがえたさいちょうのすーぱーぷろぐらま語ってドヤるとかリアル中学生かよ
プログラム10個で作り上げるのがスーパープログラマ
当然リファクタリングした結果もこうなる
つまりそういうこと
それが重要だ
何万行書こうとも
付加価値ゼロだからね
単価安いのを10人集めれば出来る！
↑ダメ管理者が陥りがちな妄想の典型。
できた場合：こんなバカでもできる仕事に金出さない
奴隷がバカだから金出さないのは大前提
おまえも単価安い十天王の一角やんか
クッキリとバカやでおまえらなんかw
だったら高いほうに合わせて金よこせ
馬鹿に合わせて全員の給料下げようとするんじゃねえ
ふざけんな畜生
プロジェクトが失敗したって高い給与貰ってるPMさんが責任取ってくれる
プログラマみんなでこれを徹底する
これしかないんだよいい加減理解しろよ
すぐ論点ずらしに走るのもダメ管理者の特徴。
まあ本人は上手いこと言ってやっだニダwとか思ってるのが痛いけど。
どまんなかの直球やぞ？マジにずれて見えるんか？
打たれすぎて脳ミソ液状化しとるやんおまえw
成果に見合った代価を得るのもスキルだぞ
プログラミングがろくにできない奴がバカプログラマだとしたら、金の話ができないのはバカリーマンww
適当にやらせていただきます
ただの作業員だわな
適当でいいんだよ
上が全部責任取ってくれる
すぐファビョるのもダメ管理者の特徴だな。
ttps://gigazine.net/news/20150603-how-critical-software-tested/ だってさ
スーパープログラマなんていらなかったんや
l} ､:: ＼ﾍ,___,＿ ＿＿＿＿＿＿/::.＿＿| .|＿＿＿＿＿＿＿＿＿_＿
|l ＼:: | | ｜､:.. |[], _ .|:[ニ]:::::
|l'-,､イ＼: | | ∧,,,∧ . ｜::.. ﾍ￣￣,/:::(_＿)::
|l ´ヽ,ノ: | | （´・ω・｀） ,l､::: ￣￣::::::::::::::::
|l | :| | |,r'",´￣￣￣￣￣｀ヽ､l:::::
|l.,＼＼| :| | ,' :::::... ..::ll:::: そうだ
|l | :| | | :::::::... . .:::|l:::: これは夢なんだ
|l＿＿,,| :| | | ::::.... ..:::|l:::: ぼくは今、夢を見ているんだ
|l￣｀~~| :| | | |l:::: 目が覚めたとき、
|l | :| | | |l:::: ぼくはまだ12歳
|l | :| | | ''"´ |l:::: 起きたらラジオ体操に行って、
|l ＼＼[]:| | | |l:::: 朝ご飯を食べて、涼しい午前中にスイカを食べながら宿題して、
|l ｨ'´~ヽ | | ｀`' |l:::: 午後から友達とプールにいっておもいっきり遊ぶんだ・・・
|l-''´ヽ,／:: | | ''"´ |l::::
|l ／:: | ＼,'´＿___..:::::::::::::::_`l__,ｲ::::
何もかも足りなすぎる
人類滅びねえかな
何故、枯れた分野だと？
不具合はすぐにユーザーが見つけてくれる
新しい価値の想像、そしてスピード感こそすべて
実際拭いてないとかいそうで困る
確かにお前さんのは想像だけみたいだな。
MSさん毎月毎月止めてください
実際にはマイクロソフトが好きなようにいじくりまわす
おじいちゃんこんにちは
基本成功したやつをパクって金と物量でシェアもぎ取る感じやん
お前の言う最前線ってなんだ？
成功したもの＝最前線じゃないんだが？
どうせアップル信者だろうからそれで例えると
MacやiPhoneに最前線のものなど存在しない
どんなものでも成功できなかった最前線が別にある
十分条件であるが
必要条件ではない
相手のコンピューターを実質自分のものにして
個人情報を収集して国家に横流しし
見返りに便宜を図ってもらうことで会社が存続する
先鋭的ビジネスモデルの開発に成功した
サーフェス
アジュール
ウィンドウズモバイル
マウス復刻
Xbox
Windows10
TypeScript
VScode
VSのターゲットOS拡大
オフィス製品の料金体系
オフィスオンライン
SQLServerがいい感じになってきた
ほら、いろいろやってるじゃん
程度問題でもあるけど
アップルやグーグルもほとんどそうだぞ
自動運転だって1970年代には日本は研究はじめてるし
↑
革新的かつ成功
typescript
革新的だが失敗
Surface→肝心のRTは失敗
Windowsモバイル→何故か失敗
成功したが、フォロアーとか競合とか繋いだだけ
Xbox
VSCode
VSターゲットOS(cordova、Xcode連携)
office365
office onlime
革新的でもなく、失敗
VSターゲットOS(xamarin系)
↓
ダサい
SQLserver、officeの料金体系とマウス復刻はわからん。なんの話題だろう
VS2017もUnityをC#でやるなら神
それは否定しようがない
IntelliJは英語わかんないガイジにはきついもんな
Android開発するときは使ってるよ
その上でVisual Studioの方が優れてると思うね
VScodeもVSに比べたらカス
スペック低いだけじゃないの？
OSSのようにマルチプラットフォームで作業したい場合
Web系のように多彩な外部ツールを柔軟に組み合わせたい場合
そういう時には本家VSというかall-in-oneが基本のIDEは不便なんだよね
VSCodeはエディタやろ
IDEと同じ土俵で比べなすなw
class VSCode : ITextEditor
class Git : IVersionControlSystem
class CakeBuild : IBuildSystem
class VisualStudio : IGodDevSystem
だいたいこんなイメージ
使いようによってはIDEみたいなもんだろ
違うよ
好きな奴が多いのもわかるw
確かにVSの代わりとして使おうとするのはバカやな
ttps://blogs.yahoo.co.jp/kamyu_2010/35442561.html そもそも用途が全然違うから比較するのがおかしい
vscodeでビルドやデバッグしたり、SCMと統合したりしてないの？
（VSが例に出てるから）たとえばC#の場合、それはVSCodeじゃなくてOmnisharp
うん、だからそういうのを統合したものが統合開発環境だよね
という定義なら確かにVSCodeも統合開発環境と言える
しかしこれではEmacsやVimあるいはただのターミナルですら統合開発環境と言ってしまえる
じゃあ統合開発環境とその他の明確な境界線ってどこにあるのと聞かれるとそんなものは定義できないというしかないのが実情
なのでベンダが統合開発環境を公称したりユーザーの大部分がこれは統合開発環境だと認識して初めて統合開発環境とする以外に現実的な定義方法は存在しない
EmacsやVimなどの高機能エディタやただのターミナルを統合開発環境と呼ぶ人は滅多に居ないのでテキストエディタだ
同じようにVSCodeを統合開発環境と呼ぶ人は滅多に居ないのでこれもただのテキストエディタだ
記憶が間違ってなければ公式もそう自称してるし
多くのユーザーが統合開発環境だと認識している
違うってば
統合して無い分は外部呼び出しなんてまるっきり同じだろ？
統合環境というのは（開発環境が）統合済みの環境であって
統合可能な環境じゃない
Emacsは統合開発環境って自称してないしみんなテキストエディタと思ってるからテキストエディタだよ
