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

機能追加や変更した時に、全部テストしてるでしょ？
いつもやってることじゃん

それなｗ

あと、リファクタリングするとお前責任取れるのかとか言ってくるが
機能修正でバグった時の責任はリファクタリングじゃないんだから
全部あんたがとれよって言うと顔真っ赤になるｗ

半角カナを使う奴まだいたのか

スレタイ長くて入らないからね

簡潔にまとめられない奴はプログラミング向いてない

そんなことない
なんでもかんでも一緒にするな

>>1
テスト粒度とかリスクとか理解できないの？

リファクタリングはテスト必須で
論理的におかしくならないと判明している
決められたやり方でやるので
リスクは低いしテストは自動化されています。
その前提ぐらい知らないんですか？

>>8
だからテストやらなくていいって？
そもそもクラスまで作り変えてるならテスト免除どころか設計書のレビューからだよね

>>9
リファクタリングは「テストをやってる」ことが
前提なので、
あんたが言ってるのは別のものでは？

> そもそもクラスまで作り変えてるならテスト免除どころか設計書のレビューからだよね

そうですね？　なんでレビューせずに
リファクタリングするなんて思い込んでんの？

> リファクタリングはテスト必須で

って書いてあるのに

↓

9 返信：仕様書無しさん[sage] 投稿日：2018/04/15(日) 14:45:55.12
>>8
だからテストやらなくていいって？


これもう頭が悪いレベルだろｗ

リファクタリングの存在を否定できないと
困る人がいるんですよｗ

設計書から書き直すならただの改修作業なんだよね？

>>14

改修作業の中身の違い

　1. 無計画に適当に修正して手動でテストしてそれでもバグでて苦労するのと
　2. リファクタリングの手法を使ってテストコード書いて低リスクで修正するかの違い

>>15
具体的にどう違うの？

>>15
TDDでリファクタリングした場合、
1、初歩的なミスにすぐ気付ける
2、作業者が精神的に安心できる

なお、開発者目線の開発体制の優先順位は
バージョン管理 > コードレビュー > 自動テスト > リファクタリング
なので、必ずリファクタリングとTDDはセットになる

>>16
リファクタリングの手法では先に自動化されたテストコードを書く
もしくはすでに存在していなければならない
だから、リファクタリングしたらテストしろよっていうのは意味不明。

リファクタリングの中にテストすることが条件として含まれており
修正前と修正後の両方、それどころか修正のたびにテストすると言ってるのに
なんでそんな当たり前ことを、それも最後だけテストするような質問をするんだ？と
疑問になる

おそらく修正とテストが分離した考え方しか持って無くて
修正後に手動でテストを行うというやり方しか知らないのだろう
そんな再現性がなくてテスト回数もすくないんじゃ、
バグがなかなか取れずにデスマになるのは必死だろう

>>17
工数も削減できないし
品質も上がらないんだ？ｗ

なにをゆうちょるんじゃあ主は

リファクタリング厨って受け売りでしか語らないから面白くない

ゴミスレ

オープニングから自演ｗ

>>21
というか、責任あるポジションの経験がないやつが語ってるだけだからな
ちゃんと決定権を持つやつを納得させるだけの説明ができればいいだけだが、
それすらできていないっつーね

>>2
責任とって辞めます。

>>19
そこらへんの話でいうと、
売上や品質が上がった客観的なデータが示せりゃ、どの会社でも自動テストやリファクタリングは採用されるんよ
そこまでしてないなら、その議論は語るに値しない
んで、殆どの会社はそこを検証していない

>>26
そんなもん、やってみりゃ肌で感じ取れること
数値にしなきゃ理解できないよぉとかバカみたいなこと言ってると腕のいい職人にはなれませんよ？？

>>27
数値にできる学がねぇんだろｗ
数値化しろよ

>>27
仕事を規定の時間内に許容できる品質のものを上げるのが実装者に求める要求で、それに付随する手段は手段でしかない。
で、手段は自由にやればいいし、基本介入しないし、結果しか見る気は無い。
だからやりたければやれば？としか自分は言わない
工数増えるのは論外

>>26
> そこまでしてないなら、その議論は語るに値しない
> んで、殆どの会社はそこを検証していない

検証しろっていうのはわかるが、それは世間一般には
すでに検証されていてすでに品質が上がったというデータは出てるんだよな

それも検証するコストも出せないような会社がやるような中途半端な
方法じゃなくて、もっと大規模で信頼できる方法で検証した結果がすでにある。

で、それを参考にすりゃいいのに、参考にしないんだろう。
つまり他人を信用してない。だから他人がなにやってもどんなデータを出しても
そういう会社は信用しないんだろう。

リファクタリングが有効かどうか？
検証してやるよ。コスト？そりゃ当然かかるよ

ここで嫌がる会社が多い

重要なのは、失敗するかもしれないがやってみよう
という考えが通じる会社かどうかなんだろうな

体力がなくて単純工すらできないごみクズがIT技術者(笑)になる日本では
コストメリットどころかリスクしかない。

「リファクタリングしたら工数減ります」
「リファクタリングの為の工数ください」

うん。意味不明だね。

> 「リファクタリングの為の工数ください」

誰もそんなこと言ってないけど？

>>31が言ってること勘違いした？
リファクタリングが有効かどうかの検証の話だよ。
検証するには、同じことをリファクタリグをするのと
しないので2回やらないといけない。
検証にはコストがかかる。

>>28
俺の筋肉量でリファクタリングの効果を説明できる

>>34
いや、リファクタリングで総工数が減るなら勝手にやればいいだけじゃね？
リファクタリングで品質下がるなんて聞いた事無いわけだし。それとも単体テストレベルまでがっちり管理されてんの？

リファクタリングで増減する工数って、内部設計クラスレベル〜クラステストまででしょ
詳細設計省かずやる巨大案件でも無い限り、実装者に委ねられる部分やん。
ともすれば、やりたきゃやれって回答にしかならん。

>>36
> いや、リファクタリングで総工数が減るなら勝手にやればいいだけじゃね？

俺はやってるよ。リファクタリングで工数減るから
そもそも修正作業の中に自動的に組み込まれるものだから
あえて "リファクタリング単体で" 工数を取るなんてことはしない

だからリファクタリングのために工数くださいっていう発想が
そもそも間違ってるわけ。修正に伴う追加作業じゃない。
修正作業そのものなんだから

仕組みが悪いからって正常に動いてる箇所まで手を入れるってねーな

リファクタ自体は否定しないが、>>１は確実に技術に溺れて盲信してるアホだから許可出さない

>>39
正常に動いていると証明するテストをしてないってこと？

正常に動いていることを証明するテストを修正後にもやれば、
正常に動くと証明できるでしょう？

>>40
修正許可与えてるなら、どんな修正をしたとしても
許されるはずだけど？

>>38
修正が発生したときにしかリファクタしないの？

修正ってなんだよ、バグってんのか
機能追加だろうがなんでも修正って言う奴は素人でしょ

ただのレッテル張りじゃねえかｗ

素人というやつは童貞だ
イカ臭いプログラム書いてろ
と言ってるようなもの

>>43
なんどもリファクタリングは修正の一部だって言ってるじゃん
一部ってことはそれ以外も有るってことだよ

複雑なコードを読み解いて、リファクタリングしないで複雑なまま修正するのと
複雑なコードを読み解いて、リファクタリングしてから修正するのと
どっちがリスクが少ないかって話だ

前者だと、複雑なコードを読み解いた人（修正担当者）がいるにもかかわらず
別の人が、また大変な思いをして読み解いてレビューしなければいけない
そして、次同じところを修正する時、また複雑なコード読み解かなければいけない

みんな実装するだけで精一杯なんよ

リファクタリングは神の領域に達するものにのみ許される技。
素人はおとなしくExcel方眼紙でセル結合の練習でもしておけ。

>>47
そんな入門書の1章に書いてあるような話はいいよ、面白くないから

>>50
入門未満の人がいるんでね

入門レベルの奴でも上から目線になれるから張り切ってんのか

だから>>1にはやらせない

>>37
テストの品質が後工程に無関係ならな。
まあそんな現場が多いのは事実だが。

>>51
リファクタリングするときのレビューとかどうしてる？
設計レビューもだし、コードレビューもだけど

リファクタリングしてるのでNG

>>47
お前さん、理想通りに開発が進めば
自動試験だけで完璧なものができるとか信じてる？

テストしづらいとか、クラスが肥大化しすぎて開発に支障があるとかならまだしも
見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか

リファクタリングは超プロの領域
このスレには本当のリファクタリングが出来る奴はいない

elseなしに書き換えるのが精一杯のFラン説教野郎みたいなのがいるだけ

大規模リファクタリングの秘孔をついた
お前のプロジェクトはもう死んでいる

>>55
> リファクタリングするときのレビューとかどうしてる？
リファクタリングではないときはどうしてる？
それと同じなんだが。

まあそういう質問するってことはリファクタリングに限らず
そもそも設計もコードもレビューしてないってことなんだろうけど
まずはそこからやねｗ

>>57
> 自動試験だけで完璧なものができるとか信じてる？

だからレビューするんでしょ？

自動試験はバグがないことを証明する手段
その手段が正しいかどうかはレビューでみる。

人手でレビューして、テストした内容も記録されて
後なにがあれば完璧なものができると思います？

>>58
> テストしづらいとか、クラスが肥大化しすぎて開発に支障があるとかならまだしも
> 見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか

機能追加とか修正するという前提なんだから、どちらにしろ変更するしかないでしょｗ

>>62
自動試験してレビュー通ったらシステムインしてサービス開始すんの？

入門書第1章に書いてあることの受け売りなら長文で語るけど、具体的な話からは煽りで逃げるし、
体験から語ってると思えるような発言もないし、こいつ多分そんなにノウハウないよ

>>64
レビューもするし自動以外のテストもする
そこは普通の機能変更のときとなにも変わらない

ただその時のやり方が、複雑なコードを頑張って解析して
無理やりパッチを当てるような、あとから見た時に
なんでこんな面倒なことしてんの？と思われるような変更をするやり方から、

次回は複雑なコードを読まなくて良いように、複雑なコードを
シンプルに修正しつつ、まるで0からコードを書いた時のように
こういう機能を実現するなら、普通こう書くよねという
当たり前の形にするやり方に変わるだけ

変更するたびに複雑になっていくやり方をやめて
変更しても複雑にならない、むしろシンプルになるような
やり方をしましょうってこと

その後にやるテストうんぬんは、もともと機能変更でやる予定だったんだろ？
なら最初からやるって決まってることじゃないか

>>65
> 具体的な話からは煽りで逃げるし、
ん？ どのレス？

レビューってさ
もう儀式になってない？

TDDってさ
組織的にガチガチにやるもんじゃなくて
設計者の間で守るべき密やかな秘密程度で
やったほうが良い気がすんのね。

>>68
それはどんなコード変更のときでもやるべきことだから
リファクタリングの話とは関係ないという注意だけしておくね

>>69
ようは、リファクタリング前に存在するテストコードが
リファクタリング後でも通ることで動きを変えてないことが
証明できれば良いのでTDDである必要はないよ。

具体的にはgit使えば歴史変えられるんで、
コード変更しつつテストコード書いて、
コード変更とテストコードでコミット分けて
あとでrebaseしてテストコードのコミットをコード変更の
コミットより前に持ってくれば良い

>>71
TDDは保護するためのテストじゃないから

>>68
レビューのつもりで儀式やってるだけのところが多いね。

>>72
> TDDは保護するためのテストじゃないから

TDDはテストではなく開発手法ですよ？

TDDという開発手法ではリファクタリングの前にテストを書き
書いたテストが、その後に行うリファクタリングが問題ないことを証明するんですよ

つまり
× TDD = 保護するためのテスト
○ TDD =「保護するためのテスト」を用いた開発手法

（あんたの言った「保護」がリファクタリングで壊さないように守るという意味である前提）

俺が>>71で言ったことは、TDDでやらなくてもテストで保護できると言ったんです。

https://postd.cc/test-driven-development/

> 簡単に言うと、TDDは機能を記述する前に自動テストを書く行為です。
> 例えば、Bobが素晴らしい新たなソーシャルネットワークのアイデアの
> ために新しい機能を開発する必要があるとしましょう。
>
> Bobは自動テストを書くことから始めますが、機能を正しく実装せずに、
> テストを失敗（赤色表示）させます。次に、Bobはテストを成功（緑色表示）
> させるための最小限のコードを記述します。緑色表示になったら、
> Bobはコードをきれいにし、テストを実行して機能が正しく
> 実装されたままであることを確認します（コードのリファクタリング）。
> 重複することなく、コードと自動テストは他の人も簡単に保守できます。

>>66
えーと、まずはスレタイの
「リファクタリングすると全部テスト」については、
「全部テストするのは当たり前」という理解でOK？

それなら、大筋では意見に違いは無い。

>>75

before（リファクタリングしない場合）
　1. 機能追加やバグ修正などの変更依頼が来る
　2. 変更する
　3. 変更したので全部テストをする

after（リファクタリングする場合）
　1. 機能追加やバグ修正などの変更依頼が来る
　2. 変更する（リファクタリングもする）
　3. 変更したので全部テストをする


afterに対して、余計なことするな！
リファクタリングしたなら全部テストしろ！
と言われましても、beforeでも全部テストしてますよね？という話です。

リファクタリングしたら(その時点で、機能改修する前に)(単体)テストしろって要求なんじゃね？

まあ普通やるけど。

>>77
いやぁ、違うなぁ
リファクタリングさせないための方便として使ってるので
お前がリファクタリングするとテストする人が迷惑するんだぞ
だから余計なことするなという意味だろう。

だがもともとテストするわけで矛盾になるんだよな

>>74
そういうことじゃないんだよなぁ

>>78
違うよ
デグレしたときの徹底的なイジメがヤバイ

>>79
じゃあどういうことか書けよｗ

>>80
でもどっちみちコード変更するんでしょ？
リファクタリングしない方がデグレさせる可能性高いし

リリースしたらあとはそのシステムのことは知らん
だからリファクタリングする気もない

>>81
いやリファクタリングすると触らなくていいとこまで変更するじゃん
既存コードを変更するって時点でまずい

>>83
触らなくていいかどうかが重要なんですか？

重要なのはテストする所かどうかでしょう？
触った所でテストするなら、なにも問題ないはずですが？

>>84
そうはいかねぇだろ
文章化されてないけど
クリアしてるいろんな仕様があんだからよ
長い間運用してるとそういうのあるわけよ

>>84
触らなければテストもしなくていい
プロは余計なコードも書かないし、余計なテストもしない

>>76
イメージはあってそう（スレ建てた奴とは違う意見）に読めたので、
具体的な内容を書いてみる。

大規模で難解なプロジェクトの一部機能で、
一カ所の編集バッファの数が足りず、
長い氏名の編集に失敗する仕様となっていた。
メモリの使用率なども調査済みで、編集文字数を増やすという仕様変更案件の場合。

バッファサイズを増やして関連箇所の試験して完了。

リファクタリングしたら、統べての試験をやり直し。

リファクタリングの有無でどちらが安いのか、
時と場合によるって認識はあってる？

WFとアジャイルとでも違うし
リファクタリングできる設計になってるの？
も大きな要素だが

動いているなら弄るなよは永遠の真理

>>88
そのレベルの現場が多いもんな。

バッファサイズの変更でなにをリファクタするというんだ

文字編集がややこしいから途中量の計算が難しいから処理変更とか？

>>85

リファクタリングの話は一旦おいておきましょう。


> そうはいかねぇだろ
> 文章化されてないけど
> クリアしてるいろんな仕様があんだからよ

それでどうやってコードを正しく変更できるんですか？
コードを変更する時に文書化されてない仕様を
間違って変えてしまうことがありますよね？

文書化されてない仕様をテストでどうやって
見つけるんですか？

>>87

> バッファサイズを増やして関連箇所の試験して完了。
>
> リファクタリングしたら、統べての試験をやり直し。

え？なんで？先に修正して試験するのがいけないんじゃん


1. リファクタリングをする
2. バッファサイズを増やす
3. 関連箇所の試験して完了

基本はこうですよ？
実際にはこんな大雑把作業じゃなくもう少し細かく
（ユニットテストと）リファクタリングと修正を何回か繰り返しますが

コードの変更とリファクタリングは切り離せません

コードの変更とリファクタリングの間に「関連箇所の試験して完了」
なんてものは入らないし入れたらダメです。

ちゃんと設計できてないから改修する度にいちいち事前のリファクタリングが必要になるんだろうな

>>91
まさにそのスレでその話してるんだからおいとくなよ…

現に存在するものに文句言ったってしょうがないだろ
あるんだから
非機能要件のないソフトなんてない

改修部分が少なければ少ないほど踏んじゃうリスクは減るだろう

> ちゃんと設計できてないから改修する度にいちいち事前のリファクタリングが必要になるんだろうな

そりゃリファクタリングの必要がない場合にはリファクタリングしませんよｗ

前提として、リファクタリングの必要があるコードだって
ちゃんと書きましょうか？ そうすればもっとわかりやすくなりますね。

・リファクタリングをしない場合
1. ちゃんとした設計になっていない
2. そのままで無理やりバッファサイズを増やす
3. やってることが意味不明。変更に自信が持てない。コードレビューも大変。
4. 変更で問題が出やすい。そのたびに意味不明なコードと格闘する。
5. 関連箇所の試験して完了。


・リファクタリングをする場合
1. ちゃんとした設計になっていない
2. 設計を修正する（リファクタリング）
3. ちゃんとした設計に自然な形でバッファサイズを増やす
4. やってることが明確。変更に自信が持てる。コードレビューも簡単。
5. 変更に問題が出にくい。仮に出たとしてもちゃんとした設計になってるのですぐに修正できる
6. 関連箇所の試験して完了。

リファクタリングしたことで1工程増えたように見えますが、
ちゃんとした設計になってないものを無理やり修正した複雑なコードは
バグが出やすく、修正も大変になって時間がかかります。
それはわかるでしょう？

>>94
> 改修部分が少なければ少ないほど踏んじゃうリスクは減るだろう

改修部分をリファクタリングするんだから、
改修部分の量は同じですが？

>>96
具体的なイメージがわからない

本当に改修部分だけ改修だったらリファクタ部分消えちゃうじゃない
それってただの改修では

>>97
ちょっとなにかいいサンプルないか探したんだが
見つからなかったので、軽く例を書くわ


ある関数を改修部分することになった。これが100行を超える複雑なコード。
これをリファクタリングすると10行にできるとする
（ライブラリ使用の有無とかで、これぐらいざらにあるからｗ）

リファクタリングしない場合は無駄なコードで処理が入り組んでおり
入り組んだコードを時間をかけて頑張って解析し
そのまま修正するとなると数箇所を変更しなければいけなくなることが判明した
だが本当にその数箇所の変更で問題ないのか？ コードが複雑なのでよくわからない
レビュー依頼した所で時間をかけて解析したものを他の人がすぐに分かるはずもない
多くの時間を費やすることになった。

リファクタリングして10行にまで減らすと、コードはシンプルになりなにやってるのか一目瞭然になった。
テストコードがあるのでリファクタリングの前後でコードが壊れてないことはわかる。
リファクタリングしたため修正箇所もたったの一行になった。
他の人も何の修正をしたのかすぐに分かる

>>98
おまいのレスが長すぎてリファクタリングしないと読めない

>>99
バイバイ

>>95
リファクタリングの必要性をそこまで感じないってことは、俺の設計ってちゃんとしてるんだろうなぁ

>>101
あと仕様変更がないってことだろうね。

仕様変更があれば、少なからず設計を変更することになるから

>>102
OCPができてないから仕様の変更がいろんなところに波及するんだよ
あとから直せばいいやじゃなくて、もう少し基本を身に付けよう

>>103
最初から何でも考慮した過剰な設計は止めましょう
こっちが基本ですよ？ｗ

言語からスクリプト言語が呼べるようにしておけば汎用性は無限
バグも無限

>>98
リファクタの状況的にはありだけど

それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
テストで検出できない非機能要件を踏んじゃうリスクは明らかに増えてるよね？

数年経ってもリファクタバカは相変わらずだなｗ
未だに賛同者が現れないｗｗｗｗ
しかも、リファクタリングそのものではなく、リファクタバカに対する非賛同が増殖ｗ

