Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Angularプロダクト構築アンチパターン
Search
ponday
January 20, 2018
Technology
1.6k
0
Share
Angularプロダクト構築アンチパターン
ng-fukuoka Angular Meetup #2の発表資料です。
ponday
January 20, 2018
More Decks by ponday
See All by ponday
関数型でGoFのデザインパターンやってみる
honda
1
1.6k
TypeScriptの型表現
honda
10
3.1k
Web Componentsの今
honda
1
470
これまでのReact、これからのReact
honda
0
340
Gatsbyお試し
honda
0
130
styled-components or emotion?
honda
0
720
Web ComponentsとAngular
honda
0
150
Atomic Design周りについての私見
honda
1
790
え、まだWeb Componentsを未来の技術だと思ってるの?
honda
2
880
Other Decks in Technology
See All in Technology
データモデリング通り #5オンライン勉強会: AIに『ビジネスの文脈』を教え込むデータモデリング
datayokocho
0
190
AIが自律的に働く時代へ Amazon Quick で実現するAIエージェント紹介
koheiyoshikawa
0
190
QAエンジニアはどうやって プロダクト議論の場に入れるのか?
moritamasami
2
410
Building a Study Buddy AI Agent from Scratch: From Passive Chatbots to Autonomous Systems
itchimonji
0
140
AI時代に、 データアナリストがデータエンジニアに異動して
jackojacko_
0
250
色を視る
yuzneri
0
320
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
100k
試作とデモンストレーション / Prototyping and Demonstrations
ks91
PRO
0
190
AIの揺らぎに“コシ”を与える階層化品質設計
ickx
0
270
OWASP APTSを眺めてみた
su3158
0
130
サービスの信頼性を高めるため、形骸化した「プロダクションミーティング」を立て直すまでの取り組み
stefafafan
1
250
GKE Agent SandboxでAIが生成したコードを 安全に実行してみた
lamaglama39
0
210
Featured
See All Featured
New Earth Scene 8
popppiees
3
2.2k
The Limits of Empathy - UXLibs8
cassininazir
1
320
Bootstrapping a Software Product
garrettdimon
PRO
307
120k
Navigating Team Friction
lara
192
16k
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
380
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
540
Balancing Empowerment & Direction
lara
6
1.1k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
3.2k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
Code Reviewing Like a Champion
maltzj
528
40k
Testing 201, or: Great Expectations
jmmastey
46
8.1k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
122
21k
Transcript
Angularプロダクト構築アンチパターン ng-fukuoka Angular Meetup #2 / Jan 20, 2018 ponday(@ponday_dev)
Profile Honda, Yusuke (@ponday_dev) chibi-developer ng-fukuoka organizer Community TypeScript /
JavaScript / Kotlin RxJS / Angular Like
お仕事でもAngularを書いてます
その中で感じた (個人的)プロダクト構築アンチパターン
- あくまで個人的な見解ですので、Angular公式が推奨するもの ではありません - フロントエンドのみで約3万行の小~中規模アプリケーション開 発を通じての感想です。規模によっては不適切な場合があり ます。 ご注意
アンチパターン① Angular CLIを使わない
使いましょう
- 自前で環境構築してメンテするには覚悟が必要 - 追従が大変 - コード生成できない - (一応)脱出もしやすい - ng
eject webpack.config.js - IonicにもCLIがあるのでそっち使うほうが無難 アンチパターン① Angular CLIを使わない
アンチパターン② NgModuleがネストしている
モジュールBはモジュールAにインポートされるから... /A/A.module.ts /A/modules/B/B.module.ts
モジュールBはモジュールAにインポートされるから... /A/A.module.ts /A/modules/B/B.module.ts ←
- ネストしても良いことは少ない - インポートパスが長くなる - 再利用しにくい - ディレクトリ構造そのまま別のモジュールでインポートすると実態と合わなくな る -
モジュールはディレクトリ的にはフラットに アンチパターン② NgModuleがネストしている
アンチパターン③ コンポーネントを分割しすぎる
- header - my-button - view-container - foo-page - foo-toolbar
- foo-list - foo-list-header - foo-list-body - foo-footer - … - bar-page - bar-toolbar - bar-form - ...
- header - my-button - view-container - foo-page - foo-toolbar
- foo-list - foo-list-header - foo-list-body - foo-footer - … - bar-page - bar-toolbar - bar-form - ... 本当に必要...?
- header - my-button - view-container - foo-page - bar-page
いらないなら分けない
- 本当にそのコンポーネント再利用しますか? - 再利用できるコンポーネントは結構少ない - 最初はよく再利用される物だけ作る(ヘッダ、ボタンなど) - 再利用が必要になってはじめて分ける - コンポーネントの階層が深くなると状態の管理が面倒
- バケツリレーが長くなる - どのコンポーネントで状態が変更されるかわかりづらい アンチパターン③ コンポーネントを分割しすぎる
アンチパターン④ Module一つあたりの役割が大きい
モジュールは分けなくてもアプリは作れる
しかし、分けないとモジュールに紐づくソースが すごい勢いで増えていく
再利用したくなったり、 コードのまとまりが見えてきたら分けましょう
- 最初から分ける必要はない - コード量が増えるだけ - しかし、単体のモジュールを膨らませ続けると後々つらい - まとまりが見えてきたらリファクタリングをかねて分割を検討する - ライブラリとして提供する場合は小さく
- 設計段階で良く検討する - Angular Materialなども参考に (大体1機能 = 1モジュール) - 理想的にはそのモジュール単体で動作 アンチパターン④ Module一つあたりの役割が大きい
アンチパターン⑤ index.tsを作らない
TypeScriptでは、ディレクトリ直下にindex.tsがあると 勝手に読み込んでくれる
ここにexport文を書いておくといろいろ捗る
例えば... - /app - /toast - /services - toast.service.ts -
/components - toast.component.ts - toast.module.ts - app.component.ts - app.module.ts app.component.tsから使う
そのままだと... app.module.ts app.component.ts - インポートパスがディレクトリ構成に依存 - ディレクトリ構成を変えると外部のソースに影響 - 変更に弱い -
toast.component.tsは外部から使うものか分からない
ここにindex.tsを追加 - /app - /toast - /services - toast.service.ts -
/components - toast.component.ts - toast.component.ts - index.ts - app.component.ts - app.module.ts
中身はこれだけ index.ts
すると... app.module.ts app.component.ts - 内部のディレクトリ構成に依存せずインポートできる - 短く書ける - 内部の変更がしやすい -
公開されているAPIが明確
- TypeScriptの機能 - インポートが短く書ける - インポートパスがディレクトリ構成に依存しない - 外部に公開したいAPIが明示できる - 特にモジュールを分割するときに有効
アンチパターン⑤ index.tsを作らない
アンチパターン⑥ RxJSを何となく使う
(間違いなく)死にます
- Angular RxJS - AngularはRxJSに依存。いろいろなものがObservableを返す。 - AngularのディープなAPIより利用頻度はかなり高いはず - RxJSはむずかしい -
TypeScriptとはパラダイムが全然違う - 新しい言語勉強するのと良い勝負 - その場しのぎでコードを作ると間違いなく負債化する アンチパターン⑥ RxJSを何となく使う
使いこなしたい?
技術書典3で解説書出しました https://booth.pm/ja/items/659290
Thank you !!