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

**仕様書無しさん** · 2018/04/15(日) 13:13:44.63

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

**仕様書無しさん** · 2018/05/17(木) 13:41:19.44

emacs の学習曲線を検索すれば
統合されてない環境と言える

**仕様書無しさん** · 2018/05/17(木) 19:58:19.68

リファクタリングするだけのプロジェクトとかないのかな

**仕様書無しさん** · 2018/05/17(木) 21:29:06.23

>>851
作り直しっていうプロジェクトならいくらでもある

**仕様書無しさん** · 2018/05/17(木) 21:54:00.44

月給80万円でいいから永久にリファクタリングするだけのプロジェクトないかな？

**仕様書無しさん** · 2018/05/17(木) 21:59:23.66

一般的にウェブサービスなんかだとリリースされた後も
修正（改良）が続くのでリファクタリングし続けることになるだろうね。
もちろんリファクタリングだけではないけれど

**仕様書無しさん** · 2018/05/17(木) 22:00:23.48

kbnをtypeに直したり
typeをkbnに直すお仕事

今、お前がやってる仕事とあんまり変わらないじゃん

**仕様書無しさん** · 2018/05/17(木) 22:35:46.04

>>853
歴史学者とかなるといいよ

**仕様書無しさん** · 2018/05/17(木) 22:58:54.83

>>855
直す以前に最初からそんなコードありえなくね？
普通どっちにするか決めるでしょ？

**仕様書無しさん** · 2018/05/17(木) 23:06:00.21

>>853
お前の設計センスに月80万の価値はないやろ

**仕様書無しさん** · 2018/05/18(金) 07:57:25.67

>>858
設計ではありませんリファクタリングです
わからないのなら答えて貰わなくて結構ですよ？

**仕様書無しさん** · 2018/05/18(金) 08:31:20.14

じゃあそれで

**仕様書無しさん** · 2018/05/18(金) 08:36:00.68

承知しました

**仕様書無しさん** · 2018/05/18(金) 09:08:37.56

俺、リファクタはifダクで頼むわ、参考演算子は抜いてね

**仕様書無しさん** · 2018/05/18(金) 09:46:36.89

だいたい素人の考えるリファクタリングって
どこかずれてるよね >>862とか

**KAC** · 2018/05/18(金) 10:03:37.10

素人が考える設計もかなりズレてるから
リファクタリングがズレまくるのは仕方ない

**仕様書無しさん** · 2018/05/18(金) 10:13:30.16

で正しいリファクタリングしてるやつから、
お前間違ったリファクタリングしておいて、
自分の間違ったリファクタリングが意味ないーって
マッチポンプしてるだけじゃねーかって言われるわけな

**仕様書無しさん** · 2018/05/18(金) 12:18:10.02

>>865
ひっでえ文章
スパゲティの才能あるよキミ

**仕様書無しさん** · 2018/05/18(金) 12:28:23.21

正しいリファクタリングw
オナニーにまで権威的裏付けを求めるキチガイの発想ワロタw

**仕様書無しさん** · 2018/05/18(金) 13:12:21.69

コンパイラが思いっきり最適化すんだから、可読性以外の目的でリファクタリングなんかするなって言われた。

**仕様書無しさん** · 2018/05/18(金) 15:54:23.58

>>868
マーチン・ファウラー様がそう言っているのだから従いなさい

http://bliki-ja.github.io/IsOptimizationRefactoring/

> 最適化とリファクタリングはどちらも変化を伴うものだが
> （なかには最適化かつリファクタリングとなる変化もあるが）、
> 両者は別物だと私は考えている。
>
> なぜなら、両者の目的が異なるからである。リファクタリングは、
> コードを理解しやすくするためである。最適化は、プログラムを速くするためである。

**仕様書無しさん** · 2018/05/18(金) 16:23:34.97

一人で頑張ってリファクタリングしても百倍以上の人数で寄ってたかってスパゲティ量産されるからもう諦めた
お前らみたいな意識高い連中と仕事したい

**仕様書無しさん** · 2018/05/18(金) 16:29:18.34

>>870
それを防ぐにはコードのコミット前レビューが必須なんだよな
ただの儀式になってない、本当のコードレビュー

**仕様書無しさん** · 2018/05/18(金) 17:24:33.27

