２ちゃんねる ■掲示板に戻る■ 全部 1- 最新50

■ このスレッドは過去ログ倉庫に格納されています

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

1 ：仕様書無しさん：2018/04/15(日) 13:13:44.63 .net: 機能追加や変更した時に、全部テストしてるでしょ？
いつもやってることじゃん
2 ：仕様書無しさん：2018/04/15(日) 13:16:31.37 .net: それなｗ

あと、リファクタリングするとお前責任取れるのかとか言ってくるが
機能修正でバグった時の責任はリファクタリングじゃないんだから
全部あんたがとれよって言うと顔真っ赤になるｗ
3 ：仕様書無しさん：2018/04/15(日) 13:23:46.40 .net: 半角カナを使う奴まだいたのか
4 ：仕様書無しさん：2018/04/15(日) 13:29:25.23 .net: スレタイ長くて入らないからね
5 ：仕様書無しさん：2018/04/15(日) 13:53:39.75 .net: 簡潔にまとめられない奴はプログラミング向いてない
6 ：仕様書無しさん：2018/04/15(日) 14:07:43.60 .net: そんなことない
なんでもかんでも一緒にするな
7 ：KAC：2018/04/15(日) 14:29:02.33 .net: >>1
テスト粒度とかリスクとか理解できないの？
8 ：仕様書無しさん：2018/04/15(日) 14:43:15.84 .net: リファクタリングはテスト必須で
論理的におかしくならないと判明している
決められたやり方でやるので
リスクは低いしテストは自動化されています。
その前提ぐらい知らないんですか？
9 ：仕様書無しさん：2018/04/15(日) 14:45:55.12 .net: >>8
だからテストやらなくていいって？
そもそもクラスまで作り変えてるならテスト免除どころか設計書のレビューからだよね
10 ：仕様書無しさん：2018/04/15(日) 14:46:35.64 .net: >>9
リファクタリングは「テストをやってる」ことが
前提なので、
あんたが言ってるのは別のものでは？
11 ：仕様書無しさん：2018/04/15(日) 14:47:26.22 .net: > そもそもクラスまで作り変えてるならテスト免除どころか設計書のレビューからだよね

そうですね？　なんでレビューせずに
リファクタリングするなんて思い込んでんの？
12 ：仕様書無しさん：2018/04/15(日) 15:05:33.14 .net: > リファクタリングはテスト必須で

って書いてあるのに

↓

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

これもう頭が悪いレベルだろｗ
13 ：仕様書無しさん：2018/04/15(日) 15:06:06.29 .net: リファクタリングの存在を否定できないと
困る人がいるんですよｗ
14 ：仕様書無しさん：2018/04/15(日) 15:30:21.76 .net: 設計書から書き直すならただの改修作業なんだよね？
15 ：仕様書無しさん：2018/04/15(日) 15:32:49.90 .net: >>14

改修作業の中身の違い

　1. 無計画に適当に修正して手動でテストしてそれでもバグでて苦労するのと
　2. リファクタリングの手法を使ってテストコード書いて低リスクで修正するかの違い
16 ：仕様書無しさん：2018/04/15(日) 16:11:52.19 .net: >>15
具体的にどう違うの？
17 ：仕様書無しさん：2018/04/15(日) 19:48:05.09 .net: >>15
TDDでリファクタリングした場合、
1、初歩的なミスにすぐ気付ける
2、作業者が精神的に安心できる

なお、開発者目線の開発体制の優先順位は
バージョン管理 > コードレビュー > 自動テスト > リファクタリング
なので、必ずリファクタリングとTDDはセットになる
18 ：仕様書無しさん：2018/04/15(日) 19:48:54.60 .net: >>16
リファクタリングの手法では先に自動化されたテストコードを書く
もしくはすでに存在していなければならない
だから、リファクタリングしたらテストしろよっていうのは意味不明。

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

おそらく修正とテストが分離した考え方しか持って無くて
修正後に手動でテストを行うというやり方しか知らないのだろう
そんな再現性がなくてテスト回数もすくないんじゃ、
バグがなかなか取れずにデスマになるのは必死だろう
19 ：仕様書無しさん：2018/04/15(日) 21:04:44.02 .net: >>17
工数も削減できないし
品質も上がらないんだ？ｗ
20 ：仕様書無しさん：2018/04/15(日) 21:17:10.48 .net: なにをゆうちょるんじゃあ主は
21 ：仕様書無しさん：2018/04/15(日) 21:37:54.42 .net: リファクタリング厨って受け売りでしか語らないから面白くない
22 ：仕様書無しさん：2018/04/15(日) 23:16:16.00 .net: ゴミスレ
23 ：仕様書無しさん：2018/04/16(月) 05:06:44.38 .net: オープニングから自演ｗ
24 ：仕様書無しさん：2018/04/16(月) 05:08:34.00 .net: >>21
というか、責任あるポジションの経験がないやつが語ってるだけだからな
ちゃんと決定権を持つやつを納得させるだけの説明ができればいいだけだが、
それすらできていないっつーね
25 ：仕様書無しさん：2018/04/16(月) 06:25:24.08 .net: >>2
責任とって辞めます。
26 ：仕様書無しさん：2018/04/16(月) 12:37:10.95 .net: >>19
そこらへんの話でいうと、
売上や品質が上がった客観的なデータが示せりゃ、どの会社でも自動テストやリファクタリングは採用されるんよ
そこまでしてないなら、その議論は語るに値しない
んで、殆どの会社はそこを検証していない
27 ：仕様書無しさん：2018/04/16(月) 12:45:59.35 .net: >>26
そんなもん、やってみりゃ肌で感じ取れること
数値にしなきゃ理解できないよぉとかバカみたいなこと言ってると腕のいい職人にはなれませんよ？？
28 ：仕様書無しさん：2018/04/16(月) 13:26:59.58 .net: >>27
数値にできる学がねぇんだろｗ
数値化しろよ
29 ：仕様書無しさん：2018/04/16(月) 13:36:47.19 .net: >>27
仕事を規定の時間内に許容できる品質のものを上げるのが実装者に求める要求で、それに付随する手段は手段でしかない。
で、手段は自由にやればいいし、基本介入しないし、結果しか見る気は無い。
だからやりたければやれば？としか自分は言わない
工数増えるのは論外
30 ：仕様書無しさん：2018/04/16(月) 14:37:58.22 .net: >>26
> そこまでしてないなら、その議論は語るに値しない
> んで、殆どの会社はそこを検証していない

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

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

で、それを参考にすりゃいいのに、参考にしないんだろう。
つまり他人を信用してない。だから他人がなにやってもどんなデータを出しても
そういう会社は信用しないんだろう。
31 ：仕様書無しさん：2018/04/16(月) 14:41:43.64 .net: リファクタリングが有効かどうか？
検証してやるよ。コスト？そりゃ当然かかるよ

ここで嫌がる会社が多い

重要なのは、失敗するかもしれないがやってみよう
という考えが通じる会社かどうかなんだろうな
32 ：仕様書無しさん：2018/04/16(月) 14:52:53.46 .net: 体力がなくて単純工すらできないごみクズがIT技術者(笑)になる日本では
コストメリットどころかリスクしかない。
33 ：KAC：2018/04/16(月) 17:54:10.17 .net: 「リファクタリングしたら工数減ります」
「リファクタリングの為の工数ください」

うん。意味不明だね。
34 ：仕様書無しさん：2018/04/16(月) 18:19:38.72 .net: > 「リファクタリングの為の工数ください」

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

>>31が言ってること勘違いした？
リファクタリングが有効かどうかの検証の話だよ。
検証するには、同じことをリファクタリグをするのと
しないので2回やらないといけない。
検証にはコストがかかる。
35 ：仕様書無しさん：2018/04/16(月) 19:00:22.44 .net: >>28
俺の筋肉量でリファクタリングの効果を説明できる
36 ：仕様書無しさん：2018/04/16(月) 19:33:16.67 .net: >>34
いや、リファクタリングで総工数が減るなら勝手にやればいいだけじゃね？
リファクタリングで品質下がるなんて聞いた事無いわけだし。それとも単体テストレベルまでがっちり管理されてんの？
37 ：仕様書無しさん：2018/04/16(月) 19:50:39.52 .net: リファクタリングで増減する工数って、内部設計クラスレベル～クラステストまででしょ
詳細設計省かずやる巨大案件でも無い限り、実装者に委ねられる部分やん。
ともすれば、やりたきゃやれって回答にしかならん。
38 ：仕様書無しさん：2018/04/16(月) 20:03:20.01 .net: >>36
> いや、リファクタリングで総工数が減るなら勝手にやればいいだけじゃね？

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

だからリファクタリングのために工数くださいっていう発想が
そもそも間違ってるわけ。修正に伴う追加作業じゃない。
修正作業そのものなんだから
39 ：仕様書無しさん：2018/04/16(月) 20:08:32.88 .net: 仕組みが悪いからって正常に動いてる箇所まで手を入れるってねーな
40 ：仕様書無しさん：2018/04/16(月) 20:37:02.97 .net: リファクタ自体は否定しないが、>>１は確実に技術に溺れて盲信してるアホだから許可出さない
41 ：仕様書無しさん：2018/04/16(月) 21:02:09.30 .net: >>39
正常に動いていると証明するテストをしてないってこと？

正常に動いていることを証明するテストを修正後にもやれば、
正常に動くと証明できるでしょう？
42 ：仕様書無しさん：2018/04/16(月) 21:03:03.43 .net: >>40
修正許可与えてるなら、どんな修正をしたとしても
許されるはずだけど？
43 ：仕様書無しさん：2018/04/16(月) 21:22:15.99 .net: >>38
修正が発生したときにしかリファクタしないの？
44 ：仕様書無しさん：2018/04/16(月) 21:24:48.73 .net: 修正ってなんだよ、バグってんのか
機能追加だろうがなんでも修正って言う奴は素人でしょ
45 ：仕様書無しさん：2018/04/16(月) 21:26:39.53 .net: ただのレッテル張りじゃねえかｗ
46 ：仕様書無しさん：2018/04/16(月) 21:27:14.47 .net: 素人というやつは童貞だ
イカ臭いプログラム書いてろ
と言ってるようなもの
47 ：仕様書無しさん：2018/04/16(月) 21:30:14.08 .net: >>43
なんどもリファクタリングは修正の一部だって言ってるじゃん
一部ってことはそれ以外も有るってことだよ

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

前者だと、複雑なコードを読み解いた人（修正担当者）がいるにもかかわらず
別の人が、また大変な思いをして読み解いてレビューしなければいけない
そして、次同じところを修正する時、また複雑なコード読み解かなければいけない
48 ：仕様書無しさん：2018/04/16(月) 21:32:16.33 .net: みんな実装するだけで精一杯なんよ
49 ：仕様書無しさん：2018/04/16(月) 21:33:31.81 .net: リファクタリングは神の領域に達するものにのみ許される技。
素人はおとなしくExcel方眼紙でセル結合の練習でもしておけ。
50 ：仕様書無しさん：2018/04/16(月) 21:36:56.37 .net: >>47
そんな入門書の1章に書いてあるような話はいいよ、面白くないから
51 ：仕様書無しさん：2018/04/16(月) 21:45:07.82 .net: >>50
入門未満の人がいるんでね
52 ：仕様書無しさん：2018/04/16(月) 21:48:55.54 .net: 入門レベルの奴でも上から目線になれるから張り切ってんのか
53 ：仕様書無しさん：2018/04/16(月) 21:54:14.63 .net: だから>>1にはやらせない
54 ：仕様書無しさん：2018/04/16(月) 21:58:29.27 .net: >>37
テストの品質が後工程に無関係ならな。
まあそんな現場が多いのは事実だが。
55 ：仕様書無しさん：2018/04/16(月) 22:14:39.29 .net: >>51
リファクタリングするときのレビューとかどうしてる？
設計レビューもだし、コードレビューもだけど
56 ：仕様書無しさん：2018/04/16(月) 22:21:54.62 .net: リファクタリングしてるのでNG
57 ：KAC：2018/04/16(月) 22:42:11.58 .net: >>47
お前さん、理想通りに開発が進めば
自動試験だけで完璧なものができるとか信じてる？
58 ：仕様書無しさん：2018/04/16(月) 23:48:14.82 .net: テストしづらいとか、クラスが肥大化しすぎて開発に支障があるとかならまだしも
見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか
59 ：仕様書無しさん：2018/04/17(火) 01:28:22.88 .net: リファクタリングは超プロの領域
このスレには本当のリファクタリングが出来る奴はいない

elseなしに書き換えるのが精一杯のFラン説教野郎みたいなのがいるだけ
60 ：仕様書無しさん：2018/04/17(火) 01:37:33.43 .net: 大規模リファクタリングの秘孔をついた
お前のプロジェクトはもう死んでいる
61 ：仕様書無しさん：2018/04/17(火) 02:47:02.14 .net: >>55
> リファクタリングするときのレビューとかどうしてる？
リファクタリングではないときはどうしてる？
それと同じなんだが。

まあそういう質問するってことはリファクタリングに限らず
そもそも設計もコードもレビューしてないってことなんだろうけど
まずはそこからやねｗ
62 ：仕様書無しさん：2018/04/17(火) 02:49:20.05 .net: >>57
> 自動試験だけで完璧なものができるとか信じてる？

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

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

人手でレビューして、テストした内容も記録されて
後なにがあれば完璧なものができると思います？
63 ：仕様書無しさん：2018/04/17(火) 02:51:40.76 .net: >>58
> テストしづらいとか、クラスが肥大化しすぎて開発に支障があるとかならまだしも
> 見通しが悪いなんて理由でうごいてるもんをほいほい変えていいもんじゃろか

機能追加とか修正するという前提なんだから、どちらにしろ変更するしかないでしょｗ
64 ：KAC：2018/04/17(火) 08:07:55.30 .net: >>62
自動試験してレビュー通ったらシステムインしてサービス開始すんの？
65 ：仕様書無しさん：2018/04/17(火) 08:35:24.00 .net: 入門書第1章に書いてあることの受け売りなら長文で語るけど、具体的な話からは煽りで逃げるし、
体験から語ってると思えるような発言もないし、こいつ多分そんなにノウハウないよ
66 ：仕様書無しさん：2018/04/17(火) 10:12:11.71 .net: >>64
レビューもするし自動以外のテストもする
そこは普通の機能変更のときとなにも変わらない

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

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

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

その後にやるテストうんぬんは、もともと機能変更でやる予定だったんだろ？
なら最初からやるって決まってることじゃないか
67 ：仕様書無しさん：2018/04/17(火) 10:12:38.07 .net: >>65
> 具体的な話からは煽りで逃げるし、
ん？どのレス？
68 ：仕様書無しさん：2018/04/17(火) 10:13:52.53 .net: レビューってさ
もう儀式になってない？
69 ：仕様書無しさん：2018/04/17(火) 10:16:36.37 .net: TDDってさ
組織的にガチガチにやるもんじゃなくて
設計者の間で守るべき密やかな秘密程度で
やったほうが良い気がすんのね。
70 ：仕様書無しさん：2018/04/17(火) 11:00:00.11 .net: >>68
それはどんなコード変更のときでもやるべきことだから
リファクタリングの話とは関係ないという注意だけしておくね
71 ：仕様書無しさん：2018/04/17(火) 11:05:57.21 .net: >>69
ようは、リファクタリング前に存在するテストコードが
リファクタリング後でも通ることで動きを変えてないことが
証明できれば良いのでTDDである必要はないよ。

具体的にはgit使えば歴史変えられるんで、
コード変更しつつテストコード書いて、
コード変更とテストコードでコミット分けて
あとでrebaseしてテストコードのコミットをコード変更の
コミットより前に持ってくれば良い
72 ：仕様書無しさん：2018/04/17(火) 12:12:26.72 .net: >>71
TDDは保護するためのテストじゃないから
73 ：仕様書無しさん：2018/04/17(火) 12:23:08.56 .net: >>68
レビューのつもりで儀式やってるだけのところが多いね。
74 ：仕様書無しさん：2018/04/17(火) 12:26:04.15 .net: >>72
> TDDは保護するためのテストじゃないから

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

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

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

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

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

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

> 簡単に言うと、TDDは機能を記述する前に自動テストを書く行為です。
> 例えば、Bobが素晴らしい新たなソーシャルネットワークのアイデアの
> ために新しい機能を開発する必要があるとしましょう。
>
> Bobは自動テストを書くことから始めますが、機能を正しく実装せずに、
> テストを失敗（赤色表示）させます。次に、Bobはテストを成功（緑色表示）
> させるための最小限のコードを記述します。緑色表示になったら、
> Bobはコードをきれいにし、テストを実行して機能が正しく
> 実装されたままであることを確認します（コードのリファクタリング）。
> 重複することなく、コードと自動テストは他の人も簡単に保守できます。
75 ：KAC：2018/04/17(火) 13:27:11.82 .net: >>66
えーと、まずはスレタイの
「リファクタリングすると全部テスト」については、
「全部テストするのは当たり前」という理解でOK？

それなら、大筋では意見に違いは無い。
76 ：仕様書無しさん：2018/04/17(火) 13:49:22.47 .net: >>75

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

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

afterに対して、余計なことするな！
リファクタリングしたなら全部テストしろ！
と言われましても、beforeでも全部テストしてますよね？という話です。
77 ：仕様書無しさん：2018/04/17(火) 15:18:23.57 .net: リファクタリングしたら(その時点で、機能改修する前に)(単体)テストしろって要求なんじゃね？

まあ普通やるけど。
78 ：仕様書無しさん：2018/04/17(火) 15:55:33.65 .net: >>77
いやぁ、違うなぁ
リファクタリングさせないための方便として使ってるので
お前がリファクタリングするとテストする人が迷惑するんだぞ
だから余計なことするなという意味だろう。

だがもともとテストするわけで矛盾になるんだよな
79 ：仕様書無しさん：2018/04/17(火) 16:16:34.63 .net: >>74
そういうことじゃないんだよなぁ
80 ：仕様書無しさん：2018/04/17(火) 16:19:52.69 .net: >>78
違うよ
デグレしたときの徹底的なイジメがヤバイ
81 ：仕様書無しさん：2018/04/17(火) 16:59:00.97 .net: >>79
じゃあどういうことか書けよｗ

>>80
でもどっちみちコード変更するんでしょ？
リファクタリングしない方がデグレさせる可能性高いし
82 ：仕様書無しさん：2018/04/17(火) 17:34:58.09 .net: リリースしたらあとはそのシステムのことは知らん
だからリファクタリングする気もない
83 ：仕様書無しさん：2018/04/17(火) 18:30:58.65 .net: >>81
いやリファクタリングすると触らなくていいとこまで変更するじゃん
既存コードを変更するって時点でまずい
84 ：仕様書無しさん：2018/04/17(火) 18:52:07.21 .net: >>83
触らなくていいかどうかが重要なんですか？

重要なのはテストする所かどうかでしょう？
触った所でテストするなら、なにも問題ないはずですが？
85 ：仕様書無しさん：2018/04/17(火) 18:54:58.04 .net: >>84
そうはいかねぇだろ
文章化されてないけど
クリアしてるいろんな仕様があんだからよ
長い間運用してるとそういうのあるわけよ
86 ：仕様書無しさん：2018/04/17(火) 19:09:26.69 .net: >>84
触らなければテストもしなくていい
プロは余計なコードも書かないし、余計なテストもしない
87 ：KAC：2018/04/17(火) 19:26:39.52 .net: >>76
イメージはあってそう（スレ建てた奴とは違う意見）に読めたので、
具体的な内容を書いてみる。

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

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

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

リファクタリングの有無でどちらが安いのか、
時と場合によるって認識はあってる？
88 ：仕様書無しさん：2018/04/17(火) 20:51:10.01 .net: WFとアジャイルとでも違うし
リファクタリングできる設計になってるの？
も大きな要素だが

