【ソフトウェア設計】モジュールをどう分割するのか？
はじめに 前々回や、前回に引き続き、ソフトウェア設計の指針に関する話をしたいと思います。 関数やクラス、そしてサービスなどシステムの塊の単位をモジュールと呼び、モジュールを作る事で、認知負荷を下げ複雑性と戦うという話をしてきました。では、モジュールは「いつ」分割するのが良いでしょうか？ また、他にも共通モジュールを不用意に作ってしまって苦労した人も多いのでは無いでしょうか？ 今回はそのあたりの話をしていきます。 TL;DR 以下があればモジュール設計を見直す 単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い 分割 is NOT 正義 - FizzBuzz Enterprise Edition 複雑性を排除するためにモジュール分割をすることは重
Electron（v.15.0.0 現在）の IPC 通信入門 - よりセキュアな方法への変遷 - Qiita
2021/09/22にリリースされた v.15.0.0 中でIPC通信周りに大きな変更はありませんでした。 ただ、その前のバージョン（14.0.0）で、contextBridge.exposeInMainWorld(apiKey, api)からExperimental（実験的）が取れ、正式運用となっていたようです（#30011）。 Electron における IPC 通信 Electron で Desktop アプリケーションを作るにあたって理解しなければならないのは、根幹を成す「IPC通信」かと思います。IPC は Inter-Process Communication、プロセス間通信の略です。 IPC 通信の方法については、Electron において、いくつかの段階を経て、進化を遂げています。今回の記事では、その歴史を追いながら、仕組みとセキュアな方法を書いていきたいと思います。 なぜ
クリーンアーキテクチャのUsecaseはなぜControllerへ値を返すのではなくOutput PortとしてPresenterを呼び出すのか - Runner in the High
何を言っているのかと言うと、みんな大好きクリーンアーキテクチャの右下に図示されているFlow of Controlのこと。 黒線が引かれているということは、つまりUsecaseの中でOutput Portのインターフェイスを持つPresenterの関数なりが最終的に実行されるということである。 ここで湧き上がってくる疑念は「UsecaseがPresenterを呼び出さなくてもControllerに返り値とかで値を返して、Controller経由でPresenterに渡して実行しても同じなんじゃないの？」である。つまりOutput Portというインターフェイスそのものを撤廃してControllerにPresenterを使わせるアイデアである。たしかに、仮にこの方針で行ったとしても依存の方向が壊されることはない。 Software Engineeringでは同様の質問がかなり盛り上がっている
個人的なアプリケーション設計のバイブル3選 - Runner in the High
自分が本格的に設計を意識するようになったのは、2015年の夏に現職であるFringe81株式会社で開催されていたサマーインターンに参加してからだ。 インターンではDDDとクリーン・アーキテクチャ*1を一から勉強してAPIサーバーに実装する、というカリキュラムであったが、いま思うと2週間という比較的長いインターンで僕が学べたことと言えば本当に微々たるものだった。つまるところ、それくらいには設計というものは奥が深い。常になんらか特定のデザイン・パターンなりアーキテクチャ・パターンを適用することでアプリケーション開発がうまくいくということはなく、それらの様々な知識から少しづつ応用されたものが最終的なアプリケーションの設計に対して真の洞察を与えてくれるものというのが、僕自身のいまの認識である。 設計はまさに Connecting the dots そのものだ。多くを知れば知るほど、アプリケーション
なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita
このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。 はじめに 拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。 この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。 しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明の難しいものです。 拙著においては、ロナルド・コースの取引コスト理論をベースに、社内取引においても取引コストが存在し、その取引コストがソフトウェアの構造をも変えていくという説明を行いました。 本記事は、さらに踏み込んで、組織やビジネスに働く力学と、システムで
そうだ、ラクスルを作り直そう！ - RAKSUL TechBlog
10月からラクスルにジョインさせていただいた水島です。 新参者ですが、宜しくお願いいたします。 さて、入社して間もなくCTOの肝いりでスタートした 「Raksul Platform Project」 のプロマネを拝命したため、今日はその全体感の話をしたいと思います。 なにをするのか 「スタートアップあるある」だなんて言わないでください。 ラクスルをフルスクラッチで作り直そうとしています。 でもそれはあくまで手段です。 目的は、 技術負債と思われている部分を根本的に解消して開発しやすい状態にする（エンジニアを幸せに） システムに柔軟性を持たせて経営戦略の選択肢が増えている状態にする（経営を幸せに） の大きく2つです。 特に前者の「エンジニアを幸せに」という目的に対する経営陣の温度感が不思議と高いのはポジティブに感じています。短期的な投資対効果とかではなく、「ものづくり」を大切にする会社になる
漫画で説明する Flux
Lin Clark 氏が “A cartoon guide to Flux” というタイトルでとてもわかりやすく Flux についての記事を投稿していました。この文章のなかでも書かれていますが Flux はとてもホットな話題です。しかし、まだまだ十分に理解されていない技術なので、著者の Lin Clark 氏に許可を頂いて翻訳させていただきました。何か間違いや分かりにくいところ、より良くするための助言などありましたら気軽に@sota0805 までコメントお願いします。 （以下、2015年9月29日に Lin Clark 氏によって書かれた “A cartoon guide to Flux” の翻訳です。） 漫画で説明する FluxFlux は現在のウェブ開発で最もよく理解されていない話題の１つです。このガイドでは誰もが理解できる方法で説明しようとしています。 問題はじめに Flux が解決
バーガーショップで例えるオールアバウトでのLaravelアーキテクチャ - オールアバウトTech Blog
オールアバウトで開発チームに所属している@pakkunです。 12月も近くなり、大きく時期から外れてしまいますが、弊社では8月から9月にかけてサマーインターンを行いました。 その際に弊社で導入しているLaravelというPHPフレームワークの付き合い方を資料とライブコーディングでインターン生に説明しました。 抜粋になりますが、弊社でのLaravelとの付き合い方をブログでも公開します。 とは言え、Laravelを知らない人もいるかと思いますので、まず初めに軽く説明します。 3行でLaravelを知る PHPで書かれたフルスタックフレームワーク。 MVCベース。 PHP界隈ですごく流行っている。 MVCベースと記載しましたが、開発者のTaylor Otwellさんは「MVC Is Killing You」と著書で言っており、MVCに縛られると辛くなるので、あまり深くとらわれないようにしましょ
AWS認定ソリューションアーキテクト - プロフェッショナルに合格したので、調子に乗って勉強方法を考えてみる - プログラマでありたい
AWSの本を2冊書いていますが、AWS認定資格を1つも持っていませんでした。（正確に言うと、ソリューションアーキテクトのアソシエイトを持っていたけれど、2016年4月末で有効期限切れで失効していました。）会社の後輩たちが、どんどんプロ資格を取っていって疑いの目を向けられるようになってきたので、これはまずいと受験することにしました。昨日受けて無事合格したものの、幾つか反省点があるのでまとめてみます。 AWS認定資格の概要 AWSの認定資格は、2016年5月現在では2つのレベル・3つの分野があります。まずエントリーレベルであるAssociateは、一番メジャーで全般的な知識を問うSolutions Architect、開発者向けのDeveloper、運用管理者向けのSysOpsの３つがあります。そして下位の資格を持っていないと受験できないプロフェッショナルは、Solutions Archite
『Embulk』に見るモダンJavaの実践的テクニック ～並列分散処理システムの実装手法～
↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。 訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtdWwO48njcB8IdkN3kVAMu3wsmZo0O3S-f_4/edit?usp=sharing 専門家による資料・専門家向けの資料ではありません。自分自身で学習し、論文・文献等を読解してまとめた内容となります。間違い等あるかもしれませんが、あれば是非コメント頂ければと思います。 【訂正事項】 スライド16: 誤：たった一つのプロセスが故障しただけでも有限時間で合意できない 正：たった一つのプロセスが故障しうるだけでも有限時間で合意できない スライド20: 誤: 重要: あるschedule σ1, σ2 がdisjoint (nodeが被ってない) なら
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type