アプリケーションを実装していくと、「大規模なUI改修」に遭遇することがある。 あちこちで見聞きした結果、以下のようなパターンがあるように感じたのでまとめてみた。 （UI改修なので基本的にフロントエンドからみた内容） これは一般的に「技術的負債」と呼ばれることが多いが、デザインの負債（UIを置く場所が無くなったり無くなったり、同じ概念のUIが分散したり）である場合も多い。 （ちなみに、デザインの負債は「ダイアログを多用する」とか、「最小画面サイズが大きくなる」とかの形で現れやすい） そして、デザイン負債に対応するために実装の困難なUIが増えるため、技術的負債も高くなる傾向がある。 （サーバサイドの技術的負債がDBの負債に起因する場合が多いことと似ているかもしれない）
リレーションシップ駆動要件分析(RDRA)とは？ 要件定義において、重要な要素が3つあります。 「網羅性」：システムの目的や、それを実現するための要件が漏れや重複無く定義されている 「整合性」：各要件の整合性が取れている 「表現力」：それぞれの要件が分かりやすく表現されている 複数の人間で共同作業する際にも、網羅性によって要件定義に必要な情報の枠組みが決まり、整合性によって作業の手順が決まり、表現力によって共通認識を確立します。 リレーションシップ駆動要件分析(RDRA)とは、要件定義において重要なこれらの３要素を高いレベルで実現するための要件分析フレームワークです。 RDRAでは要件定義を4つの構成要素に分け、UMLを拡張した表現方法で要件分析を行います。 よくあるように要件をリストでただ並べるのではなく、UMLの視覚効果を利用することで表現力を実現します。 要件定義についてはこちら↓
デザインパターンのよさが分からない人は設計に自信が持てるようになるのか問題自分語りを少々。1 目の前にあった HTML と JavaScript と PHP と SQL が渾然一体となったコードと戦うことから始め、テスタブルなコードを自分が死なないように習得していった自分にとって、鬼門の一つは 再利用のためのデザインパターン だった。 何しろ再利用可能なコードなんてほとんど何もなかったのだ。そんなもの分かるわけがない。 ところが世の中の「ためになる本」はオブジェクト指向やデザインパターンの知識が前提になってしまっているところが結構あって、歯がゆい思いをすることもそれなりに多かった。 そんなところに、少ない設定、少ない知識でもプロダクティブな開発ができる Ruby on Rails というフレームワークが登場したことで、自分にできることが広がった。2 Rails の支援していないもののうち、
疑問だったこと クリーンアーキテクチャでEnterprise Business Rules層の値オブジェクトを、Interface Adapter層にアウトプットとして直接渡していいか？ それとも、Application Business Rules層で値オブジェクトの中身をデータストラクチャオブジェクト(図2のOutput Data)に移し替えてInterface Adapter層に渡したほうがいいか？ 図1 図2 疑問の背景 今回悩んでたのはEnterprise Business Rules層に値オブジェクトが20個くらいあり、それをApplication Business Rules層でデータストラクチャに変換してアウトプットに返すかどうかという点です。実装コードを想像すると、同じコードのクラスがいくつもできてしまう気がして、どちらにするか悩んでました。 値オブジェクトをデータストラ
まずはモデリングパラダイムについて考えましょう。 目的 「モデリングパラダイム」という言葉をどういう意味を持つのでしょうか。それは、以下の二つの単語で構成されます。 モデリング 広義の意味での模型（モデル）を組み立てる事を言う。 パラダイム ある時代のものの見方・考え方を支配する認識の枠組み。 「モデルを組み立てるための認識の枠組み」と考えてよいでしょう。 DDD本の用語解説では、以下の説明があります。モデリングの「枠組み」や「スタイル」と解釈して問題なさそうです。 ドメインにおける諸概念を切り取る特定のスタイル。ツールを組み合わされて、それらの概念に類似したソフトウェアを作成する(例えば、オブジェクト指向プログラミングや論理プログラミング) そしてこのモデリングパラダイムに基づき、切り取ったモデルをプログラミング言語を使ってソフトウェアに反映します。この反映のしやすさというのは、プログラ
モバイルアプリケーションを開発していると、この要件や仕様はクライアントとサーバーどちらに置くべきか、という議論がチームでなされることがしばしばあります。例えば、 あるレスポンスAを受けて処理Bを行い、その結果をユーザーに提示する 登録処理などで、処理C,処理Dという異なる処理を並列して行い、それらが完了したらユーザー側に通知する やろうと思えばクライアント側で処理を全て持つこともできますし、サーバー側で実装もできますね。 このような仕様のディスカッションが起きたとき、チームで統一した判断基準を持っていますか? 自分の場合、クライアントアプリはロジックをなるべくサーバーに移譲すべき という設計指針をチームに提案します。 上の例で言うならば、 サーバーから処理Bも踏まえたレスポンスA'を返してもらい、ユーザーに提示する クライアントは1リクエストをサーバーに投げる。サーバー側で処理C,Dを投げ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? とても勉強になったので写経のつもりで翻訳しました。 普段自分でもわかっている気がするけど言語化するのが難しかったこと、自分でやっていて確かにあとから痛い目を見たかもしれないと反省を促される内容でした。 ※ゲームプログラミング特有だなと感じた内容はきちんと理解できなかったので割愛しています。 Now that people have already said highly controversial stuff like ”debugger is useless for C++ development”, I think I can sh
緊急度も重要度も高いものはMUSTで実施されるのでそう気にする必要はありません。 気をつけなくてはいけないのは、緊急度が高くて重要度が低い ものです。それが優先度が高いという状態は 錯覚 です。優先度を下げましょう。重要度が高くて緊急度が低い ものは 価値 のある施策です。そういったものこそ優先度を上げましょう。 1-5. ロジカル・シンキングとクリティカル・シンキング 思考法としてのロジカル・シンキング (論理思考)とクリティカル・シンキング (批判的思考)についても少し触れます。 ロジカル・シンキング (論理思考) においては 意見と事実 (ファクト) の混同 、 論理のすり替え、 異なるものでの比較 (=Apple to Orange) などが発生しているケースが多々あります。本質解を導く為にも なぜ？を5回繰り返せ 、という言葉もありますが、適切な論理思考ができていないと５回繰り返
2018/12/8 Frontend Conference Fukuoka 2018にて発表した資料です。
こんにちは、キッズリー開発グループ サーバサイドエンジニアの @t_uyama です。 本記事では、ローンチから三年間運用されているwebサービスにFLOCSSを導入して既存のCSSをリファクタリングしたという事例をご紹介します。また、各人で解釈が分かれがちなFLOCSSのレイヤ分けの一例と、FLOCSS導入後のCSSの開発体制についても併せてご紹介します。 FLOCSSとは？ CSSを書く際のファイル構成や命名規則などを取り決めたルールの1つです。CSSの命名規則というとBEM、OOCSS ( Object Oriented CSS )、といったものが有名なところして挙げられますが、FLOCSSはこれらの良いところを組み合わせたものとなります。Foundation Layout Objectと役割ごとにレイヤ（層）が分かれているのが特徴です。これにより、CSSコードの再利用・拡張がしやす
こんにちは、クラウドワークスの新規事業のエンジニアとして仕事をしている高梨です！ 最近、「実践ドメイン駆動設計」という本を読みました！ 500ページ近くもある技術書で、なかなか量は多かったのですが、DDDがどんなものなのか一通り大枠を掴めた気がします。 ただ読み終わった後にこんな疑念や不安をいだきました。 「たしかにかなり面白そうだけど、実際にやるとどれだけ工数かかるんだろう...？」 「設計の話は全然出てこなかったけど、DDDで作るとなるといったい何から始めればいいんだ？」 「戦術についての知識はついたけど、実際に書こうとしたらできなそうだな...」 そこで、そういった疑念や不安を解決するために、実際にDDDでサンプルプロダクトを作ってみようと思ったわけです。 実際に作ってみるのが、結局一番理解が進みますしね。 今回は、そのプロダクトがリリースされるまでの過程や感想を、作成した設計書やソ
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの？」 という
本記事はドメイン駆動設計 Advent Calendar 2018 - Qiitaの3日目の記事です。 2日目は、grimroseさんのぐるぐるDDDで気をつけてることでした。 4日目は、s_edwardさんのMicroservices と DDDです。 Table of Contents Table of Contents 以下の記事を読むにあたり前提となる知識 問題 サービス詳細 ユビキタス言語 重要なビジネスルール モデリング 上の何が問題？ 解決策 解決策1 集約をマージする 解決策2 一時的な整合性の破綻を受け入れ結果整合性を使う 解決策3 アンチパターンではあるが集約間の整合性維持のためトランザクション制御を用いる 解決策4 ユースケースの見直しによる再モデリング まとめ とりあえず今どうやっているか 最終的にどうするべきだと考えているか(2018/12/01時点) ソリューシ
AWS Dev Day Tokyo 2018でMicro Frontendsについて話したスライドです。 #MicroFrontends #マイクロフロントエンド
「2018/11/8 設計Night2018 powered by Classi」で発表した資料です 当日の資料のページ数が多すぎた(140ページ）ので、2/3くらいにまとめました
SFC, Redux, HOCなどコンポーネント指向とReact開発のキーワード CTOの Shoken です。キッチハイクでは2年前にRailsへのReact導入、1年半前に0ベースからReact Nativeでアプリ開発を始めました。この記事では、React, React Nativeで開発しているチームが共通認識したいReactの重要な概念について紹介します。 2018/11/07 追記（はてブコメントより） Reactリポジトリで名称の変更が行われ、変数名やクラス名が変更されました。いままでの Functional Component が Function Component となり、 Stateless は使わなくなって Function に統一されるようです。 Terminology: Functional -> Function Component #13775 Before
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く