動いているなら弄るなよは永遠の真理
89 ：仕様書無しさん：2018/04/17(火) 21:08:17.92 .net: >>88
そのレベルの現場が多いもんな。
90 ：仕様書無しさん：2018/04/17(火) 22:21:50.39 .net: バッファサイズの変更でなにをリファクタするというんだ

文字編集がややこしいから途中量の計算が難しいから処理変更とか？
91 ：仕様書無しさん：2018/04/17(火) 23:28:38.99 .net: >>85

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

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

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

文書化されてない仕様をテストでどうやって
見つけるんですか？
92 ：仕様書無しさん：2018/04/17(火) 23:36:25.31 .net: >>87

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

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

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

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

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

コードの変更とリファクタリングの間に「関連箇所の試験して完了」
なんてものは入らないし入れたらダメです。
93 ：仕様書無しさん：2018/04/17(火) 23:41:10.11 .net: ちゃんと設計できてないから改修する度にいちいち事前のリファクタリングが必要になるんだろうな
94 ：仕様書無しさん：2018/04/17(火) 23:41:50.05 .net: >>91
まさにそのスレでその話してるんだからおいとくなよ…

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

改修部分が少なければ少ないほど踏んじゃうリスクは減るだろう
95 ：仕様書無しさん：2018/04/17(火) 23:48:58.45 .net: > ちゃんと設計できてないから改修する度にいちいち事前のリファクタリングが必要になるんだろうな

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

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

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

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

リファクタリングしたことで1工程増えたように見えますが、
ちゃんとした設計になってないものを無理やり修正した複雑なコードは
バグが出やすく、修正も大変になって時間がかかります。
それはわかるでしょう？
96 ：仕様書無しさん：2018/04/17(火) 23:50:34.78 .net: >>94
> 改修部分が少なければ少ないほど踏んじゃうリスクは減るだろう

改修部分をリファクタリングするんだから、
改修部分の量は同じですが？
97 ：仕様書無しさん：2018/04/17(火) 23:55:28.57 .net: >>96
具体的なイメージがわからない

本当に改修部分だけ改修だったらリファクタ部分消えちゃうじゃない
それってただの改修では
98 ：仕様書無しさん：2018/04/18(水) 00:26:44.21 .net: >>97
ちょっとなにかいいサンプルないか探したんだが
見つからなかったので、軽く例を書くわ

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

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

リファクタリングして10行にまで減らすと、コードはシンプルになりなにやってるのか一目瞭然になった。
テストコードがあるのでリファクタリングの前後でコードが壊れてないことはわかる。
リファクタリングしたため修正箇所もたったの一行になった。
他の人も何の修正をしたのかすぐに分かる
99 ：仕様書無しさん：2018/04/18(水) 01:15:38.23 .net: >>98
おまいのレスが長すぎてリファクタリングしないと読めない
100 ：仕様書無しさん：2018/04/18(水) 01:33:21.47 .net: >>99
バイバイ
101 ：仕様書無しさん：2018/04/18(水) 01:43:53.78 .net: >>95
リファクタリングの必要性をそこまで感じないってことは、俺の設計ってちゃんとしてるんだろうなぁ
102 ：仕様書無しさん：2018/04/18(水) 02:00:52.61 .net: >>101
あと仕様変更がないってことだろうね。

仕様変更があれば、少なからず設計を変更することになるから
103 ：仕様書無しさん：2018/04/18(水) 03:09:17.61 .net: >>102
OCPができてないから仕様の変更がいろんなところに波及するんだよ
あとから直せばいいやじゃなくて、もう少し基本を身に付けよう
104 ：仕様書無しさん：2018/04/18(水) 03:41:28.10 .net: >>103
最初から何でも考慮した過剰な設計は止めましょう
こっちが基本ですよ？ｗ
105 ：仕様書無しさん：2018/04/18(水) 07:33:52.26 .net: 言語からスクリプト言語が呼べるようにしておけば汎用性は無限
バグも無限
106 ：仕様書無しさん：2018/04/18(水) 07:50:27.25 .net: >>98
リファクタの状況的にはありだけど

それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
テストで検出できない非機能要件を踏んじゃうリスクは明らかに増えてるよね？
107 ：仕様書無しさん：2018/04/18(水) 10:52:23.05 .net: 数年経ってもリファクタバカは相変わらずだなｗ
未だに賛同者が現れないｗｗｗｗ
しかも、リファクタリングそのものではなく、リファクタバカに対する非賛同が増殖ｗ

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

技術書に溺れなくてよかった・・・。
108 ：KAC：2018/04/18(水) 12:55:46.41 .net: >>98
あぁ、そういう事か。
「リファクタリング」という範囲のイメージが合ってなかったんだな。

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

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

それはそうとして、
関数の処理削減などで処理速度が変わったのなら、同期など含めてその観点での試験はちゃんとやれよ？
109 ：仕様書無しさん：2018/04/18(水) 18:26:19.09 .net: >>107
意味がわからない
お前、どっち派？
110 ：仕様書無しさん：2018/04/18(水) 19:52:23.21 .net: 関数レベルのリファクタリングしか語れないレベルだということはお察し
111 ：仕様書無しさん：2018/04/18(水) 21:09:41.94 .net: おれは何も察することができんのだが
112 ：仕様書無しさん：2018/04/18(水) 22:40:51.02 .net: >>106
> それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
> テストで検出できない非機能要件を踏んじゃうリスクは明らかに増えてるよね？

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

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

結局関数全体をテストするわけでしょう？
113 ：仕様書無しさん：2018/04/18(水) 22:42:05.86 .net: >>108
> 関数の処理削減などで処理速度が変わったのなら、同期など含めてその観点での試験はちゃんとやれよ？

もともと修正すべき関数なんだから、リファクタリングしなくても
テスト必須でしょう？なにを言ってるんでしょうか
114 ：仕様書無しさん：2018/04/18(水) 22:50:36.63 .net: >>112
でもさ
ソースで見たとき処理の下の方をちょっと修正すればいいところで
上の方の関係なさ気な箇所がバグったら言い訳できねぇよ
差分見て

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

って言われたらちょっと嫌な空気流れるよ
115 ：仕様書無しさん：2018/04/18(水) 22:52:17.90 .net: >>106
> それって関数全体に手が入ってるわけだから改修量同じじゃないじゃん
「可読性」って言葉ご存知ですか？

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

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

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

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

リファクタリングは改修時間を短くします。
116 ：仕様書無しさん：2018/04/18(水) 22:53:03.68 .net: >>114
関係ない所を修正するのがいけないのでは？ｗ
117 ：仕様書無しさん：2018/04/18(水) 22:58:24.94 .net: >>112
具体的なシナリオをいうとだ

日付をこりこり自前でデコードして値つくってる１００行近いまぬけコードを
Ｊａｖａのライブラリつかって数行にしてホルホルしてたら
ついうっかり見たことないようなフォーマットも受け入れちゃうようになってて
そんなん存在もわかんないからテストしてるわけなくて
でもユーザーは何の気なしに入れちゃうと入るからそのまま入れて、想定と異なるへんなデータが蓄積していって
集計バッチの演算とかにちょっとづつ毒虫のように影響を与え続けて
気が付いたらえらいことになってたりとか
118 ：仕様書無しさん：2018/04/18(水) 23:00:32.39 .net: >>115
理解できたらもとに戻してもいいのよ？
119 ：KAC：2018/04/18(水) 23:03:03.55 .net: >>113
修正内容に応じてテスト観点増やさないの？
費用対効果考えながらテスト計画立てないと破綻するぞ？
120 ：仕様書無しさん：2018/04/18(水) 23:04:52.45 .net: >>117
それはリファクタリングしなくても起こる話ですね。

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

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

>>118
> 理解できたらもとに戻してもいいのよ？
次修正する時、また改修時間（読む時間）がかかりますよね？
121 ：仕様書無しさん：2018/04/18(水) 23:06:20.06 .net: >>118
もとに戻すと改修時間（読む時間）が無駄になるだけですね。
次回修正するときも、また改修時間がかかります。

バグが見つかったら、また改修時間がかかります。
122 ：仕様書無しさん：2018/04/18(水) 23:07:43.72 .net: >>119
> 修正内容に応じてテスト観点増やさないの？

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

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

どれくらい影響があるか、それはコードが複雑であれば
有るほど不明です。
123 ：KAC：2018/04/18(水) 23:17:24.91 .net: >>122
テスト計画建てたこと無いの？
「全ての条件を網羅したらバグは無くなる」
は真だけど、それができないからみんな工夫してるんだよ。

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

なんてのは、この業界の常識。
124 ：仕様書無しさん：2018/04/18(水) 23:22:51.13 .net: >>120
リファクタだけの問題じゃないが、リファクタも修正のうち
修正する以上人間がやらかすリスクはある

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

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

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

リファクタ後に修正したほうがテスト工数が削減できるとか、規約が新たにできたから合わせるとか
なにかしら明白な理由がないと
125 ：仕様書無しさん：2018/04/18(水) 23:23:52.53 .net: あとどうもやっぱりリファクタリングを
単なるコードの修正の意味で使ってるように見えるんだよねｗ

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

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

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

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

テスト書いて決められたやり方で式を変形するんだから
無計画なコードの修正なんかよりもずっと安全に変形できる
126 ：仕様書無しさん：2018/04/18(水) 23:24:38.02 .net: >>123
いや、だから、一行の変更なら
テスト減らせるってわけじゃないよって言ってるんだが？
127 ：仕様書無しさん：2018/04/18(水) 23:25:40.46 .net: >>124
> コードの読みやすさや理解しやすさは人の主観に大きく依存する

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

コードメトリクスを計測せよ
128 ：仕様書無しさん：2018/04/18(水) 23:27:30.62 .net: >>125
そうだね
リスクはひくいよ
Eclipseのリファクタ機能使うならなおさらだ

それでもたまにやらかすだろ！
129 ：仕様書無しさん：2018/04/18(水) 23:29:05.35 .net: >>127
メトリクスのどれ見んの？
130 ：仕様書無しさん：2018/04/18(水) 23:33:22.64 .net: >>128
> それでもたまにやらかすだろ！

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

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

重要なのは改修量ではなく改修時間な
131 ：仕様書無しさん：2018/04/18(水) 23:34:59.93 .net: マーチン本に書いてある手続きいちいち守ってたら日が暮れる
現実的には既存のユニットテストのコードを信用して
手続きを頭に置きつつ直観でつくり変えていくことになる
そんで流して結果変わってなきゃＯＫと

理想が定義されているからといって現実に耐えうるかというと
132 ：仕様書無しさん：2018/04/18(水) 23:36:04.44 .net: >>129
基本的にメトリクス測定ツールは、基準値超えたら
アラート出してくれるはずだからそれに従えばいいと思うけど、
俺はCyclomatic複雑度を重視するね。
133 ：仕様書無しさん：2018/04/18(水) 23:51:21.89 .net: >>130
改修による単体工数の削減はあるかもしらんが

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

よく考えたら書くほうが早いっつったって
結局その前に理解しないと書き直せないんだから一緒じゃねーか！
だまされるとこだった
134 ：仕様書無しさん：2018/04/18(水) 23:59:21.26 .net: > よく考えたら書くほうが早いっつったって
> 結局その前に理解しないと書き直せないんだから一緒じゃねーか！

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

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

そして理解した結果をコードに反映させないで、レビューにかかる時間
次に修正する時間、バグ出た時に読み返す時間を費やするか
コードに反映させて、その後にある時間を減らすかどうか
135 ：仕様書無しさん：2018/04/19(木) 00:04:04.23 .net: >>134
で？結局リファクタやると具体的に何がいいんだっけ？
色々話してるとメリットが全く見えなくなっちゃう
136 ：仕様書無しさん：2018/04/19(木) 00:04:52.59 .net: >>134
思うのは勝手だが最初にしてた変更リスクの話を忘れてないか
137 ：仕様書無しさん：2018/04/19(木) 00:22:17.21 .net: >>135
> で？結局リファクタやると具体的に何がいいんだっけ？

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

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

そして、レビューやバグがあったときの読み返し時間の削減
修正内容に自信が持てる。今後の修正の時の改修時間の減少
138 ：仕様書無しさん：2018/04/19(木) 00:24:02.42 .net: >>137
いや全然わからない
普通に改修する場合と比べて何がいいの？
139 ：仕様書無しさん：2018/04/19(木) 00:25:04.88 .net: 1行の修正でこんなにお金がかかるんですか！
っていう顧客の声がまんまリファクタリングしない場合にあてはまるな

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

1行の修正でもお金がかかるってことは、1行だからって
なにかを減らせるわけじゃないんですよ。
140 ：仕様書無しさん：2018/04/19(木) 00:28:14.81 .net: >>138
そこで普通に改修っていうのは
リファクタリングをしないってこと

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

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

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

複雑なものをそのままにして手を入れたら
もっと複雑になるよ。
141 ：仕様書無しさん：2018/04/19(木) 00:34:51.32 .net: 複雑なコードは壊すのがこわいからリファクタできない
簡単なコードは意味がないからリファクタできない
142 ：仕様書無しさん：2018/04/19(木) 00:37:19.05 .net: >>141
重要なのは手遅れになる前にこまめにやることだよね

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

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

リファクタリングは、機能追加や変更に伴う作業に
含まれているべきものですよ
143 ：仕様書無しさん：2018/04/19(木) 02:08:38.73 .net: >>142
今どきリファクタリングするのは機能追加や変更のタイミングに限らないよ
DDDやってる？機能の変更がなくても、業務にモデルを合わせるために日々リファクタリングするのが常識
144 ：仕様書無しさん：2018/04/19(木) 02:28:05.80 .net: こんな事が書いてあるのかｗ

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

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

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

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

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

ソフトウェア開発は、変更することで得られる利益や変更しないことで生じるコストを
正確に割り出せるような、予測可能なプロセスではない。
145 ：仕様書無しさん：2018/04/19(木) 07:16:17.90 .net: リファクタリングがだめなのではなく
おまえらがやるからだめなのだ
146 ：仕様書無しさん：2018/04/19(木) 07:34:45.44 .net: >>144
駄目コード（ウィルスみたいなもん）をばら撒いてから治療なんて無理だからねえ。
147 ：仕様書無しさん：2018/04/19(木) 08:13:02.34 .net: 結局は客がデグレを笑って許してくれるかどうかな気がしてきた
148 ：仕様書無しさん：2018/04/19(木) 09:20:08.21 .net: でかくてモノリシックなシステムを複数のマイクロサービスにリファクタリングしたけど、
デグレなんて起きなかったな
149 ：仕様書無しさん：2018/04/19(木) 09:40:04.23 .net: >>147
だからデグレは複雑なコードのまま変更するほうが
リスク高いんですってばw
150 ：仕様書無しさん：2018/04/19(木) 09:44:31.35 .net: >>149
リファクタリングは処理の内容を変えないで
コードをわかりやすく再配置するだけだから
デグレのリクスはすごく低いんだよね

>>145
リファクタリングがだめなのではなく
闇雲に修正するのがだめなのだ
151 ：仕様書無しさん：2018/04/19(木) 10:41:14.32 .net: >>150
> リファクタリングは処理の内容を変えないで
> コードをわかりやすく再配置するだけだから

外側は変えないけど内容は変えますよ
なに言ってるんですか
152 ：KAC：2018/04/19(木) 15:09:42.31 .net: >>149
難解なコードを読み解いて修正前に正しく把握するのは難しいという主張？
153 ：仕様書無しさん：2018/04/19(木) 16:40:47.18 .net: リファクタ厨はその時々でリファクタリングの定義を変えるので話にならない
正反対のことを平気でメリットとして主張してくる
154 ：仕様書無しさん：2018/04/19(木) 20:32:34.99 .net: >>144
わからないことや見えないことを逆に肯定理由にする
宗教家と同じ手口だな！
155 ：仕様書無しさん：2018/04/19(木) 21:36:48.00 .net: ある程度経過したコードは捨てろ。
リファクタなんぞせず。

さらにある程度経過したシステムは捨てろ。
リファクタなんぞせず。
156 ：仕様書無しさん：2018/04/19(木) 21:39:51.72 .net: >>151
実装は変えるけど、処理の内容は変えませんよｗ
処理の内容っていうのは、1から1000までの数を足すとかいうことです。

forループを使うとか、計算式を使うっていうのは
実装であって処理の内容じゃありません
157 ：仕様書無しさん：2018/04/19(木) 21:40:23.43 .net: >>152
> 難解なコードを読み解いて修正前に正しく把握するのは難しいという主張？

違う。時間がかかるという主張
158 ：仕様書無しさん：2018/04/19(木) 21:45:12.79 .net: コーダーの時間が現実のリスクとのトレードオフに値するだろうか？
159 ：KAC：2018/04/19(木) 21:49:39.33 .net: >>157
解読せずにリファクタリングすると酷いことになるだけだぞ？
160 ：仕様書無しさん：2018/04/19(木) 21:52:17.10 .net: >>156
どのように実装するかというのが処理の内容だから
リファクタリングで変更しないのは外部仕様な
内側は変えていいんですよ
161 ：仕様書無しさん：2018/04/19(木) 21:56:06.09 .net: 改修のためのリファクタリングって15年前ぐらいの考え方
今さら熱く語るようなトピックでもない
162 ：仕様書無しさん：2018/04/19(木) 21:57:46.81 .net: >>159
> 解読せずにリファクタリングすると酷いことになるだけだぞ？

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

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

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

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

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

何回も同じこと言ってるんだけどなｗ
163 ：仕様書無しさん：2018/04/19(木) 22:01:18.70 .net: あと解読するときも、最初から最後まで想像して解読するよりも
簡単なところから一歩ずつやったほうがいいよ
164 ：仕様書無しさん：2018/04/19(木) 22:06:50.19 .net: >>161
リファクタ病患者の闘病のために必要
165 ：仕様書無しさん：2018/04/19(木) 22:07:26.56 .net: >>164
君みたいに突っかかってるやつのためだよｗ
166 ：仕様書無しさん：2018/04/19(木) 22:11:04.54 .net: まったり普通にまともなこと言っても誰も相手してくんないし
167 ：仕様書無しさん：2018/04/19(木) 22:23:27.27 .net: 本質的に複雑なものはどうやったって複雑なので、考えるべきは複雑さをどこに押し込めるかだ
複雑な処理もリファクタリングすればシンプルになると信じてる奴は、まあ本質的には簡単なことしかやってないんだろう
例えば、SQLがわからないユーザーのために、DBにUIを提供するだけのCRUDアプリとか
168 ：仕様書無しさん：2018/04/19(木) 22:25:12.05 .net: 関数レベルのリファクタリングじゃ抜本的な設計改善にはならないからなぁ
やらないよりはやった方がいいけど、まぁ趣味の話だな
169 ：仕様書無しさん：2018/04/19(木) 22:29:02.98 .net: >>167

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

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

客は本質的に複雑なものばかり、求めてるんですか？
客が求めてるものは簡単なものばかりですよ。
170 ：仕様書無しさん：2018/04/19(木) 22:34:00.95 .net: >>168
設計ってどこまで含んでいってる？
クラス設計は？どういうメソッドが有るとか
どういう階層をしているかとか
171 ：仕様書無しさん：2018/04/19(木) 22:36:08.75 .net: データベース設計なら、まんまデータベースリファクタリングって
本があるけどもう売ってないな
172 ：仕様書無しさん：2018/04/19(木) 22:48:51.20 .net: >>169
本質的に簡単なことって、頑張れば誰にでもできるじゃん？
実際、キャリアの少ない若手プログラマだって、先輩やらの手助けを受けつつもちゃんと動くコードを書いて納品してるわけで

