網羅的なPRDやDesign Docを書かなくなった - kosui
2024/06/12 16:16 結論を追記 2024/06/12 20:29 より記事の内容を分かりやすく理解頂くため、タイトルを「PRDやDesign Docを書かなくなった」から変更 2024/06/13 20:39 結論にフロー情報・ストック情報に関する意見を追記 結論 この記事では、「様々な観点を考慮して網羅的にドキュメントを書いて、それを関係者にレビューしてもらう」のではなく、関係者と同期的に対話しながら、観点や選択肢やそのトレードオフを洗い出すことで、少ない手数でより良い答えが見つけられると主張する。 ただし、対話のために必要なドキュメントは事前に書いておくべきだし、対話した結果はドキュメントに残すことが望ましい。そして、そのドキュメントのフォーマットはPRDやDesign Doc以外でも良い。例えば、ADRはアーキテクチャに関する議論の過程と結果を述べる上で必要十分なフォー
大公開！バッチアプリケーションの品質を高めるZOZOの『バッチ開発ガイドライン』 - ZOZO TECH BLOG
こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab
要件定義、基本設計、詳細設計の流れを総復習
はじめに 📘 この記事は ラクス Advent Calendar 2023 の7日目の記事になります。 要件定義から基本設計、さらに実装や保守運用に至るまでの一貫した経験を何度か積んできましたが、毎回 「要件定義って具体的に何の項目が必要だっけ？」 「基本設計との違いって何だったっけ？」 「基本設計と詳細設計の区別って？」 といった疑問が頭をよぎってきました。 そんなわけで、これまでの経験を振り返りつつ、開発プロセスについて１からまとめていくことで頭の中の大掃除を行なっていきたいと思います🧹 この記事の対象者 🎯 開発プロセスについて学びたい方 要件定義の基本を学びたい人 要件定義と基本設計の違いがわからない人 一緒に開発プロセスについて復習したい方 前提 記事中の一部（特に要件定義や基本設計、詳細設計のサンプル）を自動生成で作成してます。一貫性の無い内容があるかも知れませんが、あく
現実世界の事象から学ぶSOLID原則
# Object-Oriented Conference 2024 https://fortee.jp/oocon-2024/proposal/e1eb34cf-78ef-43f6-8a03-bb26c996cb62 概要 オブジェクト指向プログラミング (OOP) のコーディング慣例として広く採用される、SOLIDの原則。 コードの保守性、拡張性、再利用性を語る上では共通言語としても使用される一方で、初学者にとっては決して理解のしやすいものではありません。 これらの原則が抽象的であり、実際のコードにどのように適用されるか・適用した際に得られるメリットを理解するのが難しいことが理解を困難にする一因です。 しかし一度理解すると、SOLID原則が現実世界のありとあらゆる場所で適用されていることに気が付くはずです。 「clean architecture 達人に学ぶソフトウェアの構造と設計」にお
プラットフォームの上に劣化版のプラットフォームを作成してしまうアンチパターン「内部プラットフォーム効果」とはどういうものなのか
「ソフトウェア設計におけるアンチパターンの中に特にひどいにも関わらず文書化されていないものがある」として、ソフトウェア開発のためのハウツーガイドを提供するサイト「The Daily WTF」の設立者であるアレックス・パパディムーリスさんが「内部プラットフォーム効果(Inner-platform effect)」について投稿しています。 The Inner-Platform Effect - The Daily WTF https://thedailywtf.com/articles/The_Inner-Platform_Effect パパディムーリスさんは「システムをカスタマイズしすぎることで設計時に使用されたプラットフォームの粗悪なレプリカになってしまう」という現象を、「内部プラットフォーム効果」と命名しました。 内部プラットフォーム効果の代表的な例として、エンジニア以外でもデータベース
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
非同期ジョブをユーザーアクションに組み込まない
(勤務先に投稿した社内ブログの焼き直しです) ある日同僚から ActiveJob の perform_later で Barbeque にキューした非同期ジョブの起動が遅いと言われた。が、非同期ジョブの使い所について個人的な考えを書いてみることにする。 相談は「非同期ジョブの結果をユーザーに返しているため、高速になって欲しい。現状、最大で数分の時間を要す旨のメッセージを表示している」という内容でした。具体的には {内部 API} が重く、一部の処理を非同期ジョブにしていてユーザー体験の悪化につながっているとのこと。 盲目的に非同期にしても嬉しいことはない 結論としては、非同期にするのであれば丁寧にやれば良いけど、そもそも同期的でよくない? と考えて欲しいと返した。 まず、個人的にはユーザーアクション起因かつユーザーへフィードバックする必要のある処理を非同期ジョブにするのは本当に長時間かかる
マルチテナント SaaS のノイジーネイバー対策を想定して Azure API Management のポリシーでテナントコンテキストをカウンターキーにしてみる | DevelopersIO
各テナント 300 秒間に 10 回までしかアクセス出来ないようにします。 なので user1 が 10 回リクエストを送信すると、tenant1 の user1 と user2 は一定期間はリクエストに失敗するはずです。 一方でその間にも別のテナントである tenant2 の user3 はアクセス出来るはずです。 今回リクエストテストは API Management のテスト機能を使いました。 各ユーザーの JWT は事前に払い出しておき、テストパネルから Authorization ヘッダーに設定します。 試しに user1 でリクエストを送信してみると、次のようにポリシーが動作している様子が確認出来ました。 API Management のトレース実行機能を使ってるのですが、これめちゃくちゃ良いな...！ rate-limit-by-keyのところでtenant1が抽出されており、
Organizing a Go module - The Go Programming Language
A common question developers new to Go have is “How do I organize my Go project?”, in terms of the layout of files and folders. The goal of this document is to provide some guidelines that will help answer this question. To make the most of this document, make sure you’re familiar with the basics of Go modules by reading the tutorial and managing module source. Go projects can include packages, co
モジュラモノリスにおけるトランザクション設計の考え方 / transaction design on modular monolith
モジュラモノリスにおいてトランザクションはどうあるべきなのかについて整理している資料が少ない気付きがあったので「簡易的に」整理しました
インナーソース パターンブック
Join us on Thursday, April 18th, at 9am BST / 10am CEST / 1:30pm IST / 6pm AEST, when Mishari Muqbil, from Zymple/Bitergia, will discuss Transforming MLOps Culture with InnerSource Principles Join us on Tuesday, 30th April, at 3pm BST / 4pm CEST / 9am CDT / 7am PDT to hear Florence Rolland, from Novo Nordisk, and Laura Jeffords Greenberg, from Worksome, discuss Mastering Open Source: Balancing the
How to recover from microservices
I won't deny there may well be cases where a microservices-first architecture makes sense, but I think they're few and far in between. The vast majority of systems are much better served by starting and staying with a majestic monolith. The Prime Video case study that blew up the internet yesterday is but the latest illustration. Maybe once you reach the scale of Netflix or Amazon, there are areas
HTTP/2 と gRPC に対するよくある誤解。 - ねののお庭。
以前 .NET ラボで 「C# と HTTP/2 と gRPC」というタイトルで登壇しました。その時のスライドがこちらなのですが、ちらほら反応を頂きました。その結果、HTTP/2 や gRPC について勘違いしている人がちょこちょこいる事が分かったので、少し補足を書こうと思います。 blog.neno.dev 1. HTTP/2 で向上するのはスループットであって、1リクエストあたりの応答時間ではないよ。 HTTP/2 を使うからといって、1 リクエストあたりの応答時間が短くなるわけではないのです。 まず、1 HTTP リクエストあたりにかかる時間を、RTT とかいったりします。 1 RTT の内訳はだいたいこんな感じになります。 1 RTT = ネットワーク上で往路にかかる時間 + サーバの処理時間 + ネットワーク上で復路にかかる時間 HTTP/2 になったからといって、ネットワークを
CTO から見た，なぜスタートアップ
初期のソフトウェア設計は壊れがちなのか - Speaker Deck
Speaker Deck This deck requires a password Password
SvelteKitが正式リリースされたのでtRPCとPrismaを使ってWebアプリを開発してみた
新年あけましておめでとうございます。 昨年はあっという間に過ぎ去ってしまったので、2023年はたくさん開発していきたいです。 はじめに はじめまして、kosei28という者です。 普段は大学に通いながら個人開発している19歳です。 この度、Chatockという掲示板のようなWebアプリを開発したので、紹介させてください。 つくったもの スレッドを作って、その中に投稿することができます。 スレッドにはタグをつけることができて、タグによってスレッドを検索することができます。 いいねをすることもでき、いいねしたスレッドや投稿は自分のライブラリページから見返すことができます。 背景 さて、皆さんはSvelteKitを知っていますか？ SvelteKitとは、SvelteのWebアプリを開発するためのフレームワークで、ReactにおけるNext.jsのようなものです。 ルーティングやSSRなどができ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サブスクリプションサービスをつくる時にエンジニアが考えること / Behind the Scenes: Engineering a Subscription Service
日々の意思決定の積み重ねを記録するアーキテクチャ・デシジョン・レコード / Architectural Decision Records
IPA、「重要情報を扱うシステムの要求策定ガイド」を公開 3ステップでシステムの要求策定を支援
実践！モノリスからマイクロサービス！Event Stormingによるドメイン駆動設計から実装まで / AWS_Dev_Day_2023_E_3
現実世界におけるスキーマ設計の妥協