>>870
まずはリファクタリングを仕事にしてみたら？
それが出来ない現場には、元から未来は無いし。

**仕様書無しさん** · 2018/05/18(金) 17:39:16.06

>>872
でもそれはやっちゃいけないんだわ。
本来は最初にコード書いた人がリファクタリングまでやって
コミットするのが正しい流れだから。
責任がある人に、最後まで責任を取らせるのが筋。
もちろん教育を兼ねて手本を見せるのはいいけどね

**仕様書無しさん** · 2018/05/18(金) 17:54:57.00

リファクタリング専門業者があれば転職するんだが
メンテナンス不能になったシステムを蘇らせるだけのお仕事

**KAC** · 2018/05/18(金) 18:08:18.13

リファクタリングしたら全部テストしろよ？

**仕様書無しさん** · 2018/05/18(金) 18:10:36.34

バグ修正したら全部テストしろよ？

**仕様書無しさん** · 2018/05/18(金) 19:03:58.34

Windows Updateしたら全部テストしろよ？

**仕様書無しさん** · 2018/05/18(金) 21:32:03.58

>>873
自分の将来の為に手を動かしてみたら？ってだけだよ。

**KAC** · 2018/05/19(土) 00:11:47.58

>>877
それは流石に頭おかしい

**仕様書無しさん** · 2018/05/19(土) 02:46:48.77

おかしくない
ネットから遮断してＵｐｄａｔｅなどしなければいいんだ

**仕様書無しさん** · 2018/05/19(土) 08:01:10.59

>>879
素人さんは気楽でいいよね
Windows Updateの後になんらかの不具合がでる確率はわりと現実的な数字だよ
大きな組織なら経験あると思うがね
無視できるものじゃない

**仕様書無しさん** · 2018/05/19(土) 10:48:08.33

>>881
社会に出ろよ。

**仕様書無しさん** · 2018/05/19(土) 11:16:44.17

>>882
信じろってばｗ

**仕様書無しさん** · 2018/05/19(土) 11:16:57.59

>>881
大きい組織だとむしろ経験少ないだろ
小さい組織ほど無条件に更新かけて悲惨な目にあう

**仕様書無しさん** · 2018/05/19(土) 11:18:16.17

リファクタをそそのかされて
自分のコードが非常に汚いものに思えて
鬱で死にたくなってきた

**仕様書無しさん** · 2018/05/19(土) 11:21:52.19

コードがきれいな人もリファクタしてるから

**仕様書無しさん** · 2018/05/19(土) 12:12:37.26

>>885
コードが価値を生み出していることが第一
きれいとかそういうのは付加価値
本質を見失ってはならない

**仕様書無しさん** · 2018/05/19(土) 12:31:37.71

商品が売れていることが第一
生産コストがどうとかは付加価値

↑付加価値ではないだろ

**仕様書無しさん** · 2018/05/19(土) 12:39:02.26

>>888
プログラマーが一人二人楽になるのが
広汎なユーザーに対して損ねた価値に見合うことか？

**仕様書無しさん** · 2018/05/19(土) 12:45:02.00

え？プログラマが楽になるということは
少ない作業（コスト）で生産できるということだから
結果的に利用者に恩恵があるでしょう？

**仕様書無しさん** · 2018/05/19(土) 12:50:22.23

>>885
「この消臭スプレーはすごい効きますよ。オススメです」は「お前臭いよ」をオブラートに包んだ言い方
「リファクタリングオススメ」は「お前のコードクソだよ」をオブラートに包んだ言い方
日本人は回りくどい言い方をする

**仕様書無しさん** · 2018/05/19(土) 12:55:50.98

>>890
コードのきれいさのためにアプリとしての達成度が下がってるようなときはどうなんだ

**仕様書無しさん** · 2018/05/19(土) 13:00:12.79

身近な例だとスケーリングかな
スケールしたい時ってビジネスリスク回避かビジネス拡大のチャンスのどっちかなんだよね
その時になってメチャクチャに結合してるので簡単にはスケールできませんなんて事になったら大損害だよ
綺麗なコードには多大な価値があるんだよ

**仕様書無しさん** · 2018/05/19(土) 13:02:28.95