たかだか数年の経験しかないプログラマにでもやれなくはない程度の仕事を、ああだこうだいって多少整理された状態に
持っていくのがお前の言うリファクタリングでしょ？
まぁ誰かがやらなきゃいけない仕事なんだろうけど、それって汚いコードを書く奴の尻拭い以上のものではないし、
ドヤって語るほどのもんでもないように思うけどなー
173 ：仕様書無しさん：2018/04/19(木) 23:02:09.88 .net: 改修後に予定されているテストでカバーできる範囲でリファクタするというのは
ひとつの答えのようにおもえる

あとはリファクタしたほうが本当にましになってるのかという問題
174 ：仕様書無しさん：2018/04/19(木) 23:05:48.73 .net: >>172
> 本質的に簡単なことって、頑張れば誰にでもできるじゃん？

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

でもそれじゃだめだよね
コストと時間がかかってるんだから
175 ：仕様書無しさん：2018/04/19(木) 23:05:50.09 .net: リファクタじゃなくてリジェクト
176 ：仕様書無しさん：2018/04/19(木) 23:07:11.05 .net: 関係ないけど安定した共通化部分から
関数抽出して使いまわしたいんだけど
やっていいもんじゃろか？
177 ：仕様書無しさん：2018/04/19(木) 23:13:04.60 .net: >>173
将棋でも自分の指した手がいい手かどうかわからない人いるよね。
初心者？上級者？

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

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

まあ、初心者なら仕方ないけど、そういう人は
コードメトリクスを計測したら良いよ。
客観的に良いか悪いかを判断してくれる。
178 ：仕様書無しさん：2018/04/19(木) 23:16:49.13 .net: >>177
>自分の指した手が良いかどうかわからないってことは
>恥ずかしいことだと思ったほうが良い。

やっぱりやらないに越したことはないな！
179 ：仕様書無しさん：2018/04/19(木) 23:28:59.50 .net: >>178
なんで？
そういう人はコード書いたらダメだって言ってるんだけど？
180 ：仕様書無しさん：2018/04/19(木) 23:30:15.83 .net: 料理が下手な人は料理をしないほうが良い
181 ：仕様書無しさん：2018/04/19(木) 23:33:30.35 .net: 人の問題なのか、技術の問題なのか
その区別ぐらいはできるだろうけどな

俺が運転すると事故るから
車はだめだみたいな。
182 ：KAC：2018/04/19(木) 23:44:08.24 .net: >>162
改造するのは解読に時間がかかる
リファクタリングすると解読に時間がかかる

で、何がメリットだって主張？
183 ：仕様書無しさん：2018/04/19(木) 23:53:59.72 .net: >>182
二行目が繋がってない、つまらんからやり直して。
184 ：仕様書無しさん：2018/04/20(金) 00:03:23.46 .net: >>182
コピペしろって言ってる？

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

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

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

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

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

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

何回も同じこと言ってるんだけどなｗ
185 ：仕様書無しさん：2018/04/20(金) 02:23:37.72 .net: >>184
冗長な文章だな
186 ：KAC：2018/04/20(金) 07:25:56.11 .net: >>184
リファクタリングに時間がかかるって主張だよな？
187 ：仕様書無しさん：2018/04/20(金) 14:41:02.18 .net: 数字を入力するのにテンキー使う奴の地雷率は100%
188 ：仕様書無しさん：2018/04/20(金) 19:02:31.75 .net: ソフトウエアの問題は
どんなに技術的に見えようとも
人間の問題である

って偉い人が言ってた
189 ：仕様書無しさん：2018/04/20(金) 19:05:43.41 .net: >>188
(底辺ではなwww)

が抜けてる
190 ：仕様書無しさん：2018/04/20(金) 21:52:25.40 .net: 問題というのは人間の主観的認識なのだから
人間の問題でない問題などというものがあろうか？
191 ：仕様書無しさん：2018/04/20(金) 23:16:13.44 .net: >>186
> リファクタリングに時間がかかるって主張だよな？

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

時間がかかるのは、コードの修正。
リファクタリングしなくても時間がかかる
192 ：仕様書無しさん：2018/04/20(金) 23:20:25.44 .net: 正確に言えばコードの修正を始めるまでの
コードを解析している時間だな

たった一行の修正なのにこんなにするんですか！？って
言われるぐらいの費用になるのは、"コードのタイピング"には
含まれない部分がたくさんある
193 ：KAC：2018/04/20(金) 23:23:17.89 .net: >>192
で、コードを解析する時間は
　リファクタリング　＞　一部修正
だって理解できないの？

「リファクタリング終わったコードを修正する時間は短い」
という主張に誤りは無いが、
リファクタリングする時間を無視してどうする。
194 ：仕様書無しさん：2018/04/20(金) 23:23:47.05 .net: >>190
そういうレベルの人はコードメトリクスを計測するツールを使ったほうが良い
ツールで問題が有るとされたコードはほぼ確実に問題が有る
195 ：仕様書無しさん：2018/04/20(金) 23:28:17.97 .net: >>193
> で、コードを解析する時間は
解析する時間って言ったのに、お前

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

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

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

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

こうだからな。

ぐちゃぐちゃに絡み合った紐の束から、少しづつ結び目をときながら、
適切な一本を抜き出すのと、結び目をとかずに適切な一本だけを抜き出すの
どちらが簡単なのかを考えればわかるだろ
スパゲティコードとはよく言ったものだｗ
196 ：仕様書無しさん：2018/04/20(金) 23:42:05.55 .net: >>194
それはそれでわかったが

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

リファクタする奴は思考が支離滅裂だな
197 ：仕様書無しさん：2018/04/21(土) 00:05:35.08 .net: あぁ、問題は全て、人間の主観的な問題！というのが間違いだよ、
客観的な問題も有るよっていったのが通じてないのか
話が分からんやつは困るな
198 ：KAC：2018/04/21(土) 00:14:22.07 .net: >>195
お前さん、開発したこと無いの？

一部の修正の為に必要な解析情報量と
リファクタリングに必要な解析情報量の
違いすらわからないなら
解析の仕方がおかしいか、
内容を十分理解せずにリファクタリングしてるって事。
199 ：仕様書無しさん：2018/04/21(土) 00:17:57.77 .net: >リファクタリングしながら解析する時間　＜　一部修正のために解析する時間

個人的経験から断固として異議を唱えたい
200 ：仕様書無しさん：2018/04/21(土) 00:19:59.16 .net: >>199
もしかしてリファクタリング、溜まってるんですか？
201 ：仕様書無しさん：2018/04/21(土) 00:21:01.32 .net: >>196
リファクタ厨は毎回そんなもんだよ
202 ：仕様書無しさん：2018/04/21(土) 00:23:24.27 .net: つーかさ、誰も100%納得がいくまで
リファクタリングしろなんていってないんだよ。
修正する所、どちらにしろテストが必要な所
関係がある所を、少しづつやればいい。

時間がかかるっていうのは、それはいつも手遅れの
コードばかりだって自覚有るからじゃねーの？
203 ：仕様書無しさん：2018/04/21(土) 00:24:30.08 .net: でもメリットが欠片も見えないな
204 ：仕様書無しさん：2018/04/21(土) 00:25:43.38 .net: >>142でも書いたが、
リファクタリング＝大規模なものしかイメージできてないって
状態がそもそもやばいよ

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

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

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

リファクタリングは、機能追加や変更に伴う作業に
含まれているべきものですよ
205 ：仕様書無しさん：2018/04/21(土) 00:26:03.25 .net: >>203
何度も書いた。コピペしかしないよ？
206 ：仕様書無しさん：2018/04/21(土) 00:26:42.60 .net: リファクタリングをしたから具体的にどういうコードがどうなってそれでどのくらい得になるのかわからない
207 ：仕様書無しさん：2018/04/21(土) 00:27:48.92 .net: >>205
え？説明になってないじゃん
208 ：仕様書無しさん：2018/04/21(土) 00:28:36.97 .net: >>206
そういう実例が書いてある本を紹介すればいいの？
209 ：仕様書無しさん：2018/04/21(土) 00:29:13.26 .net: >>207
ん？すでに過去レスで書いたって言ってるんだけど、
お前はどのレスが「説明」だと思ったの？
210 ：仕様書無しさん：2018/04/21(土) 00:29:45.71 .net: 肝心のマーチン本からして何が得なのかよくわからん有様
211 ：仕様書無しさん：2018/04/21(土) 00:31:35.22 .net: 本読んでもコードがどうなるかも分からんの？
212 ：仕様書無しさん：2018/04/21(土) 00:33:26.89 .net: 理解がちょっとづつ歪んでいくな
リファクタでも同じように処理をちょっとずつゆがめて気が付かずにいるにちがいない
213 ：仕様書無しさん：2018/04/21(土) 00:33:29.19 .net: >>209
いや、ここまでそんなレス1つも無いから
214 ：仕様書無しさん：2018/04/21(土) 00:35:02.56 .net: https://blogs.yahoo.co.jp/mathweather4067/5819997.html

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

まさにコレだな
215 ：仕様書無しさん：2018/04/21(土) 00:35:26.46 .net: >>213
でも説明なってないと判断したレスがあるわけでしょう？
216 ：仕様書無しさん：2018/04/21(土) 00:35:28.22 .net: >>212
自分の都合のいいように捏造と曲解ばっかりしてるよね
一度もまともな実績がないくせに何で役に立つって言うんだろうね
どうせ数字も捏造してんだろう
217 ：仕様書無しさん：2018/04/21(土) 00:38:32.40 .net: >>216
曲解って俺が先に指摘したんだけど、
言われて悔しかったからって自分も使おうとしないでよｗ
どれが曲解かを指摘してない以上意味ないよ
218 ：仕様書無しさん：2018/04/21(土) 00:42:39.66 .net: いやリファクタ野郎のことね
219 ：仕様書無しさん：2018/04/21(土) 00:43:50.39 .net: お前のことだよｗ
220 ：仕様書無しさん：2018/04/21(土) 00:45:19.25 .net: >>214
そいつの説明が悪すぎる、良さってなんやねん

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

本当に理解してたら必要性や可能になることを明確に説明できるはず
221 ：仕様書無しさん：2018/04/21(土) 00:53:21.22 .net: 本当に理解している本の作者が
十分以上に説明してるんだけどなぁ
222 ：仕様書無しさん：2018/04/21(土) 00:57:49.37 .net: 修正ってほんの数行程度なのに対して
リファクタリングってほぼ全域書き換えでしょ？
そりゃ影響範囲が違いすぎるよ
223 ：仕様書無しさん：2018/04/21(土) 01:00:47.75 .net: 読んだ上でいってんのか？

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

大規模リファクタリングなんてのはあってはだめ
リファクタリングだけのための作業なんて持っての他
224 ：仕様書無しさん：2018/04/21(土) 01:19:48.95 .net: 大規模リファクタリングもありえるよ
こまめにって言ってるのは、せいぜい関数レベルのリファクタリングの話でしょ
まだそれぐらいしか任せてもらえない立場なのかもしれないが、リファクタリングってそれだけじゃないから
225 ：仕様書無しさん：2018/04/21(土) 06:51:17.73 .net: じゃこう考えよう

リファクタリングは
テストコードのデバッグ
226 ：仕様書無しさん：2018/04/21(土) 07:13:19.41 .net: もうコーディング=リファクタリングでええやん
227 ：仕様書無しさん：2018/04/21(土) 07:29:41.93 .net: >>222
あほすｗｗｗ
228 ：仕様書無しさん：2018/04/21(土) 08:09:45.92 .net: なんで、こんな派遣すら首になるようなリファクタバカを相手にしてるの？

基地外に何言っても無駄だよ。
相手の言葉を聞く能力がないからキチガイにして派遣すら首になってんだから。
229 ：仕様書無しさん：2018/04/21(土) 08:59:08.52 .net: >>223
214のどこを読めばそのレスとつながるのか
ＩＤ出ない板で自分がわかれば相手もわかるとか思ってるとか
230 ：仕様書無しさん：2018/04/21(土) 09:04:26.73 .net: あれ？
231 ：仕様書無しさん：2018/04/21(土) 10:33:35.84 .net: >>229
なぜ>>214に対してのレスだと思ったのか？
232 ：仕様書無しさん：2018/04/21(土) 11:12:38.42 .net: なぜだろう
233 ：仕様書無しさん：2018/04/21(土) 11:24:43.22 .net: >>224
それって
リファクタリングじゃなくて
リプレース
234 ：仕様書無しさん：2018/04/21(土) 12:10:29.62 .net: どんなきれいなソースコードでも
プログラムから仕様を起こすのは大変

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

つまり、リファクタリングなんぞ不要
235 ：仕様書無しさん：2018/04/21(土) 12:12:22.10 .net: やっぱ
日本人のソフト開発って
土木工事想定なのな
236 ：仕様書無しさん：2018/04/21(土) 12:14:21.71 .net: 日本は土建と同じ構造

世界は基本的に内製
237 ：仕様書無しさん：2018/04/21(土) 23:35:59.80 .net: CIAすらアマゾンに開発委託したってのに
238 ：仕様書無しさん：2018/04/22(日) 00:00:17.09 .net: >>233
リプレースとリファクタリングを混同するな
239 ：仕様書無しさん：2018/04/22(日) 06:53:14.54 .net: >>238
区別の仕方は？
240 ：仕様書無しさん：2018/04/22(日) 08:54:37.71 .net: リプレースって、普通の文脈だとシステム置き換えじゃねーの？
コード周りの文脈でリプレースなんて表現するのか？
241 ：仕様書無しさん：2018/04/22(日) 11:36:40.79 .net: ＞大規模リファクタリングもありえるよ

大規模リファクタリングとは
リプレイスの事ではないかと言う主張だよ
242 ：仕様書無しさん：2018/04/22(日) 11:37:50.25 .net: どうでもいい
243 ：仕様書無しさん：2018/04/22(日) 11:52:15.63 .net: リプレースってハードウェア更新でしょ？
5年ごとにハードウェアを最新にして、ついでにソフトウェアも新ハード新OS向けにテストしますよと
で、ほとんどはリビルドで済む話だけど
どさくさにまぎれてちょっと不具合修正しましょうとか機能追加して欲しいとなる
そこにリファクタリングする余地は確かに出てくる
本来必要ないのに修正するという意味ではいかにもリファクタリングだ
244 ：仕様書無しさん：2018/04/22(日) 12:18:50.50 .net: >>243
ずいぶん狭い世界で生きてるんだね
245 ：仕様書無しさん：2018/04/22(日) 12:33:53.96 .net: >>244
転職経験2桁だけど何かいいたいことある？
246 ：仕様書無しさん：2018/04/22(日) 14:21:37.97 .net: 大規模リファクタリングなんてあってはならないと言っちゃった以上、「俺のリファクタリング」より大規模なものは、
リプレースでもなんでもいいけどリファクタリング以外のなにかでないと困るんだもんね
247 ：仕様書無しさん：2018/04/22(日) 14:31:39.67 .net: >>245
狭いね
248 ：仕様書無しさん：2018/04/22(日) 14:34:41.97 .net: >>245
ただのクズやんｗｗｗ
249 ：仕様書無しさん：2018/04/22(日) 14:48:42.49 .net: >>246
リファクタリングの定義は、外部的振る舞いを変えずに
理解や修正が簡単になるように内部構造を改善することなんだが
お前の言うリプレースっていうのは、外部的振る舞いを変えないものってことか？
250 ：仕様書無しさん：2018/04/22(日) 14:49:01.88 .net: > リプレースでもなんでもいいけどリファクタリング以外のなにかでないと困るんだもんね
普通にバージョンアップでは？
251 ：仕様書無しさん：2018/04/22(日) 14:49:53.01 .net: >>245
ｗｗｗ
252 ：仕様書無しさん：2018/04/22(日) 14:52:10.53 .net: >>246
> 大規模リファクタリングなんてあってはならないと言っちゃった以上

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

大規模リファクタリングなんてあってはいけないっていうのは
許されるのは小規模（せいぜい中規模）リファクタリングまでで
リファクタリングだけを大規模にやってはいけないないってことなんだが？
253 ：仕様書無しさん：2018/04/22(日) 14:56:24.55 .net: なんで大規模リファクタリングがあってはならないのかというと
リファクタリングは、機能変更の中に含まれる、
通常のソースコード変更時に、こまめに行うものだから

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

大規模リファクタリングのほとんどは単なる改修という意味になっていて
リファクタリングとなってない事が多い
254 ：仕様書無しさん：2018/04/22(日) 14:58:32.10 .net: >>243
> 本来必要ないのに修正するという意味ではいかにもリファクタリングだ

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

必要ないのに修正するのがリファクタリングなんて定義初めて聞いたわw
どーこーの、定義ですか？ソースくださいｗ
255 ：仕様書無しさん：2018/04/22(日) 15:01:25.15 .net: >>243

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

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

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

不具合修正（リファクタリング含む） or 機能追加（リファクタリング含む）
である
256 ：仕様書無しさん：2018/04/22(日) 15:05:42.64 .net: >>247
そんなことないと思うけど

>>248
そんなことないと思うけど
一社童貞のやつよりよっぽどマシ
257 ：仕様書無しさん：2018/04/22(日) 15:14:25.01 .net: >>249
俺自身は発言の中でリプレースとはどういうものかとはなにも規定してませんが
まぁ外部的振る舞いという面で考えると、変わる場合もあれば変わらない場合もあるよね当然
で、たまたま外部的振る舞いが変わらなかったとしても、それをリファクタリングとは呼ばないよね
258 ：仕様書無しさん：2018/04/22(日) 15:15:34.88 .net: >>252
中規模って具体的には？
259 ：仕様書無しさん：2018/04/22(日) 15:20:59.81 .net: >>256
なぜ？
260 ：仕様書無しさん：2018/04/22(日) 15:21:57.33 .net: > で、たまたま外部的振る舞いが変わらなかったとしても、それをリファクタリングとは呼ばないよね

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

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

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

テストを実行して、外部的振る舞いが変わらないのを確認するのが
リファクタリングだから、修正のたびに何度も "意図的に" 外部的振る舞いが
変わってないことを確認してる（だからたまたまなんて思わない）
261 ：仕様書無しさん：2018/04/22(日) 15:23:41.48 .net: >>253
普段の改修の中でこまめに行うものだけがリファクタリングじゃないよ
プログラム全体に波及するような設計の変更は、ボーイスカウトルールに則ってるだけじゃやれないからね
262 ：仕様書無しさん：2018/04/22(日) 15:24:49.90 .net: 意図的に外部的振る舞いが変わらない形で修正して
確認するのがリファクタリングだから、
たまたま動きが変わらないのは、単なるソースコードの変更ってことか
多いんだよな、単なるソースコードの変更をリファクタリングとか言ってるやつ
263 ：仕様書無しさん：2018/04/22(日) 15:25:29.52 .net: >>261
プログラム全体に波及するような設計の変更を
こまめにやるってだけですが？
264 ：仕様書無しさん：2018/04/22(日) 15:29:59.37 .net: プログラム全体に波及するような設計の変更を
こまめにやるためのテクニックも↓に書いてありますよ。

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