かたやリファクタすら許してもらえない信用と立場のリファクタバカが相変わらずの状態
かたや５年以上で完全に新規で作り直しの許可を与えられるようになった俺

技術書に溺れなくてよかった・・・。

>>98
あぁ、そういう事か。
「リファクタリング」という範囲のイメージが合ってなかったんだな。

関数単位のリファクタリングならそのイメージでだいたい合ってる。

「外部インタフェース変えずに内部の設計から見直す」事を前提に話してたよ。


それはそうとして、
関数の処理削減などで処理速度が変わったのなら、同期など含めてその観点での試験はちゃんとやれよ？

>>107
意味がわからない
お前、どっち派？

関数レベルのリファクタリングしか語れないレベルだということはお察し

おれは何も察することができんのだが

>>106
> それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
> テストで検出できない非機能要件を踏んじゃうリスクは明らかに増えてるよね？

関数の中の1行を変えたとして、
その1行だけをテストして関数全体OKってできるんですか？

そもそも関数の中の1行だけをテストすることは不可能だと思います。

結局関数全体をテストするわけでしょう？

>>108
> 関数の処理削減などで処理速度が変わったのなら、同期など含めてその観点での試験はちゃんとやれよ？

もともと修正すべき関数なんだから、リファクタリングしなくても
テスト必須でしょう？ なにを言ってるんでしょうか

>>112
でもさ
ソースで見たとき処理の下の方をちょっと修正すればいいところで
上の方の関係なさ気な箇所がバグったら言い訳できねぇよ
差分見て

何でここ弄ったの？今回の修正と関係ないじゃん

って言われたらちょっと嫌な空気流れるよ

>>106
> それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
「可読性」って言葉ご存知ですか？

「可読性」の二番目の文字は「読」です。
「書」ではないのです。

改修は「書く」ことですが、改修前には「読む」こと必須です。
では書く時間と読む時間、どちらが多くかかりますか？

もちろん読む方ですよね？
タイピングなんて1分間に200〜300なんて軽く行く

改修の書く量だけを見ても正解にはたどり着けませんよ。
改修量ではなく作業始めてからの改修時間を見るのが筋じゃないですかね？

リファクタリングは改修時間を短くします。

>>114
関係ない所を修正するのがいけないのでは？ｗ

>>112
具体的なシナリオをいうとだ

日付をこりこり自前でデコードして値つくってる１００行近いまぬけコードを
Ｊａｖａのライブラリつかって数行にしてホルホルしてたら
ついうっかり見たことないようなフォーマットも受け入れちゃうようになってて
そんなん存在もわかんないからテストしてるわけなくて
でもユーザーは何の気なしに入れちゃうと入るからそのまま入れて、想定と異なるへんなデータが蓄積していって
集計バッチの演算とかにちょっとづつ毒虫のように影響を与え続けて
気が付いたらえらいことになってたりとか

>>115
理解できたらもとに戻してもいいのよ？

>>113
修正内容に応じてテスト観点増やさないの？
費用対効果考えながらテスト計画立てないと破綻するぞ？

>>117
それはリファクタリングしなくても起こる話ですね。

何度も言うように、そこが修正箇所です。
リファクタリングしなかったとしても修正する場所です。

修正して、ついうっかり見たことないようなフォーマットも受け入れちゃうようになってて
そんなん存在もわかんないからテストしてるわけなくて
でもユーザーは何の気なしに入れちゃうと入るからそのまま入れて、想定と異なるへんなデータが蓄積していって
リファクタリングと何の関係もない話ですよね

>>118
> 理解できたらもとに戻してもいいのよ？
次修正する時、また改修時間（読む時間）がかかりますよね？

>>118
もとに戻すと改修時間（読む時間）が無駄になるだけですね。
次回修正するときも、また改修時間がかかります。

バグが見つかったら、また改修時間がかかります。

>>119
> 修正内容に応じてテスト観点増やさないの？

少ししか修正してないから、テスト減らしていいとでも？

変更したコードの量は少しでも、その影響範囲は
修正の量とは無関係です。

どれくらい影響があるか、それはコードが複雑であれば
有るほど不明です。

>>122
テスト計画建てたこと無いの？
「全ての条件を網羅したらバグは無くなる」
は真だけど、それができないからみんな工夫してるんだよ。

バグのないものは存在しない

なんてのは、この業界の常識。

>>120
リファクタだけの問題じゃないが、リファクタも修正のうち
修正する以上人間がやらかすリスクはある

だったら修正は極力限定されているほうがいいだろ


>次修正する時、また改修時間（読む時間）がかかりますよね？
そしてリファクタ最大の問題
コードの読みやすさや理解しやすさは人の主観に大きく依存する

else取っ払ってタプル戻り値の関数に変えようとするやつもいるんだぞ

リファクタ後に修正したほうがテスト工数が削減できるとか、規約が新たにできたから合わせるとか
なにかしら明白な理由がないと

あとどうもやっぱりリファクタリングを
単なるコードの修正の意味で使ってるように見えるんだよねｗ

リファクタリングは、コードの修正、コードを綺麗にするを
英語にした言葉じゃないよ？

リファクタリングっていうのはやり方が決まってる。
スタート（修正前）とゴール（修正後）は自分で決めるけど
スタートからゴールへ至る道へは、決まったやり方を使って修正する
その決まったやり方っていうのは、動きを変えないための方法

数学の等式の変形みたいなもんだ
x - 2 = 8 を「移行」して
x = 8 + 2 に変形しても意味は変わらない

こういう「移行」みたいに変形しても意味が変わらないやり方に
ご丁寧に名前までつけてカタログ化されてる。

テスト書いて決められたやり方で式を変形するんだから
無計画なコードの修正なんかよりもずっと安全に変形できる

>>123
いや、だから、一行の変更なら
テスト減らせるってわけじゃないよって言ってるんだが？

>>124
> コードの読みやすさや理解しやすさは人の主観に大きく依存する

じゃあ主観に依存しないものを採用すればいいだけでは？

コードメトリクスを計測せよ

>>125
そうだね
リスクはひくいよ
Eclipseのリファクタ機能使うならなおさらだ

それでもたまにやらかすだろ！

>>127
メトリクスのどれ見んの？

>>128
> それでもたまにやらかすだろ！

複雑なコードをそのまま修正するほうが
やらかします。

その場合、いくら修正してもバグはなおらないし
直したそばから別のバグが発生するし、
時間もかかるしで、良いことはまったくありません。

重要なのは改修量ではなく改修時間な

マーチン本に書いてある手続きいちいち守ってたら日が暮れる
現実的には既存のユニットテストのコードを信用して
手続きを頭に置きつつ直観でつくり変えていくことになる
そんで流して結果変わってなきゃＯＫと

理想が定義されているからといって現実に耐えうるかというと

>>129
基本的にメトリクス測定ツールは、基準値超えたら
アラート出してくれるはずだからそれに従えばいいと思うけど、
俺はCyclomatic複雑度を重視するね。

>>130
改修による単体工数の削減はあるかもしらんが

時間重視ならなおのことリファクタやってるひまなんかないだろ
あれほどの時間泥棒もない

よく考えたら書くほうが早いっつったって
結局その前に理解しないと書き直せないんだから一緒じゃねーか！
だまされるとこだった

> よく考えたら書くほうが早いっつったって
> 結局その前に理解しないと書き直せないんだから一緒じゃねーか！

だから、たった一行の修正とか言っても、
その修正にかかる時間は、理解する時間が大半を占めるんだから
リファクタリングしても大差ないって話だよ。

大差ないどころか、複雑なものを複雑なまま、頭の中で理解するほうが
時間かかると思うがね


そして理解した結果をコードに反映させないで、レビューにかかる時間
次に修正する時間、バグ出た時に読み返す時間を費やするか
コードに反映させて、その後にある時間を減らすかどうか

>>134
で？結局リファクタやると具体的に何がいいんだっけ？
色々話してるとメリットが全く見えなくなっちゃう

>>134
思うのは勝手だが最初にしてた変更リスクの話を忘れてないか

>>135
> で？結局リファクタやると具体的に何がいいんだっけ？

まず改修時間はさほど変わらない。
変更リスクもどちらにしろテストする場所なので変わらないし
行数が少ないほうが影響範囲が小さいってこともない

リファクタリングでバグ入れそうなコードは
リファクタリングしなかったらもっとバグを入れやすい

そして、レビューやバグがあったときの読み返し時間の削減
修正内容に自信が持てる。今後の修正の時の改修時間の減少

>>137
いや全然わからない
普通に改修する場合と比べて何がいいの？

1行の修正でこんなにお金がかかるんですか！
っていう顧客の声がまんまリファクタリングしない場合にあてはまるな

1行の修正だからリスクが少ないとお考えか！？

1行の修正でもお金がかかるってことは、1行だからって
なにかを減らせるわけじゃないんですよ。

>>138
そこで普通に改修っていうのは
リファクタリングをしないってこと

リファクタリングが「理解や修正が簡単になるように、内部構造を改善すること」
なのだからリファクタリングしないってこうのは
理解や修正が簡単になるように改善をしないってこと

元からすでに改善済みのものをリファクタリングしろとは言ってない
理解や修正が難しいコードであることは大前提


で「普通に改修」というのは改善なしに複雑なまま修正ということになるのだから
>>137で言ったようなメリットが有る

複雑なものをそのままにして手を入れたら
もっと複雑になるよ。

複雑なコードは壊すのがこわいからリファクタできない
簡単なコードは意味がないからリファクタできない

>>141
重要なのは手遅れになる前にこまめにやることだよね

大規模リファクタリングなんてのはあってはだめ
リファクタリングだけのための作業なんて持っての他

そうやって手遅れにするから、リファクタリングのための
工数なんて取れるかーみたいな話になる

リファクタリングは、機能追加や変更に伴う作業に
含まれているべきものですよ

>>142
今どきリファクタリングするのは機能追加や変更のタイミングに限らないよ
DDDやってる？機能の変更がなくても、業務にモデルを合わせるために日々リファクタリングするのが常識

こんな事が書いてあるのかｗ

http://hideoku.hatenablog.jp/entry/2013/03/07/223727

変更を完全に正当化できるまで待つのは、待ちすぎというものである。
プロジェクトはすでに重いコストを負っていて、先延ばしにすると変更するのがより
困難になる。対象となるコードには今より手が入り、さらに多くの他のコードに組み込まれることになるからだ。

