「大規模なUI改修」を行うとどうなるか
アプリケーションを実装していくと、「大規模なUI改修」に遭遇することがある。 あちこちで見聞きした結果、以下のようなパターンがあるように感じたのでまとめてみた。 （UI改修なので基本的にフロントエンドからみた内容） 機能実装を進めて行った結果、UIの実装が難しくなる。これは一般的に「技術的負債」と呼ばれることが多いが、デザインの負債（UIを置く場所が無くなったり無くなったり、同じ概念のUIが分散したり）である場合も多い。 （ちなみに、デザインの負債は「ダイアログを多用する」とか、「最小画面サイズが大きくなる」とかの形で現れやすい） そして、デザイン負債に対応するために実装の困難なUIが増えるため、技術的負債も高くなる傾向がある。 （サーバサイドの技術的負債がDBの負債に起因する場合が多いことと似ているかもしれない） 技術的負債の解消とデザイン負債の解消を目的とした「大規模なUI改修」が企画
リレーションシップ駆動要件分析(RDRA) - Qiita
リレーションシップ駆動要件分析(RDRA)とは？ 要件定義において、重要な要素が3つあります。 「網羅性」：システムの目的や、それを実現するための要件が漏れや重複無く定義されている 「整合性」：各要件の整合性が取れている 「表現力」：それぞれの要件が分かりやすく表現されている 複数の人間で共同作業する際にも、網羅性によって要件定義に必要な情報の枠組みが決まり、整合性によって作業の手順が決まり、表現力によって共通認識を確立します。 リレーションシップ駆動要件分析(RDRA)とは、要件定義において重要なこれらの３要素を高いレベルで実現するための要件分析フレームワークです。 RDRAでは要件定義を4つの構成要素に分け、UMLを拡張した表現方法で要件分析を行います。 よくあるように要件をリストでただ並べるのではなく、UMLの視覚効果を利用することで表現力を実現します。 要件定義についてはこちら↓
Clean ArchitectureとHanamiですっきりしてきた
デザインパターンのよさが分からない人は設計に自信が持てるようになるのか問題自分語りを少々。1 目の前にあった HTML と JavaScript と PHP と SQL が渾然一体となったコードと戦うことから始め、テスタブルなコードを自分が死なないように習得していった自分にとって、鬼門の一つは 再利用のためのデザインパターン だった。 何しろ再利用可能なコードなんてほとんど何もなかったのだ。そんなもの分かるわけがない。 ところが世の中の「ためになる本」はオブジェクト指向やデザインパターンの知識が前提になってしまっているところが結構あって、歯がゆい思いをすることもそれなりに多かった。 そんなところに、少ない設定、少ない知識でもプロダクティブな開発ができる Ruby on Rails というフレームワークが登場したことで、自分にできることが広がった。2 Rails の支援していないもののうち、
クリーンアーキテクチャで値オブジェクトをユースケースのアウトプットに使ってもいいか？ - Qiita
疑問だったこと クリーンアーキテクチャでEnterprise Business Rules層の値オブジェクトを、Interface Adapter層にアウトプットとして直接渡していいか？ それとも、Application Business Rules層で値オブジェクトの中身をデータストラクチャオブジェクト(図2のOutput Data)に移し替えてInterface Adapter層に渡したほうがいいか？ 図1 図2 疑問の背景 今回悩んでたのはEnterprise Business Rules層に値オブジェクトが20個くらいあり、それをApplication Business Rules層でデータストラクチャに変換してアウトプットに返すかどうかという点です。実装コードを想像すると、同じコードのクラスがいくつもできてしまう気がして、どちらにするか悩んでました。 値オブジェクトをデータストラ
混在したモデリングパラダイムの中で学ぶ重要なこと - Qiita
このエントリーは、 「ドメイン駆動設計 #1 Advent Calendar 2018」の2４日目の記事です。 23日目は、@smdmts さんの「ユビキタス言語と境界付けられたコンテキストを構築する目的とは」でした。 DDD本で触れられている、モデリングパラダイムについて考えを晒します。 まずはモデリングパラダイムについて考えましょう。 目的 「モデリングパラダイム」という言葉をどういう意味を持つのでしょうか。それは、以下の二つの単語で構成されます。 モデリング 広義の意味での模型（モデル）を組み立てる事を言う。 パラダイム ある時代のものの見方・考え方を支配する認識の枠組み。 「モデルを組み立てるための認識の枠組み」と考えてよいでしょう。 DDD本の用語解説では、以下の説明があります。モデリングの「枠組み」や「スタイル」と解釈して問題なさそうです。 ドメインにおける諸概念を切り取る特定
クライアントとサーバーどちらに実装するかの設計指針をチームで持つこと - tomoima525's blog
モバイルアプリケーションを開発していると、この要件や仕様はクライアントとサーバーどちらに置くべきか、という議論がチームでなされることがしばしばあります。例えば、 あるレスポンスAを受けて処理Bを行い、その結果をユーザーに提示する 登録処理などで、処理C,処理Dという異なる処理を並列して行い、それらが完了したらユーザー側に通知する やろうと思えばクライアント側で処理を全て持つこともできますし、サーバー側で実装もできますね。 このような仕様のディスカッションが起きたとき、チームで統一した判断基準を持っていますか? 自分の場合、クライアントアプリはロジックをなるべくサーバーに移譲すべき という設計指針をチームに提案します。 上の例で言うならば、 サーバーから処理Bも踏まえたレスポンスA'を返してもらい、ユーザーに提示する クライアントは1リクエストをサーバーに投げる。サーバー側で処理C,Dを投げ
Sebastian Aaltonen氏のプログラミング観 - Qiita
とても勉強になったので写経のつもりで翻訳しました。 普段自分でもわかっている気がするけど言語化するのが難しかったこと、自分でやっていて確かにあとから痛い目を見たかもしれないと反省を促される内容でした。 ※ゲームプログラミング特有だなと感じた内容はきちんと理解できなかったので割愛しています。 Now that people have already said highly controversial stuff like ”debugger is useless for C++ development”, I think I can share my own controversial thoughts about unit testing, DRY, copy-paste coding and function length, etc... with 20 years of C++ pro
エンジニアにも役に立つ、MBAで学んだ基礎スキル 20選 - Qiita
こちらはグロービスアドベントカレンダー25日目の記事です。グロービスは国内では最大規模のビジネススクール/経営大学院を運営している会社で、私自身もグロービス経営大学院のMBAに通っているので、この記事では私が学んだMBAスキルの中でエンジニアの皆さんにも役に立つであろう知識・フレームワークをピックアップしてご紹介します。 1. 正しい意思決定をするスキル まずは正しい意思決定をする為のスキルです。顧客が本当に欲しかったものを作り上げる為にも、エンジニア側も交渉力・調整力を持つ事が重要です。 1-1. 交渉力としての「ZOPA」と「BATNA」 ZOPA（ゾーパ）とBATNA（バトナ）と呼びます。ZOPAは Zone Of Possible Agreement の略で、お互いに交渉が締結できる範囲のことを示し、BATNAは Best Alternative To Negotiated Agr
500日のトライエラーから生まれた大規模設計ノウハウ / Frontend Conference Fukuoka 2018 - Speaker Deck
2018/12/8 Frontend Conference Fukuoka 2018にて発表した資料です。
三年間運用しているサービスにFLOCSSを導入してCSSの健全化を目指す | PSYENCE:MEDIA
こんにちは、キッズリー開発グループ サーバサイドエンジニアの @t_uyama です。 本記事では、ローンチから三年間運用されているwebサービスにFLOCSSを導入して既存のCSSをリファクタリングしたという事例をご紹介します。また、各人で解釈が分かれがちなFLOCSSのレイヤ分けの一例と、FLOCSS導入後のCSSの開発体制についても併せてご紹介します。 FLOCSSとは？ CSSを書く際のファイル構成や命名規則などを取り決めたルールの1つです。CSSの命名規則というとBEM、OOCSS ( Object Oriented CSS )、といったものが有名なところして挙げられますが、FLOCSSはこれらの良いところを組み合わせたものとなります。Foundation Layout Objectと役割ごとにレイヤ（層）が分かれているのが特徴です。これにより、CSSコードの再利用・拡張がしやす
「実践ドメイン駆動設計」を読んだので、実際にDDDで設計して作ってみた！ - Qiita
こんにちは、クラウドワークスの新規事業のエンジニアとして仕事をしている高梨です！ 最近、「実践ドメイン駆動設計」という本を読みました！ 500ページ近くもある技術書で、なかなか量は多かったのですが、DDDがどんなものなのか一通り大枠を掴めた気がします。 ただ読み終わった後にこんな疑念や不安をいだきました。 「たしかにかなり面白そうだけど、実際にやるとどれだけ工数かかるんだろう...？」 「設計の話は全然出てこなかったけど、DDDで作るとなるといったい何から始めればいいんだ？」 「戦術についての知識はついたけど、実際に書こうとしたらできなそうだな...」 そこで、そういった疑念や不安を解決するために、実際にDDDでサンプルプロダクトを作ってみようと思ったわけです。 実際に作ってみるのが、結局一番理解が進みますしね。 今回は、そのプロダクトがリリースされるまでの過程や感想を、作成した設計書やソ
新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab
ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か ドメイン駆動 + オニオンアーキテクチャ概略 以前こちらの記事でアプリケーションアーキテクチャについて書きました。 こちらの記事では比較的ネタ元に忠実な解説をしたのですが、実際これに基づいて人にレイヤの説明をした際、依存性の逆転部分や円形で表現する部分がなかなか伝わりにくいことがありました。 そんな中で、所属プロダクトで新卒含めて大規模なリニューアル案件でDDDを採用することになり、新卒にも伝わるように説明をする必要性が生じました。 結果、新卒にも伝わり、運用が割と回る説明が見つかったのでご紹介したいと思います。 アプリケーションアーキテクチャ全体図 とにかく、何か説明する際はこの図を常に傍に置き、一方通行の依存性を徹底したい、という話をしています。 何かについて議論をする際は、 「それはどの層の責務なの？」 という
![新卒にも伝わるドメイン駆動設計のアーキテクチャ説明[DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/da075520c5346bf5227bf90557a35ccf8b5b07ae/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20181210%2F20181210195849.png)
集約の境界と整合性の維持の仕方に悩んで2ヶ月ぐらい結論を出せていない話 - kbigwheelのプログラミング・ソフトウェア技術系ブログ
本記事はドメイン駆動設計 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時点) ソリューシ
Micro Frontends の理論と実践
-価値提供を高速化する真のマイクロサービスのあり方- / The Theory and Practice of Micro Frontends - Speaker Deck
AWS Dev Day Tokyo 2018でMicro Frontendsについて話したスライドです。 #MicroFrontends #マイクロフロントエンド
設計のための、問題の捉え方〜ドメイン知識の暗黙知を形式知に〜(まとめ版) - Speaker Deck
「2018/11/8 設計Night2018 powered by Classi」で発表した資料です 当日の資料のページ数が多すぎた(140ページ）ので、2/3くらいにまとめました
Reactで開発するチームが共通認識しておきたい重要な概念 - KitchHike Tech Blog
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ページを開く
入門 名前
ID生成方法についてあれこれ - Qiita
SimpleとEasyは違う / Simple is not Easy
Clean Architecture in Web Frontend #mixleap - Speaker Deck
