タグ

関連タグで絞り込む (12)

タグの絞り込みを解除

設計に関するlike_futsalのブックマーク (13)

  • 【Flutter】アプリ全体のアーキテクチャを0から考えて作り直した話

    ここ半年ほど、仕事で Flutter アプリを 0 から作り直しています。 ちょうど今年の個人的なテーマを「アーキテクチャ」に据えていたこともあり[1]、またその一環として 「Clean Architecture 達人に学ぶソフトウェアの構造と設計」 （以下：クリーンアーキテクチャ本）を読んでいたこともあり、この作り直しでは「アーキテクチャ」をしっかりと自分の頭で考えながら作ろうと決めて取り組んできました。 アーキテクチャについて頭を悩ませながら実装を進めること約半年、ようやくアプリが形になるとともにある程度知見も溜まってきましたので、その知見を一般化した内容をこの記事にまとめていきたいと思います。 注意 この記事は、「Flutter アプリのアーキテクチャはこれがベストプラクティス！」という類の記事ではありません。あくまで 私の目の前の要件ではこれが最適と判断した という一例の紹介になり

    【Flutter】アプリ全体のアーキテクチャを0から考えて作り直した話

  • アプリケーションの設計にEIPの知識が役に立つよ！

    非同期メッセージングを使ったインテグレーションパターン (EIP)は、クラス設計にも参考になるものが多い。 すぐに非同期メッセージングを使わないとしても、EIPは設計の参考情報として知っておきたい。

    アプリケーションの設計にEIPの知識が役に立つよ！

  • anopara

    終了のおしらせ ブログ anopara は 2022年12月29日 ごろに閉鎖しました。 先生の次回作にご期待ください。 次のブログは多分同じURLで再開します。 詳しいことが決まったらこちらに書きます → https://twitter.com/anoparanominal 創作関連の活動はこちら → https://y9ks.jp 絵とか → https://twitter.com/yuri9000series

    anopara

  • 論理的思考の放棄 - 登 大遊＠筑波大学情報学類の SoftEther VPN 日記

    僕は、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる。その結果、多い月で 10 万行 / 月くらいである。なお、言語は書くソフトウェアの性質上、大半が C 言語である。 また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。 とても大きく複雑で、かつレイヤ的に OS に近い処理をたくさんやるプログラムを書く場合は、プログラミングをするときでも、事前の設計が極めて重要となる。設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、パフォーマンスが低下したりする原因となり、開発者の苦痛の原因となる。 当然のことながら、これまで書いたいくつかの大きく複雑といえるソフトウェアの大半の設計も、自分で行った。いかなる場合でも、設計は、最初の 1 回目で確定

    論理的思考の放棄 - 登 大遊＠筑波大学情報学類の SoftEther VPN 日記

  • ドメインオブジェクトの責務について - Qiita

    設計するとき、「このオブジェクトの責務は何だろうか？」とか「この責務に名前をつけるなら何か？」とか、責務について考えることがよくあります。そもそもその責務とは何か、という根源的な疑問について再確認すると共に、ドメイン駆動設計の観点からドメインオブジェクトの責務についても考えてみたいと思います。 責務とは 困ったときの古典引用。もう絶版になった、オブジェクトデザインという、書籍を紐解いてみましょう。DDDからの引用が多い書籍で、DDDの設計スタイルは、この書籍で紹介する「責務駆動設計(responsibillity-driven design)」の原則に従うことが大きいとされています。 この書籍によると、「責務」には以下が含まれるそうです。 「4.1 責務とは何か」 オブジェクトが行う動作 オブジェクトが持つ知識 オブジェクトが他に影響を与える主要な判断 これらの言葉を身近な言葉で置き換える

    ドメインオブジェクトの責務について - Qiita

  • 書籍「Clean Architecture」が最高すぎたのでエッセンスをまとめてみた

    本記事では、書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」のポイントを抽出する。ただ、削った部分も多いので、ぜひ書籍を購入してほしい。 第1部　イントロダクション ソフトウェアを「一度だけ」動かすのは、それほど難しいことではない。正しくするのは難しい。 ソフトウェアを正しくすると、不思議なことが起こる。開発や保守に必要な人材はわずかで済む。変更は簡単で迅速になる。欠陥の数は少なく、ほとんど出てこなくなる。労力は最小に抑えられ、機能性と柔軟性は最大になる。 「あとでクリーンにすればいいよ。先に市場に出さなければ！」ソフトウェア開発者たちはそう言ってごまかす。だが、あとでクリーンにすることはない。短期的にも長期的にも、崩壊したコードを書くほうがクリーンなコードを書くよりも常に遅い。早く進む唯一の方法は、うまく進むことである。 すべてのソフトウェアシステムは、2

    書籍「Clean Architecture」が最高すぎたのでエッセンスをまとめてみた

  • ドメイン駆動設計 基本を理解する

    2. 本日の内容 • ドメイン駆動設計の「考え方」 • 「まえがき」を中心に – オブジェクト指向、エクストリームプログラミング • ドメイン駆動設計の「３つの原則」 • １章 ２章 ３章から – ドメイン知識の習得、言葉による意図伝達、コードで表現 • ドメイン駆動設計の「基本スキル」 • ４章 ５章 ６章 ７章から – ドメイン層の隔離、ドメインオブジェクトの設計、総合演習 2 ※「基本スキル」は、時間が足りなくなる見込み。あらかじめご了承ください。

    ドメイン駆動設計 基本を理解する

  • ひどいコードをメンテしてきたからこそ実感する、良いコードや良い設計の大切さ - give IT a try

    はじめに 先日、社内で「良いコードの書き方やお作法、プログラミングの原則って、どうやったら身に付くんだろうねえ？」という話になりました。 もちろん、「本を読んで勉強する」っていのも勉強法のひとつなんですが、そもそも、もっと強烈なモチベーションがないと、必死になって良いコードの書き方やプログラミングの原則って勉強できないのでは？なんて思ったりします。 強烈なモチベーションというのは、たとえば、 いったい何なん！？このスパゲティコードは！！！ なんでこんなコードを俺がメンテしなきゃあかんの！！？？ あ～、もう最悪や！！俺はこんなコード、絶対に書かへんぞ！！！！ っていうぐらいのモチベーションです。 というか、これは単純に僕のケースですね、はい。 幸い、ソニックガーデンに入ってからは、周りのプログラマがみんなちゃんとしているので、そんな思いをすることはほぼなくなりましたが、前職、前々職ではそんな

    ひどいコードをメンテしてきたからこそ実感する、良いコードや良い設計の大切さ - give IT a try

  • .NETの例外処理 Part.1 - とあるコンサルタントのつぶやき - Site Home - MSDN Blogs

    .NETの例外処理 Part.1 12/29/2008 5 minutes to read さて次は何を書こうかなぁと思ってましたが、前回のエントリのウケが比較的よかった様子なので、もうちょっと初心者向けのエントリを続けてみようと思ったり。ということで、今回は .NET の例外処理について書いてみたいと思います。 なぜにいまさら例外処理……？ と思われる方も多いと思うのですが、理由はただ一点。現場レベルのソースコード読んでると、未だに例外処理がめちゃくちゃなアプリがホントに多いのです。 私が昔、Java を初めて触ったときに感動した機構の一つが例外処理（とそれに関連するスタックトレース）で、例外処理を正しく書くだけで、アプリの内部動作の大部分はわかるし、障害解析も圧倒的にラクになる。しかしその一方で、例外処理についてわかりやすくまとめられた書籍が少ないために、なかなか理解するのが大変なとこ

  • [C++/分岐の処理]手続き型からジェネリックな設計まで - Qiita

    はじめに 例えばシューティングゲームを作る場合、敵を何十種類か実装して、それぞれ別の動きをさせたいでわけです。 しかしながらc++では(他の言語でも)そういう機能の実現方法がたくさんあり、最高の設計をするのは至難です。 この記事では敵の種類毎に別の動きをさせる方法について色々説明します。 それによって、どういう仕様の場合どうやって処理を分岐させるのが良いか考える助けになるかと思います。 サンプルを動くように実装するのは手間なので、そういう風にはしてません。 ※マークダウンでは表示が狂いますが、識別子に日本語を使うのはg++以外では特に問題無いです。 switchによる処理の分岐 プログラミングを始めたばかりの人はまずこんな感じにすると思われる。 あるいはif文でも似たような事したり。 enum class EnemyType { スライム, ゴブリン, ドラゴン }; class Enem

    [C++/分岐の処理]手続き型からジェネリックな設計まで - Qiita

  • [C++]ゲームのオブジェクト管理システムが遅い場合 - Qiita

    この記事の続き http://qiita.com/mrdagon/items/c49f23b426aa96694aa2 はじめに ゲームのオブジェクト管理を同じ型を静的配列に入れて処理をswitch文で分岐する方式で実装してたのから、仮想関数でポリモーフィズムする感じの設計にして配列をstd::vectorにしてstd::shared_ptr使うようにしたら遅くなって処理落ちしだした、どうしよ？みたいな人向けの記事。 具体的に言うと、下の方が書かれた記事の例で言う1.から3.にしたら遅くなったので、めんどくさいけど4.をしたい人向けです、先に読んでおくとこの記事を読みやすくなると思います。 ゲームのオブジェクト管理システムについて考える また今回の内容は同人2Dゲームを作る等のメモリが何に使うのか分からない程余っている状況を想定しています、メモリがカツカツの場合は話が変わってくると思います

    [C++]ゲームのオブジェクト管理システムが遅い場合 - Qiita

  • アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD

    注釈： CASH LAYER：キャッシュレイヤ FRONT END：フロントエンド ASSET SERVE：アセットを供給 WEB SERVER W/ROUND ROBIN FAILOVER：ラウンドロビンとフェールオーバーを実装したWebサーバ THE CLOUD：クラウド ALL READS!　：全ての読み込み WRITES：書く READS：読む MASTER：マスタ INPORTANT POINTY THINGS：重要な鋭い情報 MULTI MASTER DB CLUSTER：複数のマスタからなるデータベースの集合体 「エンジニアはまずアーキテクチャの全体像から始めるべき」、というのが先人たちの知恵からの教訓となっています。データベースを使ったサービスが他のサービスと関係する様子を、線や矢印で表したのが上の図です。キャッシュレイヤ、ロードバランサ、その他の複雑な形も上図の情報フロー

    アーキテクチャよりも設計を重視しよう – 米政府18Fチームの提案 | POSTD
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.