>>892
コードのきれいさのためにアプリとしての達成度が上がってる場合もありますよ？

**仕様書無しさん** · 2018/05/19(土) 13:04:47.54

コードが汚いと同業他社とのサービス競争にも負けるね
ライバル社が面白い機能を公開してユーザーの注目を集めてる
後追いになってしまうが自社も同等の機能を追加したい
コードが汚いと機能を追加するのにも時間がかかる
時間がかかればかかるほどユーザーの乗り換えが加速する
とんでもない損失だ

**仕様書無しさん** · 2018/05/19(土) 13:20:53.42

下請けの身だと、コードを納品して金をもらうことが第一
コストとかそういうのはエンドユーザーと元請けの間の話だから下請けには無関係

**仕様書無しさん** · 2018/05/19(土) 13:38:09.61

コードを綺麗に書けば、早く書けるしバグも少ない
すると残業もなくなるし、バグ修正の手間も減らせる
下請けでも綺麗なコードには価値があり

**仕様書無しさん** · 2018/05/19(土) 13:46:49.87

人月商売

**仕様書無しさん** · 2018/05/19(土) 14:00:47.81

>>897
つまり結果的に早ければコードのきれいさは関係ないんだよね？

**仕様書無しさん** · 2018/05/19(土) 14:32:19.77

>>899
母国語は？

**仕様書無しさん** · 2018/05/19(土) 14:38:06.94

ん？どこの国でも一緒じゃないん
さすがに関数名とか日本語にしないよ？？

**仕様書無しさん** · 2018/05/19(土) 14:47:16.03

あらら
通じなかったか

**仕様書無しさん** · 2018/05/19(土) 15:39:01.74

>>899
コスト意識の無いトイプロジェクトならそれでも良いんじゃね？

**仕様書無しさん** · 2018/05/19(土) 15:58:48.72

綺麗に早く安く高品質に書けるものをわざわざ汚く時間をかけてバグだらけにする意味がわからん

**仕様書無しさん** · 2018/05/19(土) 16:06:04.82

字下げだってそうよ
オールマンスタイルが読みやすいって人もいれば
Javaスタイルが良いという人もいる
いろんな人がいる、自分と違う価値観を受け入れてこそ
立派な社会人ですぞ

**仕様書無しさん** · 2018/05/19(土) 16:45:54.60

価値観じゃなくて実際に金に関わるんだよ
インデント派閥みたいなお遊びじゃねえんだからしっかりしろ

**仕様書無しさん** · 2018/05/19(土) 17:00:56.57

>>906
そんなのケースバイケースじゃん
アイデアをどこよりも早く出したいならスピード重視だし
末永く保守していくことが最初から確定してるSIer案件なら保守性重視するし
どちらの価値が大事ですかってことでしょ

**仕様書無しさん** · 2018/05/19(土) 17:03:00.99

>>899
> つまり結果的に早ければコードのきれいさは関係ないんだよね？

結果的に早いコードを「きれい」と言ってるんだよ

**仕様書無しさん** · 2018/05/19(土) 17:19:51.83

>>907
勘違いしてるね
アイデアをすぐに出すためには綺麗に書いた方が良いんだよ
スパゲティコードに機能を追加することは困難
綺麗に書けば書くほど機能を素早く追加できる

**仕様書無しさん** · 2018/05/19(土) 17:21:33.03

綺麗に書くのと製造スピードがトレードオフの関係にあるって誤解はなんで広まったんだろうな

**仕様書無しさん** · 2018/05/19(土) 17:29:23.99

>>910
スピード重視ならコピペ上等だからじゃないかな

**仕様書無しさん** · 2018/05/19(土) 17:30:47.66

>>909
勘違いしてないね
機能を追加するのはあとからでいい
その前にリリースしなきゃ、一生二番煎じのサービスと
言われ続けるよ、スピードが命なんだよこの世界

**仕様書無しさん** · 2018/05/19(土) 17:31:04.61

本当にコピペだけで済むなら関数にしたほうが良いじゃん。

コピペっていうのは、実はコピペ＋修正でしょ？
修正してる分遅くなってる

**仕様書無しさん** · 2018/05/19(土) 17:31:59.57

そしてスピードが重視だからこそ
リファクタリングが重要なんだよ。

