-
プログラマー
-
リファクタリングすると全部テストしろと言ってくるやつの矛盾
-
UPLIFTで広告なしで体験しましょう!快適な閲覧ライフをお約束します!
機能追加や変更した時に、全部テストしてるでしょ?
いつもやってることじゃん - コメントを投稿する
-
それなw
あと、リファクタリングするとお前責任取れるのかとか言ってくるが
機能修正でバグった時の責任はリファクタリングじゃないんだから
全部あんたがとれよって言うと顔真っ赤になるw -
半角カナを使う奴まだいたのか
-
スレタイ長くて入らないからね
-
簡潔にまとめられない奴はプログラミング向いてない
-
そんなことない
なんでもかんでも一緒にするな -
>>1
テスト粒度とかリスクとか理解できないの? -
リファクタリングはテスト必須で
論理的におかしくならないと判明している
決められたやり方でやるので
リスクは低いしテストは自動化されています。
その前提ぐらい知らないんですか? -
> そもそもクラスまで作り変えてるならテスト免除どころか設計書のレビューからだよね
そうですね? なんでレビューせずに
リファクタリングするなんて思い込んでんの? -
> リファクタリングはテスト必須で
って書いてあるのに
↓
9 返信:仕様書無しさん[sage] 投稿日:2018/04/15(日) 14:45:55.12
>>8
だからテストやらなくていいって?
これもう頭が悪いレベルだろw -
リファクタリングの存在を否定できないと
困る人がいるんですよw -
設計書から書き直すならただの改修作業なんだよね?
-
>>15
具体的にどう違うの? -
>>15
TDDでリファクタリングした場合、
1、初歩的なミスにすぐ気付ける
2、作業者が精神的に安心できる
なお、開発者目線の開発体制の優先順位は
バージョン管理 > コードレビュー > 自動テスト > リファクタリング
なので、必ずリファクタリングとTDDはセットになる -
>>16
リファクタリングの手法では先に自動化されたテストコードを書く
もしくはすでに存在していなければならない
だから、リファクタリングしたらテストしろよっていうのは意味不明。
リファクタリングの中にテストすることが条件として含まれており
修正前と修正後の両方、それどころか修正のたびにテストすると言ってるのに
なんでそんな当たり前ことを、それも最後だけテストするような質問をするんだ?と
疑問になる
おそらく修正とテストが分離した考え方しか持って無くて
修正後に手動でテストを行うというやり方しか知らないのだろう
そんな再現性がなくてテスト回数もすくないんじゃ、
バグがなかなか取れずにデスマになるのは必死だろう -
なにをゆうちょるんじゃあ主は
-
リファクタリング厨って受け売りでしか語らないから面白くない
-
ゴミスレ
-
オープニングから自演w
-
>>2
責任とって辞めます。 -
>>19
そこらへんの話でいうと、
売上や品質が上がった客観的なデータが示せりゃ、どの会社でも自動テストやリファクタリングは採用されるんよ
そこまでしてないなら、その議論は語るに値しない
んで、殆どの会社はそこを検証していない -
>>27
仕事を規定の時間内に許容できる品質のものを上げるのが実装者に求める要求で、それに付随する手段は手段でしかない。
で、手段は自由にやればいいし、基本介入しないし、結果しか見る気は無い。
だからやりたければやれば?としか自分は言わない
工数増えるのは論外 -
>>26
> そこまでしてないなら、その議論は語るに値しない
> んで、殆どの会社はそこを検証していない
検証しろっていうのはわかるが、それは世間一般には
すでに検証されていてすでに品質が上がったというデータは出てるんだよな
それも検証するコストも出せないような会社がやるような中途半端な
方法じゃなくて、もっと大規模で信頼できる方法で検証した結果がすでにある。
で、それを参考にすりゃいいのに、参考にしないんだろう。
つまり他人を信用してない。だから他人がなにやってもどんなデータを出しても
そういう会社は信用しないんだろう。 -
リファクタリングが有効かどうか?
検証してやるよ。コスト?そりゃ当然かかるよ
ここで嫌がる会社が多い
重要なのは、失敗するかもしれないがやってみよう
という考えが通じる会社かどうかなんだろうな -
体力がなくて単純工すらできないごみクズがIT技術者(笑)になる日本では
コストメリットどころかリスクしかない。 -
「リファクタリングしたら工数減ります」
「リファクタリングの為の工数ください」
うん。意味不明だね。 -
> 「リファクタリングの為の工数ください」
誰もそんなこと言ってないけど?
>>31が言ってること勘違いした?
リファクタリングが有効かどうかの検証の話だよ。
検証するには、同じことをリファクタリグをするのと
しないので2回やらないといけない。
検証にはコストがかかる。 -
>>28
俺の筋肉量でリファクタリングの効果を説明できる -
リファクタリングで増減する工数って、内部設計クラスレベル〜クラステストまででしょ
詳細設計省かずやる巨大案件でも無い限り、実装者に委ねられる部分やん。
ともすれば、やりたきゃやれって回答にしかならん。 -
>>36
> いや、リファクタリングで総工数が減るなら勝手にやればいいだけじゃね?
俺はやってるよ。リファクタリングで工数減るから
そもそも修正作業の中に自動的に組み込まれるものだから
あえて "リファクタリング単体で" 工数を取るなんてことはしない
だからリファクタリングのために工数くださいっていう発想が
そもそも間違ってるわけ。修正に伴う追加作業じゃない。
修正作業そのものなんだから -
仕組みが悪いからって正常に動いてる箇所まで手を入れるってねーな
-
リファクタ自体は否定しないが、>>1は確実に技術に溺れて盲信してるアホだから許可出さない
-
>>38
修正が発生したときにしかリファクタしないの? -
修正ってなんだよ、バグってんのか
機能追加だろうがなんでも修正って言う奴は素人でしょ -
ただのレッテル張りじゃねえかw
-
素人というやつは童貞だ
イカ臭いプログラム書いてろ
と言ってるようなもの -
>>43
なんどもリファクタリングは修正の一部だって言ってるじゃん
一部ってことはそれ以外も有るってことだよ
複雑なコードを読み解いて、リファクタリングしないで複雑なまま修正するのと
複雑なコードを読み解いて、リファクタリングしてから修正するのと
どっちがリスクが少ないかって話だ
前者だと、複雑なコードを読み解いた人(修正担当者)がいるにもかかわらず
別の人が、また大変な思いをして読み解いてレビューしなければいけない
そして、次同じところを修正する時、また複雑なコード読み解かなければいけない -
みんな実装するだけで精一杯なんよ
-
リファクタリングは神の領域に達するものにのみ許される技。
素人はおとなしくExcel方眼紙でセル結合の練習でもしておけ。 -
>>47
そんな入門書の1章に書いてあるような話はいいよ、面白くないから -
>>50
入門未満の人がいるんでね -
入門レベルの奴でも上から目線になれるから張り切ってんのか
-
だから>>1にはやらせない
-
リファクタリングしてるのでNG
-
テストしづらいとか、クラスが肥大化しすぎて開発に支障があるとかならまだしも
見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか -
リファクタリングは超プロの領域
このスレには本当のリファクタリングが出来る奴はいない
elseなしに書き換えるのが精一杯のFラン説教野郎みたいなのがいるだけ -
大規模リファクタリングの秘孔をついた
お前のプロジェクトはもう死んでいる -
>>55
> リファクタリングするときのレビューとかどうしてる?
リファクタリングではないときはどうしてる?
それと同じなんだが。
まあそういう質問するってことはリファクタリングに限らず
そもそも設計もコードもレビューしてないってことなんだろうけど
まずはそこからやねw -
>>57
> 自動試験だけで完璧なものができるとか信じてる?
だからレビューするんでしょ?
自動試験はバグがないことを証明する手段
その手段が正しいかどうかはレビューでみる。
人手でレビューして、テストした内容も記録されて
後なにがあれば完璧なものができると思います? -
>>58
> テストしづらいとか、クラスが肥大化しすぎて開発に支障があるとかならまだしも
> 見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか
機能追加とか修正するという前提なんだから、どちらにしろ変更するしかないでしょw -
>>62
自動試験してレビュー通ったらシステムインしてサービス開始すんの? -
入門書第1章に書いてあることの受け売りなら長文で語るけど、具体的な話からは煽りで逃げるし、
体験から語ってると思えるような発言もないし、こいつ多分そんなにノウハウないよ -
>>64
レビューもするし自動以外のテストもする
そこは普通の機能変更のときとなにも変わらない
ただその時のやり方が、複雑なコードを頑張って解析して
無理やりパッチを当てるような、あとから見た時に
なんでこんな面倒なことしてんの?と思われるような変更をするやり方から、
次回は複雑なコードを読まなくて良いように、複雑なコードを
シンプルに修正しつつ、まるで0からコードを書いた時のように
こういう機能を実現するなら、普通こう書くよねという
当たり前の形にするやり方に変わるだけ
変更するたびに複雑になっていくやり方をやめて
変更しても複雑にならない、むしろシンプルになるような
やり方をしましょうってこと
その後にやるテストうんぬんは、もともと機能変更でやる予定だったんだろ?
なら最初からやるって決まってることじゃないか -
レビューってさ
もう儀式になってない? -
TDDってさ
組織的にガチガチにやるもんじゃなくて
設計者の間で守るべき密やかな秘密程度で
やったほうが良い気がすんのね。 -
>>69
ようは、リファクタリング前に存在するテストコードが
リファクタリング後でも通ることで動きを変えてないことが
証明できれば良いのでTDDである必要はないよ。
具体的にはgit使えば歴史変えられるんで、
コード変更しつつテストコード書いて、
コード変更とテストコードでコミット分けて
あとでrebaseしてテストコードのコミットをコード変更の
コミットより前に持ってくれば良い -
>>71
TDDは保護するためのテストじゃないから -
>>68
レビューのつもりで儀式やってるだけのところが多いね。 -
>>72
> TDDは保護するためのテストじゃないから
TDDはテストではなく開発手法ですよ?
TDDという開発手法ではリファクタリングの前にテストを書き
書いたテストが、その後に行うリファクタリングが問題ないことを証明するんですよ
つまり
× TDD = 保護するためのテスト
○ TDD =「保護するためのテスト」を用いた開発手法
(あんたの言った「保護」がリファクタリングで壊さないように守るという意味である前提)
俺が>>71で言ったことは、TDDでやらなくてもテストで保護できると言ったんです。
https://postd.cc/tes...-driven-development/
> 簡単に言うと、TDDは機能を記述する前に自動テストを書く行為です。
> 例えば、Bobが素晴らしい新たなソーシャルネットワークのアイデアの
> ために新しい機能を開発する必要があるとしましょう。
>
> Bobは自動テストを書くことから始めますが、機能を正しく実装せずに、
> テストを失敗(赤色表示)させます。次に、Bobはテストを成功(緑色表示)
> させるための最小限のコードを記述します。緑色表示になったら、
> Bobはコードをきれいにし、テストを実行して機能が正しく
> 実装されたままであることを確認します(コードのリファクタリング)。
> 重複することなく、コードと自動テストは他の人も簡単に保守できます。 -
>>75
before(リファクタリングしない場合)
1. 機能追加やバグ修正などの変更依頼が来る
2. 変更する
3. 変更したので全部テストをする
after(リファクタリングする場合)
1. 機能追加やバグ修正などの変更依頼が来る
2. 変更する(リファクタリングもする)
3. 変更したので全部テストをする
afterに対して、余計なことするな!
リファクタリングしたなら全部テストしろ!
と言われましても、beforeでも全部テストしてますよね?という話です。 -
リファクタリングしたら(その時点で、機能改修する前に)(単体)テストしろって要求なんじゃね?
まあ普通やるけど。 -
>>77
いやぁ、違うなぁ
リファクタリングさせないための方便として使ってるので
お前がリファクタリングするとテストする人が迷惑するんだぞ
だから余計なことするなという意味だろう。
だがもともとテストするわけで矛盾になるんだよな -
>>74
そういうことじゃないんだよなぁ -
リリースしたらあとはそのシステムのことは知らん
だからリファクタリングする気もない -
>>76
イメージはあってそう(スレ建てた奴とは違う意見)に読めたので、
具体的な内容を書いてみる。
大規模で難解なプロジェクトの一部機能で、
一カ所の編集バッファの数が足りず、
長い氏名の編集に失敗する仕様となっていた。
メモリの使用率なども調査済みで、編集文字数を増やすという仕様変更案件の場合。
バッファサイズを増やして関連箇所の試験して完了。
リファクタリングしたら、統べての試験をやり直し。
リファクタリングの有無でどちらが安いのか、
時と場合によるって認識はあってる? -
WFとアジャイルとでも違うし
リファクタリングできる設計になってるの?
も大きな要素だが
動いているなら弄るなよは永遠の真理 -
>>88
そのレベルの現場が多いもんな。 -
バッファサイズの変更でなにをリファクタするというんだ
文字編集がややこしいから途中量の計算が難しいから処理変更とか? -
>>85
リファクタリングの話は一旦おいておきましょう。
> そうはいかねぇだろ
> 文章化されてないけど
> クリアしてるいろんな仕様があんだからよ
それでどうやってコードを正しく変更できるんですか?
コードを変更する時に文書化されてない仕様を
間違って変えてしまうことがありますよね?
文書化されてない仕様をテストでどうやって
見つけるんですか? -
>>87
> バッファサイズを増やして関連箇所の試験して完了。
>
> リファクタリングしたら、統べての試験をやり直し。
え?なんで?先に修正して試験するのがいけないんじゃん
1. リファクタリングをする
2. バッファサイズを増やす
3. 関連箇所の試験して完了
基本はこうですよ?
実際にはこんな大雑把作業じゃなくもう少し細かく
(ユニットテストと)リファクタリングと修正を何回か繰り返しますが
コードの変更とリファクタリングは切り離せません
コードの変更とリファクタリングの間に「関連箇所の試験して完了」
なんてものは入らないし入れたらダメです。 -
ちゃんと設計できてないから改修する度にいちいち事前のリファクタリングが必要になるんだろうな
-
>>91
まさにそのスレでその話してるんだからおいとくなよ…
現に存在するものに文句言ったってしょうがないだろ
あるんだから
非機能要件のないソフトなんてない
改修部分が少なければ少ないほど踏んじゃうリスクは減るだろう -
> ちゃんと設計できてないから改修する度にいちいち事前のリファクタリングが必要になるんだろうな
そりゃリファクタリングの必要がない場合にはリファクタリングしませんよw
前提として、リファクタリングの必要があるコードだって
ちゃんと書きましょうか? そうすればもっとわかりやすくなりますね。
・リファクタリングをしない場合
1. ちゃんとした設計になっていない
2. そのままで無理やりバッファサイズを増やす
3. やってることが意味不明。変更に自信が持てない。コードレビューも大変。
4. 変更で問題が出やすい。そのたびに意味不明なコードと格闘する。
5. 関連箇所の試験して完了。
・リファクタリングをする場合
1. ちゃんとした設計になっていない
2. 設計を修正する(リファクタリング)
3. ちゃんとした設計に自然な形でバッファサイズを増やす
4. やってることが明確。変更に自信が持てる。コードレビューも簡単。
5. 変更に問題が出にくい。仮に出たとしてもちゃんとした設計になってるのですぐに修正できる
6. 関連箇所の試験して完了。
リファクタリングしたことで1工程増えたように見えますが、
ちゃんとした設計になってないものを無理やり修正した複雑なコードは
バグが出やすく、修正も大変になって時間がかかります。
それはわかるでしょう? -
>>97
ちょっとなにかいいサンプルないか探したんだが
見つからなかったので、軽く例を書くわ
ある関数を改修部分することになった。これが100行を超える複雑なコード。
これをリファクタリングすると10行にできるとする
(ライブラリ使用の有無とかで、これぐらいざらにあるからw)
リファクタリングしない場合は無駄なコードで処理が入り組んでおり
入り組んだコードを時間をかけて頑張って解析し
そのまま修正するとなると数箇所を変更しなければいけなくなることが判明した
だが本当にその数箇所の変更で問題ないのか? コードが複雑なのでよくわからない
レビュー依頼した所で時間をかけて解析したものを他の人がすぐに分かるはずもない
多くの時間を費やすることになった。
リファクタリングして10行にまで減らすと、コードはシンプルになりなにやってるのか一目瞭然になった。
テストコードがあるのでリファクタリングの前後でコードが壊れてないことはわかる。
リファクタリングしたため修正箇所もたったの一行になった。
他の人も何の修正をしたのかすぐに分かる -
>>98
おまいのレスが長すぎてリファクタリングしないと読めない -
>>99
バイバイ -
>>95
リファクタリングの必要性をそこまで感じないってことは、俺の設計ってちゃんとしてるんだろうなぁ -
言語からスクリプト言語が呼べるようにしておけば汎用性は無限
バグも無限 -
数年経ってもリファクタバカは相変わらずだなw
未だに賛同者が現れないwwww
しかも、リファクタリングそのものではなく、リファクタバカに対する非賛同が増殖w
かたやリファクタすら許してもらえない信用と立場のリファクタバカが相変わらずの状態
かたや5年以上で完全に新規で作り直しの許可を与えられるようになった俺
技術書に溺れなくてよかった・・・。 -
>>98
あぁ、そういう事か。
「リファクタリング」という範囲のイメージが合ってなかったんだな。
関数単位のリファクタリングならそのイメージでだいたい合ってる。
「外部インタフェース変えずに内部の設計から見直す」事を前提に話してたよ。
それはそうとして、
関数の処理削減などで処理速度が変わったのなら、同期など含めてその観点での試験はちゃんとやれよ? -
関数レベルのリファクタリングしか語れないレベルだということはお察し
-
おれは何も察することができんのだが
-
>>106
> それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
> テストで検出できない非機能要件を踏んじゃうリスクは明らかに増えてるよね?
関数の中の1行を変えたとして、
その1行だけをテストして関数全体OKってできるんですか?
そもそも関数の中の1行だけをテストすることは不可能だと思います。
結局関数全体をテストするわけでしょう? -
>>108
> 関数の処理削減などで処理速度が変わったのなら、同期など含めてその観点での試験はちゃんとやれよ?
もともと修正すべき関数なんだから、リファクタリングしなくても
テスト必須でしょう? なにを言ってるんでしょうか -
>>112
でもさ
ソースで見たとき処理の下の方をちょっと修正すればいいところで
上の方の関係なさ気な箇所がバグったら言い訳できねぇよ
差分見て
何でここ弄ったの?今回の修正と関係ないじゃん
って言われたらちょっと嫌な空気流れるよ -
>>106
> それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
「可読性」って言葉ご存知ですか?
「可読性」の二番目の文字は「読」です。
「書」ではないのです。
改修は「書く」ことですが、改修前には「読む」こと必須です。
では書く時間と読む時間、どちらが多くかかりますか?
もちろん読む方ですよね?
タイピングなんて1分間に200〜300なんて軽く行く
改修の書く量だけを見ても正解にはたどり着けませんよ。
改修量ではなく作業始めてからの改修時間を見るのが筋じゃないですかね?
リファクタリングは改修時間を短くします。 -
>>114
関係ない所を修正するのがいけないのでは?w -
>>112
具体的なシナリオをいうとだ
日付をこりこり自前でデコードして値つくってる100行近いまぬけコードを
Javaのライブラリつかって数行にしてホルホルしてたら
ついうっかり見たことないようなフォーマットも受け入れちゃうようになってて
そんなん存在もわかんないからテストしてるわけなくて
でもユーザーは何の気なしに入れちゃうと入るからそのまま入れて、想定と異なるへんなデータが蓄積していって
集計バッチの演算とかにちょっとづつ毒虫のように影響を与え続けて
気が付いたらえらいことになってたりとか -
>>115
理解できたらもとに戻してもいいのよ? -
>>119
> 修正内容に応じてテスト観点増やさないの?
少ししか修正してないから、テスト減らしていいとでも?
変更したコードの量は少しでも、その影響範囲は
修正の量とは無関係です。
どれくらい影響があるか、それはコードが複雑であれば
有るほど不明です。 -
>>120
リファクタだけの問題じゃないが、リファクタも修正のうち
修正する以上人間がやらかすリスクはある
だったら修正は極力限定されているほうがいいだろ
>次修正する時、また改修時間(読む時間)がかかりますよね?
そしてリファクタ最大の問題
コードの読みやすさや理解しやすさは人の主観に大きく依存する
else取っ払ってタプル戻り値の関数に変えようとするやつもいるんだぞ
リファクタ後に修正したほうがテスト工数が削減できるとか、規約が新たにできたから合わせるとか
なにかしら明白な理由がないと -
あとどうもやっぱりリファクタリングを
単なるコードの修正の意味で使ってるように見えるんだよねw
リファクタリングは、コードの修正、コードを綺麗にするを
英語にした言葉じゃないよ?
リファクタリングっていうのはやり方が決まってる。
スタート(修正前)とゴール(修正後)は自分で決めるけど
スタートからゴールへ至る道へは、決まったやり方を使って修正する
その決まったやり方っていうのは、動きを変えないための方法
数学の等式の変形みたいなもんだ
x - 2 = 8 を「移行」して
x = 8 + 2 に変形しても意味は変わらない
こういう「移行」みたいに変形しても意味が変わらないやり方に
ご丁寧に名前までつけてカタログ化されてる。
テスト書いて決められたやり方で式を変形するんだから
無計画なコードの修正なんかよりもずっと安全に変形できる -
>>127
メトリクスのどれ見んの? -
>>128
> それでもたまにやらかすだろ!
複雑なコードをそのまま修正するほうが
やらかします。
その場合、いくら修正してもバグはなおらないし
直したそばから別のバグが発生するし、
時間もかかるしで、良いことはまったくありません。
重要なのは改修量ではなく改修時間な -
マーチン本に書いてある手続きいちいち守ってたら日が暮れる
現実的には既存のユニットテストのコードを信用して
手続きを頭に置きつつ直観でつくり変えていくことになる
そんで流して結果変わってなきゃOKと
理想が定義されているからといって現実に耐えうるかというと -
>>130
改修による単体工数の削減はあるかもしらんが
時間重視ならなおのことリファクタやってるひまなんかないだろ
あれほどの時間泥棒もない
よく考えたら書くほうが早いっつったって
結局その前に理解しないと書き直せないんだから一緒じゃねーか!
だまされるとこだった -
> よく考えたら書くほうが早いっつったって
> 結局その前に理解しないと書き直せないんだから一緒じゃねーか!
だから、たった一行の修正とか言っても、
その修正にかかる時間は、理解する時間が大半を占めるんだから
リファクタリングしても大差ないって話だよ。
大差ないどころか、複雑なものを複雑なまま、頭の中で理解するほうが
時間かかると思うがね
そして理解した結果をコードに反映させないで、レビューにかかる時間
次に修正する時間、バグ出た時に読み返す時間を費やするか
コードに反映させて、その後にある時間を減らすかどうか -
>>134
思うのは勝手だが最初にしてた変更リスクの話を忘れてないか -
>>135
> で?結局リファクタやると具体的に何がいいんだっけ?
まず改修時間はさほど変わらない。
変更リスクもどちらにしろテストする場所なので変わらないし
行数が少ないほうが影響範囲が小さいってこともない
リファクタリングでバグ入れそうなコードは
リファクタリングしなかったらもっとバグを入れやすい
そして、レビューやバグがあったときの読み返し時間の削減
修正内容に自信が持てる。今後の修正の時の改修時間の減少 -
1行の修正でこんなにお金がかかるんですか!
っていう顧客の声がまんまリファクタリングしない場合にあてはまるな
1行の修正だからリスクが少ないとお考えか!?
1行の修正でもお金がかかるってことは、1行だからって
なにかを減らせるわけじゃないんですよ。 -
複雑なコードは壊すのがこわいからリファクタできない
簡単なコードは意味がないからリファクタできない -
>>141
重要なのは手遅れになる前にこまめにやることだよね
大規模リファクタリングなんてのはあってはだめ
リファクタリングだけのための作業なんて持っての他
そうやって手遅れにするから、リファクタリングのための
工数なんて取れるかーみたいな話になる
リファクタリングは、機能追加や変更に伴う作業に
含まれているべきものですよ -
こんな事が書いてあるのかw
http://hideoku.haten...ry/2013/03/07/223727
変更を完全に正当化できるまで待つのは、待ちすぎというものである。
プロジェクトはすでに重いコストを負っていて、先延ばしにすると変更するのがより
困難になる。対象となるコードには今より手が入り、さらに多くの他のコードに組み込まれることになるからだ。
継続的なリファクタリングは「ベストプラクティス」と考えられるようになってきたが、
ほとんどのプロジェクトチームは依然として慎重すぎる。コードを変更するリスクと、変更にかかる開発者の時間のコストを見込んでいるためだ。
しかし、それほど簡単に見抜けないのが、設計をぎこちないままにしておくリスクと、
その設計を何とかするためのコストである。
リファクタリングを行いたい開発者は、その決定が正統なものであると証明するよう求められることが多い。
こうした要求は理にかなっているように見えるが、もともと難しいものを不可能なほど難しくして、
リファクタリングを抑制する(または見えない所で行わせる)傾向がある。
ソフトウェア開発は、変更することで得られる利益や変更しないことで生じるコストを
正確に割り出せるような、予測可能なプロセスではない。 -
リファクタリングがだめなのではなく
おまえらがやるからだめなのだ -
>>144
駄目コード(ウィルスみたいなもん)をばら撒いてから治療なんて無理だからねえ。 -
結局は客がデグレを笑って許してくれるかどうかな気がしてきた
-
でかくてモノリシックなシステムを複数のマイクロサービスにリファクタリングしたけど、
デグレなんて起きなかったな -
>>149
難解なコードを読み解いて修正前に正しく把握するのは難しいという主張? -
リファクタ厨はその時々でリファクタリングの定義を変えるので話にならない
正反対のことを平気でメリットとして主張してくる -
ある程度経過したコードは捨てろ。
リファクタなんぞせず。
さらにある程度経過したシステムは捨てろ。
リファクタなんぞせず。 -
>>151
実装は変えるけど、処理の内容は変えませんよw
処理の内容っていうのは、1から1000までの数を足すとかいうことです。
forループを使うとか、計算式を使うっていうのは
実装であって処理の内容じゃありません -
コーダーの時間が現実のリスクとのトレードオフに値するだろうか?
-
>>157
解読せずにリファクタリングすると酷いことになるだけだぞ? -
改修のためのリファクタリングって15年前ぐらいの考え方
今さら熱く語るようなトピックでもない -
>>159
> 解読せずにリファクタリングすると酷いことになるだけだぞ?
リファクタリングする時に解読しないなんて誰が言ったの?
そもそも解読が必要になってるのはリファクタリングしてなかったからなんだが、
まあそんなこと言ってもしょうがない。過去の話だ。
今手元にあるのは解読が必要なほど複雑なコード
リファクタリングをしないということは、複雑なコードをそのままに
さらに複雑にする行為。それをレビューしてもらったって、できるわけがない。
なにせ解読が必要なほど複雑なコードなんだから、
そして、せっかく時間を書けて解読しても、その解読をコードに反映させないなら
次回修正する時にまた時間がかかる。そして次回修正はそんなに先のことじゃないかもしれない
なぜなら複雑なコードをさらに複雑にしたのだから、デグレのリスクも高い
せっかく時間かけて解読したのだから、それをコードに反映(リファクタリング)させましょう。
読むのは時間かかるが、書くのは大して時間はかからない。
そうすれば、リファクタリングしなかった場合の時間がかかるという問題が解決できる。
何回も同じこと言ってるんだけどなw -
あと解読するときも、最初から最後まで想像して解読するよりも
簡単なところから一歩ずつやったほうがいいよ -
>>161
リファクタ病患者の闘病のために必要 -
>>164
君みたいに突っかかってるやつのためだよw -
まったり普通にまともなこと言っても誰も相手してくんないし
-
本質的に複雑なものはどうやったって複雑なので、考えるべきは複雑さをどこに押し込めるかだ
複雑な処理もリファクタリングすればシンプルになると信じてる奴は、まあ本質的には簡単なことしかやってないんだろう
例えば、SQLがわからないユーザーのために、DBにUIを提供するだけのCRUDアプリとか -
関数レベルのリファクタリングじゃ抜本的な設計改善にはならないからなぁ
やらないよりはやった方がいいけど、まぁ趣味の話だな -
>>167
> 例えば、SQLがわからないユーザーのために、DBにUIを提供するだけのCRUDアプリとか
あんたは複雑なことをしたいのかもしれないけど
仕事なんだから客が求めるものを作るべきでは?
客は本質的に複雑なものばかり、求めてるんですか?
客が求めてるものは簡単なものばかりですよ。 -
データベース設計なら、まんまデータベースリファクタリングって
本があるけどもう売ってないな -
>>169
本質的に簡単なことって、頑張れば誰にでもできるじゃん?
実際、キャリアの少ない若手プログラマだって、先輩やらの手助けを受けつつもちゃんと動くコードを書いて納品してるわけで
たかだか数年の経験しかないプログラマにでもやれなくはない程度の仕事を、ああだこうだいって多少整理された状態に
持っていくのがお前の言うリファクタリングでしょ?
まぁ誰かがやらなきゃいけない仕事なんだろうけど、それって汚いコードを書く奴の尻拭い以上のものではないし、
ドヤって語るほどのもんでもないように思うけどなー -
改修後に予定されているテストでカバーできる範囲でリファクタするというのは
ひとつの答えのようにおもえる
あとはリファクタしたほうが本当にましになってるのかという問題 -
>>172
> 本質的に簡単なことって、頑張れば誰にでもできるじゃん?
本質的に簡単なことって、頑張れば(=コストと時間をかければ)誰にでもできるよ?
でもそれじゃだめだよね
コストと時間がかかってるんだから -
リファクタじゃなくてリジェクト
-
関係ないけど安定した共通化部分から
関数抽出して使いまわしたいんだけど
やっていいもんじゃろか? -
>>173
将棋でも自分の指した手がいい手かどうかわからない人いるよね。
初心者?上級者?
マシになってるかどうかわからない?
将棋で言えばどっちかな?
自分の指した手が良いかどうかわからないってことは
恥ずかしいことだと思ったほうが良い。
まあ、初心者なら仕方ないけど、そういう人は
コードメトリクスを計測したら良いよ。
客観的に良いか悪いかを判断してくれる。 -
料理が下手な人は料理をしないほうが良い
-
人の問題なのか、技術の問題なのか
その区別ぐらいはできるだろうけどな
俺が運転すると事故るから
車はだめだみたいな。 -
>>182
二行目が繋がってない、つまらんからやり直して。 -
>>182
コピペしろって言ってる?
162 自分:仕様書無しさん[sage] 投稿日:2018/04/19(木) 21:57:46.81
>>159
> 解読せずにリファクタリングすると酷いことになるだけだぞ?
リファクタリングする時に解読しないなんて誰が言ったの?
そもそも解読が必要になってるのはリファクタリングしてなかったからなんだが、
まあそんなこと言ってもしょうがない。過去の話だ。
今手元にあるのは解読が必要なほど複雑なコード
リファクタリングをしないということは、複雑なコードをそのままに
さらに複雑にする行為。それをレビューしてもらったって、できるわけがない。
なにせ解読が必要なほど複雑なコードなんだから、
そして、せっかく時間を書けて解読しても、その解読をコードに反映させないなら
次回修正する時にまた時間がかかる。そして次回修正はそんなに先のことじゃないかもしれない
なぜなら複雑なコードをさらに複雑にしたのだから、デグレのリスクも高い
せっかく時間かけて解読したのだから、それをコードに反映(リファクタリング)させましょう。
読むのは時間かかるが、書くのは大して時間はかからない。
そうすれば、リファクタリングしなかった場合の時間がかかるという問題が解決できる。
何回も同じこと言ってるんだけどなw -
>>184
冗長な文章だな -
>>184
リファクタリングに時間がかかるって主張だよな? -
数字を入力するのにテンキー使う奴の地雷率は100%
-
ソフトウエアの問題は
どんなに技術的に見えようとも
人間の問題である
って偉い人が言ってた -
問題というのは人間の主観的認識なのだから
人間の問題でない問題などというものがあろうか? -
正確に言えばコードの修正を始めるまでの
コードを解析している時間だな
たった一行の修正なのにこんなにするんですか!?って
言われるぐらいの費用になるのは、"コードのタイピング"には
含まれない部分がたくさんある -
>>192
で、コードを解析する時間は
リファクタリング > 一部修正
だって理解できないの?
「リファクタリング終わったコードを修正する時間は短い」
という主張に誤りは無いが、
リファクタリングする時間を無視してどうする。 -
>>193
> で、コードを解析する時間は
解析する時間って言ったのに、お前
↓
> リファクタリング > 一部修正
修正する時間に話がすり替わってるじゃんw
解析する時間、すなわち複雑なコードをよんで
それがなにを意味しているか、どう書換えれば
正しく動くかを、考える時間は
リファクタリングしながら解析する時間 < 一部修正のために解析する時間
こうだからな。
ぐちゃぐちゃに絡み合った紐の束から、少しづつ結び目をときながら、
適切な一本を抜き出すのと、結び目をとかずに適切な一本だけを抜き出すの
どちらが簡単なのかを考えればわかるだろ
スパゲティコードとはよく言ったものだw -
あぁ、問題は全て、人間の主観的な問題!というのが間違いだよ、
客観的な問題も有るよっていったのが通じてないのか
話が分からんやつは困るな -
>>195
お前さん、開発したこと無いの?
一部の修正の為に必要な解析情報量と
リファクタリングに必要な解析情報量の
違いすらわからないなら
解析の仕方がおかしいか、
内容を十分理解せずにリファクタリングしてるって事。 -
>リファクタリングしながら解析する時間 < 一部修正のために解析する時間
個人的経験から断固として異議を唱えたい -
>>199
もしかしてリファクタリング、溜まってるんですか? -
>>196
リファクタ厨は毎回そんなもんだよ -
つーかさ、誰も100%納得がいくまで
リファクタリングしろなんていってないんだよ。
修正する所、どちらにしろテストが必要な所
関係がある所を、少しづつやればいい。
時間がかかるっていうのは、それはいつも手遅れの
コードばかりだって自覚有るからじゃねーの? -
でもメリットが欠片も見えないな
-
>>203
何度も書いた。コピペしかしないよ? -
リファクタリングをしたから具体的にどういうコードがどうなってそれでどのくらい得になるのかわからない
-
>>205
え?説明になってないじゃん -
>>206
そういう実例が書いてある本を紹介すればいいの? -
肝心のマーチン本からして何が得なのかよくわからん有様
-
本読んでもコードがどうなるかも分からんの?
-
理解がちょっとづつ歪んでいくな
リファクタでも同じように処理をちょっとずつゆがめて気が付かずにいるにちがいない -
>>209
いや、ここまでそんなレス1つも無いから -
https://blogs.yahoo....her4067/5819997.html
> 指導のポイント
> ここの指導は、難しい。なかなか理解されないのが、現状です。
>
> まずは、「等式の性質」を思い出させることが必要でしょう。
>
> 次に、「1次方程式の解法」も思い出させます。
>
> その後、1次方程式の解法と対比させながら、進めていきます。
>
> 「等式の変形」は、等式をその目的に応じて変形することの良さが理解できていないと、
> 何のためにするのかがわからないまま、機械的に進めてしまいます。
>
> 導入部分を大事にしたいですね。
まさにコレだな -
>>213
でも説明なってないと判断したレスがあるわけでしょう? -
いやリファクタ野郎のことね
-
お前のことだよw
-
>>214
そいつの説明が悪すぎる、良さってなんやねん
理解してもらえないのではない
自分が理解もせずに良いものだと思い込んでいるだけだ
本当に理解してたら必要性や可能になることを明確に説明できるはず -
本当に理解している本の作者が
十分以上に説明してるんだけどなぁ -
修正ってほんの数行程度なのに対して
リファクタリングってほぼ全域書き換えでしょ?
そりゃ影響範囲が違いすぎるよ -
読んだ上でいってんのか?
142 自分:仕様書無しさん[sage] 投稿日:2018/04/19(木) 00:37:19.05
>>141
重要なのは手遅れになる前にこまめにやることだよね
大規模リファクタリングなんてのはあってはだめ
リファクタリングだけのための作業なんて持っての他 -
大規模リファクタリングもありえるよ
こまめにって言ってるのは、せいぜい関数レベルのリファクタリングの話でしょ
まだそれぐらいしか任せてもらえない立場なのかもしれないが、リファクタリングってそれだけじゃないから -
じゃこう考えよう
リファクタリングは
テストコードのデバッグ -
もうコーディング=リファクタリングでええやん
-
>>222
あほすwww -
なんで、こんな派遣すら首になるようなリファクタバカを相手にしてるの?
基地外に何言っても無駄だよ。
相手の言葉を聞く能力がないからキチガイにして派遣すら首になってんだから。 -
あれ?
-
なぜだろう
-
どんなきれいなソースコードでも
プログラムから仕様を起こすのは大変
だから現場が仕様を忘れる前に、再開発をするのが正しい
つまり、リファクタリングなんぞ不要 -
やっぱ
日本人のソフト開発って
土木工事想定なのな -
日本は土建と同じ構造
世界は基本的に内製 -
CIAすらアマゾンに開発委託したってのに
-
>>233
リプレースとリファクタリングを混同するな -
>>238
区別の仕方は? -
リプレースって、普通の文脈だとシステム置き換えじゃねーの?
コード周りの文脈でリプレースなんて表現するのか? -
>大規模リファクタリングもありえるよ
大規模リファクタリングとは
リプレイスの事ではないかと言う主張だよ -
どうでもいい
-
リプレースってハードウェア更新でしょ?
5年ごとにハードウェアを最新にして、ついでにソフトウェアも新ハード新OS向けにテストしますよと
で、ほとんどはリビルドで済む話だけど
どさくさにまぎれてちょっと不具合修正しましょうとか機能追加して欲しいとなる
そこにリファクタリングする余地は確かに出てくる
本来必要ないのに修正するという意味ではいかにもリファクタリングだ -
>>243
ずいぶん狭い世界で生きてるんだね -
>>244
転職経験2桁だけど何かいいたいことある? -
大規模リファクタリングなんてあってはならないと言っちゃった以上、「俺のリファクタリング」より大規模なものは、
リプレースでもなんでもいいけどリファクタリング以外のなにかでないと困るんだもんね -
>>245
狭いね -
>>245
ただのクズやんwww -
> リプレースでもなんでもいいけどリファクタリング以外のなにかでないと困るんだもんね
普通にバージョンアップでは? -
>>245
www -
>>246
> 大規模リファクタリングなんてあってはならないと言っちゃった以上
お前意味分かってんのか?
大規模リファクタリングなんてあってはいけないっていうのは
許されるのは小規模(せいぜい中規模)リファクタリングまでで
リファクタリングだけを大規模にやってはいけないないってことなんだが? -
なんで大規模リファクタリングがあってはならないのかというと
リファクタリングは、機能変更の中に含まれる、
通常のソースコード変更時に、こまめに行うものだから
大規模リファクタリングが必要になるのは、こまめにリファクタリングしてないで
ソースコードをどんどん劣化させ、限界がきたから作り直す
(それもリファクタリングではない手法で)となってる場合が多い。
大規模リファクタリングのほとんどは単なる改修という意味になっていて
リファクタリングとなってない事が多い -
>>243
> 本来必要ないのに修正するという意味ではいかにもリファクタリングだ
何だその定義?
外部的振る舞いを変えずに理解や修正が簡単になるように
内部構造を改善することだけが「いかにもリファクタリング」って
言って良いんだよ。
必要ないのに修正するのがリファクタリングなんて定義初めて聞いたわw
どーこーの、定義ですか?ソースくださいw -
>>243
> で、ほとんどはリビルドで済む話だけど
> どさくさにまぎれてちょっと不具合修正しましょうとか
それは不具合修正であってリファクタリングではない
(外部的振る舞いが変わっている)
> 機能追加して欲しいとなる
それは機能追加であってリファクタリングではない
(外部的振る舞いが変わっている)
リファクタリングというのは、不具合修正や機能追加を行う際に
行うもので、不具合修正や機能追加でやる内容の一部
リファクタリング or 不具合修正 or 機能追加 ではない
不具合修正(リファクタリング含む) or 機能追加(リファクタリング含む)
である -
>>249
俺自身は発言の中でリプレースとはどういうものかとはなにも規定してませんが
まぁ外部的振る舞いという面で考えると、変わる場合もあれば変わらない場合もあるよね当然
で、たまたま外部的振る舞いが変わらなかったとしても、それをリファクタリングとは呼ばないよね -
>>252
中規模って具体的には? -
>>256
なぜ? -
> で、たまたま外部的振る舞いが変わらなかったとしても、それをリファクタリングとは呼ばないよね
そりゃそうだろうね。
リファクタリングは動きを変えないために、
特定の手順にしたがってソースコードを修正する
http://shop.ohmsha.c...detail/000000003881/
ここの詳細目次の、5章(は解説なので正確には6章)から
その手順がリファクタリング・カタログとしてまとめられてる。
これを読むと、このやり方なら動きが変わるわけないなってわかるはず。
そしてもう一つ重要なのはテスト。テストによって
外部的振る舞いが変わらないことを保証する
だから、たまたま外部的振る舞いが変わらないっていうのは
テストを実行してないんじゃないかと思われる
テストを実行して、外部的振る舞いが変わらないのを確認するのが
リファクタリングだから、修正のたびに何度も "意図的に" 外部的振る舞いが
変わってないことを確認してる(だからたまたまなんて思わない) -
意図的に外部的振る舞いが変わらない形で修正して
確認するのがリファクタリングだから、
たまたま動きが変わらないのは、単なるソースコードの変更ってことか
多いんだよな、単なるソースコードの変更をリファクタリングとか言ってるやつ -
プログラム全体に波及するような設計の変更を
こまめにやるためのテクニックも↓に書いてありますよ。
> http://shop.ohmsha.c...detail/000000003881/
> ここの詳細目次の、5章(は解説なので正確には6章)から
> その手順がリファクタリング・カタログとしてまとめられてる。
> これを読むと、このやり方なら動きが変わるわけないなってわかるはず。
えいやってやるしかないと思ってるのは
単にその力がないだけ -
テストしないでコード整理するのも時には必要
あまりにも悲惨なコードに短時間で多数の機能を追加しなきゃならん時とかね
多少のミスは割り切ってリファクタリングして機能追加して全体を手動テストして納品する
俺はこれをエクストリームリファクタリングと呼んでる
厳密なリファクタリング信者からすると気持ちわるいかもしれないが生産性は高い -
経験が少ないと、大規模リファクタリングの必要性に直面する状況が想像できないかもしれない
そういう場面も多々あるもんだけどね -
>>259
井の中の蛙と大海の大ウミガメの違いと言えばおわかりになるでしょうか -
>>267
× 経験が少ないと、大規模リファクタリングの必要性に直面する状況が想像できないかもしれない
○ 経験が少ないと、大規模 改修 の必要性に直面する状況が想像できないかもしれない
なんでリファクタリングじゃないものを
リファクタリングって呼ぶんですか?
リファクタリングを単なる改修の意味で使わないでください -
>>270
> あの基本書の内容を踏襲していない行為をリファクタリングとは呼びませんよ?
そうですね。基本書の内容を踏襲していない行為は
リファクタリングと呼んではいけません。
ただの改修と言いましょう -
なんで改修をリファクタリングって言いたいんだろう?
かっこつけたいのかな? -
言葉の定義とかつまらんからもっと益になる話しようぜぇ
グローバル変数(public static 変数も含む)を安全に排除するリファクタリングテクニックについて議論しよう
リファクタリングするときいつもこれだけはスマートに解決できない
リスクを背負って修正するしかなくなる -
大勃起リファクタリングと聞いて
-
>> 271
> なんでリファクタリングじゃないものを
> リファクタリングって呼ぶんですか?
お前にとっての「僕のリファクタリング」なんて知らんがな -
動脈から直接リファクタリングを投与した
-
最初に書いたテストがリファクタリングの前後で同様に動くとは限らない
壊れたテストを書き直すのもリファクタリングの一部 -
>>268
意味不明 -
>>278
大規模なものは改修で、小規模なものはリファクタリング? -
ここまで技術的な話題ゼロwwwマ板は素人しかいないってホントだったのか
-
>>281
なんでまた曲解するの?
2つの別々の話を混ぜないように
1. 大規模なものも小規模なものも外部的振る舞いが
変わらないようにちゃんとした手順で行って
テストで確認してるならリファクタリング
そうでないなら、単なる改修
2. 大規模リファクタリングが必要になるのは
普段からこまめにリファクタリングしてないから。
普段の改修の中でこまめにリファクタリングしていれば大規模なんて必要ない。
必要になるのは普段からリファクタリングしてなくて、
手遅れ状態になってる証拠。そういうのはあってはだめ -
リファクタリングは小まめに行うべきか?
ある程度たまってから行うべきか?
結論:リファクタリングが不要になるように書け! -
将来の改修や拡張の方向性がわからないのにんあことできるわけないだろ!
-
リファクタリングはソースの修正が必要だから行う
つまりソースの修正が必要なくなればいい
データベースでいうところの、UPDATEではなくINSERTになるようにすればいい
つまり、適切な粒度で関数(メソッド)を適切に作成すれば
リファクタリングは不要なのではないか?
例えば、1関数20行という教えはそういう意味も内包しているのではないか?
今までリファクタリングが必要になった場面を思い出して欲しい
やたら長い関数、スコープが不適切な変数、マジックナンバーやあり得ないelseの使い方などがほとんどではないだろうか?
本当にリファクタリングが必要な場面などほぼ無いはずである
もしリファクタリングが必要だというのであれば、それは清書を後回しにして適当に書きなぐることを優先した結果であり
そもそも「ソースを書いていない」わけである
漫画であればペン入れをしていない下書きやネームの状態、ガンプラでいえば接着剤を使わず仮組をした状態だ
もちろん、「正しく作る」ことよりも「とりあえず動く」ものを何よりも時間を優先して作ることが至上命題であることもあるだろう
それでも書道の名家は一発で何度でも美しい書体を生み出す
プログラマであっても一発で完全に美しいソースコードを生み出すスキルは必要なのではないだろうか?
以上のことから、「リファクタリングが不要になるように書け!」というのは正しいと言える -
>>280
意味明瞭 -
>>286
あー、いや、テストファーストでは
最初にテストコードを書いて、
テストに通る最低限のコードを書いて
そのあとリファクタリングして
完成だから
つまりあんたの言う「ソースを書いている」状態にするまでに
リファクタリングをする。
ちょっと勉強し直してきて -
もちろんテストファーストをしないならリファクタリングはしないってことじゃないよ。
先に実装しても、その後テストコードを書いて、それが通るのを維持しながら
ソースコードを読みやすくする。これもリファクタリング -
テストファーストはリファクタリングじゃないですよ
-
テストファーストはテストを先に書くってだけで
リファクタリングを内包するわけじゃないですよ -
テストファーストとリファクタリングは独立した概念です
-
http://www.itmedia.c...0602/24/news137.html
> 実行したテストコードが通らなければ『レッド』という状態になり、
> 実装コードを修正する。一方、テストが通った状態は『グリーン』と呼ぶ。
> ただしテストが通っても、可読性を考えてコードをきれいに整えることも多い。
> テストファーストではこの修正作業を『リファクタリング』と呼んでいる。
へー、このスレ勉強になるな -
個人的にそういうやり方をやってるってだけで
テストファーストとリファクタリングは根本的に異なり
完全に独立して成り立つものですよ -
テストファーストにリファクタリングは必要ありません
むしろテストファーストの目的を没却する悪手と言っていいでしょう -
>>287
意味不明 -
テストファーストでリファクタリングが必要になるなら
テストの粒度が間違っている証拠です、にわかがよくやります -
>>297
意味明瞭 -
>>299
ではテストファーストとリファクタリングを一緒に語るのをやめるべきです -
テストしないでリファクタリングおっかない
-
>>302
ググらないとわからないならお前がにわかです -
>>300
意味不明 -
>>305
意味明瞭 -
>>307
はいじゃないが -
>>308
バレてません、グーグルがなんでも知ってると思うな -
グーグルを神か何かだと思ってるんじゃなかろうかね
-
グーグルは知らないが、俺は知ってる。
情報の出どころは教えられないが
俺を信じてくれるよね? -
>>312
はい -
ママぐらいは信じてくれるんじゃねーの?w
-
>>306
意味不明 -
>>315
意味明瞭 -
>>316
意味不明 -
>>317
意味明瞭 -
リファクタリングの定義がないから仕方ない。
コードをいじってばかりのやつは、手段と目的が逆転している。 -
>>318
意味不明 -
>>320
意味明瞭 -
>>318
お前「意味明瞭」でググってみろwww -
>>321
意味不明 -
意味明瞭ってなんだよ
-
>>324
日本人じゃないんだろ -
>>323
意味明瞭 -
>>319
> コードをいじってばかりのやつは、手段と目的が逆転している。
いや、だからリファクタリングだけやるのは論外って言ってるんだが?
目的は機能追加などの改修で、その手段(の一つ)がリファクタリング
目的を実行する時にこまめにやる手段で、手段そのものが目的になってるような
リファクタリングだけの作業とか大規模リファクタリングはおかしいって
言ってるんだが? -
>>325
意味明瞭をわからない人間の方がブラジル人じゃないだろ -
>>324
意味がはっきりわかること -
>>326
意味不明 -
>>329
日本人なら普通そんな使い方しない -
>>328
ブラジル人ではないだろうな -
意味明瞭ワロタwww
-
>>256
で、これの理由は? -
>>335
ググってみろ -
>>336
はい知らないのな、お前日本人のこと1ミリも理解できてない -
>>335
「意味不明」と「意味明瞭」がちゃんと対照的に使われている例を教えてよ先生 -
>>338
キチガイおつ -
>>337
それ理由になってねーよ -
>>338
ググってみろ -
>>338
在日おつ -
荒らしが飽きたら続きのレスをお願いしますよ
-
>>335
うっわ -
ただ、普段からリファクタリングしてたら依頼がきたときに素早く対応できるよね
-
>>335
キチガイ -
>>335
統合失調症ですねわかります -
>>348
ソース -
>>348
対称と対照の違いもわからないカスがこちら -
>>348
世の中一般の使用例あげろよ、あるんならな -
>>353
やっぱ日本人じゃないな -
>>353
なぜ間違いなの? -
>>352
意味がはっきりわかるときに、意味明瞭と言います
これが一般的な使用例です
あなたはただの世間知らずというか無知です
無知な人間は自分が賢いと思いこむ傾向にあることが
認知心理学の研究の結果明らかになっています
あなたは自分が無知であるがゆえに意味明瞭という
自分が知らない言葉を使いこなしている僕に嫉妬しています
無知を自覚してください -
>>356
そう言われている具体的な例が未だに出てこない点でアレ -
>>356
だからその一般的に使用されている例を出してみろよ -
>>358
説明できていないwww -
>>358
これ統合失調症やろ -
>>358
対象も出てきたwww -
>>357
それでは具体的な例を上げます
意味がはっきりわかったときに
意味明瞭と言います
この上なく具体的で一般的な例を提示しました
あなたはそれでもわからないと言いはるでしょう
しかし、それは自分が知らない事柄が存在することを認められないだけです
無知であるがゆえにあなたのプライドはとても高いのです -
>>363
お前の頭の中を書き出してもそれは一般的とは言わない -
>>362
ただの書き間違いですよ、残念でしたね -
>>358
そら対象は違うやろ -
>>363
妄想おつ -
>>363
病院行きなさい -
>>366
ただの書き間違いに一生懸命レスしても意味ないですよ -
>>368
はい統合失調症 -
>>369
お前がODAに行けよ、万年引きこもり -
>>370
漢字の違いがミソなのにそれを間違える時点でもうねwww -
>>372
うっわ -
>>368
使用例 -
>>371
自分が医者だと錯覚してる人の方があれだと思います -
>>368
妄想と現実の区別がつかない状態がこれです -
>>376
それも妄想 -
>>376
医者なんて単語一言も出てきてないのに…これが統合失調症 -
>>373
打ち間違いなんてよくあることです
校正する人なんて居ないですしここ5chですし
正確さにこだわったところで1紋の得にもならないですし
一生懸命書き間違いを攻めようとしている様、とても滑稽です -
統合失調症というのはただの悪口であって
実際に病気かどうかは関係ないよ
世の中で統合失調症って言われてる人で実際に医師の診断受けた人ほとんどいないでしょ? -
>>381
よう統合失調症 -
>>381
キチガイとも言う -
>>387
変換ミスの話ではない -
>>385
よおキチガイ -
>>388
キチガイ -
>>388
妄想おつ -
>>387
漢字の違いが主張のポイントなのにその漢字を間違えるなんてありえない -
>>392
言うに事欠いてそれですかw -
>>393
対象の意味を理解してないからそんなことが起こる -
>>395
いうにことかいて -
>>394
間違いは誰にでもありますし
僕は自分のミスを素直に認めていますよ
変換ミスだって、それを一生懸命攻めようとするのは野暮だと思いますし
本来の議論を見失ってると思います
リファクタリングの話をしてましたよね -
>>395
じゃあ何? -
>>398
だからミスじゃねーよwww -
>>396
意味を理解していようといまいと変換ミスは起こるものですよ -
意味不明
-
>>402
だからそこじゃないってwww -
>>405
統合失調症やべーな -
>>406
統合失調症こっわ -
で、「意味明瞭」の一般的な使用例はいつになったら出てくるんだい?
-
>>410
お前の妄想じゃなくて、現実世界での使用例を -
>>410
ソース -
>>410
使用例のリンクをいくつか貼るだけなのに何言ってんのこいつ? -
まともな例を見つけられないんだろ
-
リファクタリング対象だな
対称でも対照でもなくて -
意味不明
-
>>411
意味がはっきりわかることってありますよね?
現実であなたはそういう経験ないんですか?
僕の妄想の話ではありません、現実にそういうことあるでしょう
そういうときに使います
意味明瞭と言って意味がとてもよくわかりましたと相手に伝えるのです -
>>417
リンク -
>>417
頑張ってググるんだ -
>>419
俺はそんな使用例知らないから貼れない -
>>419
存在しないものは貼れない -
>>423
死ね -
>>423
妄想から出られないんですね -
>>423
ないんですねわかります -
>>423
自己引用わろた -
>>421
知らないのなら覚えよう
知らないことを自覚したなら
自分の世界を広げよう
意味がはっきりわかるときに、意味明瞭と言います
そういう言葉があります
明瞭というのははっきりわかるという意味です
ゆえに意味明瞭というのは意味がはっきりわかるという意味です -
>>428
リンク -
>>428
ソース -
>>428
また妄想かよ -
>>428
長文はキチガイ -
意味不明
-
>>428
ソース -
>>427
国語辞典には日本書紀のリンクが載ってるが
日本書紀にはリンクなんて存在しないからな
だからといって日本書紀の日本語はデタラメだと言う人は居ないだろ
リンクというのはそもそもインターネットが普及してグーグルという
営利企業がそれによってランク付けをするように成ってから
重要視されるようになっただけで、それがなくても言葉っていうのは
作られていくし伝わっていくし話されていくんだよ、僕はその言葉の
大切さを少しでも伝えられたらと思います -
>>435
ソース -
>>435
オレオレ用語なんですね -
>>438
完全に一般的な言葉の使用例をいまだに出せないのはなぜ? -
>>439
どの十冊? -
日本書紀に載ってるんすか? オレオレ用語って
いやマジ、そういうの見たことないんでー、この人日本語苦手なのかなってマジそう思うっすー -
日本書紀www
-
糖質vs糖質
春の休日にふさわしいバトルやなww -
きっも
-
>>444
バトルになってなくね? -
>>447
すごーい君は国語辞典たくさん持ってるフレンズなんだね -
>>447
その十冊に「意味明瞭」は載ってるのかい? -
>>452
なぜ無理? -
意味明瞭と言った場合、意味が明瞭なんだなってわかるっしょ
漢字は表意文字だからそういうことが可能なんだよ
オレオレ用語も、オレオレ、用語という単語が合わさってできてるんだ
オレオレの意味と用語の意味がわかれば、オレオレ用語は辞書に載ってなくても
自分で定義した用語のことなんだなってわかるっしょ
オレオレ用語だという人間が意味明瞭をわかりませんというのは
完全に道理に反してる卑劣な行為だと知ってほしい -
>>453
誰もそれは否定してないやろ -
>>453
そらそうだwww -
>>454
著作権法的に違法行為にあたるからムリなんだ
僕は法律は守りたい、なぜならば法律は社会を成り立たせる
ためにあるものだし、一人ひとりがそれを尊重することによって
法律は成り立つし、それによって社会が成り立つから
法律に違反するというのは社会を否定することであるし
社会を否定して生きていけるほど僕は強くないから -
>>455
使用例 -
>>459
なぜ? -
>>459
誰も辞書の中身を写せなんて言ってなくね?持ってる辞書のパッケージ写すだけなら何が問題なの? -
>>457
使用例は
意味がはっきりわかったときに「意味明瞭だ」と言うんだよ
これが使用例です、普通というのはあなたの日常では使いませんという
意味ですよね、それはあなたの語彙が足りてないから使えてないだけで
このスレであなたは新たな語彙を獲得したんだから、是非使っていって欲しい
と僕は思うわけです -
>>447
正式名称教えておくれ -
>>463
ソース -
>>463
妄想おつ -
>>467
典型的な嘘やな -
>>467
この古臭さはどこから? -
意味不明
-
>>472
ソース -
本当はわかってるくせにわからない振りをしてるだけですよね
意味明瞭と言って本当にその言葉の意味がわからない人っていますか?
そんな人が本当に居るとしたら、その人はオレオレ用語の意味さえわかりませんよ
言葉は単語のつながりですし、単語の元々の意味が変わることなんてありません
元の単語の意味がつながるだけです
無知な人はわからないわからないと言っていれば良いので
議論において最強と言われることがありますが
そういうことで最強の名を手中に収めて満足できますか?
僕はできませんね、なぜならば無知なだけだからです
ものを知らないだけだからです、知らないことを武器に
偉そうに振る舞って相手を黙らせて何が嬉しいのでしょうか
自分の無知に気づかない本当のバカですよ -
>>474
ソース -
>>474
長文はキチガイ -
>>475
ソースが必要な部分あるか?w -
>>474
長文はキチガイ -
「意味明瞭」で検索しても、一件もヒットしないんだが?
-
>>475
ソース?
大東亜会議の真実: アジアの解放と独立を目指して - Google ブック検索結果
https://books.google...ooks?isbn=4569634958
> 東條も土壇場になると、日本の古歌、諺を引用する癖があり、いずれの場合も意味明瞭でない。
上司になってはいけない人たち - Google ブック検索結果
https://books.google...ooks?isbn=4569819184
>一塁離明瞭かつ意味明瞭な指示を心がけることによって、
>自分は何を知っていて何を知っていないかが明らかになる。
瀬戸内−道後殺人事件 - Google ブック検索結果
https://books.google...ooks?id=K_n6DAAAQBAJ
> 塔本によって、広島のどこかで麻薬漬けにされているという意味なんでしょうか」
> 「最初の書き込みは意味明瞭だが、問題はあとのほうだ」
経営理念 - TEC予備校
https://tec-yobiko.co.jp ? TECの取り組み
> つまり、あくまで言語明瞭・意味明瞭に徹した世界なのです。言うまでもなく、
> その後の人生において生徒達も、“言語明瞭・意味不明”な話術を身につけていく
> 可能性はありますが、私たちの教室ではその技術を教えることも利用を推奨することもありません。
> 「言語明瞭・意味明瞭」一点張りです。
出版物のご案内 - 株式会社ビジネスサポート
www.bizsupport.co.jp/book.html
> シート? 意味明瞭化シート
災害医療センター がん疼痛相談外来 患者情報提供書 - 独立行政法人 ...
www.nho-dmc.jp/treatment/department/pdf/gantoutuujyouhou2017.pdf
> コミュニケーション □ 0 意味明瞭・複雑な表現. □ 1 意味明瞭・単純な表現. -
意味不明
-
有名税は世相の反映、政治家のニックネーム
https://blog.goo.ne....f83d4bf09e77b5f65356
> 大平正芳:鈍牛、言語不明瞭・意味明瞭
https://blog.goo.ne....p/shima1946/m/201001
> 往年の総理・大平正芳さんは「言語不明瞭 意味明瞭」といわれたものでした。 -
>>319
> コードをいじってばかりのやつは、手段と目的が逆転している。
いや、だからリファクタリングだけやるのは論外って言ってるんだが?
目的は機能追加などの改修で、その手段(の一つ)がリファクタリング
目的を実行する時にこまめにやる手段で、手段そのものが目的になってるような
リファクタリングだけの作業とか大規模リファクタリングはおかしいって
言ってるんだが? -
結局さ、リファクタリングに文句言ってるように見えて、
実は自分らが普段やっている、いろんな問題が発生している
信頼性の低い行き当たりばったりの改修方法に
文句言ってるだけだろ?
リファクタリングをただの改修と勘違いして、
いつもの自分らを批判してるだけ -
取り敢えず、リファクタリングの意味は間違えんなよって言いたい。
リファクタリングは、利用者から見て全く振る舞い=挙動が変わらんやつのことだ。シンプルな定義じゃないか。
その性質上、リファクタリングのみで直接利益の上がる作業なんて(ほぼ)ないし、他の修正とセットになることが多い。が、ちゃんとリファクタリングとそれ以外は明確に別れる必要もある。
何も難しくない -
> が、ちゃんとリファクタリングとそれ以外は明確に別れる必要もある。
どういう意味で言ってるのか知らんが、これを読めばわかると思う
Martin Fowler氏によるリファクタリングのワークフロー
https://www.infoq.co...orkflows-refactoring
> 機能を追加するとき
> バグを修正するとき
> コードレビューと共に
> Fowler氏は「二つの帽子」の比喩を引きあわせて、プログラミングのタスクをこなす際の、
> 新しい機能の追加(ファンクションの帽子をかぶること)と、
> コードの品質向上(リファクタリングの帽子をかぶること)について説明している。
> そして、「プログラミング中は、頻繁に、ことによると数分毎に2つの帽子を
> 取り替えることになるだろう。しかし、一度にかぶれる帽子はどちらか1つだけだ。」と彼は述べている。
一つのタスクの中でこれらは混ざるが、同時に二つを行うことはない。
その意味で明確に分かれるといってるのならそれはそのとおり
もう少し具体的に言えば、ある機能実装のブランチがあって
そのブランチの中でこれらは混ざることはあるが、コミットは別れている -
> その性質上、リファクタリングのみで直接利益の上がる作業なんて(ほぼ)ないし、
それはコードのメンテナンス性や可読性を上げても
直接利益に上がらないと言ってるのと同じことで
他の業界で言えば、作業を効率化しても客の数が変わらければ
利益は上がらないと言ってるのと同じことだろう
たしかにそのとおりだが作業を効率化させないと
客の数を増やしたら忙しすぎて破綻するし、
余裕がなければ疲れるだろう。利益ではなく
作業効率に直接影響するのがリファクタリングなんだよ。 -
コストの前借りなんて話はしてない。
コードを改修する時の作業に含まれてるんだから
現在のコードの品質(理解しやすさ)によって
改修にどれくらい時間がかかるかは変わるのだから
見積もりには現在のコードの品質を反映させる必要がある。
これは改修でやらなければいけないことで、前借りではない -
こっちはリファクタリングコストは見積もらないけどな...。
他の作業と置き換えて効率化できるならOK
リファクタリングコストないじゃんとかわけわからないこと言わなきゃいい -
>>491
だから、それが間違いだと指摘してるのにまだ気付かないのか? -
リファクタリングしようがしまいが、
現状のコードが複雑なら解析に時間がかかるので、
あとはその解析結果をコードに反映して次回はもちろんのこと
今回のレビューやエンバグした時の修正を楽にするか
今のままより複雑にして大変にするかの違いなんだよな
そんなに複雑じゃないならリファクタリングも大したことない
すごく複雑なら、それリファクタリングしないと近い内に苦労するよってこと
こまめなリファクタリングが重要
100%完璧にしろなんて言ってない。修正する前よりも良くなっていればいい -
>>493
お前のその指摘が間違いなんだよw -
>>495
それが事実なら、指摘内容にちゃんと反論しろよ。。。 -
指摘内容に反論してるのが、>>491の内容でしょw
つ〜か「間違ってる」というだけじゃ
それは指摘じゃない。
地球が太陽の周りを回ってるのは間違いなんだ!
って言っても、それは指摘じゃないのと同じこと -
ちゃんと設計して作成、改修してるのにリファクタリングが必要になるのは何故?
なんかすでにおかしくね?
つまり、リファクタリングっていうのは設計が腐ってるから発生した不具合ってことだよね -
頭がばぐってる奴のこじつけ論にトラウマがある
最初から最後まで自分の主観から一歩も出ていない
立場をかさにきてるだけ
バットで頭なぐるか車でひき殺すかしたい -
そこからわからないのか?
客が仕様変更しないとでも思ってるのかな?
状況は刻々変わってるし、やってみなければわからないこともある
20年以上前のアプリがクラウド対応の設計していたらびっくりだわ
ソフトウェアは同じものを作ることはなく、はじめての道ばかりなんだから
軌道修正しながら進むしかないんだよ。
その軌道修正っていうのがリファクタリングでもある。 -
「リファクタリングは効率的」とは
いわないな。言葉の使い方が変だ
リファクタリングは効果的ならわかるが -
開発中のコードなのにテストコードのカバレッジを100%してリファクタリングするバカ
-
>>500
それは設計ミスの言い訳になるの? -
設計ミスなどない
-
>>503
テストコードのテスト? -
>>505
じゃあリファクタリングなんてやる必要ないじゃん -
後出しで変化した状況に対応するにはやったほうがいいこともある
ふくらんだクラスを分割して平行作業したり
後から出てきた概念と名前を調整したり
既存コードに手を入れなくても機能拡張できるようにしたり -
この程度のことを金にできない奴隷PGたち
よっぽど信頼されていないんだなw -
日本の場合はリファクタリングではなく、システムを作り替えるタイミングがリファクタリングにあたる。
外国人は新しいバグを埋め込んだり、仕様が変わってしまっても気にしない文化だから、日本人の感覚とは合わない。 -
>>510
テスト工数の削減が見込める場合はやるだろ -
リファクタ箇所が限定されてりゃ少量のテストでカバーできるだろ
-
>>514
> 日本の場合はリファクタリングではなく、システムを作り替えるタイミングがリファクタリングにあたる。
それは仕様がすべて文章化されていればな
実際はそんなこと不可能だし
変更した以上デグレは覚悟しなければならない -
>>514
一瞬システムリプレースの事だと勘違いするから、改修とか修正って単語使って欲しい
んで、何度も言うように、少なくともリファクタリングの時点でテストはされるし、バグがリファクタリング起因でない事は(メモリ起因やテスト自体の不備を除けば)確実だ、としておく。
なんで、外国人、日本人の下りは何かがおかしい -
仮にソースが仕様であるならば、バグは1つもないことになる
-
関数の中のロジックの一部を他の関数に切り出して、カバレッジ100%のユニットテストで元のテストの
外部的振る舞いが変わってないことを確認して満足してた奴がリファクタリング起因の障害を発生させてたわw -
テストコード自体の不備に関してはどうしようもないからな
ただそれに関しちゃ、手動テストでも同じことが言えるからどっちもどっち。 -
>>524
手動でもテストコードはあるんだが? -
リファクタリングしなければ不具合は発生しない
-
ここまで技術的な話題ゼロ
オワットルなジャップ -
ソフトウエアの問題は
それがどれほど技術的に見えようとも
結局は人間の問題である
と偉い人が言ってた -
コードがださいからリファクタしたい
気が滅入る -
結局リファクタの成否は
客を丸め込んでデグレのリスクを飲ませられるかにかかってる気がしてきた
バージョンアップとかスピードアップとかなんかこじつけて
リファクタでデグレたら原因も無理やりそこに倒す -
その前に正しい知識が必要だけどな。
リファクタリングは効果的、これを開発社側が
正しく理解してないと、現状のコードの問題を
リファクタリングのせいにしてしまう。 -
現状のコードの問題ってのは、例えば
仕様もテストコードもないんだが?とかそういうのなw -
>>534
正しい知識があったらリファクタがプログラマーが楽するためのものだってばれるじゃないか! -
開発中なのにユニットテストでプロダクションコードをガチガチに硬直化させるアホ
-
なにか問題でも?
開発側が楽になれば、それは顧客にとってメリットしかないよね? -
>>539
ユニットテストが壊れない程度のリファクタリング、つまり関数レベルのリファクタリングしかしない人にはわからないかも -
>>540
なんでユニットテストを修正してはいけないと思ってるんだ?
リファクタリングでユニットテスト修正するだろ。
というだけじゃ意味が分からんのだろうな
テストは修正しないって言ったじゃないですか!って言いそうw
リファクタリングはテストに通るように修正するのであって、
それさえ守れば、テスト自体の修正もする。
テストのリファクタリングなんて言葉もある。
説明がほしいか? -
まあここらへんだな。お前がユニットテストを壊さなきゃできないと
勘違いしているリファクタリングだ
新装版 リファクタリング 既存のコードを安全に改善する
http://shop.ohmsha.c...detail/000000003881/
第6章 メソッドの構成
メソッドの抽出
メソッドのインライン化
一時変数のインライン化
問い合せによる一時変数の置き換え
説明用変数の導入
一時変数の分離
パラメータへの代入の除去
メソッドオブジェクトによるメソッドの置き換え
アルゴリズムの取り替え
第7章 オブジェクト間での特性の移動
メソッドの移動
フィールドの移動
クラスの抽出
クラスのインライン化
委譲の隠蔽
仲介人の除去
外部メソッドの導入
局所的拡張の導入 -
まあ簡単に説明するとだな。
「実装クラス」があって
↑
「テストコード」がこの実装クラスを見ている時の
クラスを大きく書き換えるリファクタリングはな
「新しいクラス」を作って、
↑
「実装クラス」の処理を新しいクラスに移譲することで、
↑
「テストコード」から見るインターフェースを
まったく変えること無く、新しいクラスに移行するんだよ
そして「新しいクラス」のテストも書いて(もちろん一部は現在のテストコードを流用していい)
「実装クラス」を参照しているものを、新しいクラスを参照するように書き換え
どこからも使われなくなったら「実装クラス」をそのテストコードもろとも削除
というやり方が、>>542のリファクタリング本に書いている
だから「ユニットテストが壊れない程度のリファクタリング」と言われても
あー、分かってない人ねとしか思わないよ。 -
パズルやりたいなら一人でやってろや
仕事中に遊んでんじゃねえ -
画面見てキーボード打ってるとゲームして
遊んでるとか思うおっさんがいるらしいなw -
こんなパズルいらねーんだよ。
バーンと書き換えて、やっちゃって
ミスったらリファクタリングのせいにすればいいだろ
↑こういうやつがリファクタリングのせいにするわけかw
リファクタリングは変更しても問題ない手順で変更することで、
たんなる変更、いつもお前らがやってるような手抜きの
無計画な変更を言い換えた言葉ではありません -
結局テストコード削除してたらだめじゃん
やってる本人はよくても
他人はリファクタ前と後で変わってないことをどうやって確かめるんだ -
> 結局テストコード削除してたらだめじゃん
ちゃんとよめや。
移行して使われなくなってから削除するんだよ
お前みたいに、なにも考えずに削除してるんじゃねーよw
> 他人はリファクタ前と後で変わってないことをどうやって確かめるんだ
なんのためにコミットログがあると思ってんの?
あ、もしかしてそこから?
レベルの差が2段階、3段階ありそう・・・ -
>>548
勿体ぶらずにちょっと具体的な確認手続き言ってみなさい -
>>549
1. リファクタリングする前にはテストがある。
2. 足りなければ追加する
3. テストが通る
4. リファクタリングする(コードを書き換える)
5. リファクタリングしてもテストが通る
それだけじゃん。
まだ補足が必要?
1. さらにコードを書き換える
2. コードを書き換えるうちに(テスト以外で)使われないモジュールが登場する
3. テストは通るがプロダクションコードでは使われてない
4. 使われてないコードは安全に削除できる
いわれないとわからないかなあ?w -
コミットログは?w
-
>>541
だからさ、「ガチガチに硬直化」って丁寧に言ってやってんじゃん
そりゃリファクタリングの過程でテストも書き換えるよ
ていうか書き換えるに決まってんじゃんアホか
開発中の日々形を変えるコードに対してガチガチのテストを書くなって言ってんだけど、
わかんない?アホだからわかんないの?もうちょっと精進しろよアホ -
やっぱり話が通じないのは
レベルの差が4段階、5段階あるからか・・・ -
>>553
> だからさ、「ガチガチに硬直化」って丁寧に言ってやってんじゃん
ガチガチに硬直化ってなに?
ファイルをリードオンリーにでもすんのか?
変更できないコードなんてないはずだけど?
どうやるのかはしらないが、
お前がガチガチに硬直化させたのなら、
それはお前の責任だよね? -
リファクタの途中よりリファクタの前と後で結果が変わらないことを保証してほしいんだけど
-
スクラッチでシステム作ったことないんだろうか
リリース済みのコードとそれに対する改修の文脈でばかり語ってるところを見ると、そうなんだろうな -
>>556
> リファクタの途中よりリファクタの前と後で結果が変わらないことを保証してほしいんだけど
だからリファクタの前=コミットログの修正前
リファクタの後=コミットログの修正後だろ?
リファクタの前のテストコードを変更せずに
リファクタの後でもそのまま通れば
変わってないことが証明できる。
あー、これ↓を言っておかないとダメなんだろうなw
結果が変わってないと証明された後、
使われてないと判明したコードは削除できる -
>>558
テストはクラスやメソッドの仕様であってシステムの仕様ではありませんが -
おまいがリファクタして部分的な仕様を変えまくってんじゃん
そのうえで全体的な仕様が変わってないことを保証しないといけないわけだが -
>>559
> リファクタ本に書かれてる話じゃなくてごめんね
じゃあどこに書かれてる話なの?
お前の想像の世界の話はいらないからw
どうも「自分がくそったれなやり方してます。
くそったれなやり方には使えないんですけど?」
って言ってるようにしか見えない。
お前のくそったれなやり方の問題だろとしか -
偉そうな口をきいてるわりに視野が狭い
-
>>562
> おまいがリファクタして部分的な仕様を変えまくってんじゃん
変えてないよ?
日々テスト変えなきゃならないどこかの誰かさんと違って、
テストは基本安定している。
テストコードを変えない状態でコードを書き換えてるので
リファクタしても仕様はまったく変わらない -
日々コードの形が変わっていくのをイメージできない初心者はIDDDでも読んでみたらー
-
もしかしてプライベートメソッドのテストをしてるとかかな?w
それユニットテストじゃない
ユニットテストはモジュールのインターフェースのテストだから
変わりまくることはあり得ない。
もしモジュールのインターフェースという概念がなくて、
単に長いから関数にまとめましたみたいな、
なんでかしらないけど、この関数テストしづらいです。
なんてことをしてるのならそいつの問題 -
>>566
でも今まさにそれを変えるときの話してたよな? -
具体的にどんなコードとどんなテストをかいて
ガチガチに固まって、メンテナンスが大変です。
なんて状態になってるのか書いてみたら良いよ。
想像の世界の話じゃないなら書けるはず -
>>569
外から見た時の動きが変わってなければ良い。
そして外から見た時の動きが変わってないが、
(テストコード以外で)使われていないメソッドを作ることは可能
そしたら使われてないコードは安全に消せる。
こういう話をしてます。 -
低い階層がなんののか知らんが、
【現在のクラス】をリファクタリングするとき
「新しいクラス」
↑
【現在のクラス】←「その他のクラス」←「その他のクラスのテストコード」
↑
「現在のクラスのテストコード」
こういう階層の時、「現在のクラスのテストコード」はそのままに、
「新しいクラス」に処理を移動していくことはできるだろ?
(移動だけじゃなくて新しく作ってもいいけど)
リファクタリングするのは【現在のクラス】だけ
「現在のクラスのテストコード」は書き換えない
【現在のクラス】を利用している「その他のクラス」も書き換えない
(当然「その他のクラスのテストコード」も)
コードの修正をすすめると【現在のクラス】は「新しいクラス」への移譲コードだけになる。
また「その他のクラス」は「新しいクラス」を参照するようにする。
「その他のクラスのテストコード」の修正はしないから、変わってないことは保証できる。
最終的に【現在のクラス】を「その他のクラス」は参照することはなくなる。
そして【現在のクラス】は「現在のクラスのテストコード」以外からは
どこからも使われてないクラスになるので安全に削除できる
これが関数レベルではない、クラスレベルのリファクタリングのやり方
それは>>542とかの本に書いてある基本だから、ほんと勉強してくれとしか -
一応言っておくけど、これは、クラス根本的に
変えてしまうほどのリファクタリングの手順
メソッド一個だけとかならここまでやる必要はない。
その場合は、メソッド単体で、他のメソッドの委譲したりして
該当のメソッドを使われてない状態にしてから削除する -
下位クラスの結果も検証するように緻密に単体テスト作られてればいいが
ユニットテストするときなんて下位クラスはモックになってること多い
その場合参照するクラス変わったらモック設定書き換えにゃならん -
既にあるロジックをどこか別の場所に移動する以外にネタねえのかよw
-
>>547
あほ -
>>561
テストにもいろんなレベルがあることに考えが至らない奴隷コーダー -
結局単体テストは個人のテスト証跡以上の意味はないのだろうか
-
あるよ
-
だから
リファクタリングなんぞ不要
数年後には業務変化の見直しと現在業務の確認のために、システムをまるごと作り直すから -
出社めんどくせえ
-
>>581
ダメ管理者はよくそういう妄想に浸りたがるよなあ。 -
定期的なリプレースでは使う言語が変わる可能性が結構高い確率である
こまめにリファクタリングしたら大損だよ -
>>584
こまめにリファクタリングってことは、リファクタリング後の修正がこまめに発生してるんだから、そこでリファクタリングコストの半分以上は回収できてると思うの -
常に機能追加や改修しているようなソフトウェアであればリファクタリングは有効
一度作ったらあまり改修しないようなソフトウェアであればリファクタリングのデメリットが目立つ
つまり、アマゾンドットコムみたいに常に機能追加や改修が行われる投資対象であればリファクタリングで機動力を確保するのは理にかなってる
逆に家電に代表されるような組み込み系、もしくは制御系のような、機能追加や改修の頻度が低いものであればリファクタリングする意味は相対的に小さい
お金をつぎ込めばつぎ込むほどリターンがあるのであれば、CIの中にリファクタリングを入れてしまえばいいだろう
リファクタリングの結果がすぐに出やすく、デメリットであるリファクタリング起因の不具合についても
改修が多ければ多いほど、リファクタリング起因の不具合減産と相殺されるからだ
リファクタリングの問題でやはり難しいのは改修頻度が低く失敗が許されない分野だ
これらの分野は製造工数とテスト工数の比でいうとテスト工数の割合が大きい
つまり、リファクタリングによって過大なテスト工数が必要となってしまい、リファクタリングのメリットが吹き飛んでしまう
しかしながら動いている箇所はいじらない方針もいつまでも続くわけじゃない
いつかのタイミングで全面リプレースするか、リファクタリング(もはや資料もなく知っている人もいない)を行うことになる -
リファクタリングによって設計が改善されたと思ってるのはやった本人だけとかありがち
-
>>583
うちもそうだよ?
課レベルのシステム、部レベルのシステム、社レベルのシステム
があって、それぞれの長が変わったらシステムの仕様変更が最初の長の仕事になってる。
システムの見直しと再設計って、その部署の現在運用を把握するのに最適という理由で。 -
それはそのシステムで業務効率化はされてるんか...?
もはやマニュアルってレベルだろそれ
エンジニアしか理解できない仕事のマニュアル。 -
まず業務があってシステムを作るべきか ※日本風
システムのあわせて業務を再構築するべきか ※欧米風
どっちがいいんだろうね -
>>591
国内で内製やった7&iホールディングスが大コケしたけど -
>>592
セブンミール時代からたまに使ってるけど、たしかに使いづらくなった。
けど、冷静に考えると。今のレベルのシステムを一応作れたなら。元々のシステムも実装できる。
運用方針を新システム化した際に「顧客のニーズ」を取り入れるために店長に聞いたら。
「店長のニーズ」を取り入れちゃったんだろうwww
ただ、「店長のニーズ」も旧システムで現実に起こってる問題の結果で、
さらに、現在、店舗自体が人手不足に陥ってるから配達要員、商品供給ライン等で
旧システムであっても実際には様々な遅延等々があったんだろう。
おそらく、システムの使いづらさの原因は、まさかのアナログな「現場の配達に要する人手不足」だと思うわw -
リリース前のコードまで
ガチガチに変更管理してる
現場ってあんの? -
>>595
リリース前も後も管理するのは当たり前 -
>>597
お前さんが試験したこと無いのはよく分かった -
ボタン押すだけとか前時代的すぎるwww
今はもうpushするだけの時代だぞ爺さん -
>>600
変更中で清書する前のコードならpushしねえよ -
>>586
> 常に機能追加や改修しているようなソフトウェアであればリファクタリングは有効
> 一度作ったらあまり改修しないようなソフトウェアであればリファクタリングのデメリットが目立つ
やっぱりまだ勘違いしてる。
リファクタリングが、一度作った後に行うものだと、まだ勘違いしている。
一度目であっても、作ってる最中に、こまめにリファクタリングしていくもの
という考えがどうしても理解できないらしい
それとも詳細設計というものがあって、そこに最初から
すべてのクラス、関数、引数がプライベートのものまで
全部網羅されてるとでもいうのか? -
>>601
> 変更中で清書する前のコードならpushしねえよ
書きかけではなく本当に清書?
清書前でも理解しにくいだけで動くが、
理解しやすくために清書するってこと?
ならそれはリファクタリングに相当するね
もちろんちゃんとした手順でやらないといけないが -
>>587
> リファクタリングによって設計が改善されたと思ってるのはやった本人だけとかありがち
そういうレベルの人たちしかいないなら、
コードメトリクスを測定するツールで客観的に
判断したほうがよいだろう。 -
>>605
ツールで測定できるレベル(抽象度的な意味で)じゃ設計の善し悪しは測れないんで -
>>586
> リファクタリングの問題でやはり難しいのは改修頻度が低く失敗が許されない分野だ
そういう分野で、循環的複雑度100オーバーの関数1000個のソフトウェアを
修正させたらどんなにテストしていたとしても修正のたびにバグ入れると思うよ。
どうやってこの問題を解決する?
何十回、何百回もテストするかい?それこそ過大なテスト工数だよね。
テストを一回やったらバグが全て見つかり一回の修正で全部直る。
修正後の再テストはバグが見つかった所だけでOK。とか思ってないか?
参考 循環的複雑度は
50以上でテスト不可能 バグ混入確率70%
75以上でいかなる変更も誤修正を生む バグ混入確率98%
と言われている。10以下にするのが普通
とここまで書いて思ったが、どんなコードが良いコードなのかわからない人は
実際にダメなコードの複雑度がどれくらいなのか具体的な数値を示さないと
わからないだろうな。どこかにサンプルないだろうか -
>>607
> ツールで測定できるレベル(抽象度的な意味で)じゃ設計の善し悪しは測れないんで
だから自分たちで、判断できないレベルの人ばっかりなところだって、
ツールは測定するため物で、ちゃんと測定できますってw
完璧なものはわからないかもしれないけど、少なくともツールで
大きくだめだって言われた所は、マジでだめ -
リファクタリングとかやっちゃうお前らだと、給料っていくらぐらい?
-
>>614
証拠見せて -
トップクラスの企業ってGoogleとかじゃないの?
-
自分の書いたコードが汚すぎて死ぬ
-
>>615
転職 -
>>618
今より落ちるのはちょっとw -
>>614
(奴隷度)トップクラス -
トップクラスの企業って言葉で連想するのはメーカー子会社の協力企業あたりだな
GoogleやAmazonを表現するのにトップクラスの企業って言葉じゃ足りない -
株式会社トップクラス
-
FAMGAは企業を超えたよくわからないシステム
-
>>613
手取り35 -
組織と自分の履歴サーバを別けている
日本のリファクタリングあるある -
人気グループ「TOKIO」の山口達也メンバーが、自宅マンションの部屋で女子高校生に無理やりキスをするなどの行為をしたとして、警視庁は強制わいせつの疑いで書類送検しました。
全文は以下
https://www3.nhk.or....k10011417181000.html -
>>626
分けるメリットがなんかあるの? -
レビューしないのかな?
-
ぬおーん
-
コード読めないからレビューできないんじゃね?w
-
ここで一部の人に衝撃的な事実を言っておきますね。
レビューができるコードっていうのは1関数あたりだいたい10〜20行程度までです。
50行なんて超えたらぜったいにレビューできません。
人の能力の問題じゃなくて、レビューできないコードです。
解析が必要になったら、それはレビューとは言えません。
だから1関数当たり10〜20行になっていなければいけません。
これを超えるものがざらにあるようなプロジェクトは失格です -
10行って引数の多いメソッドの前準備してるだけで終わるレベル
俺は200行程度まで許容範囲 -
レビューは通過儀礼だから
コードなんて誰も見てない
見てるのは担当者の活舌 -
Web業務なら少々長くても大丈夫
帳票とかDBとかでっかい構造体にいっこずつ値入れてるだけだから
長くても込み入ってないことおおい
組み込みとかどうだろう -
関数の行数よりネストの深さとスコープの方が大事
-
>>636
> コードなんて誰も見てない
だろ?
長いコードは読まない。
レビューできないから
>>637
ウェブ系でもありえないな。
ほんとね、一人前のプログラマか、ゴミかどうかは
1関数10〜20が普通って聞いて信じられるかどうかでわかるよ
比較的大規模なウェブアプリの例。みてみろ。コレがレビュー可能なコードってもんだ
https://github.com/g...abhq/tree/master/app
50行とか超えてるコードばかり見てる人、↑これみれば、
50行なんて長いコードはレビューできないのが当たり前ってわかるよ。 -
小さなクラスやメソッドにするのはいいことだけど、適切な命名ができるのが大前提
英語が苦手な奴はデタラメな名前をつけるから余計わかりづらくなる
形だけ小さくして満足してるバカが多い -
どうせ携帯のちっこい画面用だろ
-
リファクタリングするとバグがーとか言ってるのは
おそらく50行とか平気で超えてるような所だろう
レベルに大きな差があるから話が通じない。
1関数たったのこれだけしかないから、
この関数が動くかどうかテストするのは簡単なんだ -
コードの優劣は、そのコードが生み出す経済的価値によって決まる
ただ綺麗なコードより汚くても利益を生むコードの方が価値がある
大して価値のないコードを一生懸命リファクタリングしてる奴には、そんなゴミ捨てて意味のあるコードを書けと言いたいね -
はい、言い訳きたーw
-
英検1級レベルに満たない奴はローマ字でコードを書け
-
くり返し言うが、俺が言いたいのは、技術力高い所は
本当にこれぐらいのレベルなんだよ、
ありえない話はしていない。その証拠 -
>>646
そんなに探してない
DBとかHTMLに値入れてるとことか長くなりがちなとこ探したけどなかったんで
helperっていう割とやばめの文字列が目に入ったんで開いたらあった
やっぱり扱うものによる
一番下のやつ50行超えてるぞアウトだアウトだ
https://github.com/g...n_settings_helper.rb -
>>650
他人のふんどし -
>>651
そもそもrubyがカス -
>>640
でもよ
それって設計書書くの大変じゃない?
200行のメソッドって10個〜20個になんだろ?
クラス図だって10倍か20倍にデカくなんだぞ
トレードオフの問題ちゃうんか?
たくさん仕事してるようで大半がメソッド名決めてるだけみたいな -
>>652
いや、自分も同じレベルだけど、自分のコードは出せないだろう?
オープンソースで参考にできるもの。
あの関数の短さで大規模なエンタープライズ向けの開発ツールが作れる。
そういう事実がそこにある。 -
>>656
コードが設計書 -
>>656
> それって設計書書くの大変じゃない?
設計書書くの大変なんだよ?
ようするに設計書はこのぐらいのものを作って
一人前ってことなんだよ。
普段どれだけ適当な仕事しているかってのを
わかってほしい。それだけのレベルの差がある -
>>657
1関数100行でも作れるよ -
メソッドの仕様まで設計書に起こす奴って脳死しすぎやろw
-
設計書書くの大変かどうかは知らんが
事実としてあのコードは存在する。
あのコードを作るにはどうすればいいかを考えたほうが良い -
>>663
その分、設計してる人の時間をとるんだろ? -
>>667ってなんか発想がおかしくね?
客から作業代をどうやってむしり取ろうかって発想になってる。 -
>>664
Jenkinsは至るところで使われてるけど50行以上のメソッドなんていくらでもある事実 -
まあJavaだしね。
-
Rubyは結構変な構文で圧縮してる
-
>>659
原点回帰が必要だよお前
人間が見てわかりやすい範囲を明らかに逸脱してるだろ
概算で役に立たない
2000行規模のコードでメソッド200個近く作るんだろ
どうやって表現すんの?お前
なんもドキュメント作らない前提じゃないと成り立たない
つっかえねーw -
われながら途中で投げ出してわかるからと適当に書いた設計書がやばい
自分はわかるがテスターが
どうしよ -
面白いのを見つけてきた
【読者参加型企画】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...oogle-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行にできるが
そうでない素人だと頑張らないと達成できない
そう、素人 -
>>685
リンク先読めば? -
>>688
わかんないままドヤ顔で引用しちゃったんだな -
技術的難易度が低いただのCRUDアプリみたいなものしか作れない人は、いかに綺麗にコードを書くかとか
そういう話題でしか技術っぽい話ができないから、ここぞとばかりに語るよな -
>>683
それって20行換算じゃん
最大行で見積もるなんて心苦しいから10行にしてやったんじゃん
2000行でメソッドが200個できて
20000行で2000個だ
100000行で10000個じゃん
この間やったプロジェクトのコードがそんなもんだったけど
メソッド10000個とか明らかに
茶碗が小さすぎる
おちょこに飯もってるみたいにアンバランスだろ -
そもそも設計書からしてそんなに大量のメソッド作成するように書いてるのか?
設計書に書いた処理とソースの処理を一致させないと説明が面倒だろ -
>>691
> 100000行で10000個じゃん
数を大きくして、多く見せたいようだけど無駄w
10万行だろ? 1ファイル(=1クラス相当)が200行ぐらいなので
500個もファイルがある。メソッド1万個は1ファイル(クラス)20個のメソッド
これは普通の規模だ
そもそもお前、ちゃんとモジュール化できてないだろ?
役割ごとにちゃんとファイル(クラス)分けろ -
>>695
> そもそも設計書からしてそんなに大量のメソッド作成するように書いてるのか?
実際にコードはそれぐらいになるんだから、
それに相当するメソッドは誰が作り出してるかってことだよ。
設計書にこの程度の数のメソッドが書いてないなら、
その設計書通りに作ると破綻するということを意味する
きちんとレビューしてテストするためには、
実際にそれだけの小ささのメソッドでなければいけないのだからね -
実際にコードを書いてる人は、これぐらいの数の関数は作ってるんだよね。
それにたいして、こんなに大量の関数なんて設計できない。
予め想定することなんてできない
っていうのなら、そういうことだよ。
お前らがやってる設計とやらの仕事は、
現場には通用しない仕事だということ
Sヨとか言われてバカにされてるじゃん。
それが事実だってことだよ。 -
さてリファクタリングの話に戻すぞ?
これが実際の優れた開発の現場だから、最初に全部設計して
最初に考えた関数だけで作るなんて不可能なわけさ
関数の数が多すぎる!って叫んでるアイツ見りゃわかるだろ?
でも実際のコードはそれだけの数の関数がある
この差をどうやって埋めるよ?
最初は設計に書いたとおりの形から始める
実装が進んで次第にコードが膨れ上がっていく
テストできなくなってしまうから、再設計が必要
といっても大きなものじゃない。こまめにやる。
これが開発の中に自然に含まれているリファクタリングだ。
リファクタリングは開発に含まれるもので
別の作業として分離してやるもんじゃない。 -
糞コードいつか破綻するのはわかってるのに
そのまま売りまっくて最終的には極悪に肥大したクソコードのリファクタリングしろという
まずその事実を知っていて売り続けた開発部長やら上層の誰かに責任取らせろやハゲが -
ん?やめてないよ。開発の中に改修は含まれている
改修をしない開発会社なんてないんだから -
はいはいw
-
>>695
ソースレベルの設計書なんて書くわけないやろ -
ソースレベルの設計書とか言ってる奴はまだマ歴1ヶ月なんだから優しくしてやれ
-
つまり
1. テスト可能なメソッドは十分短いものである
2. 設計でそれらを全て洗い出すのは無理
ってことなんだよね
これは重要な大前提では? -
ソースレベルの設計書ってなに?詳細設計よりもっと細かいやつ?
アセンブラ時代のフローチャートはほぼソースとイコールだったけど -
破綻はしないが非効率的すぎるわな
-
設計で関数を洗い出すのはいいんじゃねーの?
ソースは完全にプログラマに任せるスタイルなのか、ある程度は監視するスタイルなのかの差だと思うよ
個人の技量に任せたら関数の切り出しするやつとしないやつで差がですぎてソースが混乱する -
そこまで細かく詰めるならその場でコードまで書いてコンパイルと簡単なユニットテスト通しちゃえよ
少なくともインターフェースとスタブは書けるだろ -
>>712
それをやることになんの意味が? -
>>713
無駄な工数を省いた上に戻りも減らせる -
>>712
コードを書かなきゃ必要な関数を洗い出すこともできないのは最近の風潮だよな
大規模なチームで設計するときにも、
各自が関数洗い出したのを持ちよって全体最適化とかしてないだろ?
普及している手法にはメリットやデメリットがあるのは当たり前
色々な開発手法知らないと最善策見つけられんだろ -
昔に比べりゃ関数作るのはアホみたいに簡単になった
CollectionやらThreadやらStringやら
大体コアになるもんはありものが揃ってるし -
設計書ってパンチカード時代の名残だぞ
そんなものを未だに盲信してるなんて滑稽だ -
デシジョンテーブルは書くやろ?
-
>>718
そうやってすぐコード以外のなにかに逃げようとすんなよSEさんよ -
そらDBからデータを取り出してブラウザに返すだけのアプリに設計書なんていらんわな
-
二人以上で作業するなら電卓アプリでも設計書いるわ
-
>>720
メモリからデータを取り出して画面に表示するだけのアプリばかりでは? -
DBからデータを取り出してブラウザに返す仕事なんて、専門教育を受けてない文系でもこなしてるという事実
-
リファクタリングの話が盛り上がるのは、文系でも参加できるから
-
文系が参加って、技術的な話での参加じゃないじゃんw
-
設計書なんてコードから生成するもんだろが
-
>>727
そのコードを最初に、どうやって書く訳? -
エディタ開いてタイプしろよ
そんなことも言われなきゃわからん? -
>>729
お子ちゃま? -
>>728
それ辿るとBIOSまで行くぞいいのか -
すでに存在するものまで遡らなくていい
-
リファクタできない無能には9連休なんてないんだろうなww
-
明日からリファクタリングのために9連勤です
この工数がなければ休めたのに -
ほらな。なんどもリファクタリング単体の作業は間違ってる。
ふつうの開発(改修含む)に含まれているものだ。
と言ってるのに、やっぱり理解できていない
完全に間違いが身にしみてるんだろうな -
すでに運用中のシステムの保守開発に途中参画して、リファクタリング単体の仕事をやることもありますね。
視野が狭い方には思いもよらないでしょうけど。 -
>>731
howだけじゃなく、why for why考えれるかが分岐点。 -
なんで?
-
純粋なリファクタリング(笑)
どこ出典ですかねそれ
お前の最強の純粋なリファクタリングみしてみろよw -
だからどんなもんか試しにみしてみろって言われてんじゃん
-
>>731
宇宙誕生まで調べるだろフツー -
改修準備
調査分析
自動テスト作成
負債返済
利便性向上
少なくともこの5種のリファクタリングを日常的に行う
改修前のリファクタリングしか知らないならまだまだだね -
改修前のリファクタリングは純粋なリファクタリングなんだが爺さんにはわからないかな
-
機能追加とかデバッグの時に
リファクタリングしちゃだめよ -
帽子をかぶりなおす
-
ヅラ
-
事実の再構築、それが本来の純粋なリファクタ
たとえばガス室はなかったとか
強制連行でなく移民だとか
そういうことを言うとリファクタだと侮蔑的レッテルを張られ非難された
あんまり面倒なのでえらい人が別の意味で単語を上書きすることにした
そのあおりをくらってIT従事者は楽しいが不毛な作業に邁進している -
KAIZAN活動やってたぜ
-
少し話が変わるが、実装と単体テス
ト(自動化)って同時に行って、工数も含めるよな?
自動化するのに別途工数くださいって言われるんだが・・・
こっちとしてはバッファ含んでも余裕ある日数でお願いしているのに
工数が無いって言うくせに遅刻は半分くらいするし、たばこプカプカで手を動かさない
首切りたい。 -
現場のマネジメント次第でしょ
それどうするか決めるのおまえの仕事じゃねーか
そいつは工数が必要だって言ってるんだからいるんだろ
いくらコーディングだけなら余裕のある日数っつったって
最初お前の頭になかったんなら、全体的な工数がどうなるかは見直すしかない
行けるはずだから頑張れっていうかちょっと工数伸ばすか管理見直すか決断しろ
おまえがやるべきことだ -
ちなみに自分とこの現場の経験でいうと
単体テスト仕様書はコーディングの1.5倍、
ユニットテストは3倍ぐらい工数かかります
ご愁傷様 -
そんな3倍もかからんよ
せいぜい5割り増し程度
自動テスト書くとエビ撮りはもちろん実験やデバッグが爆速になるから総合するとむしろ工数が減る -
でもな
その仕様じゃ動かんのよ -
>>755
まあキチンとやってればそんなもんだね。
ただし、禄に設計されてない(抜け漏れ、重複、矛盾多数)プロジェクトだと、テスト時に発覚ーーー>設計修正工数認めない!ーーー>テストケースが歪なのを何とかしようと無駄な作業、で数倍に膨らんだりするが。 -
>>757
それテストじゃなくて別の問題だよね -
>>757
テストしっかり書いたから抜け漏れに気が付いた
気がついてよかったじゃん
悪いのは静的解析もテストもしないで設計して抜け漏れ発生させた設計チームだろ?
だから設計書は役立たずのゴミなんだよな -
>こっちとしてはバッファ含んでも余裕ある日数でお願いしているのに
この言い草にやばいSEのにおいがしてトラウマが刺激された
自分の作業の考慮抜けを無視したり、いらない仕事山ほど詰め込んだ挙句に結果工期伸びてるのに
この認識を修正できずに
「案だけ余裕あったのに何で間に合わないの?」みたいなこと言ってくる奴の多いこと… -
まだ人月とか信じてる奴いるんだね
-
バカ10人の首切ってスーパープログラマを1人雇ったほうが生産性高い
-
バカ10人集めたらできるような仕事の生産性をちょぴりあげるために
スーパープログラマを投入されてたまるか -
カスみたいなCRUDを高速で量産するスーパープログラマとはw
-
スーパープログラマにカスPGの仕事をやらせたらめんどくさがって自動化しちゃうから実質10倍どころじゃない
万倍以上の差が出る -
まあでも俺がクソプログラムを100量産してる間に10リファクタリングしたとこで意味をなさないんだがなw
-
そのクソプログラム100個相当のものを
プログラム10個で作り上げるのがスーパープログラマ
当然リファクタリングした結果もこうなる -
そして文の意味を理解できないアホが俺様リファクタリングしてむちゃくちゃにして動かなくするとw
-
お前らが100000人いてもlinuxは作れなかった
つまりそういうこと -
作れるのでは?
-
作る以前に、思いつかなかった
それが重要だ -
付加価値ゼロのコードを
何万行書こうとも
付加価値ゼロだからね -
汚いコードは価値で言えばマイナス
-
できなかった場合:奴隷がバカすぎるので金出さない
できた場合:こんなバカでもできる仕事に金出さない
奴隷がバカだから金出さないのは大前提 -
>>775
おまえも単価安い十天王の一角やんか -
お前ら自分のことは棚にあげてるけど、スーパープログラマから見たらバカとお前らのレベル差なんて誤差みたいなもんやろ
-
誤差ちゃうわw
クッキリとバカやでおまえらなんかw -
給与が低いと思ったらサボる
プロジェクトが失敗したって高い給与貰ってるPMさんが責任取ってくれる
プログラマみんなでこれを徹底する
これしかないんだよいい加減理解しろよ -
自称スーパープログラマーこんな所にるんだ
-
年収300万の人間に何を期待しているんだ?
適当にやらせていただきます -
まあ実際には何も期待されてない
ただの作業員だわな -
そうそう
適当でいいんだよ
上が全部責任取ってくれる -
二日で終わる仕事を一週間かけるのはデフォ
-
>>784
すぐファビョるのもダメ管理者の特徴だな。 -
ロケット制御みたいな枯れた分野では予測可能性が重要で創造性は必要が無いってことね
-
自分の嗜好と現実がぶつかったら現実のほうを否定するタイプだな
-
\ r'´ ̄ ̄ ̄  ̄ ̄ ̄`、::. ___
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__,イ:::: -
異世界に転生して洋食屋に行きたい
-
戻りたいと思えるような過去すらない
何もかも足りなすぎる -
三歳児は何もないのに楽しそうだよ
-
はあああああ
人類滅びねえかな -
>>792
何故、枯れた分野だと? -
テストなんて不要だ
不具合はすぐにユーザーが見つけてくれる
新しい価値の想像、そしてスピード感こそすべて -
トイレでケツを拭く時間も無駄だとか言いそうなヤツですね
実際拭いてないとかいそうで困る -
トイレにいく時間も無駄
-
>>800
確かにお前さんのは想像だけみたいだな。 -
>>800
MSさん毎月毎月止めてください -
トイレと書斎を融合すれば座りっぱなしでいいからケツ拭かなくても無問題
-
MSって2005年にvs無償化したのを最後に、何も革新的なもの打ち出せてないよね。
-
それは単にお前が革新的だと認めたくないだけじゃないの?
-
俺のパソコン買ったはずなのに
実際にはマイクロソフトが好きなようにいじくりまわす -
C#ほど攻守において高い次元でバランスのとれた言語は他に存在しない
-
>>806
おじいちゃんこんにちは -
まったまった、マジでMSが最前線を開拓した技術やサービスって、成功したのは割とないやろ
基本成功したやつをパクって金と物量でシェアもぎ取る感じやん -
まだM$とか言ってるジジイ生きてんの
-
>>811
お前の言う最前線ってなんだ?
成功したもの=最前線じゃないんだが?
どうせアップル信者だろうからそれで例えると
MacやiPhoneに最前線のものなど存在しない
どんなものでも成功できなかった最前線が別にある -
最前線なのに過去形とゆう矛盾wバカw
-
最前線が軒並み失敗ってことだろ
-
最前線である事は
十分条件であるが
必要条件ではない -
焦点は最前線をパクったのは誰かってことだろう?
-
タダでOSを配りつづける見返りに
相手のコンピューターを実質自分のものにして
個人情報を収集して国家に横流しし
見返りに便宜を図ってもらうことで会社が存続する
先鋭的ビジネスモデルの開発に成功した -
あ、はい、スマホですね
-
>>806
サーフェス
アジュール
ウィンドウズモバイル
マウス復刻
Xbox
Windows10
TypeScript
VScode
VSのターゲットOS拡大
オフィス製品の料金体系
オフィスオンライン
SQLServerがいい感じになってきた
ほら、いろいろやってるじゃん -
クール
↑
革新的かつ成功
typescript
革新的だが失敗
Surface→肝心のRTは失敗
Windowsモバイル→何故か失敗
成功したが、フォロアーとか競合とか繋いだだけ
Xbox
VSCode
VSターゲットOS(cordova、Xcode連携)
office365
office onlime
革新的でもなく、失敗
VSターゲットOS(xamarin系)
↓
ダサい
SQLserver、officeの料金体系とマウス復刻はわからん。なんの話題だろう -
なんだかんだ言ってVisual Studioは一番快適なIDEでしょ
-
VScodeは神(拡張にもない機能は他エディタと併用)
VS2017もUnityをC#でやるなら神
それは否定しようがない -
>>823
IntelliJは英語わかんないガイジにはきついもんな -
IntelliJの良さがわからない
VScodeもVSに比べたらカス
スペック低いだけじゃないの? -
VSCodeはエディタと他システムが疎結合であるという点が本家VSより優れている
OSSのようにマルチプラットフォームで作業したい場合
Web系のように多彩な外部ツールを柔軟に組み合わせたい場合
そういう時には本家VSというかall-in-oneが基本のIDEは不便なんだよね -
オブジェクト指向的で良いよなVSCode
class VSCode : ITextEditor
class Git : IVersionControlSystem
class CakeBuild : IBuildSystem
class VisualStudio : IGodDevSystem
だいたいこんなイメージ -
>>829
使いようによってはIDEみたいなもんだろ -
関数名や変数名を単なる文字列置換じゃなく構文に沿って書き換えてくれる機能は超便利だよな。
-
>>831
違うよ -
codeはバカ向けのvsやしな
好きな奴が多いのもわかるw -
>>834
確かにVSの代わりとして使おうとするのはバカやな -
>>834
そもそも用途が全然違うから比較するのがおかしい -
>>837
vscodeでビルドやデバッグしたり、SCMと統合したりしてないの? -
>>838
(VSが例に出てるから)たとえばC#の場合、それはVSCodeじゃなくてOmnisharp -
>>839
うん、だからそういうのを統合したものが統合開発環境だよね -
1つのインターフェースから様々なサブシステムをコントロールしてプログラミングのライフサイクル全体をサポートするのが統合開発環境である
という定義なら確かにVSCodeも統合開発環境と言える
しかしこれではEmacsやVimあるいはただのターミナルですら統合開発環境と言ってしまえる
じゃあ統合開発環境とその他の明確な境界線ってどこにあるのと聞かれるとそんなものは定義できないというしかないのが実情
なのでベンダが統合開発環境を公称したりユーザーの大部分がこれは統合開発環境だと認識して初めて統合開発環境とする以外に現実的な定義方法は存在しない
EmacsやVimなどの高機能エディタやただのターミナルを統合開発環境と呼ぶ人は滅多に居ないのでテキストエディタだ
同じようにVSCodeを統合開発環境と呼ぶ人は滅多に居ないのでこれもただのテキストエディタだ -
そう言う意味ではEclipseも統合環境じゃ無くなるよな?
-
Eclipseは統合開発環境と言っていいだろう
記憶が間違ってなければ公式もそう自称してるし
多くのユーザーが統合開発環境だと認識している -
>>840
違うってば -
Eclipsが統合環境なら、Emacsだって統合環境って言っていいんじゃね?
統合して無い分は外部呼び出しなんてまるっきり同じだろ? -
自分で環境を作っていくのは統合環境じゃない
統合環境というのは(開発環境が)統合済みの環境であって
統合可能な環境じゃない -
Eclipseなら最初から統合環境が整備されてるみたいな言い方だな。
-
>>845
Emacsは統合開発環境って自称してないしみんなテキストエディタと思ってるからテキストエディタだよ -
寄せ集めとintegratedは全然違うもんやろ
統合て訳すとよう分からんようになるけどw -
emacs の学習曲線を検索すれば
統合されてない環境と言える -
リファクタリングするだけのプロジェクトとかないのかな
-
>>851
作り直しっていうプロジェクトならいくらでもある -
月給80万円でいいから永久にリファクタリングするだけのプロジェクトないかな?
-
一般的にウェブサービスなんかだとリリースされた後も
修正(改良)が続くのでリファクタリングし続けることになるだろうね。
もちろんリファクタリングだけではないけれど -
kbnをtypeに直したり
typeをkbnに直すお仕事
今、お前がやってる仕事とあんまり変わらないじゃん -
>>853
歴史学者とかなるといいよ -
>>853
お前の設計センスに月80万の価値はないやろ -
じゃあそれで
-
承知しました
-
俺、リファクタはifダクで頼むわ、参考演算子は抜いてね
-
だいたい素人の考えるリファクタリングって
どこかずれてるよね >>862とか -
素人が考える設計もかなりズレてるから
リファクタリングがズレまくるのは仕方ない -
で正しいリファクタリングしてるやつから、
お前間違ったリファクタリングしておいて、
自分の間違ったリファクタリングが意味ないーって
マッチポンプしてるだけじゃねーかって言われるわけな -
正しいリファクタリングw
オナニーにまで権威的裏付けを求めるキチガイの発想ワロタw -
コンパイラが思いっきり最適化すんだから、可読性以外の目的でリファクタリングなんかするなって言われた。
-
>>868
マーチン・ファウラー様がそう言っているのだから従いなさい
http://bliki-ja.gith...mizationRefactoring/
> 最適化とリファクタリングはどちらも変化を伴うものだが
> (なかには最適化かつリファクタリングとなる変化もあるが)、
> 両者は別物だと私は考えている。
>
> なぜなら、両者の目的が異なるからである。リファクタリングは、
> コードを理解しやすくするためである。最適化は、プログラムを速くするためである。 -
一人で頑張ってリファクタリングしても百倍以上の人数で寄ってたかってスパゲティ量産されるからもう諦めた
お前らみたいな意識高い連中と仕事したい -
>>872
でもそれはやっちゃいけないんだわ。
本来は最初にコード書いた人がリファクタリングまでやって
コミットするのが正しい流れだから。
責任がある人に、最後まで責任を取らせるのが筋。
もちろん教育を兼ねて手本を見せるのはいいけどね -
リファクタリング専門業者があれば転職するんだが
メンテナンス不能になったシステムを蘇らせるだけのお仕事 -
リファクタリングしたら全部テストしろよ?
-
バグ修正したら全部テストしろよ?
-
Windows Updateしたら全部テストしろよ?
-
>>873
自分の将来の為に手を動かしてみたら?ってだけだよ。 -
>>877
それは流石に頭おかしい -
おかしくない
ネットから遮断してUpdateなどしなければいいんだ -
>>881
社会に出ろよ。 -
>>882
信じろってばw -
リファクタをそそのかされて
自分のコードが非常に汚いものに思えて
鬱で死にたくなってきた -
コードがきれいな人もリファクタしてるから
-
商品が売れていることが第一
生産コストがどうとかは付加価値
↑付加価値ではないだろ -
え?プログラマが楽になるということは
少ない作業(コスト)で生産できるということだから
結果的に利用者に恩恵があるでしょう? -
>>885
「この消臭スプレーはすごい効きますよ。オススメです」は「お前臭いよ」をオブラートに包んだ言い方
「リファクタリングオススメ」は「お前のコードクソだよ」をオブラートに包んだ言い方
日本人は回りくどい言い方をする -
>>890
コードのきれいさのためにアプリとしての達成度が下がってるようなときはどうなんだ -
身近な例だとスケーリングかな
スケールしたい時ってビジネスリスク回避かビジネス拡大のチャンスのどっちかなんだよね
その時になってメチャクチャに結合してるので簡単にはスケールできませんなんて事になったら大損害だよ
綺麗なコードには多大な価値があるんだよ -
>>892
コードのきれいさのためにアプリとしての達成度が上がってる場合もありますよ? -
コードが汚いと同業他社とのサービス競争にも負けるね
ライバル社が面白い機能を公開してユーザーの注目を集めてる
後追いになってしまうが自社も同等の機能を追加したい
コードが汚いと機能を追加するのにも時間がかかる
時間がかかればかかるほどユーザーの乗り換えが加速する
とんでもない損失だ -
下請けの身だと、コードを納品して金をもらうことが第一
コストとかそういうのはエンドユーザーと元請けの間の話だから下請けには無関係 -
コードを綺麗に書けば、早く書けるしバグも少ない
すると残業もなくなるし、バグ修正の手間も減らせる
下請けでも綺麗なコードには価値があり -
人月商売
-
>>897
つまり結果的に早ければコードのきれいさは関係ないんだよね? -
>>899
母国語は? -
ん?どこの国でも一緒じゃないん
さすがに関数名とか日本語にしないよ?? -
あらら
通じなかったか -
>>899
コスト意識の無いトイプロジェクトならそれでも良いんじゃね? -
綺麗に早く安く高品質に書けるものをわざわざ汚く時間をかけてバグだらけにする意味がわからん
-
字下げだってそうよ
オールマンスタイルが読みやすいって人もいれば
Javaスタイルが良いという人もいる
いろんな人がいる、自分と違う価値観を受け入れてこそ
立派な社会人ですぞ -
価値観じゃなくて実際に金に関わるんだよ
インデント派閥みたいなお遊びじゃねえんだからしっかりしろ -
>>906
そんなのケースバイケースじゃん
アイデアをどこよりも早く出したいならスピード重視だし
末永く保守していくことが最初から確定してるSIer案件なら保守性重視するし
どちらの価値が大事ですかってことでしょ -
綺麗に書くのと製造スピードがトレードオフの関係にあるって誤解はなんで広まったんだろうな
-
>>910
スピード重視ならコピペ上等だからじゃないかな -
本当にコピペだけで済むなら関数にしたほうが良いじゃん。
コピペっていうのは、実はコピペ+修正でしょ?
修正してる分遅くなってる -
そしてスピードが重視だからこそ
リファクタリングが重要なんだよ。
まずリリース。そして問題なさそうならリファクタリング
そうやってスピードを落とさずにリリースをし続ける -
どこよりも速いスピードでアイデアを形にして
サービスを提供してユーザが集まったら
0から作り直せば良い
最初から保守のこと考えて作ってたら
遅すぎるんだよ -
リファクタリングすればいいので
0から作り直す必要がない -
>>916
同じ部分だけを関数にすればいいだけ -
>>917
どっちでも良い -
>>912
リリースするまでも綺麗に書いた方が速いぞ
汚いコードはスケール小さくてもバグがわんさか湧いてくる
急ごしらえでリリースしたらバグが多くてユーザーが即座に興味を失ったサービスなんて珍しくもない -
お前らそんなにリファクタリングが大事なら
自分のレスをリファクタリングしてろよw -
>>925
YouTubeもGoogleもバグだらけだが圧倒的インフラパワーと
サービスの斬新さでユーザに有無を言わさず使わせてるだろ
スタートダッシュでぶち抜かれたら勝てない
ツイッターもフェイスブックも1番だったから今でも頂点に君臨してるんだ -
>>924
テストの無いリファクタリングなんてありえない
つまり最初のリリースではリファクタリングを考える必要ない
だから勝てる
その後リファクタリングをする
勝ったあとリファクタリングをする
勝ったと決まった後の話、勝つのは決定事項
その後のリファクタリングが勝利を継続させる
リファクタリング最高
勝った後勝ち続けられる -
リファクタリングは勝利を継続させる方程式
-
>>935
ユーザは使うんだよ、なぜならば斬新なアイデアだから
スピード重視でどこよりも早くそれを形にしたから
サービスとして使えるようにしたから
業界の人もなんだこれはと思いバグを見つけるだろうが
それさえも話題の一つになる、こんなバグがあったと
あざ笑う一方で笑ってる人間は同じだけの成果を出せない
つまりアイデアを誰よりも早く形にして世に出すという
ことがいつまでもできない -
つまりアイデアを誰よりも早く形にして世に出す
そしてリファクタリング -
TwitterもLINEもPayPalもコインチェックも
スピードで他を突き放したからこそ莫大な利益を得ることができた -
スピードとメンテナンス性を両立させるのは
リファクタリングしかない -
しかしリファクタリングの工数は取れない
なぜならばユーザに関係がないからだ -
開発スピードが上がるからユーザーに関係ある
-
COBOLで作られてシステムがメンテナンス不能になったのは
COBOLという言語の問題ではなくリファクタリングしていなかったことが
問題だというのが最近の結論となっている -
Windows95を開発した天才プログラマーの本を読め
大事なのはスピード・スピード・スピード
https://www.amazon.co.jp/dp/4905073413/
・遅い天才より、速い凡人がトップに立つ
・3500個の不具合があっても、世界は変えられる
・2:8の法則が、あなたの仕事を変えていく
・石膏像を掘るとき、「眉毛」から始める人はいない
・最強の昼寝は、18分
・あなたの仕事は、規則を守ることではない
・待ち合わせ30分前に、スタバでコーヒーを飲め -
ユーザーは開発費用を出さずに
開発しろと言ってるだけ
それに従うのは愚か者でしかない -
>>951
ユーザはリファクタリングに金は出さへん言うてるやろが!!! -
>>952
できたじゃん、Windows95は圧倒的シェアを獲得したじゃん
バグだらけだったじゃんWindows Meの頃までクラッシュしまくりだったじゃん
それでも圧倒的シェアを達成できたじゃろう
リファクタリングはシェアとは関係ないんじゃ
開発者の自己満なのじゃよ -
Windowsは毎回作り直していない
リファクタリングし続けてる -
>>956
NTカーネルは別で作ったんやで
リファクタリングとは別次元やで
スピードで価値を創出して
その金で新しいプロダクトに投資したんやで
リファクタリングは関係ないっす
ただの開発者の自己満っす
マジっす -
>>958
Windows 95はリファクタリングし続けた
NTカーネルもリファクタリングし続けてる
リファクタリングをした結果に満足したから
今もリファクタリングし続けてる
もしリファクタリングがだめなら
最初の一回で止めていたはずだ
勝利を継続させるためにリファクタリングは
必須であることの証拠 -
>>959
> フットプリントが小さい軽量カーネルをゼロから作ったんやで
それ以外はリファクタリングしている
リファクタリングがなければ、軽量カーネルで
OS、アプリを動かすことはできなかったであろう
リファクタリングは様々な問題を解决している -
>>960
製品に投資してるだけでリファクタリングは関係ないっす
マジっす、リファクタリングで金を生み出せるなら
ブリキのおっさんは世界の大富豪の一人になってないとおかしい
スピードこそが価値を生むのはマイクロソフトが証明してる -
>>961
リファクタリングってそんな便利なことばじゃないと思う
リファクタリングしてないんじゃないかな
修正はしてるだろうけど
はっきり言います、マイクロソフトはリファクタリングには一切手を出していません -
実際Windowsの開発者の本読んだけどリファクタリングなんて
一文字も出てこなかった、とにかく大事なのはスピードだって -
>>963
> はっきり言います、マイクロソフトはリファクタリングには一切手を出していません
ほら、ボロが出た。
こいつは息をするように嘘をつく
http://ascii.jp/elem/000/000/506/506852/
前回では、Windows 7の中核と言える「MinWin」に関して解説した。
MinWinはVistaのカーネルをベースとしているが、
「リファクタリング」というコンセプトで整理統合されている。 -
嘘つき嘘つき嘘つき
Windowsはリファクタリングしていた
https://docs.microso...-service-refactoring
Refactoring also makes it easier to view running processes in Task Manager.
You can look at Task Manager and know exactly which service is using what
resources, without having to expand many separate host groups. -
再開発なんて現実的じゃない
リファクタリングが様々な問題を解決できる
再開発を断念、BIND 9のリファクタリングへシフト
https://news.mynavi....ticle/20170216-a275/
> 開発チームは以前BINDをスクラッチから再開発する
> 取り組みを行ったことがあるが、これは失敗に終わったとしている。 -
>>965
コンセプトがリファクタリングってだけで
リファクタリングしたわけじゃないだろうが
実際にやったのは整理しましたってだけだろ
整理することをリファクタリングなんて言ったら
年末の大掃除は大リファクタリングと呼ばなければいけなくなるわ
日本人として恥ずかしい -
Windowsはなぜリファクタリングし続けるのか?
それは勝利を継続させるためである
Announcing Windows 10 Insider Preview Build 11099
https://blogs.window...preview-build-11099/
The code refactoring (リファクタリング) and other engineering work we’ve been doing to optimize OneCore is nearing
the point where we will be ready for teams to begin checking in new features and improvements. -
https://www.zdnet.co...one-3-pc-test-build/
Today's new build, 16170 for PCs, is most about refinements to
OneCore (the elements that are common to all the different variants of Windows 10),
code refactoring and other under-the-covers work needed before Microsoft developers can begin checking in code.
↑コードリファクタリング
まただ。嘘つきはクソだ -
アホほど再開発の方がマシとかいうんだよなぁ
-
>>971
その情報全部読んだけどリファクタリングが
バズワードであることを良いことになんでもかんでも
リファクタリングと言い換えてるだけだった
昔ながらのレンタルサーバをクラウドと言って
クラウドやからええんやでと言ってるようなもの
実態はただの修正 -
やはりリファクタリングだけが問題を解決する
現実的な手段なんだな -
金にならない虚業
-
知ってるか?Visual Studioには
さまざまなリファクタリングサポート機能が
搭載されている -
そもそも見積り終わってからお仕事増やすのやめてもらえます?
-
>>981
それでwindowsの不具合も直せや -
やばい、リファクタリング最強説が出てきた
アンチの言ってることを突き詰めていったら
リファクタリング最強だった -
>>985
落ち着けよ、どんだけ興奮してるんだよ、変態か -
リファクタリングはすべての問題を解決する唯一の手段
-
アンチは論破された
-
アンチは論破された
-
アンチは論破された。泣き崩れている。
-
アンチは論破された。泣き崩れている。
ウソと詭弁で自分を守ることしかできていない -
リファクタリングが金を生まない事実はどうするのか
-
アンチは論破された。泣き崩れている。
ウソと詭弁で自分を守ることしかできていない。
様々な証拠がリファクタリングの有用性を示している。 -
アンチは論破された。泣き崩れている。
ウソと詭弁で自分を守ることしかできていない。
様々な証拠がリファクタリングの有用性を示している。
マイクロソフトもリファクタリングをしていた。
Googleもリファクタリングをしていた
Appleもリファクタリングをしていた。 -
>>996
一時が万事そんな調子じゃ議論になりませんな -
アンチは論破された。泣き崩れている。
ウソと詭弁で自分を守ることしかできていない。
様々な証拠がリファクタリングの有用性を示している。
マイクロソフトもリファクタリングをしていた。
Googleもリファクタリングをしていた
Appleもリファクタリングをしていた。
もう誰にも止められない。
アンチはウソと詭弁を繰り返すだけ
↓ -
SIER!!
-
このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 34日 5時間 20分 29秒 -
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
↑今すぐ読める無料コミック大量配信中!↑