継続的なリファクタリングは「ベストプラクティス」と考えられるようになってきたが、
ほとんどのプロジェクトチームは依然として慎重すぎる。コードを変更するリスクと、変更にかかる開発者の時間のコストを見込んでいるためだ。

しかし、それほど簡単に見抜けないのが、設計をぎこちないままにしておくリスクと、
その設計を何とかするためのコストである。

リファクタリングを行いたい開発者は、その決定が正統なものであると証明するよう求められることが多い。
こうした要求は理にかなっているように見えるが、もともと難しいものを不可能なほど難しくして、
リファクタリングを抑制する（または見えない所で行わせる）傾向がある。

ソフトウェア開発は、変更することで得られる利益や変更しないことで生じるコストを
正確に割り出せるような、予測可能なプロセスではない。

リファクタリングがだめなのではなく
おまえらがやるからだめなのだ

>>144
駄目コード（ウィルスみたいなもん）をばら撒いてから治療なんて無理だからねえ。

結局は客がデグレを笑って許してくれるかどうかな気がしてきた

でかくてモノリシックなシステムを複数のマイクロサービスにリファクタリングしたけど、
デグレなんて起きなかったな

>>147
だからデグレは複雑なコードのまま変更するほうが
リスク高いんですってばw

>>149
リファクタリングは処理の内容を変えないで
コードをわかりやすく再配置するだけだから
デグレのリクスはすごく低いんだよね

>>145
リファクタリングがだめなのではなく
闇雲に修正するのがだめなのだ

>>150
> リファクタリングは処理の内容を変えないで
> コードをわかりやすく再配置するだけだから

外側は変えないけど内容は変えますよ
なに言ってるんですか

>>149
難解なコードを読み解いて修正前に正しく把握するのは難しいという主張？

リファクタ厨はその時々でリファクタリングの定義を変えるので話にならない
正反対のことを平気でメリットとして主張してくる

>>144
わからないことや見えないことを逆に肯定理由にする
宗教家と同じ手口だな！

ある程度経過したコードは捨てろ。
リファクタなんぞせず。

さらにある程度経過したシステムは捨てろ。
リファクタなんぞせず。

>>151
実装は変えるけど、処理の内容は変えませんよｗ
処理の内容っていうのは、1から1000までの数を足すとかいうことです。

forループを使うとか、計算式を使うっていうのは
実装であって処理の内容じゃありません

>>152
> 難解なコードを読み解いて修正前に正しく把握するのは難しいという主張？

違う。時間がかかるという主張

コーダーの時間が現実のリスクとのトレードオフに値するだろうか？

>>157
解読せずにリファクタリングすると酷いことになるだけだぞ？

>>156
どのように実装するかというのが処理の内容だから
リファクタリングで変更しないのは外部仕様な
内側は変えていいんですよ

改修のためのリファクタリングって15年前ぐらいの考え方
今さら熱く語るようなトピックでもない

>>159
> 解読せずにリファクタリングすると酷いことになるだけだぞ？

リファクタリングする時に解読しないなんて誰が言ったの？

そもそも解読が必要になってるのはリファクタリングしてなかったからなんだが、
まあそんなこと言ってもしょうがない。過去の話だ。

今手元にあるのは解読が必要なほど複雑なコード
リファクタリングをしないということは、複雑なコードをそのままに
さらに複雑にする行為。それをレビューしてもらったって、できるわけがない。
なにせ解読が必要なほど複雑なコードなんだから、

そして、せっかく時間を書けて解読しても、その解読をコードに反映させないなら
次回修正する時にまた時間がかかる。そして次回修正はそんなに先のことじゃないかもしれない
なぜなら複雑なコードをさらに複雑にしたのだから、デグレのリスクも高い


せっかく時間かけて解読したのだから、それをコードに反映（リファクタリング）させましょう。
読むのは時間かかるが、書くのは大して時間はかからない。
そうすれば、リファクタリングしなかった場合の時間がかかるという問題が解決できる。

何回も同じこと言ってるんだけどなｗ

あと解読するときも、最初から最後まで想像して解読するよりも
簡単なところから一歩ずつやったほうがいいよ

>>161
リファクタ病患者の闘病のために必要

>>164
君みたいに突っかかってるやつのためだよｗ

まったり普通にまともなこと言っても誰も相手してくんないし

本質的に複雑なものはどうやったって複雑なので、考えるべきは複雑さをどこに押し込めるかだ
複雑な処理もリファクタリングすればシンプルになると信じてる奴は、まあ本質的には簡単なことしかやってないんだろう
例えば、SQLがわからないユーザーのために、DBにUIを提供するだけのCRUDアプリとか

関数レベルのリファクタリングじゃ抜本的な設計改善にはならないからなぁ
やらないよりはやった方がいいけど、まぁ趣味の話だな

>>167

> 例えば、SQLがわからないユーザーのために、DBにUIを提供するだけのCRUDアプリとか

あんたは複雑なことをしたいのかもしれないけど
仕事なんだから客が求めるものを作るべきでは？

客は本質的に複雑なものばかり、求めてるんですか？
客が求めてるものは簡単なものばかりですよ。

>>168
設計ってどこまで含んでいってる？
クラス設計は？ どういうメソッドが有るとか
どういう階層をしているかとか

データベース設計なら、まんまデータベースリファクタリングって
本があるけどもう売ってないな

>>169
本質的に簡単なことって、頑張れば誰にでもできるじゃん？
実際、キャリアの少ない若手プログラマだって、先輩やらの手助けを受けつつもちゃんと動くコードを書いて納品してるわけで

たかだか数年の経験しかないプログラマにでもやれなくはない程度の仕事を、ああだこうだいって多少整理された状態に
持っていくのがお前の言うリファクタリングでしょ？
まぁ誰かがやらなきゃいけない仕事なんだろうけど、それって汚いコードを書く奴の尻拭い以上のものではないし、
ドヤって語るほどのもんでもないように思うけどなー

改修後に予定されているテストでカバーできる範囲でリファクタするというのは
ひとつの答えのようにおもえる

あとはリファクタしたほうが本当にましになってるのかという問題

>>172
> 本質的に簡単なことって、頑張れば誰にでもできるじゃん？

本質的に簡単なことって、頑張れば（＝コストと時間をかければ）誰にでもできるよ？

でもそれじゃだめだよね
コストと時間がかかってるんだから

リファクタじゃなくてリジェクト

関係ないけど安定した共通化部分から
関数抽出して使いまわしたいんだけど
やっていいもんじゃろか？

>>173
将棋でも自分の指した手がいい手かどうかわからない人いるよね。
初心者？上級者？

マシになってるかどうかわからない？
将棋で言えばどっちかな？


自分の指した手が良いかどうかわからないってことは
恥ずかしいことだと思ったほうが良い。


まあ、初心者なら仕方ないけど、そういう人は
コードメトリクスを計測したら良いよ。
客観的に良いか悪いかを判断してくれる。

>>177
>自分の指した手が良いかどうかわからないってことは
>恥ずかしいことだと思ったほうが良い。

やっぱりやらないに越したことはないな！

>>178
なんで？
そういう人はコード書いたらダメだって言ってるんだけど？

料理が下手な人は料理をしないほうが良い

人の問題なのか、技術の問題なのか
その区別ぐらいはできるだろうけどな

俺が運転すると事故るから
車はだめだみたいな。

>>162
改造するのは解読に時間がかかる
リファクタリングすると解読に時間がかかる

で、何がメリットだって主張？

>>182
二行目が繋がってない、つまらんからやり直して。

>>182
コピペしろって言ってる？

162 自分：仕様書無しさん[sage] 投稿日：2018/04/19(木) 21:57:46.81
>>159
> 解読せずにリファクタリングすると酷いことになるだけだぞ？

リファクタリングする時に解読しないなんて誰が言ったの？

そもそも解読が必要になってるのはリファクタリングしてなかったからなんだが、
まあそんなこと言ってもしょうがない。過去の話だ。

今手元にあるのは解読が必要なほど複雑なコード
リファクタリングをしないということは、複雑なコードをそのままに
さらに複雑にする行為。それをレビューしてもらったって、できるわけがない。
なにせ解読が必要なほど複雑なコードなんだから、

そして、せっかく時間を書けて解読しても、その解読をコードに反映させないなら
次回修正する時にまた時間がかかる。そして次回修正はそんなに先のことじゃないかもしれない
なぜなら複雑なコードをさらに複雑にしたのだから、デグレのリスクも高い


せっかく時間かけて解読したのだから、それをコードに反映（リファクタリング）させましょう。
読むのは時間かかるが、書くのは大して時間はかからない。
そうすれば、リファクタリングしなかった場合の時間がかかるという問題が解決できる。

何回も同じこと言ってるんだけどなｗ

>>184
冗長な文章だな

>>184
リファクタリングに時間がかかるって主張だよな？

数字を入力するのにテンキー使う奴の地雷率は100%

ソフトウエアの問題は
どんなに技術的に見えようとも
人間の問題である

って偉い人が言ってた

>>188
(底辺ではなwww)

が抜けてる

問題というのは人間の主観的認識なのだから
人間の問題でない問題などというものがあろうか？

>>186
> リファクタリングに時間がかかるって主張だよな？

なんでそう何度も曲解するの？
わざとだよね？

時間がかかるのは、コードの修正。
リファクタリングしなくても時間がかかる

正確に言えばコードの修正を始めるまでの
コードを解析している時間だな

たった一行の修正なのにこんなにするんですか！？って
言われるぐらいの費用になるのは、"コードのタイピング"には
含まれない部分がたくさんある

>>192
で、コードを解析する時間は
　リファクタリング　＞　一部修正
だって理解できないの？

「リファクタリング終わったコードを修正する時間は短い」
という主張に誤りは無いが、
リファクタリングする時間を無視してどうする。

>>190
そういうレベルの人はコードメトリクスを計測するツールを使ったほうが良い
ツールで問題が有るとされたコードはほぼ確実に問題が有る

>>193
> で、コードを解析する時間は
解析する時間って言ったのに、お前

↓
>　リファクタリング　＞　一部修正

修正する時間に話がすり替わってるじゃんｗ


解析する時間、すなわち複雑なコードをよんで
それがなにを意味しているか、どう書換えれば
正しく動くかを、考える時間は

