アプリ設計とアーキテクチャの必要性を考える

2022年1月26日 12:47

はじめに

どうも株式会社Globeeの守安です。現在は主にAndroid開発を行っています！

今回はアーキテクチャ、設計がなぜ必要なのかという点について考えたいと思います。

そもそもアーキテクチャってなんやねん、というところから入ることにします。

まず前提として、ここで言うアーキテクチャとはソフトウェア・アーキテクチャのことです。
※ハードウェア方面のエンジニアのアーキテクチャという言葉を出しても、コンピュータ・アーキテクチャ(回路)をイメージされて全く話が噛み合わないので注意

アーキテクチャ(architecture): 建築（物）、建築術、建築様式、構造、構成

端的にはソフトウェアを作る時の構造といった感じでしょうか？
責務の分離や抽象化によって問題を解決することが多いです。

データフローやドメインのレイヤーに着目したものなど多数のパターンがあります。
例) MVC、MV-VM、Flux、ReduxやClean Architecture

現在のAndroidのabceedアプリは、iOSと同様Clean Architecture + Fluxという設計で実装されています。
弊社のアーキテクチャ設計に関してabceed iOSの設計アーキテクチャを改善しましたに詳しく書かれているので、気になる方は読んでいただければと思います。

設計など考えずActivityやViewControllerなどに全てのコードを書いたとしてもアプリは作れます。俗にいうFatActivityってやつです。

なんなら最短で動くものを作るのであれば深く考えない方が早いまでありますし、世の中にはそういったプロジェクトも無数に存在します。

近年のプロジェクトでは、何かしらのアーキテクチャパターンを選択、もしくは複合的に取り入れて開発をおこなっています。

その理由は、開発効率や保守性、メンテナンス性などを向上しチームでの継続的な開発のパフォーマンスを最大化するためです。
※これは個人の意見なので異論は認めます🙇‍♂️

コンフリクトを抑えられる
責務の分離により複雑性が解消される
一定のルールにより責務の分離がされ、コードが複雑化しにくい。
実装時の迷いが減る
通信、ビジネスロジック、状態管理、View操作をどこに書くかやネーミングなどルール(方針)があれば実装時に悩まなくなる。
レビューのしやすい
設計が共通認識として存在することでコードレビュー観点を削減でき、難易度が下がる。
人的リソースが少ない場合など、最低限ビジネスロジックはレビューするといったことも可能。
テストがしやすい
依存関係が考慮されていれば、テストを書くことが容易になる。
開発チームの拡大がしやすい
アーキテクチャ・設計を理解するコストはあるが、それ以降はコードベースの理解は速い。そもそもベースとなるアーキテクチャは既知の場合も多いのでコストも大して高くなかったり。

また、開発初期にアーキテクチャ設計を考えることでプロジェクトの負債を減らすことにつながります。

実際、弊社のabceedのアーキテクチャは開発初期からClean Architectureというレイヤードアーキテクチャが採用されていました。
そのおかげで、Viewやビジネスロジック、通信などそれぞれが密結合になるといったことは抑えられています。

短いですが今回はアーキテクチャ設計の必要性について考えたことを書かせて頂きました。

アプリ設計、アーキテクチャは開発規模や開発対象、その他いろいろな条件に左右されるので厳密な正解はないですし意見も多種多様です。

話が逸れるので記載しませんでしたが、コードが冗長、非直感的になったり、前述の通り学習コストが増えるなどのデメリットも存在します。

今回はアーキテクチャについてという抽象度の高い内容だったので、次回自分が記事を担当する場合はコードが載せられるような、Androidの実装について書こうと思います。

現在株式会社Globeeでは「エンジニア職種」を中心に採用活動を積極的に行なっております。
弊社が「教育」にかける思いや「ものづくり」の考え方について、弊社代表の幾嶋より、
お話が出来ればと思いますので、皆様お気軽にご応募下さい。

この記事が気に入ったらサポートをしてみませんか？