[B! 設計] komeshogunのブックマーク

イミュータブルデータモデル - kawasima

CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。

komeshogun 2020/03/11

リンク

Excel設計書を抹殺したくて4年前にWiki設計書を導入したら、意外とちゃんと開発回ってた話。 - Qiita

初めましてこんにちは。最近コードレビューの記事書いたら、Excelベースだったことを理由に Qiitaコメントとはてブで徹底的に燃やされたおじさんです。いやね、僕だって使いたくて使ってるわけではなくてね、できることなら使いたくないんですよ。というわけで名誉挽回のために脱Excelできた話、それも日本の三大悪三大風習に数えられるExcel 設計書を抹殺した話を書きます。 (2/25修正：悪は言いすぎました。訂正します。） Growi 最高。またの名をExcel方眼紙。エクセルのセルの縦横を同じくらいの大きさに調整し方眼紙のようにして、そこに設計書として文字と図と表を記載する方式。メリット一つのファイルに文字と図と表がまとめて記載できるテキストでは文字は書けても図と表が書けない Wordでは、文字と図表エリアとを2列表示するのが難しいできなくはないが面倒くさい UMLモデ

komeshogun 2020/02/25

リンク

要件定義～システム設計ができる人材になれる記事 - Qiita

はじめに株式会社デジサクがお送りするプログラミング記事、今回は要件定義・システム設計について扱っていこうと思います。プログラミングを勉強していて、こんな事を感じた経験はないでしょうか。「勉強してもプロダクトが作れない」「そもそも開発ってどうやるの？」「要件定義ってなに？」その悩みを解決するために、まずは開発の全体感を理解しましょう。下図『ソフトウェア開発プロセス』をご覧くださいいつも勉強しているプログラミングは『実装』の部分に該当します。つまり、プログラミングの実力を発揮する前に４つも壁が存在するのです。そのため、本記事では実装（プログラミング）を開始する前に必要となる、『企画～設計』について順を追って説明して行きます。特に、エンジニアが理解しておくべき『要件定義』『設計』にフォーカスします。なお、開発全体において実装（プログラミング）に使用する時間

komeshogun 2020/01/12

リンク

質とスピード / Quality and Speed

質とスピード初演: 2019/10/31 @ EOF2019

komeshogun 2019/11/01

リンク

オブジェクト指向プログラミングを学ぶための推薦図書 - ソフトウェア設計を考える

オブジェクト指向プログラミングを学ぶオブジェクト指向プログラミングという言葉は、広い意味で使われている。オブジェクト指向プログラミングをキーワードにすべての情報をかき集めて理解するというアプローチは現実には無理。目に付いた重要そうなところを見繕って集めてみても、たぶん混乱するだけ。この記事では、オブジェクト指向プログラミングのいろいろなアプローチの中で、クラスを使って独自の「型」を定義するプログラミングスタイル関連するデータとロジックをまとめて、小さな入れ物に格納する「カプセル化」を重視するプログラミングスタイルを学ぶための参考図書を紹介したい。型とカプセル化に重点を置く設計スタイルがわかってくると、それとは異なるスタイル、異なる力点を置くアプローチとの違いが具体的にわかるようになってくる。*1 *2 まずは、オブジェクト指向プログラミングの中で、型・クラス・カプセル化に力

komeshogun 2019/09/07

リンク

それはYAGNIか? それとも思考停止か?

DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。 Read less

komeshogun 2019/06/24

リンク

履歴を持つデータの設計

酔いどれ設計ナイト2019の発表資料です。

komeshogun 2019/04/13

リンク

ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳

はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません用法用量を守り、個人の責任で業務に投入してください参考資料 2024/02/14追記実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか今北産業で頼むテーブルに状態を持たせず状態毎のテーブルを作る状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録