リファクタリングしながら解析する時間　＜　一部修正のために解析する時間

こうだからな。

ぐちゃぐちゃに絡み合った紐の束から、少しづつ結び目をときながら、
適切な一本を抜き出すのと、結び目をとかずに適切な一本だけを抜き出すの
どちらが簡単なのかを考えればわかるだろ
スパゲティコードとはよく言ったものだｗ

>>194
それはそれでわかったが

言ったことの返答にもなってない
話のつながりが見えない
レベルが何を指すのかわからない
問題が何を指すのかわからない

リファクタする奴は思考が支離滅裂だな

あぁ、問題は全て、人間の主観的な問題！というのが間違いだよ、
客観的な問題も有るよっていったのが通じてないのか
話が分からんやつは困るな

>>195
お前さん、開発したこと無いの？

一部の修正の為に必要な解析情報量と
リファクタリングに必要な解析情報量の
違いすらわからないなら
解析の仕方がおかしいか、
内容を十分理解せずにリファクタリングしてるって事。

>リファクタリングしながら解析する時間　＜　一部修正のために解析する時間

個人的経験から断固として異議を唱えたい

>>199
もしかしてリファクタリング、溜まってるんですか？

>>196
リファクタ厨は毎回そんなもんだよ

つーかさ、誰も100%納得がいくまで
リファクタリングしろなんていってないんだよ。
修正する所、どちらにしろテストが必要な所
関係がある所を、少しづつやればいい。

時間がかかるっていうのは、それはいつも手遅れの
コードばかりだって自覚有るからじゃねーの？

でもメリットが欠片も見えないな

>>142でも書いたが、
リファクタリング＝大規模なものしかイメージできてないって
状態がそもそもやばいよ

142 自分：仕様書無しさん[sage] 投稿日：2018/04/19(木) 00:37:19.05
>>141
重要なのは手遅れになる前にこまめにやることだよね

大規模リファクタリングなんてのはあってはだめ
リファクタリングだけのための作業なんて持っての他

そうやって手遅れにするから、リファクタリングのための
工数なんて取れるかーみたいな話になる

リファクタリングは、機能追加や変更に伴う作業に
含まれているべきものですよ

>>203
何度も書いた。コピペしかしないよ？

リファクタリングをしたから具体的にどういうコードがどうなってそれでどのくらい得になるのかわからない

>>205
え？説明になってないじゃん

>>206
そういう実例が書いてある本を紹介すればいいの？

>>207
ん？ すでに過去レスで書いたって言ってるんだけど、
お前はどのレスが「説明」だと思ったの？

肝心のマーチン本からして何が得なのかよくわからん有様

本読んでもコードがどうなるかも分からんの？

理解がちょっとづつ歪んでいくな
リファクタでも同じように処理をちょっとずつゆがめて気が付かずにいるにちがいない

>>209
いや、ここまでそんなレス1つも無いから

https://blogs.yahoo.co.jp/mathweather4067/5819997.html

> 指導のポイント
> ここの指導は、難しい。なかなか理解されないのが、現状です。
>
> まずは、「等式の性質」を思い出させることが必要でしょう。
>
> 次に、「１次方程式の解法」も思い出させます。
>
> その後、１次方程式の解法と対比させながら、進めていきます。
>
> 「等式の変形」は、等式をその目的に応じて変形することの良さが理解できていないと、
> 何のためにするのかがわからないまま、機械的に進めてしまいます。
>
> 導入部分を大事にしたいですね。


まさにコレだな

>>213
でも説明なってないと判断したレスがあるわけでしょう？

>>212
自分の都合のいいように捏造と曲解ばっかりしてるよね
一度もまともな実績がないくせに何で役に立つって言うんだろうね
どうせ数字も捏造してんだろう

>>216
曲解って俺が先に指摘したんだけど、
言われて悔しかったからって自分も使おうとしないでよｗ
どれが曲解かを指摘してない以上意味ないよ

いやリファクタ野郎のことね

お前のことだよｗ

>>214
そいつの説明が悪すぎる、良さってなんやねん

理解してもらえないのではない
自分が理解もせずに良いものだと思い込んでいるだけだ

本当に理解してたら必要性や可能になることを明確に説明できるはず

本当に理解している本の作者が
十分以上に説明してるんだけどなぁ

修正ってほんの数行程度なのに対して
リファクタリングってほぼ全域書き換えでしょ？
そりゃ影響範囲が違いすぎるよ

読んだ上でいってんのか？

142 自分：仕様書無しさん[sage] 投稿日：2018/04/19(木) 00:37:19.05
>>141
重要なのは手遅れになる前にこまめにやることだよね

大規模リファクタリングなんてのはあってはだめ
リファクタリングだけのための作業なんて持っての他

大規模リファクタリングもありえるよ
こまめにって言ってるのは、せいぜい関数レベルのリファクタリングの話でしょ
まだそれぐらいしか任せてもらえない立場なのかもしれないが、リファクタリングってそれだけじゃないから

じゃこう考えよう

リファクタリングは
テストコードのデバッグ

もうコーディング=リファクタリングでええやん

>>222
あほすｗｗｗ

なんで、こんな派遣すら首になるようなリファクタバカを相手にしてるの？

基地外に何言っても無駄だよ。
相手の言葉を聞く能力がないからキチガイにして派遣すら首になってんだから。

>>223
214のどこを読めばそのレスとつながるのか
ＩＤ出ない板で自分がわかれば相手もわかるとか思ってるとか

あれ？

>>229
なぜ>>214に対してのレスだと思ったのか？

なぜだろう

>>224
それって
リファクタリングじゃなくて
リプレース

どんなきれいなソースコードでも
プログラムから仕様を起こすのは大変

だから現場が仕様を忘れる前に、再開発をするのが正しい

つまり、リファクタリングなんぞ不要

やっぱ
日本人のソフト開発って
土木工事想定なのな

日本は土建と同じ構造

世界は基本的に内製

CIAすらアマゾンに開発委託したってのに

>>233
リプレースとリファクタリングを混同するな

>>238
区別の仕方は？

リプレースって、普通の文脈だとシステム置き換えじゃねーの？
コード周りの文脈でリプレースなんて表現するのか？

＞大規模リファクタリングもありえるよ

大規模リファクタリングとは
リプレイスの事ではないかと言う主張だよ

どうでもいい

リプレースってハードウェア更新でしょ？
5年ごとにハードウェアを最新にして、ついでにソフトウェアも新ハード新OS向けにテストしますよと
で、ほとんどはリビルドで済む話だけど
どさくさにまぎれてちょっと不具合修正しましょうとか機能追加して欲しいとなる
そこにリファクタリングする余地は確かに出てくる
本来必要ないのに修正するという意味ではいかにもリファクタリングだ

>>243
ずいぶん狭い世界で生きてるんだね

>>244
転職経験2桁だけど何かいいたいことある？

大規模リファクタリングなんてあってはならないと言っちゃった以上、「俺のリファクタリング」より大規模なものは、
リプレースでもなんでもいいけどリファクタリング以外のなにかでないと困るんだもんね

>>245
狭いね

>>245
ただのクズやんｗｗｗ

>>246
リファクタリングの定義は、外部的振る舞いを変えずに
理解や修正が簡単になるように内部構造を改善することなんだが
お前の言うリプレースっていうのは、外部的振る舞いを変えないものってことか？

> リプレースでもなんでもいいけどリファクタリング以外のなにかでないと困るんだもんね
普通にバージョンアップでは？

>>245
ｗｗｗ

>>246
> 大規模リファクタリングなんてあってはならないと言っちゃった以上

お前意味分かってんのか？

大規模リファクタリングなんてあってはいけないっていうのは
許されるのは小規模（せいぜい中規模）リファクタリングまでで
リファクタリングだけを大規模にやってはいけないないってことなんだが？

なんで大規模リファクタリングがあってはならないのかというと
リファクタリングは、機能変更の中に含まれる、
通常のソースコード変更時に、こまめに行うものだから

大規模リファクタリングが必要になるのは、こまめにリファクタリングしてないで
ソースコードをどんどん劣化させ、限界がきたから作り直す
（それもリファクタリングではない手法で）となってる場合が多い。

大規模リファクタリングのほとんどは単なる改修という意味になっていて
リファクタリングとなってない事が多い

>>243
> 本来必要ないのに修正するという意味ではいかにもリファクタリングだ

何だその定義？
外部的振る舞いを変えずに理解や修正が簡単になるように
内部構造を改善することだけが「いかにもリファクタリング」って
言って良いんだよ。

必要ないのに修正するのがリファクタリングなんて定義初めて聞いたわw
どーこーの、定義ですか？ソースくださいｗ

>>243

> で、ほとんどはリビルドで済む話だけど
> どさくさにまぎれてちょっと不具合修正しましょうとか
それは不具合修正であってリファクタリングではない
（外部的振る舞いが変わっている）

> 機能追加して欲しいとなる
それは機能追加であってリファクタリングではない
（外部的振る舞いが変わっている）


リファクタリングというのは、不具合修正や機能追加を行う際に
行うもので、不具合修正や機能追加でやる内容の一部
リファクタリング or 不具合修正 or 機能追加 ではない

不具合修正（リファクタリング含む） or 機能追加（リファクタリング含む）
である

>>247
そんなことないと思うけど

>>248
そんなことないと思うけど
一社童貞のやつよりよっぽどマシ

>>249
俺自身は発言の中でリプレースとはどういうものかとはなにも規定してませんが
まぁ外部的振る舞いという面で考えると、変わる場合もあれば変わらない場合もあるよね当然
で、たまたま外部的振る舞いが変わらなかったとしても、それをリファクタリングとは呼ばないよね

>>252
中規模って具体的には？

>>256
なぜ？

> で、たまたま外部的振る舞いが変わらなかったとしても、それをリファクタリングとは呼ばないよね

そりゃそうだろうね。
リファクタリングは動きを変えないために、
特定の手順にしたがってソースコードを修正する

http://shop.ohmsha.co.jp/shopdetail/000000003881/
ここの詳細目次の、5章（は解説なので正確には6章）から
その手順がリファクタリング･カタログとしてまとめられてる。
これを読むと、このやり方なら動きが変わるわけないなってわかるはず。

