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

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

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

**仕様書無しさん** · 2018/05/08(火) 21:28:59.63

C#ほど攻守において高い次元でバランスのとれた言語は他に存在しない

**仕様書無しさん** · 2018/05/08(火) 23:13:03.66

>>806
おじいちゃんこんにちは

**仕様書無しさん** · 2018/05/09(水) 01:19:15.28

まったまった、マジでMSが最前線を開拓した技術やサービスって、成功したのは割とないやろ
基本成功したやつをパクって金と物量でシェアもぎ取る感じやん

**仕様書無しさん** · 2018/05/09(水) 02:46:20.20

まだM$とか言ってるジジイ生きてんの

**仕様書無しさん** · 2018/05/09(水) 02:54:34.82

>>811
お前の言う最前線ってなんだ？
成功したもの＝最前線じゃないんだが？

どうせアップル信者だろうからそれで例えると
MacやiPhoneに最前線のものなど存在しない
どんなものでも成功できなかった最前線が別にある

**仕様書無しさん** · 2018/05/09(水) 12:14:43.48

最前線なのに過去形とゆう矛盾wバカw

**仕様書無しさん** · 2018/05/09(水) 13:30:14.38

最前線が軒並み失敗ってことだろ

**仕様書無しさん** · 2018/05/09(水) 15:53:49.25

最前線である事は
十分条件であるが
必要条件ではない

**仕様書無しさん** · 2018/05/09(水) 15:56:42.93

焦点は最前線をパクったのは誰かってことだろう？

**仕様書無しさん** · 2018/05/10(木) 07:35:15.76

タダでＯＳを配りつづける見返りに
相手のコンピューターを実質自分のものにして
個人情報を収集して国家に横流しし
見返りに便宜を図ってもらうことで会社が存続する

先鋭的ビジネスモデルの開発に成功した

**仕様書無しさん** · 2018/05/10(木) 07:55:02.71

あ、はい、スマホですね

**仕様書無しさん** · 2018/05/10(木) 11:10:17.56

>>806
サーフェス
アジュール
ウィンドウズモバイル
マウス復刻
Xbox
Windows10
TypeScript
VScode
VSのターゲットOS拡大
オフィス製品の料金体系
オフィスオンライン
SQLServerがいい感じになってきた

ほら、いろいろやってるじゃん

**仕様書無しさん** · 2018/05/10(木) 11:12:31.49

>>811
程度問題でもあるけど
アップルやグーグルもほとんどそうだぞ
自動運転だって1970年代には日本は研究はじめてるし

**仕様書無しさん** · 2018/05/11(金) 00:03:49.96

クール
↑
革新的かつ成功
typescript

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

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

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

SQLserver、officeの料金体系とマウス復刻はわからん。なんの話題だろう

**仕様書無しさん** · 2018/05/11(金) 00:10:59.36

なんだかんだ言ってVisual Studioは一番快適なIDEでしょ

**仕様書無しさん** · 2018/05/11(金) 00:15:38.04

VScodeは神(拡張にもない機能は他エディタと併用)
VS2017もUnityをC#でやるなら神
それは否定しようがない

**仕様書無しさん** · 2018/05/11(金) 00:36:33.78

>>823
IntelliJは英語わかんないガイジにはきついもんな

**仕様書無しさん** · 2018/05/11(金) 01:07:44.54

>>825
Android開発するときは使ってるよ
その上でVisual Studioの方が優れてると思うね

**仕様書無しさん** · 2018/05/12(土) 00:25:57.46

IntelliJの良さがわからない
VScodeもVSに比べたらカス
スペック低いだけじゃないの？

**仕様書無しさん** · 2018/05/12(土) 09:34:52.77

VSCodeはエディタと他システムが疎結合であるという点が本家VSより優れている
OSSのようにマルチプラットフォームで作業したい場合
Web系のように多彩な外部ツールを柔軟に組み合わせたい場合
そういう時には本家VSというかall-in-oneが基本のIDEは不便なんだよね

**仕様書無しさん** · 2018/05/12(土) 09:46:45.36

>>827
VSCodeはエディタやろ
IDEと同じ土俵で比べなすなw

**仕様書無しさん** · 2018/05/12(土) 10:04:47.70

オブジェクト指向的で良いよなVSCode

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

class VisualStudio : IGodDevSystem

だいたいこんなイメージ

**仕様書無しさん** · 2018/05/12(土) 10:44:59.96

>>829
使いようによってはIDEみたいなもんだろ

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

関数名や変数名を単なる文字列置換じゃなく構文に沿って書き換えてくれる機能は超便利だよな。

**仕様書無しさん** · 2018/05/12(土) 10:51:55.06

>>831
違うよ

**仕様書無しさん** · 2018/05/12(土) 11:53:23.76

codeはバカ向けのvsやしな
好きな奴が多いのもわかるw

**仕様書無しさん** · 2018/05/12(土) 11:59:14.37

>>834
確かにVSの代わりとして使おうとするのはバカやな

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

デザインパターンのブログ（ヤフーブログ）・・・・なかなか良い。

https://blogs.yahoo.co.jp/kamyu_2010/35442561.html

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

>>834
そもそも用途が全然違うから比較するのがおかしい

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

>>837
vscodeでビルドやデバッグしたり、SCMと統合したりしてないの？

**仕様書無しさん** · 2018/05/12(土) 13:09:50.99

>>838
（VSが例に出てるから）たとえばC#の場合、それはVSCodeじゃなくてOmnisharp

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

>>839
うん、だからそういうのを統合したものが統合開発環境だよね

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

１つのインターフェースから様々なサブシステムをコントロールしてプログラミングのライフサイクル全体をサポートするのが統合開発環境である

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

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

EmacsやVimなどの高機能エディタやただのターミナルを統合開発環境と呼ぶ人は滅多に居ないのでテキストエディタだ
同じようにVSCodeを統合開発環境と呼ぶ人は滅多に居ないのでこれもただのテキストエディタだ

**仕様書無しさん** · 2018/05/12(土) 14:23:48.20

そう言う意味ではEclipseも統合環境じゃ無くなるよな？

**仕様書無しさん** · 2018/05/12(土) 14:27:49.40

Eclipseは統合開発環境と言っていいだろう
記憶が間違ってなければ公式もそう自称してるし
多くのユーザーが統合開発環境だと認識している

**仕様書無しさん** · 2018/05/12(土) 14:53:28.87

>>840
違うってば

**仕様書無しさん** · 2018/05/12(土) 15:34:35.01

Eclipsが統合環境なら、Emacsだって統合環境って言っていいんじゃね？
統合して無い分は外部呼び出しなんてまるっきり同じだろ？

**仕様書無しさん** · 2018/05/12(土) 15:47:03.72

自分で環境を作っていくのは統合環境じゃない
統合環境というのは（開発環境が）統合済みの環境であって
統合可能な環境じゃない

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

Eclipseなら最初から統合環境が整備されてるみたいな言い方だな。

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

>>845
Emacsは統合開発環境って自称してないしみんなテキストエディタと思ってるからテキストエディタだよ

**仕様書無しさん** · 2018/05/14(月) 12:36:08.62

寄せ集めとintegratedは全然違うもんやろ
統合て訳すとよう分からんようになるけどw

**仕様書無しさん** · 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
> つまり結果的に早ければコードのきれいさは関係ないんだよね？

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