まずリリース。そして問題なさそうならリファクタリング
そうやってスピードを落とさずにリリースをし続ける

**仕様書無しさん** · 2018/05/19(土) 17:32:39.90

どこよりも速いスピードでアイデアを形にして
サービスを提供してユーザが集まったら
0から作り直せば良い
最初から保守のこと考えて作ってたら
遅すぎるんだよ

**仕様書無しさん** · 2018/05/19(土) 17:33:35.15

>>913
ちょっと違う関数が出てきた場合に
抽象化するかコピペするかの選択を迫られる
躊躇なくコピペできる人間が勝負に勝つ

**仕様書無しさん** · 2018/05/19(土) 17:33:38.11

リファクタリングすればいいので
0から作り直す必要がない

**仕様書無しさん** · 2018/05/19(土) 17:34:07.66

>>916
同じ部分だけを関数にすればいいだけ

**仕様書無しさん** · 2018/05/19(土) 17:34:56.04

>>911
修正工数が跳ね上がるな

そもそもコピペするよりメソッド呼び出しの方が書くのも圧倒的に速いんだが

コピペって口で言うよりめんどくさい作業だと思うんだが？
お前らどう思う？

**仕様書無しさん** · 2018/05/19(土) 17:35:03.25

>>914
テスト作ってる暇なんて無いわ
リファクタリングなんてやってたら
リリース時点で負ける、最初の敗北は取り戻せない

**仕様書無しさん** · 2018/05/19(土) 17:35:26.83

>>917
どっちでも良い

**仕様書無しさん** · 2018/05/19(土) 17:36:07.74

>>920
だからリファクタリングがある
最初のリリースではテスト作らなくていい
だから勝てる。
そして勝った後リファクタリングをする
勝ち続けられる

**仕様書無しさん** · 2018/05/19(土) 17:36:27.44

>>918
はい負けた、お前いまスピード勝負で敗北した
お前のサービスは誰も使わない、どっかの誰かの真似だから
一番じゃないとダメなんだよ！

**仕様書無しさん** · 2018/05/19(土) 17:37:15.41

>>922
テストの無いリファクタリングなんてありえない
つまり最初のリリースではリファクタリングを考える必要ない
だから俺が言ってることが完全に正しい

**仕様書無しさん** · 2018/05/19(土) 17:37:54.88

>>912
リリースするまでも綺麗に書いた方が速いぞ
汚いコードはスケール小さくてもバグがわんさか湧いてくる
急ごしらえでリリースしたらバグが多くてユーザーが即座に興味を失ったサービスなんて珍しくもない

**仕様書無しさん** · 2018/05/19(土) 17:38:05.68

お前らそんなにリファクタリングが大事なら
自分のレスをリファクタリングしてろよｗ

**仕様書無しさん** · 2018/05/19(土) 17:40:02.41

>>920
テストコードを書かなくても手動テストはやらなきゃならない
手動テストやる工数でテストコードを書くのは容易

**仕様書無しさん** · 2018/05/19(土) 17:40:18.56

>>925
YouTubeもGoogleもバグだらけだが圧倒的インフラパワーと
サービスの斬新さでユーザに有無を言わさず使わせてるだろ
スタートダッシュでぶち抜かれたら勝てない
ツイッターもフェイスブックも1番だったから今でも頂点に君臨してるんだ

**仕様書無しさん** · 2018/05/19(土) 17:41:03.61

>>924
テストの無いリファクタリングなんてありえない
つまり最初のリリースではリファクタリングを考える必要ない
だから勝てる

その後リファクタリングをする
勝ったあとリファクタリングをする
勝ったと決まった後の話、勝つのは決定事項
その後のリファクタリングが勝利を継続させる
リファクタリング最高
勝った後勝ち続けられる

**仕様書無しさん** · 2018/05/19(土) 17:41:14.07

>>927
手動テストは必要ない
マウスポチポチして動いたやったリリースだ
これでOK
これが最速の世界

**仕様書無しさん** · 2018/05/19(土) 17:41:42.67

>>923
お前の負け
バグだらけで使い物にならん
急ごしらえでインターフェースデザインがクソだし
この会社名は脳内のブラックリストに入れて忘れるまでもう二度と使わん