えいやってやるしかないと思ってるのは
単にその力がないだけ
265 ：仕様書無しさん：2018/04/22(日) 15:32:00.64 .net: テストしないでコード整理するのも時には必要
あまりにも悲惨なコードに短時間で多数の機能を追加しなきゃならん時とかね
多少のミスは割り切ってリファクタリングして機能追加して全体を手動テストして納品する
俺はこれをエクストリームリファクタリングと呼んでる
厳密なリファクタリング信者からすると気持ちわるいかもしれないが生産性は高い
266 ：仕様書無しさん：2018/04/22(日) 15:35:23.66 .net: >>258
ド素人か？
この業界で中規模と言ったら1000行以上、1万行未満のことだ
267 ：仕様書無しさん：2018/04/22(日) 15:35:46.27 .net: 経験が少ないと、大規模リファクタリングの必要性に直面する状況が想像できないかもしれない
そういう場面も多々あるもんだけどね
268 ：仕様書無しさん：2018/04/22(日) 15:35:59.41 .net: >>259
井の中の蛙と大海の大ウミガメの違いと言えばおわかりになるでしょうか
269 ：仕様書無しさん：2018/04/22(日) 15:39:24.39 .net: >>265
うん。だから動きが変わるかもしれないわけでしょ？
それは単なる修正って言えば良いんだよ。
リファクタリングと呼ばなければいい

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

こまめにリファクタリングしなかったから、
ソースコードに限界が来てしまった場合に
大規模リファクタリングになるって言ってるじゃないか
（そういう自体になる前にこまめにリファクタリングしよう）
270 ：仕様書無しさん：2018/04/22(日) 15:40:10.62 .net: >>265
そんなのファウラーの本に書いてあるか？
あの基本書の内容を踏襲していない行為をリファクタリングとは呼びませんよ？
271 ：仕様書無しさん：2018/04/22(日) 15:40:31.92 .net: >>267
×　経験が少ないと、大規模リファクタリングの必要性に直面する状況が想像できないかもしれない
○　経験が少ないと、大規模改修の必要性に直面する状況が想像できないかもしれない

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

リファクタリングを単なる改修の意味で使わないでください
272 ：仕様書無しさん：2018/04/22(日) 15:41:21.46 .net: >>270
> あの基本書の内容を踏襲していない行為をリファクタリングとは呼びませんよ？

そうですね。基本書の内容を踏襲していない行為は
リファクタリングと呼んではいけません。
ただの改修と言いましょう
273 ：仕様書無しさん：2018/04/22(日) 15:42:30.64 .net: なんで改修をリファクタリングって言いたいんだろう？
かっこつけたいのかな？
274 ：仕様書無しさん：2018/04/22(日) 15:43:40.96 .net: 言葉の定義とかつまらんからもっと益になる話しようぜぇ

グローバル変数(public static 変数も含む)を安全に排除するリファクタリングテクニックについて議論しよう
リファクタリングするときいつもこれだけはスマートに解決できない
リスクを背負って修正するしかなくなる
275 ：仕様書無しさん：2018/04/22(日) 15:46:22.63 .net: 大勃起リファクタリングと聞いて
276 ：仕様書無しさん：2018/04/22(日) 15:49:05.55 .net: >> 271
> なんでリファクタリングじゃないものを
> リファクタリングって呼ぶんですか？

お前にとっての「僕のリファクタリング」なんて知らんがな
277 ：仕様書無しさん：2018/04/22(日) 15:54:49.49 .net: 動脈から直接リファクタリングを投与した
278 ：仕様書無しさん：2018/04/22(日) 15:56:28.91 .net: >>276
俺にとってのとかじゃなくて
リファクタリングの正しい定義だ
ちゃんと調べてこいよ。
単なる改修の意味で使うな
279 ：仕様書無しさん：2018/04/22(日) 15:59:46.87 .net: 最初に書いたテストがリファクタリングの前後で同様に動くとは限らない
壊れたテストを書き直すのもリファクタリングの一部
280 ：仕様書無しさん：2018/04/22(日) 16:02:17.79 .net: >>268
意味不明
281 ：仕様書無しさん：2018/04/22(日) 16:06:43.03 .net: >>278
大規模なものは改修で、小規模なものはリファクタリング？
282 ：仕様書無しさん：2018/04/22(日) 16:09:52.55 .net: ここまで技術的な話題ゼロｗｗｗマ板は素人しかいないってホントだったのか
283 ：仕様書無しさん：2018/04/22(日) 16:10:33.85 .net: >>281
なんでまた曲解するの？
２つの別々の話を混ぜないように

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

2. 大規模リファクタリングが必要になるのは
普段からこまめにリファクタリングしてないから。
普段の改修の中でこまめにリファクタリングしていれば大規模なんて必要ない。
必要になるのは普段からリファクタリングしてなくて、
手遅れ状態になってる証拠。そういうのはあってはだめ
284 ：仕様書無しさん：2018/04/22(日) 16:37:26.44 .net: リファクタリングは小まめに行うべきか？
ある程度たまってから行うべきか？

結論：リファクタリングが不要になるように書け！
285 ：仕様書無しさん：2018/04/22(日) 16:38:45.75 .net: 将来の改修や拡張の方向性がわからないのにんあことできるわけないだろ！
286 ：仕様書無しさん：2018/04/22(日) 16:55:29.35 .net: リファクタリングはソースの修正が必要だから行う
つまりソースの修正が必要なくなればいい
データベースでいうところの、UPDATEではなくINSERTになるようにすればいい
つまり、適切な粒度で関数（メソッド）を適切に作成すれば
リファクタリングは不要なのではないか？
例えば、1関数20行という教えはそういう意味も内包しているのではないか？

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

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

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

以上のことから、「リファクタリングが不要になるように書け！」というのは正しいと言える
287 ：仕様書無しさん：2018/04/22(日) 16:58:10.99 .net: >>280
意味明瞭
288 ：仕様書無しさん：2018/04/22(日) 16:58:35.06 .net: >>286
あー、いや、テストファーストでは
最初にテストコードを書いて、
テストに通る最低限のコードを書いて
そのあとリファクタリングして
完成だから

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

ちょっと勉強し直してきて
289 ：仕様書無しさん：2018/04/22(日) 17:02:47.45 .net: もちろんテストファーストをしないならリファクタリングはしないってことじゃないよ。
先に実装しても、その後テストコードを書いて、それが通るのを維持しながら
ソースコードを読みやすくする。これもリファクタリング
290 ：仕様書無しさん：2018/04/22(日) 17:07:13.80 .net: テストファーストはリファクタリングじゃないですよ
291 ：仕様書無しさん：2018/04/22(日) 17:08:24.89 .net: テストファーストはテストを先に書くってだけで
リファクタリングを内包するわけじゃないですよ
292 ：仕様書無しさん：2018/04/22(日) 17:08:52.51 .net: テストファーストとリファクタリングは独立した概念です
293 ：仕様書無しさん：2018/04/22(日) 17:08:57.78 .net: >>290
テストファーストの手順の中に含まれるものだって話をしてるんだから
テストファースト＝リファクタリングなわけないでしょｗ
お前の日本語の理解力の問題だ
294 ：仕様書無しさん：2018/04/22(日) 17:10:15.59 .net: http://www.itmedia.co.jp/im/articles/0602/24/news137.html

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

へー、このスレ勉強になるな
295 ：仕様書無しさん：2018/04/22(日) 17:11:11.12 .net: 個人的にそういうやり方をやってるってだけで
テストファーストとリファクタリングは根本的に異なり
完全に独立して成り立つものですよ
296 ：仕様書無しさん：2018/04/22(日) 17:12:42.21 .net: テストファーストにリファクタリングは必要ありません
むしろテストファーストの目的を没却する悪手と言っていいでしょう
297 ：仕様書無しさん：2018/04/22(日) 17:14:01.77 .net: >>287
意味不明
298 ：仕様書無しさん：2018/04/22(日) 17:14:35.76 .net: テストファーストでリファクタリングが必要になるなら
テストの粒度が間違っている証拠です、にわかがよくやります
299 ：仕様書無しさん：2018/04/22(日) 17:14:49.44 .net: >>295
そりゃそうだろｗ
だからこそ、テストファーストしてから
リファクタリングするって話になる
300 ：仕様書無しさん：2018/04/22(日) 17:14:49.71 .net: >>297
意味明瞭
301 ：仕様書無しさん：2018/04/22(日) 17:15:28.25 .net: >>299
ではテストファーストとリファクタリングを一緒に語るのをやめるべきです
302 ：仕様書無しさん：2018/04/22(日) 17:15:31.11 .net: >>298
でも、ぐぐったけど、そんな事ないてないよ
ニワカはお前では？
303 ：仕様書無しさん：2018/04/22(日) 17:15:38.76 .net: テストしないでリファクタリングおっかない
304 ：仕様書無しさん：2018/04/22(日) 17:16:22.76 .net: >>302
ググらないとわからないならお前がにわかです
305 ：仕様書無しさん：2018/04/22(日) 17:16:56.81 .net: >>300
意味不明
306 ：仕様書無しさん：2018/04/22(日) 17:17:37.22 .net: >>305
意味明瞭
307 ：仕様書無しさん：2018/04/22(日) 17:18:09.05 .net: >>301
はい。だからリファクタリングだけでも話をしています。

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

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

開発の前にテストコードを書いてないのでこれはテストファーストではありません。
308 ：仕様書無しさん：2018/04/22(日) 17:18:46.64 .net: >>304
でもお前はググってないで、自分の意見を主張しているわけだよね？
そしてそれが世間で言われてないことがバレたよね？
309 ：仕様書無しさん：2018/04/22(日) 17:18:56.98 .net: >>307
はいじゃないが
310 ：仕様書無しさん：2018/04/22(日) 17:19:25.47 .net: >>308
バレてません、グーグルがなんでも知ってると思うな
311 ：仕様書無しさん：2018/04/22(日) 17:19:51.01 .net: グーグルを神か何かだと思ってるんじゃなかろうかね
312 ：仕様書無しさん：2018/04/22(日) 17:20:34.82 .net: グーグルは知らないが、俺は知ってる。
情報の出どころは教えられないが
俺を信じてくれるよね？
313 ：仕様書無しさん：2018/04/22(日) 17:20:52.25 .net: >>312
はい
314 ：仕様書無しさん：2018/04/22(日) 17:22:08.32 .net: ママぐらいは信じてくれるんじゃねーの？ｗ
315 ：仕様書無しさん：2018/04/22(日) 17:26:27.77 .net: >>306
意味不明
316 ：仕様書無しさん：2018/04/22(日) 17:29:39.31 .net: >>315
意味明瞭
317 ：仕様書無しさん：2018/04/22(日) 17:30:08.17 .net: >>316
意味不明
318 ：仕様書無しさん：2018/04/22(日) 17:30:32.03 .net: >>317
意味明瞭
319 ：仕様書無しさん：2018/04/22(日) 17:31:10.19 .net: リファクタリングの定義がないから仕方ない。

コードをいじってばかりのやつは、手段と目的が逆転している。
320 ：仕様書無しさん：2018/04/22(日) 17:31:43.76 .net: >>318
意味不明
321 ：仕様書無しさん：2018/04/22(日) 17:32:16.13 .net: >>320
意味明瞭
322 ：仕様書無しさん：2018/04/22(日) 17:32:34.25 .net: >>318
お前「意味明瞭」でググってみろｗｗｗ
323 ：仕様書無しさん：2018/04/22(日) 17:32:48.05 .net: >>321
意味不明
324 ：仕様書無しさん：2018/04/22(日) 17:33:03.99 .net: 意味明瞭ってなんだよ
325 ：仕様書無しさん：2018/04/22(日) 17:33:33.32 .net: >>324
日本人じゃないんだろ
326 ：仕様書無しさん：2018/04/22(日) 17:33:40.70 .net: >>323
意味明瞭
327 ：仕様書無しさん：2018/04/22(日) 17:34:51.48 .net: >>319
> コードをいじってばかりのやつは、手段と目的が逆転している。

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

目的を実行する時にこまめにやる手段で、手段そのものが目的になってるような
リファクタリングだけの作業とか大規模リファクタリングはおかしいって
言ってるんだが？
328 ：仕様書無しさん：2018/04/22(日) 17:35:16.48 .net: >>325
意味明瞭をわからない人間の方がブラジル人じゃないだろ
329 ：仕様書無しさん：2018/04/22(日) 17:35:49.03 .net: >>324
意味がはっきりわかること
330 ：仕様書無しさん：2018/04/22(日) 17:35:50.61 .net: >>326
意味不明
331 ：仕様書無しさん：2018/04/22(日) 17:36:29.45 .net: >>329
日本人なら普通そんな使い方しない
332 ：仕様書無しさん：2018/04/22(日) 17:36:45.31 .net: >>328
ブラジル人ではないだろうな
333 ：仕様書無しさん：2018/04/22(日) 17:38:05.31 .net: 意味明瞭ワロタｗｗｗ
334 ：仕様書無しさん：2018/04/22(日) 17:38:29.33 .net: >>256
で、これの理由は？
335 ：仕様書無しさん：2018/04/22(日) 17:38:31.57 .net: >>331
お前は普通じゃないし日本人のこと1ミリも理解してない
史実に登場する最初の天皇の名前を言ってみろ
336 ：仕様書無しさん：2018/04/22(日) 17:38:58.60 .net: >>335
ググってみろ
337 ：仕様書無しさん：2018/04/22(日) 17:39:18.98 .net: >>334
>>268
338 ：仕様書無しさん：2018/04/22(日) 17:39:54.17 .net: >>336
はい知らないのな、お前日本人のこと1ミリも理解できてない
339 ：仕様書無しさん：2018/04/22(日) 17:40:09.54 .net: >>335
「意味不明」と「意味明瞭」がちゃんと対照的に使われている例を教えてよ先生
340 ：仕様書無しさん：2018/04/22(日) 17:40:23.74 .net: >>338
キチガイおつ
341 ：仕様書無しさん：2018/04/22(日) 17:40:42.04 .net: >>337
それ理由になってねーよ
342 ：仕様書無しさん：2018/04/22(日) 17:40:56.42 .net: >>338
ググってみろ
343 ：仕様書無しさん：2018/04/22(日) 17:41:12.26 .net: >>338
在日おつ
344 ：仕様書無しさん：2018/04/22(日) 17:41:18.43 .net: 荒らしが飽きたら続きのレスをお願いしますよ
345 ：仕様書無しさん：2018/04/22(日) 17:42:42.76 .net: >>335
うっわ
346 ：仕様書無しさん：2018/04/22(日) 17:43:39.06 .net: ただ、普段からリファクタリングしてたら依頼がきたときに素早く対応できるよね
347 ：仕様書無しさん：2018/04/22(日) 17:43:59.08 .net: >>335
キチガイ
348 ：仕様書無しさん：2018/04/22(日) 17:44:11.09 .net: >>339
「意味不明」とは意味がはっきりしないという意味です
「意味明瞭」とは意味がはっきりしてるという意味です
ゆえにこれらの言葉は対称の関係にあるわけです
349 ：仕様書無しさん：2018/04/22(日) 17:44:39.53 .net: >>335
統合失調症ですねわかります
350 ：仕様書無しさん：2018/04/22(日) 17:44:56.13 .net: >>348
ソース
351 ：仕様書無しさん：2018/04/22(日) 17:45:59.20 .net: >>348
対称と対照の違いもわからないカスがこちら
352 ：仕様書無しさん：2018/04/22(日) 17:47:23.36 .net: >>348
世の中一般の使用例あげろよ、あるんならな
353 ：仕様書無しさん：2018/04/22(日) 17:50:04.15 .net: >>351
対照は文脈的に大間違いだったので訂正しました
わかってないのはお前です、お前がカス
354 ：仕様書無しさん：2018/04/22(日) 17:50:27.92 .net: >>353
やっぱ日本人じゃないな
355 ：仕様書無しさん：2018/04/22(日) 17:50:44.06 .net: >>353
なぜ間違いなの？
356 ：仕様書無しさん：2018/04/22(日) 17:52:10.58 .net: >>352
意味がはっきりわかるときに、意味明瞭と言います
これが一般的な使用例です

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

あなたは自分が無知であるがゆえに意味明瞭という
自分が知らない言葉を使いこなしている僕に嫉妬しています
無知を自覚してください
357 ：仕様書無しさん：2018/04/22(日) 17:52:55.49 .net: >>356
そう言われている具体的な例が未だに出てこない点でアレ
358 ：仕様書無しさん：2018/04/22(日) 17:52:56.99 .net: >>355
対照ではないからです
なぜならば対称しているからです
対照関係と対象関係は明らかに異なります
359 ：仕様書無しさん：2018/04/22(日) 17:53:20.71 .net: >>356
だからその一般的に使用されている例を出してみろよ
360 ：仕様書無しさん：2018/04/22(日) 17:53:46.10 .net: >>358
説明できていないｗｗｗ
361 ：仕様書無しさん：2018/04/22(日) 17:54:00.32 .net: >>358
これ統合失調症やろ
362 ：仕様書無しさん：2018/04/22(日) 17:54:30.05 .net: >>358
対象も出てきたｗｗｗ
363 ：仕様書無しさん：2018/04/22(日) 17:54:30.49 .net: >>357
それでは具体的な例を上げます

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

