Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
![ソフトウェアの負債には多額の費用がかかる](https://cdn-ak-scissors.b.st-hatena.com/image/square/945e00b1c7c09c358584cecb10d006bd8c989bf8/height=288;version=1;width=512/https%3A%2F%2Fcdn.infoq.com%2Fstatics_s1_20240815071826%2Fstyles%2Fstatic%2Fimages%2Flogo%2Flogo-big.jpg)
画面設計とか外部設計とか、もうやめようよに対し色々意見をいただいた。感謝。 要点繰り返し 自分は「画面の見本を使ってフィーチャを抽出する」というやり方に反対はしてない。 ただし、その「見本」が妙に具体的かつ詳細になってくると、本来フィーチャではないものまでフィーチャとして取り出してしまい、後続の工数が膨れちゃうよ、ということを警告しているのである。 「妙に具体的かつ詳細な見本」ってのは、世の人がいう「画面設計書」でしょ? なのでそんなのはやめちゃえ、ということ。 以下、頂いた意見に対しての感想などを。 家やマンションに例えない 「家やマンションは最初に完成像をみてもらい納得してもらう必要がある。システム開発も同じだ。」みたいな意見があった。 画面の見本があれば完成像を想像しやすくはなるけど、実際に動く見本があれば想像する必要はなくなる。 むしろ、操作することで「紙芝居」ではわからなかった要
どうやって設計で品質を作りこむか? 平鍋さんのblog、An Agile Wayのエントリ、 「Back Slash -- 開発V字モデルのバックスラッシュ」の以下の一文を読んで、 最近考えていた、設計工程でどう品質を作りこむのかについての考えが正しい のではないかという気がしてきた。アジャイルはこれをミクロに行います(V字をフラクタルに細かく切る) その考えとは、 少なくとも詳細設計の段階、または何らかのシミュレートが必要な場面では、 最低でも擬似コードレベルでのコーディングが必要である。 UMLのクラス図とシーケンス図を書いて、設計したつもりになってはいけない。 というものである。 きっかけは、「ソフトウェア設計とは何か?」に書かれている 以下のような内容である。 私は自らが理解しているソフトウェア開発のライフサイクルを 再吟味することにより,工学的な設計基準を本当
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く