そしてもう一つ重要なのはテスト。テストによって
外部的振る舞いが変わらないことを保証する
だから、たまたま外部的振る舞いが変わらないっていうのは
テストを実行してないんじゃないかと思われる

テストを実行して、外部的振る舞いが変わらないのを確認するのが
リファクタリングだから、修正のたびに何度も "意図的に" 外部的振る舞いが
変わってないことを確認してる（だからたまたまなんて思わない）

>>253
普段の改修の中でこまめに行うものだけがリファクタリングじゃないよ
プログラム全体に波及するような設計の変更は、ボーイスカウトルールに則ってるだけじゃやれないからね

意図的に外部的振る舞いが変わらない形で修正して
確認するのがリファクタリングだから、
たまたま動きが変わらないのは、単なるソースコードの変更ってことか
多いんだよな、単なるソースコードの変更をリファクタリングとか言ってるやつ

>>261
プログラム全体に波及するような設計の変更を
こまめにやるってだけですが？

プログラム全体に波及するような設計の変更を
こまめにやるためのテクニックも↓に書いてありますよ。

> http://shop.ohmsha.co.jp/shopdetail/000000003881/
> ここの詳細目次の、5章（は解説なので正確には6章）から
> その手順がリファクタリング･カタログとしてまとめられてる。
> これを読むと、このやり方なら動きが変わるわけないなってわかるはず。

えいやってやるしかないと思ってるのは
単にその力がないだけ

テストしないでコード整理するのも時には必要
あまりにも悲惨なコードに短時間で多数の機能を追加しなきゃならん時とかね
多少のミスは割り切ってリファクタリングして機能追加して全体を手動テストして納品する
俺はこれをエクストリームリファクタリングと呼んでる
厳密なリファクタリング信者からすると気持ちわるいかもしれないが生産性は高い

>>258
ド素人か？
この業界で中規模と言ったら1000行以上、1万行未満のことだ

経験が少ないと、大規模リファクタリングの必要性に直面する状況が想像できないかもしれない
そういう場面も多々あるもんだけどね

>>259
井の中の蛙と大海の大ウミガメの違いと言えばおわかりになるでしょうか

>>265
うん。だから動きが変わるかもしれないわけでしょ？
それは単なる修正って言えば良いんだよ。
リファクタリングと呼ばなければいい

>>267
> 経験が少ないと、大規模リファクタリングの必要性に直面する状況が想像できないかもしれない
想像してるぞ？

こまめにリファクタリングしなかったから、
ソースコードに限界が来てしまった場合に
大規模リファクタリングになるって言ってるじゃないか
（そういう自体になる前にこまめにリファクタリングしよう）

>>265
そんなのファウラーの本に書いてあるか？
あの基本書の内容を踏襲していない行為をリファクタリングとは呼びませんよ？

>>267
×　経験が少ないと、大規模リファクタリングの必要性に直面する状況が想像できないかもしれない
○　経験が少ないと、大規模 改修 の必要性に直面する状況が想像できないかもしれない

なんでリファクタリングじゃないものを
リファクタリングって呼ぶんですか？

リファクタリングを単なる改修の意味で使わないでください

>>270
> あの基本書の内容を踏襲していない行為をリファクタリングとは呼びませんよ？

そうですね。基本書の内容を踏襲していない行為は
リファクタリングと呼んではいけません。
ただの改修と言いましょう

なんで改修をリファクタリングって言いたいんだろう？
かっこつけたいのかな？

言葉の定義とかつまらんからもっと益になる話しようぜぇ

グローバル変数(public static 変数も含む)を安全に排除するリファクタリングテクニックについて議論しよう
リファクタリングするときいつもこれだけはスマートに解決できない
リスクを背負って修正するしかなくなる

大勃起リファクタリングと聞いて

>> 271
> なんでリファクタリングじゃないものを
> リファクタリングって呼ぶんですか？

お前にとっての「僕のリファクタリング」なんて知らんがな

動脈から直接リファクタリングを投与した

>>276
俺にとってのとかじゃなくて
リファクタリングの正しい定義だ
ちゃんと調べてこいよ。
単なる改修の意味で使うな

最初に書いたテストがリファクタリングの前後で同様に動くとは限らない
壊れたテストを書き直すのもリファクタリングの一部

>>268
意味不明

>>278
大規模なものは改修で、小規模なものはリファクタリング？

ここまで技術的な話題ゼロｗｗｗマ板は素人しかいないってホントだったのか

>>281
なんでまた曲解するの？
２つの別々の話を混ぜないように

1. 大規模なものも小規模なものも外部的振る舞いが
変わらないようにちゃんとした手順で行って
テストで確認してるならリファクタリング
そうでないなら、単なる改修

2. 大規模リファクタリングが必要になるのは
普段からこまめにリファクタリングしてないから。
普段の改修の中でこまめにリファクタリングしていれば大規模なんて必要ない。
必要になるのは普段からリファクタリングしてなくて、
手遅れ状態になってる証拠。そういうのはあってはだめ

リファクタリングは小まめに行うべきか？
ある程度たまってから行うべきか？

結論：リファクタリングが不要になるように書け！

将来の改修や拡張の方向性がわからないのにんあことできるわけないだろ！

リファクタリングはソースの修正が必要だから行う
つまりソースの修正が必要なくなればいい
データベースでいうところの、UPDATEではなくINSERTになるようにすればいい
つまり、適切な粒度で関数（メソッド）を適切に作成すれば
リファクタリングは不要なのではないか？
例えば、1関数20行という教えはそういう意味も内包しているのではないか？

今までリファクタリングが必要になった場面を思い出して欲しい
やたら長い関数、スコープが不適切な変数、マジックナンバーやあり得ないelseの使い方などがほとんどではないだろうか？
本当にリファクタリングが必要な場面などほぼ無いはずである

もしリファクタリングが必要だというのであれば、それは清書を後回しにして適当に書きなぐることを優先した結果であり
そもそも「ソースを書いていない」わけである
漫画であればペン入れをしていない下書きやネームの状態、ガンプラでいえば接着剤を使わず仮組をした状態だ
もちろん、「正しく作る」ことよりも「とりあえず動く」ものを何よりも時間を優先して作ることが至上命題であることもあるだろう

それでも書道の名家は一発で何度でも美しい書体を生み出す
プログラマであっても一発で完全に美しいソースコードを生み出すスキルは必要なのではないだろうか？

以上のことから、「リファクタリングが不要になるように書け！」というのは正しいと言える

>>280
意味明瞭

>>286
あー、いや、テストファーストでは
最初にテストコードを書いて、
テストに通る最低限のコードを書いて
そのあとリファクタリングして
完成だから

つまりあんたの言う「ソースを書いている」状態にするまでに
リファクタリングをする。

ちょっと勉強し直してきて

もちろんテストファーストをしないならリファクタリングはしないってことじゃないよ。
先に実装しても、その後テストコードを書いて、それが通るのを維持しながら
ソースコードを読みやすくする。これもリファクタリング

テストファーストはリファクタリングじゃないですよ

テストファーストはテストを先に書くってだけで
リファクタリングを内包するわけじゃないですよ

テストファーストとリファクタリングは独立した概念です

>>290
テストファーストの手順の中に含まれるものだって話をしてるんだから
テストファースト＝リファクタリングなわけないでしょｗ
お前の日本語の理解力の問題だ

http://www.itmedia.co.jp/im/articles/0602/24/news137.html

> 　実行したテストコードが通らなければ『レッド』という状態になり、
> 実装コードを修正する。一方、テストが通った状態は『グリーン』と呼ぶ。
> ただしテストが通っても、可読性を考えてコードをきれいに整えることも多い。
> テストファーストではこの修正作業を『リファクタリング』と呼んでいる。

へー、このスレ勉強になるな

個人的にそういうやり方をやってるってだけで
テストファーストとリファクタリングは根本的に異なり
完全に独立して成り立つものですよ

テストファーストにリファクタリングは必要ありません
むしろテストファーストの目的を没却する悪手と言っていいでしょう

>>287
意味不明

テストファーストでリファクタリングが必要になるなら
テストの粒度が間違っている証拠です、にわかがよくやります

>>295
そりゃそうだろｗ
だからこそ、テストファーストしてから
リファクタリングするって話になる

>>297
意味明瞭

>>299
ではテストファーストとリファクタリングを一緒に語るのをやめるべきです

>>298
でも、ぐぐったけど、そんな事ないてないよ
ニワカはお前では？

テストしないでリファクタリングおっかない

>>302
ググらないとわからないならお前がにわかです

>>300
意味不明

>>305
意味明瞭

>>301
はい。だからリファクタリングだけでも話をしています。

>>289でもそう書いたでしょう？
> もちろんテストファーストをしないならリファクタリングはしないってことじゃないよ。

テストファースト（開発の前にテストを書く）をしなくても、
リファクタリングは独立したものなので、
開発→テストコードを書く→リファクタリングという手順で、
リファクタリングをすることがあります。

開発の前にテストコードを書いてないのでこれはテストファーストではありません。

>>304
でもお前はググってないで、自分の意見を主張しているわけだよね？
そしてそれが世間で言われてないことがバレたよね？

>>307
はいじゃないが

>>308
バレてません、グーグルがなんでも知ってると思うな

グーグルを神か何かだと思ってるんじゃなかろうかね

グーグルは知らないが、俺は知ってる。
情報の出どころは教えられないが
俺を信じてくれるよね？

>>312
はい

ママぐらいは信じてくれるんじゃねーの？ｗ

>>306
意味不明

>>315
意味明瞭

>>316
意味不明

>>317
意味明瞭

リファクタリングの定義がないから仕方ない。

コードをいじってばかりのやつは、手段と目的が逆転している。

>>318
意味不明

>>320
意味明瞭

>>318
お前「意味明瞭」でググってみろｗｗｗ

>>321
意味不明

意味明瞭ってなんだよ

>>324
日本人じゃないんだろ

>>323
意味明瞭

>>319
> コードをいじってばかりのやつは、手段と目的が逆転している。

いや、だからリファクタリングだけやるのは論外って言ってるんだが？
目的は機能追加などの改修で、その手段（の一つ）がリファクタリング

目的を実行する時にこまめにやる手段で、手段そのものが目的になってるような
リファクタリングだけの作業とか大規模リファクタリングはおかしいって
言ってるんだが？

>>325
意味明瞭をわからない人間の方がブラジル人じゃないだろ

