イミュータブルデータモデル - kawasima
CRUDのうちUPDATEがもっともシステムを複雑化する。更新には複雑なルールが伴うからだ。業務的に複雑なルールが存在するのは仕方ないこともあるが、システム、設計で複雑さを更に増さないようにしたい。UPDATEに着目し、その発生をできるだけ削ることによって複雑さをおさえるためには、まずデータモデルをそのように設計しておかなけれなならない。このイミュータブルデータモデルは、それを手助けする手法で、手順に沿って実施すればある程度のスキルのバラつきも吸収できるように組み立てられている。
CTOの頭の中：技術と組織と牽制関係｜Shin Takeuchi
うちの会社には技術的なCXOとして、CTO、CIO、CISOの3パートがあります。何が違うねん、という話なのですが、ここにはのっぴきならない事情と仕組み化の流れがあって、3つのロールに分けました。このあたりの話を今日はつらつら書いてみたいと思います。 CTOの責任昔はCTOこそ全てのバランスを有し、社長よりも俯瞰したロールであれ、的な思想を持っていました。というのもマーケットを理解し、P/L、B/Sも理解しながら先日書いたG/Pを最大化しろ、また負債をいつどのようにどうやって減らしていくのかを考え、説明責任を果たし（その間機能開発力が落ちるかもしれないし）、実行しなければならない。これらは、短期的な収益と中長期的な投資をバランス良く、柔軟に判断しなければならない、という意味で、できりゃいいのですが簡単ではありません。特に簡単ではないのが、結局社長なり、トップの視点、視野にこの広大さと深さが
責任(関心)を意識したアプリケーション設計 - Qiita
プログラムが上手く組めるようになりたい プログラミングが上手くなりたいと考えたときに、個人的には『名付けを意識』するのと、『アプリケーション設計のときに責任を意識する』考え方を取り入れることをおすすめしております。 今回は『アプリケーション設計のときに責任を意識する』ことについて書いてみたいと思います。 基本的には単一責任原則と、関心の分離のお話になります。 ※ タイトルに『関心』というワードがありますが、アスペクト指向プログラミングの話ではありません 単一責任原則とは まずは単一責任原則とは何かについてです。 よく単一責任原則の説明では「クラスを変更する理由は複数存在してはいけない」というニュアンスの言葉がよく使われます。 例えば、社員管理システムの実装を行いたい場合、一つのクラスに「社員登録」「出勤管理」「給与管理」などの機能を詰め込むと、『社員登録』の変更をする際にそのクラスが変更さ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クソコード動画「Userクラス」で考える技術的負債解消の観点
分散システムについて語らせてくれ