**仕様書無しさん** · 2018/05/19(土) 17:42:12.76

>>929
なるほどじゃあお前は俺と全く同じことを言ってる
俺の代弁者として認めよう

**仕様書無しさん** · 2018/05/19(土) 17:43:39.28

>>928
そいつらはお前のコピペコードとは段違いの綺麗なコードを初手から書いてるんだよ
だかた大規模なサービスでもスムーズにスタートできた

**仕様書無しさん** · 2018/05/19(土) 17:43:58.60

リファクタリングは勝利を継続させる方程式

**仕様書無しさん** · 2018/05/19(土) 17:44:18.73

>>930
はいバグだらけ
ユーザーは見向きもしない
バイバイ

**仕様書無しさん** · 2018/05/19(土) 17:48:39.75

>>935
ユーザは使うんだよ、なぜならば斬新なアイデアだから
スピード重視でどこよりも早くそれを形にしたから
サービスとして使えるようにしたから
業界の人もなんだこれはと思いバグを見つけるだろうが
それさえも話題の一つになる、こんなバグがあったと
あざ笑う一方で笑ってる人間は同じだけの成果を出せない
つまりアイデアを誰よりも早く形にして世に出すという
ことがいつまでもできない

**仕様書無しさん** · 2018/05/19(土) 17:51:08.35

つまりアイデアを誰よりも早く形にして世に出す
そしてリファクタリング

**仕様書無しさん** · 2018/05/19(土) 17:51:16.64

TwitterもLINEもPayPalもコインチェックも
スピードで他を突き放したからこそ莫大な利益を得ることができた

**仕様書無しさん** · 2018/05/19(土) 17:51:36.18

スピードとメンテナンス性を両立させるのは
リファクタリングしかない

**仕様書無しさん** · 2018/05/19(土) 17:53:15.79

しかしリファクタリングの工数は取れない
なぜならばユーザに関係がないからだ

**仕様書無しさん** · 2018/05/19(土) 17:53:53.39

開発スピードが上がるからユーザーに関係ある

**仕様書無しさん** · 2018/05/19(土) 17:55:47.84

COBOLで作られてシステムがメンテナンス不能になったのは
COBOLという言語の問題ではなくリファクタリングしていなかったことが
問題だというのが最近の結論となっている

**仕様書無しさん** · 2018/05/19(土) 17:56:09.36

>>941
ユーザの要望はこういうサービスを作ってくれって
ことだ、開発のスピードは開発会社内での話だ
ユーザの要望とは一切関係ないし興味もないから
絶対に金は出しません！

**仕様書無しさん** · 2018/05/19(土) 17:56:57.52

>>943
端的に物事を言ったらどうだ？
ユーザーは開発費用を出さずに
開発しろと言ってるだけ

**仕様書無しさん** · 2018/05/19(土) 17:57:43.29

Windows95を開発した天才プログラマーの本を読め
大事なのはスピード・スピード・スピード

https://www.amazon.co.jp/dp/4905073413/
・遅い天才より、速い凡人がトップに立つ
・3500個の不具合があっても、世界は変えられる
・2:8の法則が、あなたの仕事を変えていく
・石膏像を掘るとき、「眉毛」から始める人はいない
・最強の昼寝は、18分
・あなたの仕事は、規則を守ることではない
・待ち合わせ30分前に、スタバでコーヒーを飲め

**仕様書無しさん** · 2018/05/19(土) 17:58:14.53

>>944
はい二番煎じ
俺が先に言った、お前は敗北者

**仕様書無しさん** · 2018/05/19(土) 17:58:39.79

ユーザーは開発費用を出さずに
開発しろと言ってるだけ
それに従うのは愚か者でしかない

**仕様書無しさん** · 2018/05/19(土) 17:59:13.43

>>945
Windows 10はリファクタリングしまくってる
スピードとはリファクタリングのことである

**仕様書無しさん** · 2018/05/19(土) 18:00:29.77

>>947
でも実績はできますよ
ユーザが有名な組織だったら
その実績をかざして儲かる仕事にありつけるって算段ですわ

**仕様書無しさん** · 2018/05/19(土) 18:01:20.23

>>948
圧倒的シェアで囲い込みができて
ベンダーロックインの状態なら
そうすることもできるやろうけどね