JJUG CCC 2024 Spring 複雑な業務ロジックに立ち向かうための実践技法 【初級編】 ①値の種類 ②範囲型 ③階段型 【中級編】 ④状態遷移 ⑤入出金履歴と残高 ⑥未来在庫 【上級編】 ⑦セット演算 ⑧割合と端数 ⑨決定表 ⑩経路探索
いまどきの分析設計パターン10選
JJUG CCC 2024 Spring 複雑な業務ロジックに立ち向かうための実践技法 【初級編】 ①値の種類 ②範囲型 ③階段型 【中級編】 ④状態遷移 ⑤入出金履歴と残高 ⑥未来在庫 【上級編】 ⑦セット演算 ⑧割合と端数 ⑨決定表 ⑩経路探索
「わし詳細設計書書くのやだよ」システム開発で細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない話に賛否両論
しのゆ𝕏酒くずエンジニア @shinoyu 新宿で社長やってるソフトウェアエンジニア18年生のおかまちゃん / 💻技術🎧 V系 🎀ロリィタの人 / 170スペ109 スプリング、骨ウェーブ、顔ソフエレ / 絡みない鍵とスパムは🚫 / 原則IT関連業のみフォロー /たまに会えるかも @shinjukudist しのゆ𝕏酒くずエンジニア @shinoyu わし詳細設計書書くのやだよ(￣･ω･￣) 細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない。 必要なのは完成に必要要件がまとめられたもの。それを元に受け入れ試験書がつくられる。それクリアすればどう作ってようが構わんわけだ 改修コストを下げるための設計になってることは前提だけどね。 だけど、詳細設計書が必要となる現場はこの設計することはできない。だってそれできてたら詳細設計書
2024/06/12 16:16 結論を追記 2024/06/12 20:29 より記事の内容を分かりやすく理解頂くため、タイトルを「PRDやDesign Docを書かなくなった」から変更 2024/06/13 20:39 結論にフロー情報・ストック情報に関する意見を追記 結論 この記事では、「様々な観点を考慮して網羅的にドキュメントを書いて、それを関係者にレビューしてもらう」のではなく、関係者と同期的に対話しながら、観点や選択肢やそのトレードオフを洗い出すことで、少ない手数でより良い答えが見つけられると主張する。 ただし、対話のために必要なドキュメントは事前に書いておくべきだし、対話した結果はドキュメントに残すことが望ましい。そして、そのドキュメントのフォーマットはPRDやDesign Doc以外でも良い。例えば、ADRはアーキテクチャに関する議論の過程と結果を述べる上で必要十分なフォー
やらない事を決めるプロダクト設計
https://kichijojipm.connpass.com/event/316361/ 設計ナイト2024で使った資料です。
設計ナイト2024でお話した内容です 開発組織の設計がまずは大事だよってことを書いてます https://kichijojipm.connpass.com/event/316361/
APIの開発は複雑でコストがかかる可能性があり、頻繁に更新されることからドキュメントを整備するのも難しい。APIの設計、開発、ドキュメントの整備、管理にまつわる課題と効率さの問題に対処するアプローチが、RESTful API Modeling Language（RAML：RESTful APIモデリング言語）だ。 RAMLコードを使えば、開発者はAPIの動作を説明する仕様を策定してからそのAPIをデプロイするまでのAPIライフサイクルを管理することができる。 RAMLとは RAMLは、RESTful APIを記述することを目的とするオープンソースの記述言語だ。2013年、米国のIT自動化および統合ベンダーであるMuleSoftを中心とする数社の企業によって作成されたRAMLはAPIの開発に大きな役割を果たしてきた。2018年、MuleSoftはSalesforceによって買収され、RAML
コンポーネント設計って何だろう | ドクセル
マーチン・ファウラー モジュールとは、明確に定義された一部のサブセットを 理解するだけでシステムを変更できるようにソフトウェ アシステムを分割したものと定義します。 コンポーネントはモジュールの一形態であり、独立して 置換できるという追加の特性を備えています。 出典 martinFowler.com “Software Component” より筆者抄訳 https://www.martinfowler.com/bliki/SoftwareComponent.html https://www.martinfowler.com/bliki/SoftwareComponent.html
こんにちは、株式会社FIXER＠名古屋オフィスの村上です。 クラウドインフラのシステム基盤構築にTerraformを採用している組織は多いですね。村上自身は特別な要件がない限り、”どのクラウドを使う場合でも” システム基盤構築にはTerraformを使いたいと考えているインフラエンジニアです。 私は、Terraformを3年間使用する中で、6つの課題に直面してきました。 このブログでは、実際の開発現場でどのような問題が起こったのか、またその問題をどのように回避、あるいは対策すべきだったのかについて、綴ってみました。 【課題１】プロジェクト始動直後にTerraform開発を開始したため、後工程で改修タスクが多発 SI案件では、クライアントが提案する調達要件RFPをもとに、ITベンダーがヒアリングを行いながら要件定義を進めていきます。 要件定義の一例として以下のようなものがあります。 クラウド
イベント駆動アーキテクチャ導入の手引きと共通の落とし穴 / Guide to Implementing Event-Driven Architecture and Common Pitfalls
イベント駆動アーキテクチャにおける落とし穴についてお話しています。 こちらは JJUG CCC 2024 Spring の講演用資料です。 Code: https://github.com/nrslib/pubsubdoc # URL YouTube: https://www.youtube.com/c/narusemi HomePage: https://nrslib.com Twitter: https://twitter.com/nrslib
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
網羅的なPRDやDesign Docを書かなくなった - kosui
良い開発のためにまず組織を設計せい
RESTful APIの設計、開発、ドキュメント管理を手助けする「RAML」とは
Terraformを採用する前に知っておくべき6つの課題