【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
"The Essence of Software"が提唱する全く新しいソフトウェア設計の考え方｜Idein株式会社
（6/22 注：書き足りないと思っていた箇所を補って加筆修正しました） エンジニアのbonotakeです。Ideinに入ってかれこれ3年以上経ちますが、Ideinでブログ記事を書くのは初めてです。 今日は、ソフトウェア設計の全く新しい考え方について書かれた "The Essence of Software" という本の紹介をしたいと思います。 この本の著者はMIT教授でソフトウェア工学の世界的な研究者であるDaniel Jacksonです。形式手法Alloyの発明者、と言ったほうが通じる人には通じるかもしれません。形式手法とは、ありていにいえば、数理論理学を駆使してソフトウェアに潜むバグを論理的に駆逐する手法です。 （個人的な宣伝ですが、彼の書いたAlloyの本を以前翻訳して出版しました。） そんな彼が昨年11月に新著を出版したというので、ほぼその日に買いました。……ですが、本を開いてみる
深いドメインと統合型経営プラットフォームを支えるモジュラモノリスの事例 / Modular Monolith That Support Deep Domains And Integrated Management Platform
freeeにおけるモジュラモノリスの事例を大規模プロダクトから新規プロダクトまで紹介します。
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
スタメンの技術的負債解消戦略 - stmn tech blog
1. これはなに こんにちは、リファクタリング大好きなミノ駆動です。2023年7月より株式会社スタメンにジョインしました。 この記事は、今後スタメンにおいてサービスの技術的負債を解消する設計戦略についてまとめたものです。 2. 背景、課題 株式会社スタメンは2016年創業。主要サービスであるTUNAG（ツナグ）は、企業のエンゲージメントの構築、つまりお互いを知って理解し、信頼し合う組織を作るための社内コミュニケーションを活性化させるプロダクトです。TUNAGのバックエンドはRuby on Railsで開発され、ローンチから7年をむかえつつあります。 これまでTUNAGは、プロダクトをいかに伸ばすかに注力してきた一方、内部品質や開発効率など「開発者体験」に関する課題が後手に回っていました。本来プロダクトチームはユーザーにとっての本質的な価値にのみフォーカスできる状況が理想ですし、開発者体験が
【C#】SOLID原則を学ぼう - Annulus Games
今回の記事はオブジェクト指向プログラミングにおける設計の基本、「SOLID原則」について。 ある程度プログラミングの文法を知っていれば、動作するコードを書くことは可能です。しかし、より良いコードを書きたいのであれば、文法の知識だけではなく、設計に関する知識も必要になってきます。 特にUnityでは、適当にコードを書いていくと目も当てられないようなスパゲッティーコードが容易に出来上がります。「とりあえずシングルトンにすりゃいいや！」みたいなノリで「何とかManager」クラスを作りまくった結果、「あれ？この処理どこに書いたんだっけ？」という状況になったこと、誰しも一度はありますよね…？ 今回は、そんなクソk…良くないコードを書かないための設計原則である「SOLID原則」について紹介します。記事内のコードはC#で記述しますが、言語に関わらずSOLID原則は広く応用の効く考え方なので、是非とも覚
改めて整理するアプリケーション設計の基本
「ビジネスロジックの処理は2つに分類すると整理しやすい」 4つの例から考える、プレゼンテーション層・データアクセス層の見分け方
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コミュニケーション手段としてのモデリング
マイクロサービスにおけるBFFアーキテクチャでのモジュラモノリスの導入
“A Philosophy of Software Design” を30分でざっと理解する / Understand roughly "Philosophy of Software Design" in 30 minutes
【2022/10/20】改めて整理するアプリケーション設計の基本【アーカイブ】
改めて整理するアプリケーション設計の基本