この上なく具体的で一般的な例を提示しました
あなたはそれでもわからないと言いはるでしょう
しかし、それは自分が知らない事柄が存在することを認められないだけです
無知であるがゆえにあなたのプライドはとても高いのです
364 ：仕様書無しさん：2018/04/22(日) 17:54:57.96 .net: >>363
お前の頭の中を書き出してもそれは一般的とは言わない
365 ：仕様書無しさん：2018/04/22(日) 17:54:58.76 .net: >>362
ただの書き間違いですよ、残念でしたね
366 ：仕様書無しさん：2018/04/22(日) 17:55:15.31 .net: >>358
そら対象は違うやろ
367 ：仕様書無しさん：2018/04/22(日) 17:55:43.55 .net: >>363
妄想おつ
368 ：仕様書無しさん：2018/04/22(日) 17:55:53.40 .net: >>364
一般的に意味がはっきりわかる場面というのはあるでしょう？
無いんですか？ありますよね、ありますよ
完全に一般的です
369 ：仕様書無しさん：2018/04/22(日) 17:56:10.00 .net: >>363
病院行きなさい
370 ：仕様書無しさん：2018/04/22(日) 17:56:21.60 .net: >>366
ただの書き間違いに一生懸命レスしても意味ないですよ
371 ：仕様書無しさん：2018/04/22(日) 17:56:25.39 .net: >>368
はい統合失調症
372 ：仕様書無しさん：2018/04/22(日) 17:56:48.89 .net: >>369
お前がODAに行けよ、万年引きこもり
373 ：仕様書無しさん：2018/04/22(日) 17:56:56.98 .net: >>370
漢字の違いがミソなのにそれを間違える時点でもうねｗｗｗ
374 ：仕様書無しさん：2018/04/22(日) 17:57:08.36 .net: >>372
うっわ
375 ：仕様書無しさん：2018/04/22(日) 17:57:23.08 .net: >>368
使用例
376 ：仕様書無しさん：2018/04/22(日) 17:57:26.61 .net: >>371
自分が医者だと錯覚してる人の方があれだと思います
377 ：仕様書無しさん：2018/04/22(日) 17:57:54.38 .net: >>368
妄想と現実の区別がつかない状態がこれです
378 ：仕様書無しさん：2018/04/22(日) 17:58:12.96 .net: >>376
それも妄想
379 ：仕様書無しさん：2018/04/22(日) 17:58:51.07 .net: >>376
医者なんて単語一言も出てきてないのに…これが統合失調症
380 ：仕様書無しさん：2018/04/22(日) 17:58:55.43 .net: >>373
打ち間違いなんてよくあることです
校正する人なんて居ないですしここ5chですし
正確さにこだわったところで1紋の得にもならないですし
一生懸命書き間違いを攻めようとしている様、とても滑稽です
381 ：仕様書無しさん：2018/04/22(日) 17:59:27.12 .net: >>379
統合失調症と診断できるのは医者だけですよん
想像力足りてなくないですか？
382 ：仕様書無しさん：2018/04/22(日) 17:59:49.39 .net: >>380
対称と対照の話で対象は書かねーよ
キチガイ以外は
383 ：仕様書無しさん：2018/04/22(日) 18:00:08.18 .net: >>381
だれも診断してない　
妄想おつ
384 ：仕様書無しさん：2018/04/22(日) 18:00:26.15 .net: 統合失調症というのはただの悪口であって
実際に病気かどうかは関係ないよ
世の中で統合失調症って言われてる人で実際に医師の診断受けた人ほとんどいないでしょ？
385 ：仕様書無しさん：2018/04/22(日) 18:00:30.25 .net: >>381
よう統合失調症
386 ：仕様書無しさん：2018/04/22(日) 18:00:50.63 .net: >>381
キチガイとも言う
387 ：仕様書無しさん：2018/04/22(日) 18:01:12.32 .net: >>382
変換ミスっただけだよ
変換ミスっただけでキチガイ呼ばわりとは
そっちの方がむしろあれじゃないですか
388 ：仕様書無しさん：2018/04/22(日) 18:01:55.62 .net: >>383
はい統合失調症って断定してた人いましたよ
妄想じゃないですよ、スレを検索してください
そんな人居ないというあなたの方が妄想乙です
389 ：仕様書無しさん：2018/04/22(日) 18:02:41.19 .net: >>387
変換ミスの話ではない
390 ：仕様書無しさん：2018/04/22(日) 18:02:54.03 .net: >>385
よおキチガイ
391 ：仕様書無しさん：2018/04/22(日) 18:02:54.73 .net: >>388
キチガイ
392 ：仕様書無しさん：2018/04/22(日) 18:03:21.21 .net: >>388
妄想おつ
393 ：仕様書無しさん：2018/04/22(日) 18:03:56.39 .net: >>389
対称を対象と変換ミスった話ですよ
それを変換ミスの話ではないと思ってるなら
それこそ妄想があれですよね
394 ：仕様書無しさん：2018/04/22(日) 18:04:20.08 .net: >>387
漢字の違いが主張のポイントなのにその漢字を間違えるなんてありえない
395 ：仕様書無しさん：2018/04/22(日) 18:04:30.11 .net: >>392
言うに事欠いてそれですかｗ
396 ：仕様書無しさん：2018/04/22(日) 18:05:13.75 .net: >>393
対象の意味を理解してないからそんなことが起こる
397 ：仕様書無しさん：2018/04/22(日) 18:05:31.36 .net: >>395
いうにことかいて
398 ：仕様書無しさん：2018/04/22(日) 18:05:44.70 .net: >>394
間違いは誰にでもありますし
僕は自分のミスを素直に認めていますよ
変換ミスだって、それを一生懸命攻めようとするのは野暮だと思いますし
本来の議論を見失ってると思います
リファクタリングの話をしてましたよね
399 ：仕様書無しさん：2018/04/22(日) 18:06:07.43 .net: >>395
じゃあ何？
400 ：仕様書無しさん：2018/04/22(日) 18:06:52.57 .net: >>398
誰もミスを責めてるんじゃない
統合失調症やな
401 ：仕様書無しさん：2018/04/22(日) 18:07:11.08 .net: >>398
だからミスじゃねーよｗｗｗ
402 ：仕様書無しさん：2018/04/22(日) 18:07:51.59 .net: >>396
意味を理解していようといまいと変換ミスは起こるものですよ
403 ：仕様書無しさん：2018/04/22(日) 18:08:02.47 .net: 意味不明
404 ：仕様書無しさん：2018/04/22(日) 18:08:09.28 .net: >>402
だからそこじゃないってｗｗｗ
405 ：仕様書無しさん：2018/04/22(日) 18:09:34.98 .net: >>401
ミスった本人がミスだと言ってるわけですからミスですよ
いいやお前はミスターだとかそんな寒いこと言おうとしてるんですか？
やめてください
406 ：仕様書無しさん：2018/04/22(日) 18:10:36.56 .net: >>404
そこですよ、僕の些細な変換ミスを針小棒大に大問題だと
大騒ぎしてYahoo!のトップを飾ろうと画策してる人はいないにしても
そこですよ
407 ：仕様書無しさん：2018/04/22(日) 18:10:43.40 .net: >>405
統合失調症やべーな
408 ：仕様書無しさん：2018/04/22(日) 18:11:28.65 .net: >>406
統合失調症こっわ
409 ：仕様書無しさん：2018/04/22(日) 18:12:18.92 .net: で、「意味明瞭」の一般的な使用例はいつになったら出てくるんだい？
410 ：仕様書無しさん：2018/04/22(日) 18:16:57.87 .net: >>409
>>363

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

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

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

僕はそれを悪いことだとは思いませんが無知な人だなって思います
411 ：仕様書無しさん：2018/04/22(日) 18:18:13.23 .net: >>410
お前の妄想じゃなくて、現実世界での使用例を
412 ：仕様書無しさん：2018/04/22(日) 18:18:26.53 .net: >>410
ソース
413 ：仕様書無しさん：2018/04/22(日) 18:19:17.85 .net: >>410
使用例のリンクをいくつか貼るだけなのに何言ってんのこいつ？
414 ：仕様書無しさん：2018/04/22(日) 18:19:53.37 .net: まともな例を見つけられないんだろ
415 ：仕様書無しさん：2018/04/22(日) 18:20:34.20 .net: リファクタリング対象だな
対称でも対照でもなくて
416 ：仕様書無しさん：2018/04/22(日) 18:21:01.08 .net: 意味不明
417 ：仕様書無しさん：2018/04/22(日) 18:21:09.26 .net: >>411
意味がはっきりわかることってありますよね？
現実であなたはそういう経験ないんですか？
僕の妄想の話ではありません、現実にそういうことあるでしょう
そういうときに使います

意味明瞭と言って意味がとてもよくわかりましたと相手に伝えるのです
418 ：仕様書無しさん：2018/04/22(日) 18:21:43.07 .net: >>417
リンク
419 ：仕様書無しさん：2018/04/22(日) 18:21:58.64 .net: >>413
リンクが貼りたいならあなたが貼りなさいよ
何でもかんでも他人に頼ろうとするな
420 ：仕様書無しさん：2018/04/22(日) 18:22:02.44 .net: >>417
頑張ってググるんだ
421 ：仕様書無しさん：2018/04/22(日) 18:22:22.77 .net: >>419
俺はそんな使用例知らないから貼れない
422 ：仕様書無しさん：2018/04/22(日) 18:22:36.81 .net: >>419
存在しないものは貼れない
423 ：仕様書無しさん：2018/04/22(日) 18:23:03.86 .net: >>418
http://medaka.5ch.net/test/read.cgi/prog/1523765624/417
424 ：仕様書無しさん：2018/04/22(日) 18:23:34.28 .net: >>423
死ね
425 ：仕様書無しさん：2018/04/22(日) 18:23:51.16 .net: >>423
妄想から出られないんですね
426 ：仕様書無しさん：2018/04/22(日) 18:24:07.58 .net: >>423
ないんですねわかります
427 ：仕様書無しさん：2018/04/22(日) 18:24:34.86 .net: >>423
自己引用わろた
428 ：仕様書無しさん：2018/04/22(日) 18:24:53.23 .net: >>421
知らないのなら覚えよう
知らないことを自覚したなら
自分の世界を広げよう

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

明瞭というのははっきりわかるという意味です
ゆえに意味明瞭というのは意味がはっきりわかるという意味です
429 ：仕様書無しさん：2018/04/22(日) 18:25:10.05 .net: >>428
リンク
430 ：仕様書無しさん：2018/04/22(日) 18:25:18.61 .net: >>428
ソース
431 ：仕様書無しさん：2018/04/22(日) 18:25:34.34 .net: >>428
また妄想かよ
432 ：仕様書無しさん：2018/04/22(日) 18:26:19.92 .net: >>428
長文はキチガイ
433 ：仕様書無しさん：2018/04/22(日) 18:27:59.08 .net: 意味不明
434 ：仕様書無しさん：2018/04/22(日) 18:28:27.25 .net: >>428
ソース
435 ：仕様書無しさん：2018/04/22(日) 18:28:30.52 .net: >>427
国語辞典には日本書紀のリンクが載ってるが
日本書紀にはリンクなんて存在しないからな
だからといって日本書紀の日本語はデタラメだと言う人は居ないだろ
リンクというのはそもそもインターネットが普及してグーグルという
営利企業がそれによってランク付けをするように成ってから
重要視されるようになっただけで、それがなくても言葉っていうのは
作られていくし伝わっていくし話されていくんだよ、僕はその言葉の
大切さを少しでも伝えられたらと思います
436 ：仕様書無しさん：2018/04/22(日) 18:29:48.17 .net: >>435
ソース
437 ：仕様書無しさん：2018/04/22(日) 18:30:13.69 .net: >>435
オレオレ用語なんですね
438 ：仕様書無しさん：2018/04/22(日) 18:31:03.20 .net: >>430
>>434
ソースは一般社会だ
意味がはっきりわかったときに意味明瞭！と言ってみろ
それで相手に伝わらなかった経験があるわけ？
ないだろうが、意味明瞭というのは完全に一般的な言葉なわけ
439 ：仕様書無しさん：2018/04/22(日) 18:31:47.08 .net: >>437
オレオレ用語ってなんすか？
国語辞典10冊見ても載ってないんすけど、なんすかそれ？
440 ：仕様書無しさん：2018/04/22(日) 18:31:52.75 .net: >>438
完全に一般的な言葉の使用例をいまだに出せないのはなぜ？
441 ：仕様書無しさん：2018/04/22(日) 18:32:25.95 .net: >>439
どの十冊？
442 ：仕様書無しさん：2018/04/22(日) 18:33:01.84 .net: 日本書紀に載ってるんすか？オレオレ用語って
いやマジ、そういうの見たことないんでー、この人日本語苦手なのかなってマジそう思うっすー
443 ：仕様書無しさん：2018/04/22(日) 18:33:44.15 .net: 日本書紀ｗｗｗ
444 ：仕様書無しさん：2018/04/22(日) 18:34:03.60 .net: 糖質vs糖質
春の休日にふさわしいバトルやなww
445 ：仕様書無しさん：2018/04/22(日) 18:34:10.13 .net: きっも
446 ：仕様書無しさん：2018/04/22(日) 18:34:43.43 .net: >>444
バトルになってなくね？
447 ：仕様書無しさん：2018/04/22(日) 18:35:08.84 .net: >>441
明鏡、明解、日本、現国、基準、共明、共立、新日国、現銘、金田一
の10冊
448 ：仕様書無しさん：2018/04/22(日) 18:36:06.22 .net: >>447
すごーい君は国語辞典たくさん持ってるフレンズなんだね
449 ：仕様書無しさん：2018/04/22(日) 18:36:52.27 .net: >>448
IT社会だから、紙の本は殆どないけどね
いつでも検索できるようにしてる
450 ：仕様書無しさん：2018/04/22(日) 18:37:55.48 .net: >>447
すげえそんなにあるんやな
写真見せて
451 ：仕様書無しさん：2018/04/22(日) 18:38:43.91 .net: >>447
その十冊に「意味明瞭」は載ってるのかい？
452 ：仕様書無しさん：2018/04/22(日) 18:39:36.27 .net: >>450
著作権的にアウトだからムリ
漫画村とかも見たらアカンで
5chで無茶言ってもそういうところはきちんとしないと
453 ：仕様書無しさん：2018/04/22(日) 18:40:12.62 .net: >>451
意味明瞭の四字熟語は載ってないけど
意味、明瞭では載ってるよ
454 ：仕様書無しさん：2018/04/22(日) 18:40:36.14 .net: >>452
なぜ無理？
455 ：仕様書無しさん：2018/04/22(日) 18:42:38.30 .net: 意味明瞭と言った場合、意味が明瞭なんだなってわかるっしょ
漢字は表意文字だからそういうことが可能なんだよ
オレオレ用語も、オレオレ、用語という単語が合わさってできてるんだ
オレオレの意味と用語の意味がわかれば、オレオレ用語は辞書に載ってなくても
自分で定義した用語のことなんだなってわかるっしょ

オレオレ用語だという人間が意味明瞭をわかりませんというのは
完全に道理に反してる卑劣な行為だと知ってほしい
456 ：仕様書無しさん：2018/04/22(日) 18:43:05.88 .net: >>453
誰もそれは否定してないやろ
457 ：仕様書無しさん：2018/04/22(日) 18:43:59.99 .net: >>455
だからその使用例を出してみなって
出せないのは普通そんな使い方しないからやろ
458 ：仕様書無しさん：2018/04/22(日) 18:44:17.72 .net: >>453
そらそうだｗｗｗ
459 ：仕様書無しさん：2018/04/22(日) 18:45:27.68 .net: >>454
著作権法的に違法行為にあたるからムリなんだ
僕は法律は守りたい、なぜならば法律は社会を成り立たせる
ためにあるものだし、一人ひとりがそれを尊重することによって
法律は成り立つし、それによって社会が成り立つから
法律に違反するというのは社会を否定することであるし
社会を否定して生きていけるほど僕は強くないから
460 ：仕様書無しさん：2018/04/22(日) 18:45:52.93 .net: >>455
使用例
461 ：仕様書無しさん：2018/04/22(日) 18:46:03.35 .net: >>459
なぜ？
462 ：仕様書無しさん：2018/04/22(日) 18:46:56.21 .net: >>459
誰も辞書の中身を写せなんて言ってなくね？持ってる辞書のパッケージ写すだけなら何が問題なの？
463 ：仕様書無しさん：2018/04/22(日) 18:47:28.58 .net: >>457
使用例は
意味がはっきりわかったときに「意味明瞭だ」と言うんだよ
これが使用例です、普通というのはあなたの日常では使いませんという
意味ですよね、それはあなたの語彙が足りてないから使えてないだけで
このスレであなたは新たな語彙を獲得したんだから、是非使っていって欲しい
と僕は思うわけです
464 ：仕様書無しさん：2018/04/22(日) 18:48:03.50 .net: >>447
正式名称教えておくれ
465 ：仕様書無しさん：2018/04/22(日) 18:48:20.50 .net: >>463
ソース
466 ：仕様書無しさん：2018/04/22(日) 18:48:37.07 .net: >>463
妄想おつ
467 ：仕様書無しさん：2018/04/22(日) 18:48:37.69 .net: >>462
IT社会だから辞書はコンピュータから検索できるようにしていて
そのUIは独自のもので秘匿が原則であることが記されているから
お示しすることはできないというわけです
468 ：仕様書無しさん：2018/04/22(日) 18:49:31.52 .net: >>467
典型的な嘘やな
469 ：仕様書無しさん：2018/04/22(日) 18:50:06.73 .net: >>467
この古臭さはどこから？
470 ：仕様書無しさん：2018/04/22(日) 18:52:01.63 .net: 意味不明
471 ：仕様書無しさん：2018/04/22(日) 18:55:07.63 .net: >>467
IT社会
コンピュータ

うーん
472 ：仕様書無しさん：2018/04/22(日) 18:56:12.13 .net: >>468
仮にそれが嘘だとしても、意味明瞭が「意味がはっきりわかること」
に変わりはないんだからね!?

>>469
仮にそれが古臭いとしても意味明瞭が「意味がはっきりわかること」
を意味することに異論はないでしょ？
473 ：仕様書無しさん：2018/04/22(日) 18:57:35.06 .net: >>472
ソース
474 ：仕様書無しさん：2018/04/22(日) 19:02:06.16 .net: 本当はわかってるくせにわからない振りをしてるだけですよね
意味明瞭と言って本当にその言葉の意味がわからない人っていますか？
そんな人が本当に居るとしたら、その人はオレオレ用語の意味さえわかりませんよ
言葉は単語のつながりですし、単語の元々の意味が変わることなんてありません
元の単語の意味がつながるだけです

無知な人はわからないわからないと言っていれば良いので
議論において最強と言われることがありますが
そういうことで最強の名を手中に収めて満足できますか？
僕はできませんね、なぜならば無知なだけだからです
ものを知らないだけだからです、知らないことを武器に
偉そうに振る舞って相手を黙らせて何が嬉しいのでしょうか
自分の無知に気づかない本当のバカですよ
475 ：仕様書無しさん：2018/04/22(日) 19:03:36.45 .net: >>474
ソース
476 ：仕様書無しさん：2018/04/22(日) 19:03:49.80 .net: >>474
長文はキチガイ
477 ：仕様書無しさん：2018/04/22(日) 19:06:34.92 .net: >>476
短文は知恵遅れ
みたいな

やめましょうよそういう煽り合いみたいなの
知性ある議論がしたいです
478 ：仕様書無しさん：2018/04/22(日) 19:07:58.86 .net: >>475
ソースが必要な部分あるか？ｗ
479 ：仕様書無しさん：2018/04/22(日) 19:24:09.78 .net: >>474
長文はキチガイ
480 ：仕様書無しさん：2018/04/22(日) 19:24:43.46 .net: 「意味明瞭」で検索しても、一件もヒットしないんだが？
481 ：仕様書無しさん：2018/04/22(日) 19:29:17.78 .net: >>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
> シート⑩ 意味明瞭化シート

災害医療センターがん疼痛相談外来患者情報提供書 - 独立行政法人 ...
www.nho-dmc.jp/treatment/department/pdf/gantoutuujyouhou2017.pdf
> コミュニケーション □ 0 意味明瞭・複雑な表現. □ 1 意味明瞭・単純な表現.
482 ：仕様書無しさん：2018/04/22(日) 19:29:21.16 .net: 意味不明
483 ：仕様書無しさん：2018/04/22(日) 19:38:24.06 .net: 有名税は世相の反映、政治家のニックネーム
https://blog.goo.ne.jp/tenyumineo/e/114c240601bdf83d4bf09e77b5f65356
> 大平正芳：鈍牛、言語不明瞭・意味明瞭

https://blog.goo.ne.jp/shima1946/m/201001
> 往年の総理・大平正芳さんは「言語不明瞭　意味明瞭」といわれたものでした。
484 ：仕様書無しさん：2018/04/22(日) 19:44:20.78 .net: >>319
> コードをいじってばかりのやつは、手段と目的が逆転している。

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

目的を実行する時にこまめにやる手段で、手段そのものが目的になってるような
リファクタリングだけの作業とか大規模リファクタリングはおかしいって
言ってるんだが？
485 ：仕様書無しさん：2018/04/22(日) 20:14:12.25 .net: 結局さ、リファクタリングに文句言ってるように見えて、
実は自分らが普段やっている、いろんな問題が発生している
信頼性の低い行き当たりばったりの改修方法に
文句言ってるだけだろ？

リファクタリングをただの改修と勘違いして、
いつもの自分らを批判してるだけ
486 ：仕様書無しさん：2018/04/22(日) 21:06:56.52 .net: 取り敢えず、リファクタリングの意味は間違えんなよって言いたい。
リファクタリングは、利用者から見て全く振る舞い=挙動が変わらんやつのことだ。シンプルな定義じゃないか。

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

何も難しくない
487 ：仕様書無しさん：2018/04/22(日) 21:22:12.90 .net: > が、ちゃんとリファクタリングとそれ以外は明確に別れる必要もある。

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

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

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

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

もう少し具体的に言えば、ある機能実装のブランチがあって
そのブランチの中でこれらは混ざることはあるが、コミットは別れている
488 ：仕様書無しさん：2018/04/22(日) 21:30:13.63 .net: > その性質上、リファクタリングのみで直接利益の上がる作業なんて(ほぼ)ないし、

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

