プログラマの雑談部屋 ★113

**仕様書無しさん** · 2020/06/19(金) 01:12:03.24

雑談スレ
※前スレ
プログラマの雑談部屋 ★110
https://medaka.5ch.net/test/read.cgi/prog/1592044204/
プログラマの雑談部屋 ★111
https://medaka.5ch.net/test/read.cgi/prog/1592114550/
プログラマの雑談部屋 ★112
https://medaka.5ch.net/test/read.cgi/prog/1592172381/

**仕様書無しさん** · 2020/07/05(日) 20:55:17.52

日本の未来は暗そうだ

**仕様書無しさん** · 2020/07/05(日) 20:55:41.78

アジャイルってスケジュールは大体だけ
決めておいて
いつ機能をリリースするかは進捗次第って感じなの？

これ読んだけどアジャイルが何なのか
理解できたか分からない

「アジャイル案件」に失敗して思ったこと
https://qiita.com/oedkty/items/182ad8f62422a0cc7edd

残業して無理やり決めたスケジュールの間に合わせるのはアジャイル的じゃないらしいが
開始時点でケツが決まってる開発スタイルだと
そんな柔軟な運用出来ないよな

**仕様書無しさん** · 2020/07/05(日) 20:56:42.77

トウキョウはもはや別の国

**仕様書無しさん** · 2020/07/05(日) 21:00:40.61

トラムプは、アメリカを変える権限はなくても、
日本を変える権限はある。

**仕様書無しさん** · 2020/07/05(日) 21:11:38.19

宇都宮先生は頑張った
都知事選も終わったから明日からはまたゲリゾーの汚職追求が始まるぞ

**仕様書無しさん** · 2020/07/05(日) 21:13:10.70

>>528
アジャイルはまず測定から始める
実装する機能に対して、多数決でポイントを与える
1回の開発サイクル（概ね二週間）で何ポイント消化できるかを把握する
それがチームの生産性（開発速度）となる

生産性がわかれば、次の開発サイクルに実装できるポイント数がわかる
ポイント数に収まるように、どの機能を実装するかみんなで協議して選ぶ
対象機能を決めたら、よほどのことがない限りはサイクルが終わるまで対象を変えない

こうして開発サイクルを繰り返して、一定期間ごとに、機能を追加したり減らしたり変更したりする
毎回ポイントの消化数を計測して、チームの生産性を最新化する
生産性に収まるだけ、次のサイクルの作業を選んで潰していく

生産性が落ちてきたら、リファクタリングで生産性を向上させる
リファクタリングにもポイントを割り振って、機能追加と同じように管理する

**仕様書無しさん** · 2020/07/05(日) 21:15:24.55

終わった終わった。
今回はクソオモシレー政見放送が見られたから、良しとしよう。

オンナの家をてんてんむし

**仕様書無しさん** · 2020/07/05(日) 21:15:26.48

>>495
チェック制約が追加されたのか
残念だがうちのバージョンだと動かせないな

**仕様書無しさん** · 2020/07/05(日) 21:25:54.87

ふむ

**仕様書無しさん** · 2020/07/05(日) 21:33:04.83

>>534
チェック制約が実装されてないDBでもトリガーで代替できるぞ
こういう基本を収めてないと仕事にならなくない？
アプリにバグがあっただけですぐに不正なデータが紛れ込むシステムなんてガバガバすぎて運用できん
UI、ドメイン、DBで多重チェックしなきゃ駄目だ

**仕様書無しさん** · 2020/07/05(日) 21:34:30.02

運用時に手作業でデータ入れることも多々ある
そういうときに制約がないと地獄だぞ

**仕様書無しさん** · 2020/07/05(日) 21:46:19.91

https://qiita.com/tokishirazu/items/147fe3cb3ec60a636154

**仕様書無しさん** · 2020/07/05(日) 21:48:52.24

>>536
DBでガチガチにするとそのガチガチさで死ねるってのがあるからねえ

>>537
制約があろうがなかろうがいわゆる管理機能的なものでシステム経由でデータの
追加削除を用意していない時点でダメな運用だという認識だからなあ
運用時の手作業でのDBのデータ操作なんてインシデントのトップ10に入るような
作業だろうよ、そういうのをいかに減らすかなんだけど

**仕様書無しさん** · 2020/07/05(日) 21:54:25.09

>>539
DBガチガチの動きにくさは問題じゃない
ガチガチで使いにくいなと思うってことは即ち不正なデータを入れようとしたってことだからな
ガチガチじゃなかったらバグデータが紛れ込んで後でもっと酷い目にあうところだ

**仕様書無しさん** · 2020/07/05(日) 21:58:37.44

>>539
そういうのを減らすのは当たり前、それでも必要なときはやらなきゃいかん
そういうときに制約があるかないかでは別世界だ
運用時に発生するイレギュラーとその対処法を全て予測することはできないし、それに備えてアプリを開発する予算だって無限には出てこない
それにくらべればDBが満たすべき制約は比較的容易に導き出せるし、実装も安い

**仕様書無しさん** · 2020/07/05(日) 22:00:07.93

>>532
解説ありがとう
それがベロシティってやつ？

サイクルを繰り返していれば
ボトルネックになってる部分は改善され、
ポイントの見積もりも正確になって残業も少なくなる・・・という感じ？

**仕様書無しさん** · 2020/07/05(日) 22:07:19.53

>>542
そだよ
ボトルネックが改善するかどうかは、分析と対応次第だけどね

**仕様書無しさん** · 2020/07/05(日) 22:15:07.68

DBの制約はプログラムの静的解析のように役に立つ
静的解析が通らなかったら苛つくけど、直すまではコミットしないだろ
それと同じだ
成約無しでデータを登録するのは、静的解析を通さずにコミットするようなものだ
そんなものは、後で盛大な事故を起こすに決まってる

**仕様書無しさん** · 2020/07/05(日) 22:28:15.93

そんなに多重チェックはいつもテストコードが動いているような
ことなのでは
テストにできることはテストでやればいい

**仕様書無しさん** · 2020/07/05(日) 22:33:40.34

外部キー設定しないプロジェクトはすごくよく見るな
というか馬鹿正直にやってたの数えるほどしかない

**仕様書無しさん** · 2020/07/05(日) 22:37:42.72

ドメイン層に例外処理を集約するのがdry原則的にベターなのでは

**仕様書無しさん** · 2020/07/05(日) 22:39:30.84

結局DELETE禁止にしてもDELETEフラグとかで管理するから十分な制約ができぬい