「わし詳細設計書書くのやだよ」システム開発で細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない話に賛否両論
しのゆ𝕏酒くずエンジニア @shinoyu 新宿で社長やってるソフトウェアエンジニア18年生のおかまちゃん / 💻技術🎧 V系 🎀ロリィタの人 / 170スペ110 スプリング、骨ウェーブ、顔ソフエレ / 絡みない鍵とスパムは🚫 / 原則IT関連業のみフォロー /たまに会えるかも @shinjukudist しのゆ𝕏酒くずエンジニア @shinoyu わし詳細設計書書くのやだよ(￣･ω･￣) 細かければ細かいほど仕様変わった時の変更が爆増してメンテコスト爆上がりする。かけるべきコストはそこじゃない。 必要なのは完成に必要要件がまとめられたもの。それを元に受け入れ試験書がつくられる。それクリアすればどう作ってようが構わんわけだ 改修コストを下げるための設計になってることは前提だけどね。 だけど、詳細設計書が必要となる現場はこの設計することはできない。だってそれできてたら詳細設計書
Why, after 6 years, I’m over GraphQL
GraphQL is an incredible piece of technology that has captured a lot of mindshare since I first started slinging it in production in 2018. You won’t have to look far back on this (rather inactive) blog to see I have previously championed this technology. After building many a React SPA on top of a hodge podge of untyped JSON REST APIs, I found GraphQL a breath of fresh air. I was truly a GraphQL h
ヨドバシの中の人が語る、開発中のヨドバシAPIが目指す機能、仕組み、そしてセキュリティ（前編）
DB に JSON を保存したいときに Protobuf を使うと便利 #LayerXテックアドカレ - LayerX エンジニアブログ
アメリカの職場ではなぜドキュメントも無いのに人が去っても問題ないのだろう？｜牛尾 剛
雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
ドメイン駆動設計（DDD）で開発されたシステムを5ヶ月保守開発した感想・学び - Qiita
レイヤードアーキテクチャを振り返る - Sansan Tech Blog
こんにちは、Sansanプロダクト開発部の清水です。 ある程度のアプリケーションの大きさだと当たり前に使われる事が多い「レイヤードアーキテクチャ」の自分が考える設計のポイントや、実際に運用する際のポイントについて書いてみようかと思います。 基本的な話なので「今更かよ」って感じがしますが、実際に設計、運用する際には様々な考慮事項のあるものだと思うので、知ってる人にとっても復習にでもお役に立てればと思います。 そもそもレイヤードアーキテクチャって何? 概要 一言でいうと、アプリケーションを作る際にそれを構成する部品を、それぞれ責務が定義された論理的なグループにまとめて整理し、それぞれのグループ間のやり取りの仕方を決めておこうという事です。 このグループ間のやりとりにおいて、一方向かつ隣接するグループとしかやりとりを行えないようにする事が多く、層状になるのでレイヤードアーキテクチャと呼ばれます。
DDD本を読むためには前提知識が非常に多いよ - Qiita
Amazon VPCを「これでもか！」というくらい丁寧に解説 - Qiita
データモデルはドメインモデルに先行する - 設計者の発言
関わっているあるプロジェクトで、Javaでのコンポーネントベース開発を進めるためのクラス図が出来上がりつつある。DDD（ドメイン駆動設計）に関心を持つ技術者にとってお手本になるような端正なドメインモデルだ。それを眺めながら関係者がしみじみと感じていることがある。どんなに優秀なドメインエキスパートと組んだとしても、DDDにもとづいてこのモデルを「先に」生み出すことは不可能だっただろう。 どういうことか。我々はまず、泥臭い分析と設計を重ね、あるべきデータモデルを完成させた。そのうえで実装方式の専門家の協力を仰ぎ、クラス図が出来上がった。つまり、データモデルからドメインモデルが導かれたのであって、その逆ではない。じっさい、ドメインモデルからデータモデルを導くことが不可能であったことは、両者を並べたら一目瞭然なのであった。 これは重要な論点だ。データモデリングとドメインモデリングのどちらを先行させ
SPAはコストが高いのか | foo-x
なぜ僕が「SPAはコストが高い」と考えているのか を読みました。 「反論お待ちしています」とのことなので、書いてみます。 結論としては、 コストが低いのは慣れているほうだよ。 どっちも使えるならSPAのほうが低いよ。 です。 前提 元記事で挙げられている前提をまとめます。 用語 SPAとは、クライアント側でビューを構築する方式を指す MPAとは、サーバ側でビューを構築する方式を指す 背景 エンジニアのスキルはあまり高くない 開発期間は1.5年未満 PMFを意識したフェーズであり、チャレンジを繰り返す ログイン機能が存在するサービスを作る コストの定義 エンジニアの採用のしやすさ サービス開発の 初速 サービス開発の 継続性 分業のしやすさ、手伝ってもらいやすさ web標準の挙動の実現のしやすさ セキュアなデータを流出する可能性の高低 バグがあった時の気づきやすさ / 対応のしやすさ ドキュ
最近の海外DDDセミナーを聞いてみたら色々と常識が破壊された - Qiita
なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】 - Qiita
実はDDDってしっくりこないんです - タオルケット体操
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
DDD(ドメイン駆動設計)、理念に大賛成、実装に大反対。
Microservices における認証と認可の設計パターン
テックリードになって気をつけていること - Qiita
フューチャーアドベントカレンダー2020の24日目です。 はじめに フューチャーに入ってテックリード（社内だとアーキリーダーと呼ぶことも多い）のような役割をし始めて4,5年ほど経過しました。 いくつかの案件を回して自分なりに汎化・パターン化してきた部分も増えてきたので、気を付けていることをまとめました。 テックリードとは エンジニアのためのマネジメントキャリアパス――テックリードからCTOまでマネジメントスキル向上ガイド によると、以下のように説明されています。 テックリードはエンジニアの階層におけるランクのひとつではなく、シニアのレベルに達したエンジニアが担うことのできる職責群である 技術的なプロジェクトの管理者 部下に効率良く仕事を割り振って自身の負担を適宜軽減するよ う心がける チーム全体の生産性に照準を定め、しかるべき成果を上げるよう全力を尽くさなければならない 管理やリーダーシッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
1,000行で作るオペレーティングシステム
DB外の副作用をトランザクションから分離しよう / Isolate out-of-DB side effects from transactions