たしかにそのとおりだが作業を効率化させないと
客の数を増やしたら忙しすぎて破綻するし、
余裕がなければ疲れるだろう。利益ではなく
作業効率に直接影響するのがリファクタリングなんだよ。
489 ：仕様書無しさん：2018/04/22(日) 21:30:55.90 .net: >>487
あってるあってる。俺もそんなこと言おうとしてた。
もっと言うと、リファクタリングコミットでテスト回してないなら、ただのedit and prayやろって奴やな
490 ：仕様書無しさん：2018/04/22(日) 21:40:47.76 .net: >>488
効率化云々を否定するつもりはない。効率化するならいいじゃないか。
ただ俺は>>36の通りの主張。
コストの前借りは基本通らねえよ、とだけ。
491 ：仕様書無しさん：2018/04/22(日) 21:45:35.66 .net: コストの前借りなんて話はしてない。
コードを改修する時の作業に含まれてるんだから

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

これは改修でやらなければいけないことで、前借りではない
492 ：仕様書無しさん：2018/04/22(日) 22:05:59.89 .net: こっちはリファクタリングコストは見積もらないけどな...。
他の作業と置き換えて効率化できるならOK
リファクタリングコストないじゃんとかわけわからないこと言わなきゃいい
493 ：KAC：2018/04/22(日) 22:10:21.43 .net: >>491
だから、それが間違いだと指摘してるのにまだ気付かないのか？
494 ：仕様書無しさん：2018/04/22(日) 22:11:13.87 .net: リファクタリングしようがしまいが、
現状のコードが複雑なら解析に時間がかかるので、
あとはその解析結果をコードに反映して次回はもちろんのこと
今回のレビューやエンバグした時の修正を楽にするか
今のままより複雑にして大変にするかの違いなんだよな

そんなに複雑じゃないならリファクタリングも大したことない
すごく複雑なら、それリファクタリングしないと近い内に苦労するよってこと
こまめなリファクタリングが重要
100%完璧にしろなんて言ってない。修正する前よりも良くなっていればいい
495 ：仕様書無しさん：2018/04/22(日) 22:11:59.83 .net: >>493
お前のその指摘が間違いなんだよｗ
496 ：KAC：2018/04/22(日) 22:23:15.10 .net: >>495
それが事実なら、指摘内容にちゃんと反論しろよ。。。
497 ：仕様書無しさん：2018/04/22(日) 22:34:53.57 .net: 指摘内容に反論してるのが、>>491の内容でしょｗ

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

地球が太陽の周りを回ってるのは間違いなんだ！
って言っても、それは指摘じゃないのと同じこと
498 ：仕様書無しさん：2018/04/22(日) 22:44:53.89 .net: ちゃんと設計して作成、改修してるのにリファクタリングが必要になるのは何故？
なんかすでにおかしくね？

つまり、リファクタリングっていうのは設計が腐ってるから発生した不具合ってことだよね
499 ：仕様書無しさん：2018/04/22(日) 22:49:24.59 .net: 頭がばぐってる奴のこじつけ論にトラウマがある
最初から最後まで自分の主観から一歩も出ていない
立場をかさにきてるだけ
バットで頭なぐるか車でひき殺すかしたい
500 ：仕様書無しさん：2018/04/22(日) 22:55:32.38 .net: そこからわからないのか？

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

ソフトウェアは同じものを作ることはなく、はじめての道ばかりなんだから
軌道修正しながら進むしかないんだよ。
その軌道修正っていうのがリファクタリングでもある。
501 ：KAC：2018/04/22(日) 22:59:46.88 .net: >>497
はあ、都合の悪いものは見えない人か。
なら、お前の主観ではさぞかしリファクタリングは効率的なんだろうな。
502 ：仕様書無しさん：2018/04/22(日) 23:02:28.12 .net: 「リファクタリングは効率的」とは
いわないな。言葉の使い方が変だ

リファクタリングは効果的ならわかるが
503 ：仕様書無しさん：2018/04/22(日) 23:05:14.75 .net: 開発中のコードなのにテストコードのカバレッジを100%してリファクタリングするバカ
504 ：仕様書無しさん：2018/04/22(日) 23:38:13.28 .net: >>500
それは設計ミスの言い訳になるの？
505 ：仕様書無しさん：2018/04/22(日) 23:55:15.44 .net: 設計ミスなどない
506 ：仕様書無しさん：2018/04/22(日) 23:58:31.24 .net: >>503
テストコードのテスト？
507 ：仕様書無しさん：2018/04/23(月) 00:04:46.84 .net: >>505
じゃあリファクタリングなんてやる必要ないじゃん
508 ：仕様書無しさん：2018/04/23(月) 00:12:15.78 .net: 後出しで変化した状況に対応するにはやったほうがいいこともある

ふくらんだクラスを分割して平行作業したり
後から出てきた概念と名前を調整したり
既存コードに手を入れなくても機能拡張できるようにしたり
509 ：仕様書無しさん：2018/04/23(月) 00:29:35.44 .net: 取り敢えず>>486から>>492まで話が割と繋がってるんだから、そこから結論出せそうじゃん
510 ：仕様書無しさん：2018/04/23(月) 00:32:08.58 .net: >>508
全部金になんないね
お前、仕事やって金稼いだことあんの？
511 ：KAC：2018/04/23(月) 00:49:44.07 .net: >>508
お前さんが「リファクタリングを理解していない」のは既に指摘したが、
まさかそこまで酷いとは驚きだよ。

もう一度リファクタリングとは何か調べてから出直してこい。
512 ：仕様書無しさん：2018/04/23(月) 01:09:41.41 .net: この程度のことを金にできない奴隷PGたち
よっぽど信頼されていないんだなｗ
513 ：仕様書無しさん：2018/04/23(月) 01:34:52.95 .net: >>498、>>507
基本的にYAGNIでKISSだから。
機能追加する時初めてインターフェースを切り出したり、関数の所在を変えたりする場合も少なくない。

>>500
少なくとも20年前云々は、例として適切でない。
リファクタリング文化がある98年制のソースを触ったことなどない。

>>502
言葉そのものでなく、>>488、>>490の流れを受けての文脈。つまり(トータルコストを見て)効率的かどうか。という事。
514 ：仕様書無しさん：2018/04/23(月) 02:17:31.75 .net: 日本の場合はリファクタリングではなく、システムを作り替えるタイミングがリファクタリングにあたる。

外国人は新しいバグを埋め込んだり、仕様が変わってしまっても気にしない文化だから、日本人の感覚とは合わない。
515 ：仕様書無しさん：2018/04/23(月) 05:36:26.93 .net: >>510
テスト工数の削減が見込める場合はやるだろ
516 ：仕様書無しさん：2018/04/23(月) 06:14:50.48 .net: >>515
やらない
お前のやり方だとデグレが怖いから
517 ：仕様書無しさん：2018/04/23(月) 07:49:11.35 .net: リファクタ箇所が限定されてりゃ少量のテストでカバーできるだろ
518 ：仕様書無しさん：2018/04/23(月) 08:18:26.16 .net: >>517
それは仕様がすべて文章化されていればな
実際はそんなこと不可能だし
変更した以上デグレは覚悟しなければならない
519 ：仕様書無しさん：2018/04/23(月) 09:45:42.62 .net: >>514
> 日本の場合はリファクタリングではなく、システムを作り替えるタイミングがリファクタリングにあたる。

それは仕様がすべて文章化されていればな
実際はそんなこと不可能だし
変更した以上デグレは覚悟しなければならない
520 ：仕様書無しさん：2018/04/23(月) 09:53:07.78 .net: >>518
仕様なんてソースコード読んで、
その動きが仕様なのでは？
521 ：仕様書無しさん：2018/04/23(月) 09:54:57.20 .net: >>514
一瞬システムリプレースの事だと勘違いするから、改修とか修正って単語使って欲しい

んで、何度も言うように、少なくともリファクタリングの時点でテストはされるし、バグがリファクタリング起因でない事は(メモリ起因やテスト自体の不備を除けば)確実だ、としておく。
なんで、外国人、日本人の下りは何かがおかしい
522 ：仕様書無しさん：2018/04/23(月) 10:53:40.38 .net: 仮にソースが仕様であるならば、バグは１つもないことになる
523 ：仕様書無しさん：2018/04/23(月) 12:08:46.41 .net: 関数の中のロジックの一部を他の関数に切り出して、カバレッジ100%のユニットテストで元のテストの
外部的振る舞いが変わってないことを確認して満足してた奴がリファクタリング起因の障害を発生させてたわw
524 ：仕様書無しさん：2018/04/23(月) 13:27:15.16 .net: テストコード自体の不備に関してはどうしようもないからな
ただそれに関しちゃ、手動テストでも同じことが言えるからどっちもどっち。
525 ：仕様書無しさん：2018/04/23(月) 14:56:45.98 .net: >>524
手動でもテストコードはあるんだが？
526 ：仕様書無しさん：2018/04/23(月) 17:34:25.51 .net: リファクタリングしなければ不具合は発生しない
527 ：仕様書無しさん：2018/04/23(月) 19:31:15.43 .net: ここまで技術的な話題ゼロ
オワットルなジャップ
528 ：仕様書無しさん：2018/04/23(月) 20:11:50.92 .net: ソフトウエアの問題は
それがどれほど技術的に見えようとも
結局は人間の問題である

と偉い人が言ってた
529 ：仕様書無しさん：2018/04/23(月) 21:31:15.36 .net: コードがださいからリファクタしたい
気が滅入る
530 ：仕様書無しさん：2018/04/23(月) 21:37:25.89 .net: >>523
> 外部的振る舞いが変わってないことを確認して満足してた奴がリファクタリング起因の障害を発生させてたわw

それ普通に修正してもバグ入れ込むよね？
531 ：仕様書無しさん：2018/04/23(月) 21:38:22.86 .net: >>525
> 手動でもテストコードはあるんだが？

なら手動でバグを見つけられなかったことでは？
まあ手動によるテストは信頼性が低いからね
532 ：仕様書無しさん：2018/04/23(月) 21:46:49.18 .net: >>530
>>530
触らないならバグらないよ
533 ：仕様書無しさん：2018/04/23(月) 22:01:01.53 .net: 結局リファクタの成否は
客を丸め込んでデグレのリスクを飲ませられるかにかかってる気がしてきた

バージョンアップとかスピードアップとかなんかこじつけて
リファクタでデグレたら原因も無理やりそこに倒す
534 ：仕様書無しさん：2018/04/23(月) 22:09:44.65 .net: その前に正しい知識が必要だけどな。
リファクタリングは効果的、これを開発社側が
正しく理解してないと、現状のコードの問題を
リファクタリングのせいにしてしまう。
535 ：仕様書無しさん：2018/04/23(月) 22:10:30.68 .net: 現状のコードの問題ってのは、例えば
仕様もテストコードもないんだが？とかそういうのなｗ
536 ：仕様書無しさん：2018/04/23(月) 22:14:41.53 .net: >>534
正しい知識があったらリファクタがプログラマーが楽するためのものだってばれるじゃないか！
537 ：仕様書無しさん：2018/04/23(月) 22:16:20.23 .net: 開発中なのにユニットテストでプロダクションコードをガチガチに硬直化させるアホ
538 ：仕様書無しさん：2018/04/23(月) 22:16:42.65 .net: なにか問題でも？
開発側が楽になれば、それは顧客にとってメリットしかないよね？
539 ：仕様書無しさん：2018/04/23(月) 22:17:49.19 .net: >>537
お前のその「開発中」は何ヶ月あるんだ？

お前の所は各モジュールごとに計画を立てて開発するんじゃなくて
全部いっぺんに作業してしまってるのか？
540 ：仕様書無しさん：2018/04/23(月) 22:21:41.39 .net: >>539
ユニットテストが壊れない程度のリファクタリング、つまり関数レベルのリファクタリングしかしない人にはわからないかも
541 ：仕様書無しさん：2018/04/23(月) 22:24:43.47 .net: >>540
なんでユニットテストを修正してはいけないと思ってるんだ？

リファクタリングでユニットテスト修正するだろ。
というだけじゃ意味が分からんのだろうな
テストは修正しないって言ったじゃないですか！って言いそうｗ

リファクタリングはテストに通るように修正するのであって、
それさえ守れば、テスト自体の修正もする。
テストのリファクタリングなんて言葉もある。

説明がほしいか？
542 ：仕様書無しさん：2018/04/23(月) 22:26:59.68 .net: まあここらへんだな。お前がユニットテストを壊さなきゃできないと
勘違いしているリファクタリングだ

新装版　リファクタリング　既存のコードを安全に改善する
http://shop.ohmsha.co.jp/shopdetail/000000003881/

第6章メソッドの構成
メソッドの抽出
メソッドのインライン化
一時変数のインライン化
問い合せによる一時変数の置き換え
説明用変数の導入
一時変数の分離
パラメータへの代入の除去
メソッドオブジェクトによるメソッドの置き換え
アルゴリズムの取り替え

第7章オブジェクト間での特性の移動
メソッドの移動
フィールドの移動
クラスの抽出
クラスのインライン化
委譲の隠蔽
仲介人の除去
外部メソッドの導入
局所的拡張の導入
543 ：仕様書無しさん：2018/04/23(月) 22:31:31.09 .net: まあ簡単に説明するとだな。

「実装クラス」があって
↑
「テストコード」がこの実装クラスを見ている時の
クラスを大きく書き換えるリファクタリングはな

「新しいクラス」を作って、
↑
「実装クラス」の処理を新しいクラスに移譲することで、
↑
「テストコード」から見るインターフェースを
まったく変えること無く、新しいクラスに移行するんだよ

そして「新しいクラス」のテストも書いて（もちろん一部は現在のテストコードを流用していい）
「実装クラス」を参照しているものを、新しいクラスを参照するように書き換え
どこからも使われなくなったら「実装クラス」をそのテストコードもろとも削除

というやり方が、>>542のリファクタリング本に書いている

だから「ユニットテストが壊れない程度のリファクタリング」と言われても
あー、分かってない人ねとしか思わないよ。
544 ：仕様書無しさん：2018/04/23(月) 22:36:31.59 .net: パズルやりたいなら一人でやってろや
仕事中に遊んでんじゃねえ
545 ：仕様書無しさん：2018/04/23(月) 22:40:36.13 .net: 画面見てキーボード打ってるとゲームして
遊んでるとか思うおっさんがいるらしいなw
546 ：仕様書無しさん：2018/04/23(月) 22:43:19.23 .net: こんなパズルいらねーんだよ。
バーンと書き換えて、やっちゃって
ミスったらリファクタリングのせいにすればいいだろ

↑こういうやつがリファクタリングのせいにするわけかｗ

リファクタリングは変更しても問題ない手順で変更することで、
たんなる変更、いつもお前らがやってるような手抜きの
無計画な変更を言い換えた言葉ではありません
547 ：仕様書無しさん：2018/04/23(月) 22:44:15.53 .net: 結局テストコード削除してたらだめじゃん

やってる本人はよくても
他人はリファクタ前と後で変わってないことをどうやって確かめるんだ
548 ：仕様書無しさん：2018/04/23(月) 22:46:32.34 .net: > 結局テストコード削除してたらだめじゃん

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

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

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

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

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

それだけじゃん。

まだ補足が必要？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

変えてないよ？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

長いそれであっても50行は超えていない
647 ：仕様書無しさん：2018/04/25(水) 23:25:41.82 .net: コードの優劣は、そのコードが生み出す経済的価値によって決まる
ただ綺麗なコードより汚くても利益を生むコードの方が価値がある
大して価値のないコードを一生懸命リファクタリングしてる奴には、そんなゴミ捨てて意味のあるコードを書けと言いたいね
648 ：仕様書無しさん：2018/04/25(水) 23:26:50.34 .net: はい、言い訳きたーｗ
649 ：仕様書無しさん：2018/04/25(水) 23:30:48.77 .net: 英検1級レベルに満たない奴はローマ字でコードを書け
650 ：仕様書無しさん：2018/04/25(水) 23:31:01.06 .net: くり返し言うが、俺が言いたいのは、技術力高い所は
本当にこれぐらいのレベルなんだよ、
ありえない話はしていない。その証拠
651 ：仕様書無しさん：2018/04/25(水) 23:31:51.26 .net: >>646
そんなに探してない
ＤＢとかＨＴＭＬに値入れてるとことか長くなりがちなとこ探したけどなかったんで
helperっていう割とやばめの文字列が目に入ったんで開いたらあった

やっぱり扱うものによる

一番下のやつ５０行超えてるぞアウトだアウトだ
https://github.com/gitlabhq/gitlabhq/blob/master/app/helpers/application_settings_helper.rb
652 ：仕様書無しさん：2018/04/25(水) 23:32:00.49 .net: >>650
他人のふんどし
653 ：仕様書無しさん：2018/04/25(水) 23:32:43.50 .net: >>651
そもそもrubyがカス
654 ：仕様書無しさん：2018/04/25(水) 23:33:46.00 .net: >>651
今までに何ファイル探した？
少ないのがわかるだろう？
655 ：仕様書無しさん：2018/04/25(水) 23:35:10.56 .net: >>651
よくそんなの見つけてくるねｗ
ただの配列定義だった
656 ：仕様書無しさん：2018/04/25(水) 23:35:35.10 .net: >>640
でもよ
それって設計書書くの大変じゃない？
200行のメソッドって10個～20個になんだろ？
クラス図だって10倍か20倍にデカくなんだぞ
トレードオフの問題ちゃうんか？
たくさん仕事してるようで大半がメソッド名決めてるだけみたいな
657 ：仕様書無しさん：2018/04/25(水) 23:36:38.18 .net: >>652
いや、自分も同じレベルだけど、自分のコードは出せないだろう？
オープンソースで参考にできるもの。

あの関数の短さで大規模なエンタープライズ向けの開発ツールが作れる。
そういう事実がそこにある。
658 ：仕様書無しさん：2018/04/25(水) 23:36:38.93 .net: >>656
コードが設計書
659 ：仕様書無しさん：2018/04/25(水) 23:37:57.03 .net: >>656
> それって設計書書くの大変じゃない？

設計書書くの大変なんだよ？

ようするに設計書はこのぐらいのものを作って
一人前ってことなんだよ。

普段どれだけ適当な仕事しているかってのを
わかってほしい。それだけのレベルの差がある
660 ：仕様書無しさん：2018/04/25(水) 23:38:04.24 .net: >>657
1関数100行でも作れるよ
661 ：仕様書無しさん：2018/04/25(水) 23:39:09.20 .net: メソッドの仕様まで設計書に起こす奴って脳死しすぎやろw
662 ：仕様書無しさん：2018/04/25(水) 23:39:47.86 .net: 設計書書くの大変かどうかは知らんが
事実としてあのコードは存在する。

あのコードを作るにはどうすればいいかを考えたほうが良い
663 ：仕様書無しさん：2018/04/25(水) 23:40:24.20 .net: >>662
そうだな

リファクタする時間をプログラマにくれればいいんじゃないかな？
664 ：仕様書無しさん：2018/04/25(水) 23:41:06.73 .net: >>660
作れるかどうかという理論上の話ではなく
実際に作られたシステムが、あれだけ関数の長さが短いという事実
665 ：仕様書無しさん：2018/04/25(水) 23:41:39.80 .net: >>663
その分、設計してる人の時間をとるんだろ？
666 ：仕様書無しさん：2018/04/25(水) 23:42:57.70 .net: >>665
役に立たない設計書を書いてるような
やつに時間はいらない
667 ：仕様書無しさん：2018/04/25(水) 23:43:22.49 .net: >>665
コードの奇麗さが価値なら
客からリファクタ用の時間をたっぷりふんだくれるはず
668 ：仕様書無しさん：2018/04/25(水) 23:47:04.45 .net: >>667
別にいらんよ。コードが綺麗なら
同じ時間でより多くのものが作れる。