>>324
意味がはっきりわかること

>>326
意味不明

>>329
日本人なら普通そんな使い方しない

>>328
ブラジル人ではないだろうな

意味明瞭ワロタｗｗｗ

>>256
で、これの理由は？

>>331
お前は普通じゃないし日本人のこと1ミリも理解してない
史実に登場する最初の天皇の名前を言ってみろ

>>335
ググってみろ

>>334
>>268

>>336
はい知らないのな、お前日本人のこと1ミリも理解できてない

>>335
「意味不明」と「意味明瞭」がちゃんと対照的に使われている例を教えてよ先生

>>338
キチガイおつ

>>337
それ理由になってねーよ

>>338
ググってみろ

>>338
在日おつ

荒らしが飽きたら続きのレスをお願いしますよ

>>335
うっわ

ただ、普段からリファクタリングしてたら依頼がきたときに素早く対応できるよね

>>335
キチガイ

>>339
「意味不明」とは意味がはっきりしないという意味です
「意味明瞭」とは意味がはっきりしてるという意味です
ゆえにこれらの言葉は対称の関係にあるわけです

>>335
統合失調症ですねわかります

>>348
ソース

>>348
対称と対照の違いもわからないカスがこちら

>>348
世の中一般の使用例あげろよ、あるんならな

>>351
対照は文脈的に大間違いだったので訂正しました
わかってないのはお前です、お前がカス

>>353
やっぱ日本人じゃないな

>>353
なぜ間違いなの？

>>352
意味がはっきりわかるときに、意味明瞭と言います
これが一般的な使用例です

あなたはただの世間知らずというか無知です
無知な人間は自分が賢いと思いこむ傾向にあることが
認知心理学の研究の結果明らかになっています

あなたは自分が無知であるがゆえに意味明瞭という
自分が知らない言葉を使いこなしている僕に嫉妬しています
無知を自覚してください

>>356
そう言われている具体的な例が未だに出てこない点でアレ

>>355
対照ではないからです
なぜならば対称しているからです
対照関係と対象関係は明らかに異なります

>>356
だからその一般的に使用されている例を出してみろよ

>>358
説明できていないｗｗｗ

>>358
これ統合失調症やろ

>>358
対象も出てきたｗｗｗ

>>357
それでは具体的な例を上げます

意味がはっきりわかったときに
意味明瞭と言います

この上なく具体的で一般的な例を提示しました
あなたはそれでもわからないと言いはるでしょう
しかし、それは自分が知らない事柄が存在することを認められないだけです
無知であるがゆえにあなたのプライドはとても高いのです

>>363
お前の頭の中を書き出してもそれは一般的とは言わない

>>362
ただの書き間違いですよ、残念でしたね

>>358
そら対象は違うやろ

>>363
妄想おつ

>>364
一般的に意味がはっきりわかる場面というのはあるでしょう？
無いんですか？ ありますよね、ありますよ
完全に一般的です

>>363
病院行きなさい

>>366
ただの書き間違いに一生懸命レスしても意味ないですよ

>>368
はい統合失調症

>>369
お前がODAに行けよ、万年引きこもり

>>370
漢字の違いがミソなのにそれを間違える時点でもうねｗｗｗ

>>372
うっわ

>>368
使用例

>>371
自分が医者だと錯覚してる人の方があれだと思います

>>368
妄想と現実の区別がつかない状態がこれです

>>376
それも妄想

>>376
医者なんて単語一言も出てきてないのに…これが統合失調症

>>373
打ち間違いなんてよくあることです
校正する人なんて居ないですしここ5chですし
正確さにこだわったところで1紋の得にもならないですし
一生懸命書き間違いを攻めようとしている様、とても滑稽です

>>379
統合失調症と診断できるのは医者だけですよん
想像力足りてなくないですか？

>>380
対称と対照の話で対象は書かねーよ
キチガイ以外は

>>381
だれも診断してない　
妄想おつ

統合失調症というのはただの悪口であって
実際に病気かどうかは関係ないよ
世の中で統合失調症って言われてる人で実際に医師の診断受けた人ほとんどいないでしょ？

>>381
よう統合失調症

>>381
キチガイとも言う

>>382
変換ミスっただけだよ
変換ミスっただけでキチガイ呼ばわりとは
そっちの方がむしろあれじゃないですか

>>383
はい統合失調症って断定してた人いましたよ
妄想じゃないですよ、スレを検索してください
そんな人居ないというあなたの方が妄想乙です

>>387
変換ミスの話ではない

>>385
よおキチガイ

>>388
キチガイ

>>388
妄想おつ

>>389
対称を対象と変換ミスった話ですよ
それを変換ミスの話ではないと思ってるなら
それこそ妄想があれですよね

>>387
漢字の違いが主張のポイントなのにその漢字を間違えるなんてありえない

>>392
言うに事欠いてそれですかｗ

>>393
対象の意味を理解してないからそんなことが起こる

>>395
いうにことかいて

>>394
間違いは誰にでもありますし
僕は自分のミスを素直に認めていますよ
変換ミスだって、それを一生懸命攻めようとするのは野暮だと思いますし
本来の議論を見失ってると思います
リファクタリングの話をしてましたよね

>>395
じゃあ何？

>>398
誰もミスを責めてるんじゃない
統合失調症やな

>>398
だからミスじゃねーよｗｗｗ

>>396
意味を理解していようといまいと変換ミスは起こるものですよ

意味不明

>>402
だからそこじゃないってｗｗｗ

>>401
ミスった本人がミスだと言ってるわけですからミスですよ
いいやお前はミスターだとかそんな寒いこと言おうとしてるんですか？
やめてください

>>404
そこですよ、僕の些細な変換ミスを針小棒大に大問題だと
大騒ぎしてYahoo!のトップを飾ろうと画策してる人はいないにしても
そこですよ

>>405
統合失調症やべーな

>>406
統合失調症こっわ

で、「意味明瞭」の一般的な使用例はいつになったら出てくるんだい？

>>409
>>363

もう何回も言いましたよ
あなたがそれを受け入れられないことも予測してみせました
無知な人間というのは知を拒絶するものなのです

あなたは、意味明瞭という言葉を知らない
僕は、意味明瞭という言葉を知っている
この現実を受け入れられないのです

自分より賢い人間がいることを、自分が知らないことが
世の中にあることを受け入れることができず
自分だけの小さい世界の中に閉じこもって心の平穏を望むのです

僕はそれを悪いことだとは思いませんが無知な人だなって思います

>>410
お前の妄想じゃなくて、現実世界での使用例を

>>410
ソース

>>410
使用例のリンクをいくつか貼るだけなのに何言ってんのこいつ？

まともな例を見つけられないんだろ

リファクタリング対象だな
対称でも対照でもなくて

意味不明

>>411
意味がはっきりわかることってありますよね？
現実であなたはそういう経験ないんですか？
僕の妄想の話ではありません、現実にそういうことあるでしょう
そういうときに使います

意味明瞭と言って意味がとてもよくわかりましたと相手に伝えるのです

>>417
リンク

>>413
リンクが貼りたいならあなたが貼りなさいよ
何でもかんでも他人に頼ろうとするな

>>417
頑張ってググるんだ

>>419
俺はそんな使用例知らないから貼れない

>>419
存在しないものは貼れない

>>418
http://2chb.net/r/prog/1523765624/417

>>423
死ね

>>423
妄想から出られないんですね

>>423
ないんですねわかります

>>423
自己引用わろた

>>421
知らないのなら覚えよう
知らないことを自覚したなら
自分の世界を広げよう

意味がはっきりわかるときに、意味明瞭と言います
そういう言葉があります

明瞭というのははっきりわかるという意味です
ゆえに意味明瞭というのは意味がはっきりわかるという意味です

>>428
リンク

>>428
ソース

>>428
また妄想かよ

>>428
長文はキチガイ

意味不明

>>428
ソース

>>427
国語辞典には日本書紀のリンクが載ってるが
日本書紀にはリンクなんて存在しないからな
だからといって日本書紀の日本語はデタラメだと言う人は居ないだろ
リンクというのはそもそもインターネットが普及してグーグルという
営利企業がそれによってランク付けをするように成ってから
重要視されるようになっただけで、それがなくても言葉っていうのは
作られていくし伝わっていくし話されていくんだよ、僕はその言葉の
大切さを少しでも伝えられたらと思います

>>435
ソース

>>435
オレオレ用語なんですね

>>430
>>434
ソースは一般社会だ
意味がはっきりわかったときに意味明瞭！と言ってみろ
それで相手に伝わらなかった経験があるわけ？
ないだろうが、意味明瞭というのは完全に一般的な言葉なわけ

>>437
オレオレ用語ってなんすか？
国語辞典10冊見ても載ってないんすけど、なんすかそれ？

>>438
完全に一般的な言葉の使用例をいまだに出せないのはなぜ？

>>439
どの十冊？

日本書紀に載ってるんすか？ オレオレ用語って
いやマジ、そういうの見たことないんでー、この人日本語苦手なのかなってマジそう思うっすー

日本書紀ｗｗｗ

糖質vs糖質
春の休日にふさわしいバトルやなww

きっも

>>444
バトルになってなくね？

>>441
明鏡、明解、日本、現国、基準、共明、共立、新日国、現銘、金田一
の10冊

>>447
すごーい君は国語辞典たくさん持ってるフレンズなんだね

>>448
IT社会だから、紙の本は殆どないけどね
いつでも検索できるようにしてる

>>447
すげえそんなにあるんやな
写真見せて

>>447
その十冊に「意味明瞭」は載ってるのかい？

>>450
著作権的にアウトだからムリ
漫画村とかも見たらアカンで
5chで無茶言ってもそういうところはきちんとしないと

>>451
意味明瞭の四字熟語は載ってないけど
意味、明瞭では載ってるよ

>>452
なぜ無理？

意味明瞭と言った場合、意味が明瞭なんだなってわかるっしょ
漢字は表意文字だからそういうことが可能なんだよ
オレオレ用語も、オレオレ、用語という単語が合わさってできてるんだ
オレオレの意味と用語の意味がわかれば、オレオレ用語は辞書に載ってなくても
自分で定義した用語のことなんだなってわかるっしょ

オレオレ用語だという人間が意味明瞭をわかりませんというのは
完全に道理に反してる卑劣な行為だと知ってほしい

