匿名ダイアリー「Railsは技術的負債である」？
https://anond.hatelabo.jp/20190329105413
なにも目新しいことは何一つ言ってないし，べつにRailsやWebフレームワークに固有の問題でもないと思う．*1
Railsを使うと、初速は早くなる。それは間違いないと思う。一方で、RailsはVierwからDBまで密結合したフレームワークなので、
(中略）
これは、まさに技術的負債そのものである。ここでわたしが「技術的負債」を「単なる悪いもの」として扱っているわけではないことに注意してほしい。
そもそも疎結合とか密結合とかいうのは相対的なものであり，完全に密結合な設計も完全に疎結合な設計も存在しない．あくまで「特定の実装に比べてどうか」という話でしかない．
そして
Railsを使うというのは、そういう将来の負債を借り入れて、その借金を使って早くプロダクトを世の中に届けるという判断をしている、ということだ、ということを言っているのであって、「借金してでも早く出したい」という判断が合理的で正しい場合ってのは、腐るほどある。
この愚かな判断が正当化されることは滅多にないということを，クソ経営者には胆に命じておいてもらいたい．*2
世の製品の99％では開発速度は問題にならない．仮に予定通りに，或いは予定より早くプロダクトを出荷しても，ヒットせずに失敗するからだ．
残りの1％では，速度は重要だ．特に「ヒットした後」の速度が重要だ．様々な機能追加，パフォーマンス向上，高いセキュリティなどなど．ユーザーの要求は止まる所を知らない．当初は全く予想していなかった使い方をされたり，歴史的事件で注目を集めることもあるかもしれない．
その際に機能が十分に早く実現できれば生きのこれるかもしれないし，そうできなければ消えゆくサービスとなるかもしれない．
そして、もしそれらのハードルをなんとか乗り越えられたとき、ビジネスが成功するか失敗するかをソフトウェアの品質が握る分岐点にあなたは立つことになるのだ。
(中略）
バグの修正には何時間も何日もかかり、修正や機能の変更には数日から丸々1週間を費やし、この停滞が速く仕事を進めたいと思う他の関係者を足止めし、あなたは技術的負債を解消する時間を取ることもできず、痛みが悪化するだけという悪循環に陥る。言うまでもないが、この悪循環はしばしば死のスパイラルになり得る。最初の「最小限の実行可能な製品」は完璧にエレガントでスケーラブルであることはなく、またその必要もないというのは事実だ。しかし、もしそれが泥沼ソフトウェアで、あなたが人々が望むものを構築仕損なっていた場合には、対応はとても困難で遅々として進まず、目標を変えるのも高価についてしまうのだ。一方高品質のソフトウェアを持つ競争相手や新規参入者たちは次々と素早く取捨選択を進めていける。
https://jp.techcrunch.com/2016/07/25/20160724how-much-does-it-matter-if-your-software-quality-sucks/
http://javablack.hatenablog.com/entry/20150319/p1
まさに今現在，COVID-19の大流行という歴史的事件のおかげで利用者が増えた Zoom が，セキュリティ問題を指摘され窮地に立っている．
- 「問題が相次いで発覚した「Zoom」でヴィデオ会議を開く際に、まずユーザーが考えるべきこと」 https://wired.jp/2020/04/03/zoom-backlash-zero-days/
- 「Zoom、台湾政府がセキュリティ上の懸念から全面禁止。ドイツ外務省やGoogleも使用に制限」 https://japanese.engadget.com/jp-2020-04-09-zoom-google.html
- 「Zoomの株主が同社のセキュリティ対策の「誇張」で提訴」 https://jp.techcrunch.com/2020/04/09/2020-04-08-zoom-sued-shareholder-security/
この危機を早期に乗り越えれば飛躍的な急成長を遂げるかもしれないし，失敗すればライバルに敗北して早々に市場から消え去るかも知れない．
- 「Zoom、会議ID非表示などセキュリティ関連のアップデート」 https://www.itmedia.co.jp/news/articles/2004/09/news059.html
- 「Zoom、元Facebookのセキュリティ責任者をアドバイザーに指名し、CISO評議会を結成」 https://www.itmedia.co.jp/news/articles/2004/09/news056.html
- 「Zoomのセキュリティ強化が続く。90日後には使い勝手の良さとセキュリティが両立する可能性も。」 https://news.yahoo.co.jp/byline/ohmototakashi/20200415-00173356/
- 「ビデオ会議のセキュリティをめぐってZoomとマイクロソフトがつばぜり合い」 https://ascii.jp/elem/000/004/009/4009227/
クソコード動画「Managerクラス」#すえなみチャンス暑気払い pic.twitter.com/3FSQDkXfHu
— ミノ駆動 (@MinoDriven) August 3, 2019
そういえば 7pay も終わったなあ．．．最速のサービスだった．(嬉しくない）
https://www.7pay.co.jp/
https://b.hatena.ne.jp/entry/s/anond.hatelabo.jp/20190329105413
laiso 質とスピード https://speakerdeck.com/twada/quality-and-speed-2020-spring-edition でいうスピードを支えるのは個人の能力、保守性向上の損益分岐点は1ヶ月という話を思い出してた
「あとでクリーンにすればいいよ。先に市場に出さなければ！」
開発者はそうやっていつもごまかす。だが、 あとでクリーンにすることはない。 市場からのプレッシャーは止まらないからだ。「先に市場に出さなければ」ということは、後ろに競合他社が大勢いるということである。競合他社に追い抜かれないためには、これからも走り続けるしかない。技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、 意図的に品質を落としたとしても速度はあまり上がらない。
逆に、技術力が高くない人が時間をかけて作ったとしてもその人の技術力以上の品質のコードは書けない。
このプレゼンに同意だなあ．早い人は手抜きはしても汚くはならない．綺麗「だから」早いのであって，汚くて早いというのはまずない．健全な経営なら，資産は少なくてもサラ金から大金を借りたりはしない．
- id:hdampty7 RailsがっていうよりかつてはRubyそのものがスケールデメリットをもってた感じだった。失敗としてよくあるのは未熟な自称アジャイル開発者がサービス本番の要求スケールを考えもせずに採用して事故って環境のせいにする
やりすぎた疎結合は，それ自体が技術的負債ですよ．特にプログラミングを分かってない人の作った疎結合は，論理的にはスパゲッティ化した密結合になっていて手に負えないこともある．
- id:garbagephilia 「n年で終了事前確定。その後機能含めて再設計」が通るのは夢の世界。言語バージョンの、フレームワークバージョンの、ライブラリの…EOL掛け合わせると本当の寿命はえーと、えーと…というところ多そう。
- id:non_117 愚痴は具体的に書かないと共感されませんよ。
- id: hororman この記事は最終更新日から1年以上が経過しています。
ほんとだ．なんでいまさらホットエントリ入りしたんだろう．
*1:しかも古い奴なのに，なんでいまごろ．
*2:「借金してでも早く出したい」と言ってるのは，「ベンチャーキャピタルから出資を受けて」みたいな意味で使ってるんだろうけど，技術的負債の例えとしては適切なものではない．技術的負債は，あえていうなら「高利貸し」だろう．それもとってもヤバいスジの人．