言い換えると技術力が高ければ、
同じ時間でより多くのものが作れる
という当たり前の話だ
669 ：仕様書無しさん：2018/04/25(水) 23:48:23.93 .net: >>667ってなんか発想がおかしくね？
客から作業代をどうやってむしり取ろうかって発想になってる。
670 ：仕様書無しさん：2018/04/25(水) 23:49:15.19 .net: >>664
Jenkinsは至るところで使われてるけど50行以上のメソッドなんていくらでもある事実
671 ：仕様書無しさん：2018/04/25(水) 23:54:21.44 .net: >>670
これ？なかなか見つからなくて苦労している
https://github.com/jenkinsci/jenkins/tree/master/core/src/main/java/jenkins/model
672 ：仕様書無しさん：2018/04/25(水) 23:55:28.95 .net: まあJavaだしね。
673 ：仕様書無しさん：2018/04/25(水) 23:57:50.39 .net: Rubyは結構変な構文で圧縮してる
674 ：仕様書無しさん：2018/04/26(木) 00:03:21.92 .net: >>659
原点回帰が必要だよお前
人間が見てわかりやすい範囲を明らかに逸脱してるだろ
概算で役に立たない
2000行規模のコードでメソッド200個近く作るんだろ
どうやって表現すんの？お前
なんもドキュメント作らない前提じゃないと成り立たない

つっかえねーｗ
675 ：仕様書無しさん：2018/04/26(木) 00:05:16.32 .net: われながら途中で投げ出してわかるからと適当に書いた設計書がやばい
自分はわかるがテスターが
どうしよ
676 ：仕様書無しさん：2018/04/26(木) 00:11:00.24 .net: >>668
当たり前とはつまり自分の思い込みで根拠がないことを指す

このコードだって最初からきれいに書いてちゃっちゃと作ったのか
時間をかけてレビューして整頓したのかどうかなんてわかんないじゃん
677 ：仕様書無しさん：2018/04/26(木) 00:17:32.88 .net: >>674
> 2000行規模のコードでメソッド200個近く作るんだろ
> どうやって表現すんの？お前

でもさ、コードでは実際にそう表現されてるよ？
そこの矛盾に、君が気づかないといけない
678 ：仕様書無しさん：2018/04/26(木) 00:20:48.44 .net: 面白いのを見つけてきた

【読者参加型企画】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行にかかるコードレビューの時間です。
679 ：仕様書無しさん：2018/04/26(木) 00:32:42.36 .net: https://gigazine.net/news/20150918-google-2billion-code/

> 2015年1月時点で、総ファイル数は10億、ソースファイルの数は900万、
> コードは20億行あり、3500万回のコミットがあって、内容は86TBあるとのこと。
> そして、営業日1日に対してのコミット回数は4万5000回。

1ファイルの平均は20億÷900万＝222行でした。
2000行規模なら10ファイル程度

俺は妥当なところだねと思うが、
そう思わない人がいる。

そこにレベルの差を感じる
680 ：仕様書無しさん：2018/04/26(木) 00:34:49.47 .net: トレードオフって言葉を覚えた方がいいよ
この機能を実現するために必要な処理は何？
って聞かれても何も答えられないっしょ？
さらにドキュメントを書かせる現場で君は役に立たない
たった2000行程度で200個もメソッド作るようなカスはどこ行っても
使えねーからオープンソースでも
組んでろよ
681 ：仕様書無しさん：2018/04/26(木) 00:44:22.87 .net: > この機能を実現するために必要な処理は何？
> って聞かれても何も答えられないっしょ？

「この機能」って？
この機能だけで見積もりできるの？設計できるの？
682 ：仕様書無しさん：2018/04/26(木) 00:45:19.30 .net: >>678
で、なにが言いたいの？
スレの流れは関数の長さとそのレビューにかかる時間だったけど、その引用のレビュー時間は
関数の長さとどう関係があんの？
まさか、2000行のコードっていうのを、2000行のひとつの関係って解釈した？
683 ：仕様書無しさん：2018/04/26(木) 00:46:39.82 .net: >>680
2000行なら100メソッドだろ？
何勝手に水増ししてんだｗ

普通に作れば100個のメソッドなんて普通にできる
1関数10～20行にしないとテスト不可能
テスト可能にするとだいたいコレぐらいになる。

そこから逆算すれば100個のメソッドは
普通に作ればできる

トレードオフの話をするのであれば、
トレードオフした結果が100個だ

って、やっぱりマジ1関数10～20なんてありえない
50行超えるのがザラなの？　レベルに大きな差があるよ。
自覚だけはしておこう
684 ：仕様書無しさん：2018/04/26(木) 00:49:24.26 .net: トレードオフって何と何のトレードオフなんだろう？

最初から短い関数で書けばいいと思うけど、
関数を長くすることで、何のメリットがあるの？
685 ：仕様書無しさん：2018/04/26(木) 00:49:29.64 .net: >>678
そもそもテクニカルレビューってなに？
どういう目的でどういうレビューをしてるかによってかかる時間はいくらでも変わると思うけど、
テクニカルレビューがなんなのかわからないから10～20時間が長いのか短いのか評価できないんだけど
686 ：仕様書無しさん：2018/04/26(木) 00:51:12.51 .net: ふつうだのレベルだの漠然としたことしか言わんやっちゃ
687 ：仕様書無しさん：2018/04/26(木) 00:51:43.19 .net: 例えばプロだと間違えずにキーを打つことが高速にできる。

だけど素人だと間違えずにキーを打たなければいけないという
条件をつけると途端にタイプするのが遅くなる。

それと一緒でプロだと普通に作っても関数は10～20行にできるが
そうでない素人だと頑張らないと達成できない

そう、素人
688 ：仕様書無しさん：2018/04/26(木) 00:52:05.80 .net: >>685
リンク先読めば？
689 ：仕様書無しさん：2018/04/26(木) 00:57:05.65 .net: >>688
わかんないままドヤ顔で引用しちゃったんだな
690 ：仕様書無しさん：2018/04/26(木) 01:00:43.49 .net: 技術的難易度が低いただのCRUDアプリみたいなものしか作れない人は、いかに綺麗にコードを書くかとか
そういう話題でしか技術っぽい話ができないから、ここぞとばかりに語るよな
691 ：仕様書無しさん：2018/04/26(木) 01:00:54.12 .net: >>683
それって20行換算じゃん
最大行で見積もるなんて心苦しいから10行にしてやったんじゃん

2000行でメソッドが200個できて
20000行で2000個だ
100000行で10000個じゃん

この間やったプロジェクトのコードがそんなもんだったけど
メソッド10000個とか明らかに
茶碗が小さすぎる
おちょこに飯もってるみたいにアンバランスだろ
692 ：仕様書無しさん：2018/04/26(木) 01:04:35.27 .net: >>689
> わかんないままドヤ顔で引用しちゃったんだな
いや、普通にリンク貼ってるじゃん？
693 ：仕様書無しさん：2018/04/26(木) 01:06:27.50 .net: >>691
> この間やったプロジェクトのコードがそんなもんだったけど

お？　ちょうどいいやん。
何ファイルで何クラスで何行ぐらい？
694 ：仕様書無しさん：2018/04/26(木) 01:10:21.07 .net: >>693
いいや、コードは100000行でメソッド数は2000ってとこだね
10000とかドキュメント工数単純に5倍になんじゃねーか？
695 ：仕様書無しさん：2018/04/26(木) 01:14:29.41 .net: そもそも設計書からしてそんなに大量のメソッド作成するように書いてるのか？
設計書に書いた処理とソースの処理を一致させないと説明が面倒だろ
696 ：仕様書無しさん：2018/04/26(木) 01:15:20.39 .net: >>691
> 100000行で10000個じゃん
数を大きくして、多く見せたいようだけど無駄ｗ

10万行だろ？ 1ファイル（=1クラス相当）が200行ぐらいなので
500個もファイルがある。メソッド1万個は1ファイル（クラス）20個のメソッド
これは普通の規模だ

そもそもお前、ちゃんとモジュール化できてないだろ？
役割ごとにちゃんとファイル（クラス）分けろ
697 ：仕様書無しさん：2018/04/26(木) 01:17:14.11 .net: >>695
> そもそも設計書からしてそんなに大量のメソッド作成するように書いてるのか？

実際にコードはそれぐらいになるんだから、
それに相当するメソッドは誰が作り出してるかってことだよ。

設計書にこの程度の数のメソッドが書いてないなら、
その設計書通りに作ると破綻するということを意味する

きちんとレビューしてテストするためには、
実際にそれだけの小ささのメソッドでなければいけないのだからね
698 ：仕様書無しさん：2018/04/26(木) 01:25:34.92 .net: 実際にコードを書いてる人は、これぐらいの数の関数は作ってるんだよね。

それにたいして、こんなに大量の関数なんて設計できない。
予め想定することなんてできない

っていうのなら、そういうことだよ。
お前らがやってる設計とやらの仕事は、
現場には通用しない仕事だということ

Sヨとか言われてバカにされてるじゃん。
それが事実だってことだよ。
699 ：仕様書無しさん：2018/04/26(木) 01:39:49.55 .net: さてリファクタリングの話に戻すぞ？

これが実際の優れた開発の現場だから、最初に全部設計して
最初に考えた関数だけで作るなんて不可能なわけさ
関数の数が多すぎる！って叫んでるアイツ見りゃわかるだろ？

でも実際のコードはそれだけの数の関数がある
この差をどうやって埋めるよ？

最初は設計に書いたとおりの形から始める
実装が進んで次第にコードが膨れ上がっていく
テストできなくなってしまうから、再設計が必要
といっても大きなものじゃない。こまめにやる。

これが開発の中に自然に含まれているリファクタリングだ。
リファクタリングは開発に含まれるもので
別の作業として分離してやるもんじゃない。
700 ：仕様書無しさん：2018/04/26(木) 02:27:16.80 .net: 糞コードいつか破綻するのはわかってるのに
そのまま売りまっくて最終的には極悪に肥大したクソコードのリファクタリングしろという
まずその事実を知っていて売り続けた開発部長やら上層の誰かに責任取らせろやハゲが
701 ：仕様書無しさん：2018/04/26(木) 03:03:40.58 .net: >>699
リファクタリングは「改修」に含まれるものっていう主張はやめたんだねw
視野が狭かったことに気づいてくれて嬉しいよ
702 ：仕様書無しさん：2018/04/26(木) 03:26:26.13 .net: ん？やめてないよ。開発の中に改修は含まれている
改修をしない開発会社なんてないんだから
703 ：仕様書無しさん：2018/04/26(木) 03:26:52.94 .net: はいはいw
704 ：仕様書無しさん：2018/04/26(木) 05:13:46.24 .net: >>695
ソースレベルの設計書なんて書くわけないやろ
705 ：仕様書無しさん：2018/04/26(木) 09:34:52.67 .net: ソースレベルの設計書とか言ってる奴はまだマ歴1ヶ月なんだから優しくしてやれ
706 ：仕様書無しさん：2018/04/26(木) 09:51:20.89 .net: つまり

1. テスト可能なメソッドは十分短いものである
2. 設計でそれらを全て洗い出すのは無理

ってことなんだよね

これは重要な大前提では？
707 ：仕様書無しさん：2018/04/26(木) 09:52:44.36 .net: >>705
世の中には、設計で洗い出した関数しか作らない
作れないプロジェクトがあるらしい

そういうプロジェクトが破綻するのは目に見えてる
708 ：仕様書無しさん：2018/04/26(木) 10:30:15.01 .net: ソースレベルの設計書ってなに？詳細設計よりもっと細かいやつ？
アセンブラ時代のフローチャートはほぼソースとイコールだったけど
709 ：仕様書無しさん：2018/04/26(木) 12:27:07.55 .net: >>707
それくらいで破綻しないよ、昔の人の多くはそれでやってたんだから
破綻するなんてのは、誰にでもできるがゆえに参入障壁が低く競争過多な世界で納期に追われてる奴の発想笑
710 ：仕様書無しさん：2018/04/26(木) 12:31:16.98 .net: 破綻はしないが非効率的すぎるわな
711 ：仕様書無しさん：2018/04/26(木) 12:57:21.34 .net: 設計で関数を洗い出すのはいいんじゃねーの？
ソースは完全にプログラマに任せるスタイルなのか、ある程度は監視するスタイルなのかの差だと思うよ
個人の技量に任せたら関数の切り出しするやつとしないやつで差がですぎてソースが混乱する
712 ：仕様書無しさん：2018/04/26(木) 15:10:37.16 .net: そこまで細かく詰めるならその場でコードまで書いてコンパイルと簡単なユニットテスト通しちゃえよ
少なくともインターフェースとスタブは書けるだろ
713 ：仕様書無しさん：2018/04/26(木) 17:56:23.04 .net: >>712
それをやることになんの意味が？
714 ：仕様書無しさん：2018/04/26(木) 18:26:57.92 .net: >>713
無駄な工数を省いた上に戻りも減らせる
715 ：KAC：2018/04/26(木) 20:18:39.67 .net: >>712
コードを書かなきゃ必要な関数を洗い出すこともできないのは最近の風潮だよな

大規模なチームで設計するときにも、
各自が関数洗い出したのを持ちよって全体最適化とかしてないだろ？

普及している手法にはメリットやデメリットがあるのは当たり前
色々な開発手法知らないと最善策見つけられんだろ
716 ：仕様書無しさん：2018/04/26(木) 21:06:08.65 .net: 昔に比べりゃ関数作るのはアホみたいに簡単になった
CollectionやらThreadやらStringやら
大体コアになるもんはありものが揃ってるし
717 ：仕様書無しさん：2018/04/26(木) 21:57:25.51 .net: 設計書ってパンチカード時代の名残だぞ
そんなものを未だに盲信してるなんて滑稽だ
718 ：仕様書無しさん：2018/04/26(木) 22:34:16.48 .net: デシジョンテーブルは書くやろ？
719 ：仕様書無しさん：2018/04/26(木) 22:43:24.25 .net: >>718
そうやってすぐコード以外のなにかに逃げようとすんなよSEさんよ
720 ：仕様書無しさん：2018/04/26(木) 22:52:07.11 .net: そらDBからデータを取り出してブラウザに返すだけのアプリに設計書なんていらんわな
721 ：仕様書無しさん：2018/04/26(木) 22:59:08.51 .net: 二人以上で作業するなら電卓アプリでも設計書いるわ
722 ：仕様書無しさん：2018/04/26(木) 23:20:45.92 .net: >>720
メモリからデータを取り出して画面に表示するだけのアプリばかりでは？
723 ：仕様書無しさん：2018/04/26(木) 23:44:04.93 .net: DBからデータを取り出してブラウザに返す仕事なんて、専門教育を受けてない文系でもこなしてるという事実
724 ：仕様書無しさん：2018/04/26(木) 23:45:51.71 .net: リファクタリングの話が盛り上がるのは、文系でも参加できるから
725 ：仕様書無しさん：2018/04/26(木) 23:52:49.47 .net: 文系が参加って、技術的な話での参加じゃないじゃんｗ
726 ：仕様書無しさん：2018/04/26(木) 23:57:54.18 .net: >>723
宇宙ロケットのネジだって高卒が締めてるにちがいない
そんな理屈で仕事の難しさがわかるものか
727 ：仕様書無しさん：2018/04/27(金) 06:18:08.07 .net: 設計書なんてコードから生成するもんだろが
728 ：仕様書無しさん：2018/04/27(金) 07:15:01.31 .net: >>727
そのコードを最初に、どうやって書く訳？
729 ：仕様書無しさん：2018/04/27(金) 07:24:26.55 .net: エディタ開いてタイプしろよ
そんなことも言われなきゃわからん？
730 ：仕様書無しさん：2018/04/27(金) 12:13:18.45 .net: >>729
お子ちゃま？
731 ：仕様書無しさん：2018/04/27(金) 21:44:36.77 .net: >>728
それ辿るとBIOSまで行くぞいいのか
732 ：仕様書無しさん：2018/04/27(金) 21:54:27.71 .net: すでに存在するものまで遡らなくていい
733 ：仕様書無しさん：2018/04/27(金) 21:57:24.49 .net: リファクタできない無能には9連休なんてないんだろうなww
734 ：仕様書無しさん：2018/04/27(金) 22:13:06.31 .net: 明日からリファクタリングのために9連勤です
この工数がなければ休めたのに
735 ：仕様書無しさん：2018/04/27(金) 22:20:26.31 .net: ほらな。なんどもリファクタリング単体の作業は間違ってる。
ふつうの開発（改修含む）に含まれているものだ。
と言ってるのに、やっぱり理解できていない
完全に間違いが身にしみてるんだろうな
736 ：仕様書無しさん：2018/04/27(金) 22:50:04.81 .net: すでに運用中のシステムの保守開発に途中参画して、リファクタリング単体の仕事をやることもありますね。
視野が狭い方には思いもよらないでしょうけど。
737 ：仕様書無しさん：2018/04/28(土) 00:55:26.89 .net: >>731
howだけじゃなく、why for why考えれるかが分岐点。
738 ：仕様書無しさん：2018/04/28(土) 01:04:45.94 .net: なんで？
739 ：KAC：2018/04/28(土) 01:49:53.92 .net: >>735
お前さん、純粋なリファクタリングやったこと無いのな。
どおりで作業量とかリスクとか全く理解していない訳だ。
740 ：仕様書無しさん：2018/04/28(土) 02:04:59.74 .net: 純粋なリファクタリング（笑）

どこ出典ですかねそれ
お前の最強の純粋なリファクタリングみしてみろよｗ
741 ：KAC：2018/04/28(土) 02:37:47.95 .net: >>740
お前は「リファクタリングを改修と併せてやる」事しか知らないんだろ？
「リファクタリングのみ」の評価知らないのに正しく評価できないだろ。
742 ：仕様書無しさん：2018/04/28(土) 02:41:55.96 .net: だからどんなもんか試しにみしてみろって言われてんじゃん
743 ：仕様書無しさん：2018/04/28(土) 04:13:15.29 .net: >>731
宇宙誕生まで調べるだろフツー
744 ：仕様書無しさん：2018/04/28(土) 07:14:45.24 .net: 改修準備
調査分析
自動テスト作成
負債返済
利便性向上

少なくともこの5種のリファクタリングを日常的に行う
改修前のリファクタリングしか知らないならまだまだだね
745 ：仕様書無しさん：2018/04/28(土) 07:16:05.03 .net: 改修前のリファクタリングは純粋なリファクタリングなんだが爺さんにはわからないかな
746 ：仕様書無しさん：2018/04/28(土) 13:16:55.76 .net: 機能追加とかデバッグの時に
リファクタリングしちゃだめよ
747 ：仕様書無しさん：2018/04/28(土) 13:25:13.25 .net: 帽子をかぶりなおす
748 ：仕様書無しさん：2018/04/28(土) 13:27:23.72 .net: ヅラ
749 ：仕様書無しさん：2018/04/28(土) 16:36:26.14 .net: 事実の再構築、それが本来の純粋なリファクタ

たとえばガス室はなかったとか
強制連行でなく移民だとか
そういうことを言うとリファクタだと侮蔑的レッテルを張られ非難された

あんまり面倒なのでえらい人が別の意味で単語を上書きすることにした

そのあおりをくらってＩＴ従事者は楽しいが不毛な作業に邁進している
750 ：仕様書無しさん：2018/04/28(土) 16:41:21.19 .net: KAIZAN活動やってたぜ
751 ：仕様書無しさん：2018/04/30(月) 00:19:13.47 .net: 少し話が変わるが、実装と単体テス
ト(自動化)って同時に行って、工数も含めるよな？
自動化するのに別途工数くださいって言われるんだが・・・
こっちとしてはバッファ含んでも余裕ある日数でお願いしているのに
工数が無いって言うくせに遅刻は半分くらいするし、たばこプカプカで手を動かさない
首切りたい。
752 ：仕様書無しさん：2018/04/30(月) 00:29:57.65 .net: 現場のマネジメント次第でしょ
それどうするか決めるのおまえの仕事じゃねーか

そいつは工数が必要だって言ってるんだからいるんだろ
いくらコーディングだけなら余裕のある日数っつったって
最初お前の頭になかったんなら、全体的な工数がどうなるかは見直すしかない

行けるはずだから頑張れっていうかちょっと工数伸ばすか管理見直すか決断しろ
おまえがやるべきことだ
753 ：仕様書無しさん：2018/04/30(月) 00:30:23.53 .net: >>751
契約ではどうなっているの？
請負の成果物になければんなもんつくんねーよ
754 ：仕様書無しさん：2018/04/30(月) 00:45:24.35 .net: ちなみに自分とこの現場の経験でいうと
単体テスト仕様書はコーディングの１．５倍、
ユニットテストは３倍ぐらい工数かかります

ご愁傷様
755 ：仕様書無しさん：2018/04/30(月) 06:17:53.95 .net: そんな3倍もかからんよ
せいぜい5割り増し程度
自動テスト書くとエビ撮りはもちろん実験やデバッグが爆速になるから総合するとむしろ工数が減る
756 ：仕様書無しさん：2018/04/30(月) 07:27:48.52 .net: でもな
その仕様じゃ動かんのよ
757 ：仕様書無しさん：2018/04/30(月) 08:34:15.52 .net: >>755
まあキチンとやってればそんなもんだね。
ただし、禄に設計されてない（抜け漏れ、重複、矛盾多数）プロジェクトだと、テスト時に発覚ーーー＞設計修正工数認めない！ーーー＞テストケースが歪なのを何とかしようと無駄な作業、で数倍に膨らんだりするが。
758 ：仕様書無しさん：2018/04/30(月) 08:38:37.95 .net: >>757
それテストじゃなくて別の問題だよね
759 ：仕様書無しさん：2018/04/30(月) 08:42:49.78 .net: >>757
テストしっかり書いたから抜け漏れに気が付いた
気がついてよかったじゃん
悪いのは静的解析もテストもしないで設計して抜け漏れ発生させた設計チームだろ？
だから設計書は役立たずのゴミなんだよな
760 ：仕様書無しさん：2018/04/30(月) 09:32:29.73 .net: >こっちとしてはバッファ含んでも余裕ある日数でお願いしているのに

この言い草にやばいＳＥのにおいがしてトラウマが刺激された

自分の作業の考慮抜けを無視したり、いらない仕事山ほど詰め込んだ挙句に結果工期伸びてるのに
この認識を修正できずに
「案だけ余裕あったのに何で間に合わないの？」みたいなこと言ってくる奴の多いこと…
761 ：仕様書無しさん：2018/04/30(月) 10:28:50.80 .net: まだ人月とか信じてる奴いるんだね
762 ：仕様書無しさん：2018/04/30(月) 11:12:10.98 .net: バカ10人の首切ってスーパープログラマを1人雇ったほうが生産性高い
763 ：仕様書無しさん：2018/04/30(月) 11:17:42.25 .net: バカ１０人集めたらできるような仕事の生産性をちょぴりあげるために
スーパープログラマを投入されてたまるか
764 ：仕様書無しさん：2018/04/30(月) 11:29:56.67 .net: カスみたいなCRUDを高速で量産するスーパープログラマとはw
765 ：仕様書無しさん：2018/04/30(月) 11:31:28.59 .net: スーパープログラマにカスPGの仕事をやらせたらめんどくさがって自動化しちゃうから実質10倍どころじゃない
万倍以上の差が出る
766 ：仕様書無しさん：2018/04/30(月) 12:05:57.16 .net: >>765
500人月を1人日か
そんな事例知らないくせに、ぼくのかんがえたさいちょうのすーぱーぷろぐらま語ってドヤるとかリアル中学生かよ
767 ：仕様書無しさん：2018/04/30(月) 12:10:21.19 .net: まあでも俺がクソプログラムを100量産してる間に10リファクタリングしたとこで意味をなさないんだがなw
768 ：仕様書無しさん：2018/04/30(月) 12:17:18.95 .net: そのクソプログラム100個相当のものを
プログラム10個で作り上げるのがスーパープログラマ
当然リファクタリングした結果もこうなる
769 ：仕様書無しさん：2018/04/30(月) 12:18:09.57 .net: そして文の意味を理解できないアホが俺様リファクタリングしてむちゃくちゃにして動かなくするとw
770 ：仕様書無しさん：2018/04/30(月) 12:20:25.30 .net: お前らが100000人いてもlinuxは作れなかった
つまりそういうこと
771 ：仕様書無しさん：2018/04/30(月) 12:23:04.24 .net: 作れるのでは？
772 ：仕様書無しさん：2018/04/30(月) 13:13:20.41 .net: 作る以前に、思いつかなかった
それが重要だ
773 ：仕様書無しさん：2018/04/30(月) 13:58:00.43 .net: 付加価値ゼロのコードを
何万行書こうとも
付加価値ゼロだからね
774 ：仕様書無しさん：2018/04/30(月) 14:08:24.19 .net: 汚いコードは価値で言えばマイナス
775 ：仕様書無しさん：2018/04/30(月) 15:28:00.84 .net: >>763
単価安いのを10人集めれば出来る！
↑ダメ管理者が陥りがちな妄想の典型。
776 ：仕様書無しさん：2018/04/30(月) 16:04:59.12 .net: できなかった場合：奴隷がバカすぎるので金出さない
できた場合：こんなバカでもできる仕事に金出さない

奴隷がバカだから金出さないのは大前提
777 ：仕様書無しさん：2018/04/30(月) 19:09:11.03 .net: >>775
おまえも単価安い十天王の一角やんか
778 ：仕様書無しさん：2018/04/30(月) 19:15:18.91 .net: お前ら自分のことは棚にあげてるけど、スーパープログラマから見たらバカとお前らのレベル差なんて誤差みたいなもんやろ
779 ：仕様書無しさん：2018/04/30(月) 19:27:55.44 .net: 誤差ちゃうわw
クッキリとバカやでおまえらなんかw
780 ：仕様書無しさん：2018/04/30(月) 19:36:10.50 .net: >>778
だったら高いほうに合わせて金よこせ
馬鹿に合わせて全員の給料下げようとするんじゃねえ

ふざけんな畜生
781 ：仕様書無しさん：2018/04/30(月) 19:52:13.54 .net: 給与が低いと思ったらサボる
プロジェクトが失敗したって高い給与貰ってるPMさんが責任取ってくれる
プログラマみんなでこれを徹底する
これしかないんだよいい加減理解しろよ
782 ：仕様書無しさん：2018/04/30(月) 19:52:36.84 .net: 自称スーパープログラマーこんな所にるんだ
783 ：仕様書無しさん：2018/04/30(月) 20:09:40.59 .net: >>777
すぐ論点ずらしに走るのもダメ管理者の特徴。
まあ本人は上手いこと言ってやっだニダwとか思ってるのが痛いけど。
784 ：仕様書無しさん：2018/04/30(月) 20:15:53.56 .net: >>783
どまんなかの直球やぞ？マジにずれて見えるんか？
打たれすぎて脳ミソ液状化しとるやんおまえw
785 ：仕様書無しさん：2018/04/30(月) 20:34:48.35 .net: >>780
成果に見合った代価を得るのもスキルだぞ
プログラミングがろくにできない奴がバカプログラマだとしたら、金の話ができないのはバカリーマンww
786 ：仕様書無しさん：2018/04/30(月) 20:59:59.71 .net: 年収３００万の人間に何を期待しているんだ？
適当にやらせていただきます
787 ：仕様書無しさん：2018/04/30(月) 21:02:36.56 .net: まあ実際には何も期待されてない
ただの作業員だわな
788 ：仕様書無しさん：2018/04/30(月) 21:21:26.19 .net: そうそう
適当でいいんだよ
上が全部責任取ってくれる
789 ：仕様書無しさん：2018/04/30(月) 21:30:28.84 .net: 二日で終わる仕事を一週間かけるのはデフォ
790 ：仕様書無しさん：2018/04/30(月) 21:34:35.72 .net: >>784
すぐファビョるのもダメ管理者の特徴だな。
791 ：仕様書無しさん：2018/04/30(月) 23:39:07.39 .net: https://gigazine.net/news/20150603-how-critical-software-tested/

だってさ
スーパープログラマなんていらなかったんや
792 ：仕様書無しさん：2018/04/30(月) 23:48:16.67 .net: ロケット制御みたいな枯れた分野では予測可能性が重要で創造性は必要が無いってことね
793 ：仕様書無しさん：2018/05/01(火) 00:24:51.63 .net: 自分の嗜好と現実がぶつかったら現実のほうを否定するタイプだな
794 ：仕様書無しさん：2018/05/01(火) 00:29:43.04 .net: 　　　　　　　＼　 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__,ｲ::::
795 ：仕様書無しさん：2018/05/01(火) 00:33:25.55 .net: 異世界に転生して洋食屋に行きたい
796 ：仕様書無しさん：2018/05/01(火) 01:05:01.27 .net: 戻りたいと思えるような過去すらない
何もかも足りなすぎる
797 ：仕様書無しさん：2018/05/01(火) 11:24:21.67 .net: 三歳児は何もないのに楽しそうだよ
798 ：仕様書無しさん：2018/05/01(火) 11:41:22.97 .net: はあああああ
人類滅びねえかな
799 ：仕様書無しさん：2018/05/01(火) 13:16:25.14 .net: >>792
何故、枯れた分野だと？
800 ：仕様書無しさん：2018/05/01(火) 17:07:58.55 .net: テストなんて不要だ
不具合はすぐにユーザーが見つけてくれる
新しい価値の想像、そしてスピード感こそすべて
801 ：仕様書無しさん：2018/05/01(火) 17:16:31.18 .net: トイレでケツを拭く時間も無駄だとか言いそうなヤツですね
実際拭いてないとかいそうで困る
802 ：仕様書無しさん：2018/05/01(火) 22:19:55.22 .net: トイレにいく時間も無駄
803 ：仕様書無しさん：2018/05/01(火) 22:47:05.99 .net: >>800
確かにお前さんのは想像だけみたいだな。
804 ：仕様書無しさん：2018/05/02(水) 16:05:14.33 .net: >>800
MSさん毎月毎月止めてください
805 ：仕様書無しさん：2018/05/06(日) 21:12:14.93 .net: トイレと書斎を融合すれば座りっぱなしでいいからケツ拭かなくても無問題
806 ：仕様書無しさん：2018/05/08(火) 20:29:09.78 .net: MSって2005年にvs無償化したのを最後に、何も革新的なもの打ち出せてないよね。
807 ：仕様書無しさん：2018/05/08(火) 20:34:33.22 .net: それは単にお前が革新的だと認めたくないだけじゃないの？
808 ：仕様書無しさん：2018/05/08(火) 21:20:16.03 .net: 俺のパソコン買ったはずなのに
実際にはマイクロソフトが好きなようにいじくりまわす
809 ：仕様書無しさん：2018/05/08(火) 21:28:59.63 .net: C#ほど攻守において高い次元でバランスのとれた言語は他に存在しない
810 ：仕様書無しさん：2018/05/08(火) 23:13:03.66 .net: >>806
おじいちゃんこんにちは
811 ：仕様書無しさん：2018/05/09(水) 01:19:15.28 .net: まったまった、マジでMSが最前線を開拓した技術やサービスって、成功したのは割とないやろ
基本成功したやつをパクって金と物量でシェアもぎ取る感じやん
812 ：仕様書無しさん：2018/05/09(水) 02:46:20.20 .net: まだM$とか言ってるジジイ生きてんの
813 ：仕様書無しさん：2018/05/09(水) 02:54:34.82 .net: >>811
お前の言う最前線ってなんだ？
成功したもの＝最前線じゃないんだが？

どうせアップル信者だろうからそれで例えると
MacやiPhoneに最前線のものなど存在しない
どんなものでも成功できなかった最前線が別にある
814 ：仕様書無しさん：2018/05/09(水) 12:14:43.48 .net: 最前線なのに過去形とゆう矛盾wバカw
815 ：仕様書無しさん：2018/05/09(水) 13:30:14.38 .net: 最前線が軒並み失敗ってことだろ
816 ：仕様書無しさん：2018/05/09(水) 15:53:49.25 .net: 最前線である事は
十分条件であるが
必要条件ではない
817 ：仕様書無しさん：2018/05/09(水) 15:56:42.93 .net: 焦点は最前線をパクったのは誰かってことだろう？
818 ：仕様書無しさん：2018/05/10(木) 07:35:15.76 .net: タダでＯＳを配りつづける見返りに
相手のコンピューターを実質自分のものにして
個人情報を収集して国家に横流しし
見返りに便宜を図ってもらうことで会社が存続する

先鋭的ビジネスモデルの開発に成功した
819 ：仕様書無しさん：2018/05/10(木) 07:55:02.71 .net: あ、はい、スマホですね
820 ：仕様書無しさん：2018/05/10(木) 11:10:17.56 .net: >>806
サーフェス
アジュール
ウィンドウズモバイル
マウス復刻
Xbox
Windows10
TypeScript
VScode
VSのターゲットOS拡大
オフィス製品の料金体系
オフィスオンライン
SQLServerがいい感じになってきた

ほら、いろいろやってるじゃん
821 ：仕様書無しさん：2018/05/10(木) 11:12:31.49 .net: >>811
程度問題でもあるけど
アップルやグーグルもほとんどそうだぞ
自動運転だって1970年代には日本は研究はじめてるし
822 ：仕様書無しさん：2018/05/11(金) 00:03:49.96 .net: クール
↑
革新的かつ成功
typescript

革新的だが失敗
Surface→肝心のRTは失敗
Windowsモバイル→何故か失敗

成功したが、フォロアーとか競合とか繋いだだけ
Xbox
VSCode
VSターゲットOS(cordova、Xcode連携)
office365
office onlime

革新的でもなく、失敗
VSターゲットOS(xamarin系)
↓
ダサい

SQLserver、officeの料金体系とマウス復刻はわからん。なんの話題だろう
823 ：仕様書無しさん：2018/05/11(金) 00:10:59.36 .net: なんだかんだ言ってVisual Studioは一番快適なIDEでしょ
824 ：仕様書無しさん：2018/05/11(金) 00:15:38.04 .net: VScodeは神(拡張にもない機能は他エディタと併用)
VS2017もUnityをC#でやるなら神
それは否定しようがない
825 ：仕様書無しさん：2018/05/11(金) 00:36:33.78 .net: >>823
IntelliJは英語わかんないガイジにはきついもんな
826 ：仕様書無しさん：2018/05/11(金) 01:07:44.54 .net: >>825
Android開発するときは使ってるよ
その上でVisual Studioの方が優れてると思うね
827 ：仕様書無しさん：2018/05/12(土) 00:25:57.46 .net: IntelliJの良さがわからない
VScodeもVSに比べたらカス
スペック低いだけじゃないの？
828 ：仕様書無しさん：2018/05/12(土) 09:34:52.77 .net: VSCodeはエディタと他システムが疎結合であるという点が本家VSより優れている
OSSのようにマルチプラットフォームで作業したい場合
Web系のように多彩な外部ツールを柔軟に組み合わせたい場合
そういう時には本家VSというかall-in-oneが基本のIDEは不便なんだよね
829 ：仕様書無しさん：2018/05/12(土) 09:46:45.36 .net: >>827
VSCodeはエディタやろ
IDEと同じ土俵で比べなすなw
830 ：仕様書無しさん：2018/05/12(土) 10:04:47.70 .net: オブジェクト指向的で良いよなVSCode

class VSCode : ITextEditor
class Git : IVersionControlSystem
class CakeBuild : IBuildSystem

class VisualStudio : IGodDevSystem

だいたいこんなイメージ
831 ：仕様書無しさん：2018/05/12(土) 10:44:59.96 .net: >>829
使いようによってはIDEみたいなもんだろ
832 ：仕様書無しさん：2018/05/12(土) 10:50:18.06 .net: 関数名や変数名を単なる文字列置換じゃなく構文に沿って書き換えてくれる機能は超便利だよな。
833 ：仕様書無しさん：2018/05/12(土) 10:51:55.06 .net: >>831
違うよ
834 ：仕様書無しさん：2018/05/12(土) 11:53:23.76 .net: codeはバカ向けのvsやしな
好きな奴が多いのもわかるw
835 ：仕様書無しさん：2018/05/12(土) 11:59:14.37 .net: >>834
確かにVSの代わりとして使おうとするのはバカやな
836 ：仕様書無しさん：2018/05/12(土) 12:00:42.20 .net: デザインパターンのブログ（ヤフーブログ）・・・・なかなか良い。

https://blogs.yahoo.co.jp/kamyu_2010/35442561.html
837 ：仕様書無しさん：2018/05/12(土) 12:57:56.86 .net: >>834
そもそも用途が全然違うから比較するのがおかしい
838 ：仕様書無しさん：2018/05/12(土) 12:59:58.30 .net: >>837
vscodeでビルドやデバッグしたり、SCMと統合したりしてないの？
839 ：仕様書無しさん：2018/05/12(土) 13:09:50.99 .net: >>838
（VSが例に出てるから）たとえばC#の場合、それはVSCodeじゃなくてOmnisharp
840 ：仕様書無しさん：2018/05/12(土) 13:13:55.54 .net: >>839
うん、だからそういうのを統合したものが統合開発環境だよね
841 ：仕様書無しさん：2018/05/12(土) 14:12:29.90 .net: １つのインターフェースから様々なサブシステムをコントロールしてプログラミングのライフサイクル全体をサポートするのが統合開発環境である

という定義なら確かにVSCodeも統合開発環境と言える
しかしこれではEmacsやVimあるいはただのターミナルですら統合開発環境と言ってしまえる

じゃあ統合開発環境とその他の明確な境界線ってどこにあるのと聞かれるとそんなものは定義できないというしかないのが実情
なのでベンダが統合開発環境を公称したりユーザーの大部分がこれは統合開発環境だと認識して初めて統合開発環境とする以外に現実的な定義方法は存在しない

EmacsやVimなどの高機能エディタやただのターミナルを統合開発環境と呼ぶ人は滅多に居ないのでテキストエディタだ
同じようにVSCodeを統合開発環境と呼ぶ人は滅多に居ないのでこれもただのテキストエディタだ
842 ：仕様書無しさん：2018/05/12(土) 14:23:48.20 .net: そう言う意味ではEclipseも統合環境じゃ無くなるよな？
843 ：仕様書無しさん：2018/05/12(土) 14:27:49.40 .net: Eclipseは統合開発環境と言っていいだろう
記憶が間違ってなければ公式もそう自称してるし
多くのユーザーが統合開発環境だと認識している
844 ：仕様書無しさん：2018/05/12(土) 14:53:28.87 .net: >>840
違うってば
845 ：仕様書無しさん：2018/05/12(土) 15:34:35.01 .net: Eclipsが統合環境なら、Emacsだって統合環境って言っていいんじゃね？
統合して無い分は外部呼び出しなんてまるっきり同じだろ？
846 ：仕様書無しさん：2018/05/12(土) 15:47:03.72 .net: 自分で環境を作っていくのは統合環境じゃない
統合環境というのは（開発環境が）統合済みの環境であって
統合可能な環境じゃない
847 ：仕様書無しさん：2018/05/12(土) 15:58:56.55 .net: Eclipseなら最初から統合環境が整備されてるみたいな言い方だな。
848 ：仕様書無しさん：2018/05/12(土) 19:07:01.18 .net: >>845
Emacsは統合開発環境って自称してないしみんなテキストエディタと思ってるからテキストエディタだよ
849 ：仕様書無しさん：2018/05/14(月) 12:36:08.62 .net: 寄せ集めとintegratedは全然違うもんやろ
統合て訳すとよう分からんようになるけどw

総レス数 849
226 KB

掲示板に戻る全部前100 次100 最新50

read.cgi ver.24052200