>>453
誰もそれは否定してないやろ

>>455
だからその使用例を出してみなって
出せないのは普通そんな使い方しないからやろ

>>453
そらそうだｗｗｗ

>>454
著作権法的に違法行為にあたるからムリなんだ
僕は法律は守りたい、なぜならば法律は社会を成り立たせる
ためにあるものだし、一人ひとりがそれを尊重することによって
法律は成り立つし、それによって社会が成り立つから
法律に違反するというのは社会を否定することであるし
社会を否定して生きていけるほど僕は強くないから

>>455
使用例

>>459
なぜ？

>>459
誰も辞書の中身を写せなんて言ってなくね？持ってる辞書のパッケージ写すだけなら何が問題なの？

>>457
使用例は
意味がはっきりわかったときに「意味明瞭だ」と言うんだよ
これが使用例です、普通というのはあなたの日常では使いませんという
意味ですよね、それはあなたの語彙が足りてないから使えてないだけで
このスレであなたは新たな語彙を獲得したんだから、是非使っていって欲しい
と僕は思うわけです

>>447
正式名称教えておくれ

>>463
ソース

>>463
妄想おつ

>>462
IT社会だから辞書はコンピュータから検索できるようにしていて
そのUIは独自のもので秘匿が原則であることが記されているから
お示しすることはできないというわけです

>>467
典型的な嘘やな

>>467
この古臭さはどこから？

意味不明

>>467
IT社会
コンピュータ

うーん

>>468
仮にそれが嘘だとしても、意味明瞭が「意味がはっきりわかること」
に変わりはないんだからね!?

>>469
仮にそれが古臭いとしても意味明瞭が「意味がはっきりわかること」
を意味することに異論はないでしょ？

>>472
ソース

本当はわかってるくせにわからない振りをしてるだけですよね
意味明瞭と言って本当にその言葉の意味がわからない人っていますか？
そんな人が本当に居るとしたら、その人はオレオレ用語の意味さえわかりませんよ
言葉は単語のつながりですし、単語の元々の意味が変わることなんてありません
元の単語の意味がつながるだけです

無知な人はわからないわからないと言っていれば良いので
議論において最強と言われることがありますが
そういうことで最強の名を手中に収めて満足できますか？
僕はできませんね、なぜならば無知なだけだからです
ものを知らないだけだからです、知らないことを武器に
偉そうに振る舞って相手を黙らせて何が嬉しいのでしょうか
自分の無知に気づかない本当のバカですよ

>>474
ソース

>>474
長文はキチガイ

>>476
短文は知恵遅れ
みたいな

やめましょうよそういう煽り合いみたいなの
知性ある議論がしたいです

>>475
ソースが必要な部分あるか？ｗ

>>474
長文はキチガイ

「意味明瞭」で検索しても、一件もヒットしないんだが？

>>475
ソース？

大東亜会議の真実: アジアの解放と独立を目指して - Google ブック検索結果
https://books.google.co.jp/books?isbn=4569634958
> 東條も土壇場になると、日本の古歌、諺を引用する癖があり、いずれの場合も意味明瞭でない。

上司になってはいけない人たち - Google ブック検索結果
https://books.google.co.jp/books?isbn=4569819184
>一塁離明瞭かつ意味明瞭な指示を心がけることによって、
>自分は何を知っていて何を知っていないかが明らかになる。

瀬戸内−道後殺人事件 - Google ブック検索結果
https://books.google.co.jp/books?id=K_n6DAAAQBAJ
> 塔本によって、広島のどこかで麻薬漬けにされているという意味なんでしょうか」
> 「最初の書き込みは意味明瞭だが、問題はあとのほうだ」

経営理念 - TEC予備校
https://tec-yobiko.co.jp ? TECの取り組み
> つまり、あくまで言語明瞭・意味明瞭に徹した世界なのです。言うまでもなく、
> その後の人生において生徒達も、“言語明瞭・意味不明”な話術を身につけていく
> 可能性はありますが、私たちの教室ではその技術を教えることも利用を推奨することもありません。
> 「言語明瞭・意味明瞭」一点張りです。

出版物のご案内 - 株式会社ビジネスサポート
www.bizsupport.co.jp/book.html
> シート�I 意味明瞭化シート

災害医療センター がん疼痛相談外来 患者情報提供書 - 独立行政法人 ...
www.nho-dmc.jp/treatment/department/pdf/gantoutuujyouhou2017.pdf
> コミュニケーション □ 0 意味明瞭・複雑な表現. □ 1 意味明瞭・単純な表現.

意味不明

有名税は世相の反映、政治家のニックネーム
https://blog.goo.ne.jp/tenyumineo/e/114c240601bdf83d4bf09e77b5f65356
> 大平正芳：鈍牛、言語不明瞭・意味明瞭

https://blog.goo.ne.jp/shima1946/m/201001
> 往年の総理・大平正芳さんは「言語不明瞭　意味明瞭」といわれたものでした。

>>319
> コードをいじってばかりのやつは、手段と目的が逆転している。

いや、だからリファクタリングだけやるのは論外って言ってるんだが？
目的は機能追加などの改修で、その手段（の一つ）がリファクタリング

目的を実行する時にこまめにやる手段で、手段そのものが目的になってるような
リファクタリングだけの作業とか大規模リファクタリングはおかしいって
言ってるんだが？

結局さ、リファクタリングに文句言ってるように見えて、
実は自分らが普段やっている、いろんな問題が発生している
信頼性の低い行き当たりばったりの改修方法に
文句言ってるだけだろ？

リファクタリングをただの改修と勘違いして、
いつもの自分らを批判してるだけ

取り敢えず、リファクタリングの意味は間違えんなよって言いたい。
リファクタリングは、利用者から見て全く振る舞い=挙動が変わらんやつのことだ。シンプルな定義じゃないか。

その性質上、リファクタリングのみで直接利益の上がる作業なんて(ほぼ)ないし、他の修正とセットになることが多い。が、ちゃんとリファクタリングとそれ以外は明確に別れる必要もある。

何も難しくない

> が、ちゃんとリファクタリングとそれ以外は明確に別れる必要もある。

どういう意味で言ってるのか知らんが、これを読めばわかると思う

Martin Fowler氏によるリファクタリングのワークフロー
https://www.infoq.com/jp/news/2014/03/fowler-workflows-refactoring

> 機能を追加するとき
> バグを修正するとき
> コードレビューと共に
> Fowler氏は「二つの帽子」の比喩を引きあわせて、プログラミングのタスクをこなす際の、
> 新しい機能の追加（ファンクションの帽子をかぶること）と、
> コードの品質向上（リファクタリングの帽子をかぶること）について説明している。
> そして、「プログラミング中は、頻繁に、ことによると数分毎に2つの帽子を
> 取り替えることになるだろう。しかし、一度にかぶれる帽子はどちらか1つだけだ。」と彼は述べている。

一つのタスクの中でこれらは混ざるが、同時に二つを行うことはない。
その意味で明確に分かれるといってるのならそれはそのとおり

もう少し具体的に言えば、ある機能実装のブランチがあって
そのブランチの中でこれらは混ざることはあるが、コミットは別れている

> その性質上、リファクタリングのみで直接利益の上がる作業なんて(ほぼ)ないし、

それはコードのメンテナンス性や可読性を上げても
直接利益に上がらないと言ってるのと同じことで
他の業界で言えば、作業を効率化しても客の数が変わらければ
利益は上がらないと言ってるのと同じことだろう

たしかにそのとおりだが作業を効率化させないと
客の数を増やしたら忙しすぎて破綻するし、
余裕がなければ疲れるだろう。利益ではなく
作業効率に直接影響するのがリファクタリングなんだよ。

>>487
あってるあってる。俺もそんなこと言おうとしてた。
もっと言うと、リファクタリングコミットでテスト回してないなら、ただのedit and prayやろって奴やな

>>488
効率化云々を否定するつもりはない。効率化するならいいじゃないか。
ただ俺は>>36の通りの主張。
コストの前借りは基本通らねえよ、とだけ。

コストの前借りなんて話はしてない。
コードを改修する時の作業に含まれてるんだから

現在のコードの品質（理解しやすさ）によって
改修にどれくらい時間がかかるかは変わるのだから
見積もりには現在のコードの品質を反映させる必要がある。

これは改修でやらなければいけないことで、前借りではない

こっちはリファクタリングコストは見積もらないけどな...。
他の作業と置き換えて効率化できるならOK
リファクタリングコストないじゃんとかわけわからないこと言わなきゃいい

>>491
だから、それが間違いだと指摘してるのにまだ気付かないのか？

リファクタリングしようがしまいが、
現状のコードが複雑なら解析に時間がかかるので、
あとはその解析結果をコードに反映して次回はもちろんのこと
今回のレビューやエンバグした時の修正を楽にするか
今のままより複雑にして大変にするかの違いなんだよな

そんなに複雑じゃないならリファクタリングも大したことない
すごく複雑なら、それリファクタリングしないと近い内に苦労するよってこと
こまめなリファクタリングが重要
100%完璧にしろなんて言ってない。修正する前よりも良くなっていればいい

>>493
お前のその指摘が間違いなんだよｗ

>>495
それが事実なら、指摘内容にちゃんと反論しろよ。。。

指摘内容に反論してるのが、>>491の内容でしょｗ

つ〜か「間違ってる」というだけじゃ
それは指摘じゃない。

地球が太陽の周りを回ってるのは間違いなんだ！
って言っても、それは指摘じゃないのと同じこと

ちゃんと設計して作成、改修してるのにリファクタリングが必要になるのは何故？
なんかすでにおかしくね？

つまり、リファクタリングっていうのは設計が腐ってるから発生した不具合ってことだよね

頭がばぐってる奴のこじつけ論にトラウマがある
最初から最後まで自分の主観から一歩も出ていない
立場をかさにきてるだけ
バットで頭なぐるか車でひき殺すかしたい

そこからわからないのか？

客が仕様変更しないとでも思ってるのかな？
状況は刻々変わってるし、やってみなければわからないこともある
20年以上前のアプリがクラウド対応の設計していたらびっくりだわ

ソフトウェアは同じものを作ることはなく、はじめての道ばかりなんだから
軌道修正しながら進むしかないんだよ。
その軌道修正っていうのがリファクタリングでもある。