タグ

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

タグの絞り込みを解除

アーキテクチャと設計に関するshimanpのブックマーク (7)

  • 設計・ソフトウェアアーキテクチャを学べるGitHubリポジトリ 16選

    はじめに 今回の記事では、設計やソフトウェアアーキテクチャを学べるGitHubリポジトリを16個紹介する。 対象とする読者 設計やソフトウェアアーキテクチャに興味関心があるエンジニア GitHubをエンジニアリングの情報収集に活用したいエンジニア タイトルで気になった人 Architectural Patterns システムの基本的な構成を理解するためのパターンやテンプレートを提供している。これらのパターンを学ぶことで、システムの構造やコンポーネントの関連性、相互作用を理解できる。これが開発者にシステムをより効率的かつ効果的に設計・実装する能力をもたらす。 Design Patterns for Humans 設計パターンを人間が理解しやすい形で説明している。デザインパターンは特定の問題に対して再利用可能なソリューションを提供する。これによって、開発者はより効率的にコードを記述でき、メンテ

    設計・ソフトウェアアーキテクチャを学べるGitHubリポジトリ 16選

  • [翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita

    こんにちは、食べログシステム本部長の京和です。 本エントリでは Shopify の Engineering Blog から、Kirsten Westeinde による「Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity」を翻訳して掲載します。 食べログではユーザーや飲食店に価値を届けるスピードを最大化するべく、マイクロサービス化などをはじめとしたこれまでの組織やアーキテクチャを刷新するための取り組みを始めています。しかし、マイクロサービスはアプリケーションアーキテクチャとインフラアーキテクチャが複雑に絡み合ったシステムで技術的難易度が非常に高く、適切に構築できなければ「分散されたモノリス」と呼ばれるアンチパターンに陥ります。1 Shopifyではマイクロサービスではなく、

    [翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita

  • 技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita

    はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための１種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、５年も

    技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita

  • クリーンアーキテクチャ(The Clean Architecture翻訳)

    Robert Martin (a.k.a. ボブおじさん) による、 The Clean Architecture の翻訳です。似たようなアーキテクチャである ヘキサゴナルアーキテクチャ も翻訳したので参考にしてください。 この記事を翻訳して公開したことは 8th Light, Inc. に報告済みです。いまのところ苦情は来ていません。 ここ数年以上、システムのアーキテクチャに関する実にさまざまなアイデアを見てきた。これには、次のものが含まれる: Hexagonal Architecture (別名 Ports and Adapters) by Alistair Cockburn。Steve FreemanとNat Pryceが、Growing Object-Oriented Software というすばらしい本で採用した。 Onion Architecture by Jeffrey Pa

    クリーンアーキテクチャ(The Clean Architecture翻訳)

  • 「設計なんて不要でしょ」について - Qiita

    経緯 以前とある席で偶然シニアエンジニアの方と設計について議論することがありました。 その時に特に耳に残っていたのは以下の様な内容です。 クリーンアーキテクチャってテストしやすくする為のですよね？ 設計はコード書ける人が他のコードを書ける人に威張るための道具なのではないか？ 設計を学習するならブロックチェーンとかを勉強して技術力を高めるべきなのではないか？ リーダブルコードさえ読んでいれば設計は必要ないのではないか？ 設計なんて不要でしょ その方はかなり詳しく設計の歴史をしっていて尤もな事を言っていましたが、平成も終わる頃においてはその限りではないです。 なので平成最後の日にそれら全てに対して最終的に解答できる形で設計の有用性を説明し、気持ちよく令和を迎えます。 注意: 一応ここで説明する内容や要素も一面だけです。 よくある誤解 クリーンアーキテクチャといえばこの有名なリングですよね。 こ

    「設計なんて不要でしょ」について - Qiita

  • 変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita

    この記事は、設計・アーキテクチャ Advent Calendar 2018 の第7日目の記事である。 はじめに この記事では、IT業界19年目の僕が実践している変更に強いアーキテクチャについて、出来るだけ難しい表現を避け、教科書的なありきたりな内容ではなく現場の肌感覚に近い切り口で「超ザックリ」な解説を試みてみようと思う。 普段自分がよく用いている実装パターンの紹介ともいうべきかも知れない。 この記事で説明すること いざ「変更に強いアーキテクチャとは」とズバリ訊かれても、一概に「これだ！」という答えはない。 プログラミング言語や、フレームワークによっても条件が異なるし、利用可能な技術や開発チームの特性、業務要件や運用要件の特性によっても様々であるし、インフラや開発プロセスまで含めて考えると考慮すべきことは無限にある。 ここでは主にソフトウェアの構造という観点から、"変更に強い" ということ

    変更に強いアーキテクチャについてIT業界19年目の僕が超ザックリ説明する - Qiita

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

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

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

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

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

  • @hatebu

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

はてなブックマーク

公式Twitter

はてなのサービス

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