「良いコードとは何か」で消耗するのはもうやめよう - DMM Developers Blog
これはなに？ こんにちは、DMM.comのミノ駆動です。 プラットフォーム開発本部 Developer Productivity Group 横断チームにて、 プラットフォームの設計品質向上に取り組んでいます。 さて、ネット上ではソフトウェア開発における「良いコードとは何か」をめぐって、 いろんな意見が交錯したり、 ときには激論を呼んだりします。 収拾がつかないこともしばしばです。 この記事は、良いコードを考えるうえでの要素を整理し、 建設的な議論を助けることを目的とします。 これはなに？ この記事の理解目標 良いコードをめぐる議論 議論1: 何をもって良いコードなのか 議論2: 良いコードはどうやったら書けるのか 議論3: 「綺麗なコード（良いコード） vs 動くコード」問題 議論改善のために提案します 提案1: ソフトウェア品質特性の観点でコードの良し悪しを判断しよう 提案2: 原理原
『現場で役立つシステム設計の原則』を読みました - 人間のあるべき姿の探索
はじめに 現場で役立つシステム設計の原則を知りたいと思っていたのですが、丁度現場で役立つシステム設計の原則について言及されている書籍があったので読みました。 gihyo.jp ある程度知名度のある書籍で、QiitaやZenn等でまとめられている方がいらっしゃるのですが、自分のアウトプットとして、感想も交えてまとめていきます。 全体の話 この書籍の雰囲気や見通しを立ちやすくするために、参考書籍の一覧を抜粋して紹介します。 『エリック・エヴァンスのドメイン駆動設計ソフトウェアの核心にある複雑さに立ち向かう』『新装版リファクタリング既存のコードを安全に改善する』『SQLアンチパターン』『エンタープライズアプリケーションアーキテクチャパターン』『エクストリームプログラミング』 システム設計の全般を対象にしているのですが、ベースの思考としてはオブジェクト指向プログラミングから発展して、ドメイン駆動設
要件定義失敗と改善の歴史 ~ その時、要求・ユーザーストーリーをどうまとめ、どう改善してきたか ~ - 株式会社ヘンリー エンジニアブログ
こんにちは。ヘンリーCEOの逆瀬川です。 開発する上で、難しい部分の一つである要件定義。 最近、社内では「要求仕様」と呼ばれるようになり、要求仕様化のプロセスとフォーマットの改善に取り組んでいます。しかし、3年間にわたって苦労し、失敗と改善を繰り返してきた歴史があります。 本ブログでは、主にプロセスとフォーマットの失敗について触れますので、詳細は割愛します。「ココもっと深く知りたい！」という方は、ぜひカジュアルにお話しましょう。その場で深堀りいただいた内容を元に、更にブログで考察していきたいと思います。 では、過去私たちが体験した5つの時代と今後訪れるだろう要求開発黄金時代についてお話しましょう。 ユースケースで仕様漏れた時代 要求導入混沌時代 要求を全員で書くぞ時代 プロダクト要求と仕様を分けて書き始めた時代 CSと連携して速度が上がり始めた夜明け前 将来訪れるだろう要求開発黄金時代へ
CTO から見た，なぜスタートアップ
初期のソフトウェア設計は壊れがちなのか - Speaker Deck
Speaker Deck This deck requires a password Password
Flutterアプリにおける、過不足ない設計の考察🎅
Photo by Hush Naidoo Jade Photography on Unsplash「一般的なモバイルアプリ」の設計全般において、特に何に気を付ける必要があるか、あるいは逆にあまり気にしてなくても良いのではと思うことなどを述べていきます。 (…のつもりでしたが、後者含めると1記事に収めるの困難で、最後にさらっと触れつつ別記事で手厚く書きたいところです🤔) ここでの「一般的なモバイルアプリ」は規模観点では以下程度のイメージですが、それを超えるような規模でも通ずる内容も多いと思っています。 コード量: 数万〜十数万行実装者: 一桁人種類としては(スマホ向けの)クライアントアプリコードであり、以下などではないです。 パッケージ・ライブラリではないサーバーサイドではないこの種類によって適切な組み方はけっこう変わり、アプリコードは依存関係の末端側(基本的に依存される側にはならない)な
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
2022年10月1日に開催された #postdev での発表です
ソフトウェア設計について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では、「これはどうな
テーブル設計の考え方とやり方 [入門編]
「基本から学ぶテーブル設計 超入門！」 https://modeling-how-to-learn.connpass.com/event/242944/ の発表資料。 - ２つの設計スタイルの違いを理解する - 何を記録するか（資源・活動・当事者・規程） - どう記録するか（テーブルの役割…
![テーブル設計の考え方とやり方 [入門編]](https://cdn-ak-scissors.b.st-hatena.com/image/square/fff34d6fcb76b27f602c88a8a78045329642f395/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F5416b70d025345fc95b30d1ec95701b6%2Fslide_0.jpg%3F20931325)
最近の海外DDDセミナーを聞いてみたら色々と常識が破壊された - Qiita
TL;DR 最近の設計志向はイベント駆動がかなり中心になっている とくにDDD界隈がここまでイベント駆動一本槍だとは思わなかった ストーリーを出発点にイベント駆動で設計を組み立てる「イベントストーミング」がかなり多くの場所で事例として取り上げられている はじめに 最近、洋書や動画の講演資料などいくつか海外の情報源に当たることがおおくなり、その中で「結構日本でやられている取り組みとちがうなー」と考えることが多く、一旦そのあたりの差分をまとめておこうかと思いました。 ただの出羽守（あるいは鹿鳴館精神）ではなく、一つの潮流としてこんなのがあるってのを記述できればなと思います イベントが設計の基本線となりつつある、、、のか？ まず1つ目に驚いたのが、イベントが設計の中心になっている、そう感じる機会が多かったこと。 ここで言うイベントは、実践ドメイン駆動設計の中でも「ドメインイベント」として実装パタ
良いコードとは何か - エンジニア新卒研修 スライド公開
株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 https://note.com/cyberz_cto/n/n26f535d6c575
リーダブルコード by DDD / Readable Code by DDD
リーダブルコード by DDD モデリングを起点に可読性の高いコードを実現する
スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場
単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や
システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers
Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey（プログラミング言語Clojure作者）のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは本質的に複雑 ソフトウェアの複雑さはどこから来るのか？ 複雑さは、別の複雑さを産む 複雑さを分類する 本当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか
ドメイン駆動設計の集約のわかりにくさの原因と集約を理解するためのヒント - ソフトウェア設計を考える
『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう
モダンなソフトウェア設計の書籍 - kawasima
型駆動設計から始まるフォーマルなアプローチもカバーしているが、フォーマルな方法の簡単な紹介も含まれているもの。
5年間 Laravel を使って辿り着いた，全然頑張らない「なんちゃってクリーンアーキテクチャ」という落としどころ
この記事は Laravel Advent Calendar 2020 - Qiita 最終日の記事です。 TL;DR DDD や "真の" クリーンアーキテクチャは， Web 業界における大抵の現場ではオーバースペックだし，導入しても全員がついてこれるとは限らない app/UseCases ディレクトリだけ切って，ドメインごとに単一責務なクラスを置くと使いやすいよ ActiveRecord 指向のフレームワークで Repository パターンを無理に導入すると死ぬので， UseCase で Eloquent Model の機能を使うことを恐れるな はじめに Zenn では初投稿です。日本の Laravel コミュニティではもうお馴染みのようで実はあまり顔を出していない（？） @mpyw と申します。オンラインサロンの火付け役となった Synapse が最初の仕事でしたが，就職後すぐ会社が
ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab
この記事は ドメイン駆動設計 Advent Calendarの記事です。 今年の9月にログラスというスタートアップに転職しました。 ログラスは元々DDDについて講師として勉強会をさせてもらっていた会社であり、DDD自体は社として取り組んでおりある程度進んでいました。ですが、講師ではなく中の人になったからこそできる色々な取り組みがあり、3ヶ月である程度形になりました。 本記事では、DDDを広めるための取り組みについて、極力再現性がある形を意識しつつ、ご紹介したいと思います。 入社時の状況 なにをしたか テストの話が多い理由 実施内容詳細 TDD Boot Campの@t_wadaさんの基調講演観賞会を行った Serviceクラスを1パブリックメソッドにした レイヤーごとのオブジェクトの依存関係を整理 レイヤーごとのテスト方針 クラス名の重要性 参照実装を作成した 「責務」と「テスト」の重要性
![ドメイン駆動設計を導入するために転職して最初の3ヶ月でやったこと[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/468995f3b9ed8114c64ac798322572db942591ca/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20201221%2F20201221103037.png)
リアクティブは難しいが役に立つ - kubell Creator's Note
お久しぶりです、かとじゅん(@j5ik2o)です。テックブログを書くのは何年ぶりか…。 サービスが停止したり応答性が低下すると、お叱りや逆に励ましをいただきますが、エンジニアとして設計レベルからそういった問題に対処するにはどうするか、日々精進しているところですmm。この記事はそういう論点で注目されている「リアクティブ原則」についてまとめてみたいと思います。 それなりのボリュームになってしまったので、時間があるときに読んでいただければと思います。 さて、Linux Foundation内の新たなトップレベルプロジェクトであるReactive Foundationが主催する、Reactive Summit 2020が11月10日にオンラインで開催されたので参加しました。 www.reactivesummit.org 参加されていたスピーカーはLightbendをはじめ、Netflix, Fac
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふつうのプログラマのふつうの設計
