※この記事は下記note記事の転載になります。
https://note.com/globee/n/n678755bf8446
目次
- はじめに
- アーキテクチャとは
- 英語学習アプリabceedでは
- アーキテクチャ設計はなくても実装はできる
- なぜ必要なのか
- 自分が感じる具体的なメリット
- さいごに
はじめに
どうも株式会社Globeeの守安です。現在は主にAndroid開発を行っています!
今回はアーキテクチャ、設計がなぜ必要なのかという点について考えたいと思います。
アーキテクチャとは
そもそもアーキテクチャってなんやねん、というところから入ることにします。
まず前提として、ここで言うアーキテクチャとはソフトウェア・アーキテクチャのことです。
※ハードウェア方面のエンジニアのアーキテクチャという言葉を出しても、コンピュータ・アーキテクチャ(回路)をイメージされて全く話が噛み合わないので注意
アーキテクチャ(architecture): 建築(物)、建築術、建築様式、構造、構成
端的にはソフトウェアを作る時の構造といった感じでしょうか?
責務の分離や抽象化によって問題を解決することが多いです。
データフローやドメインのレイヤーに着目したものなど多数のパターンがあります。
例) MVC、MV-VM、Flux、ReduxやClean Architecture
英語学習アプリabceedでは
現在のAndroidのabceedアプリは、iOSと同様Clean Architecture + Fluxという設計で実装されています。
弊社のアーキテクチャ設計に関してabceed iOSの設計アーキテクチャを改善しましたに詳しく書かれているので、気になる方は読んでいただければと思います。
アーキテクチャ設計はなくても実装はできる
設計など考えずActivityやViewControllerなどに全てのコードを書いたとしてもアプリは作れます。俗にいうFatActivityってやつです。
なんなら最短で動くものを作るのであれば深く考えない方が早いまでありますし、世の中にはそういったプロジェクトも無数に存在します。
なぜ必要なのか
近年のプロジェクトでは、何かしらのアーキテクチャパターンを選択、もしくは複合的に取り入れて開発をおこなっています。
その理由は、開発効率や保守性、メンテナンス性などを向上しチームでの継続的な開発のパフォーマンスを最大化するためです。
※これは個人の意見なので異論は認めます🙇♂️
自分が感じる具体的なメリット
- コンフリクトを抑えられる
- 責務の分離により複雑性が解消される
一定のルールにより責務の分離がされ、コードが複雑化しにくい。 - 実装時の迷いが減る
通信、ビジネスロジック、状態管理、View操作をどこに書くかやネーミングなどルール(方針)があれば実装時に悩まなくなる。 - レビューのしやすい
設計が共通認識として存在することでコードレビュー観点を削減でき、難易度が下がる。
人的リソースが少ない場合など、最低限ビジネスロジックはレビューするといったことも可能。 - テストがしやすい
依存関係が考慮されていれば、テストを書くことが容易になる。 - 開発チームの拡大がしやすい
アーキテクチャ・設計を理解するコストはあるが、それ以降はコードベースの理解は速い。そもそもベースとなるアーキテクチャは既知の場合も多いのでコストも大して高くなかったり。
また、開発初期にアーキテクチャ設計を考えることでプロジェクトの負債を減らすことにつながります。実際、弊社のabceedのアーキテクチャは開発初期からClean Architectureというレイヤードアーキテクチャが採用されていました。そのおかげで、Viewやビジネスロジック、通信などそれぞれが密結合になるといったことは抑えられています。
さいごに
短いですが今回はアーキテクチャ設計の必要性について考えたことを書かせて頂きました。
アプリ設計、アーキテクチャは開発規模や開発対象、その他いろいろな条件に左右されるので厳密な正解はないですし意見も多種多様です。話が逸れるので記載しませんでしたが、コードが冗長、非直感的になったり、前述の通り学習コストが増えるなどのデメリットも存在します。
今回はアーキテクチャについてという抽象度の高い内容だったので、次回自分が記事を担当する場合はコードが載せられるような、Androidの実装について書こうと思います。
さて現在、株式会社Globeeでは採用活動を積極的に行なっております。
直近での転職意欲がなくて問題御座いません。まずはカジュアルにお話をさせて下さい。 もし少しでも興味をお持ち頂けた方は下記よりご応募よろしくお願い致します。