🅰️

脱 Angular 初心者 - 次に進むための設計、コーディング

2021/07/04に公開

Angular 2 入門者の会

Oct 3, 2016 / レバレジーズ株式会社

  • 初めてスライドモード使ってみる

armorik83

<img src="https://qiita-image-store.s3.amazonaws.com/0/17959/a646f3c3-d3f3-83cf-1596-4e96b11b8e81.png" alt="C8zptgfr.png" width="64px">


Angular 2.0.0 released! :tada:


  • みなさん、安定版なのでもちろんプロダクションに使っていきますよね?
  • まだHeroとかTodoしか作れない?

脱初心者してこ 💪


ここでの初心者の定義

  • あらゆる問題に対して、解決方法が分からない
    • 解決できず挫折
    • 抱えきれず破綻
  • API を知らない = 初心者ではない
    • いくらでも調べればいい
    • 調べ方が分かっているなら、知らなくてもいい
      • ※ 知っているに越したことはない

中級者へ進む方法

  • あらゆる問題に対して、一つ一つ適切な解決法を知る
  • 解決法の根拠を理解する

初心者あるある


1. ファイルの分割粒度が分からない

  • チュートリアルの一部を、自分の作りたいものに変えてみた
  • チュートリアルにはない機能を足してみた
  • 足してみた
  • 足してみた
  • 足してみた

神クラス 👼


ソースファイルを分割しよう

  • 大きいと、どこを変えて何が変わるか把握しにくい
  • どうやって分割する?
    • 機械的にソースの行数が n 行になったら分割すればいい?
      • 🙅
  • 責務分割の意識を持つ

単一責任原則 (SRP)


Angular ではどうするか

  • × Component に全部の処理を書く
  • 処理は Service に移して、Component は薄くする
  • 責務ごとに Service を実装し、適宜 Service 同士が連携する

新しく Service を作ることを恐れるな

  • もしイマイチでも、修正すればいい
    • プログラムは常々修正される
  • 分割した方がいい?と感じたら分ける
    • Component の中に 1 メソッド 10 行以上のものが出てきたら分割の予感
    • とりあえず分割した方が吉

2. リファクタリングを知らない

  • リファクタリングとは
    • アプリケーションの振る舞いは保ちつつ
    • ソースを洗練し理解しやすくし
    • 保守・拡張を容易にするための改善

コードは腐る 👻


リファクタリングの方法を知ろう

  • いつリファクタリングするか
    • コードの臭いの例
      • 重複したコード
      • 長すぎるメソッド
    • 『Martin Fowler リファクタリング - プログラムの体質改善テクニック』

Angular ではどうするか

  • テストを書いてリファクタリングに備える
  • Jasmine + Karma
    • 機能単位のユニットテスト
    • モックを組み合わせた局所的なモックテスト
  • Protractor
    • ブラウザ上の表示やマウス・キーボード操作のシミュレートを組み合わせた e2e テスト

依存関係逆転の原則 (DIP)

  • Dependency Inversion Principle
    • 抽象に依存せよ
      • 具象に依存するとテストが困難になる
      • 抽象に依存しておけば、テスト時にモックを参照できる
  • 出典
    • SOLID 原則
  • Angular のDI 機構は DIP を実践するためのもの

SOLID 原則

  • 1.のSRPも、2.のDIPも両方とも出典はSOLID 原則
  • この原則を念頭においておけば、
    • 客観的に適切に分割される
    • テストをしやすい設計が自然に導かれる
      • ただしリファクタリングという保守活動を絶やすことはできない

リファクタリングのためにはテスト

  • 納期が迫っているとき
    • やむを得ず汚いコードを書くこともあり得る
    • テストを書く余裕もない
      • → こんなときリファクタリングは不可能なのか?
  • 勘違いされがちだが
    • リファクタリングは「自動テスト」が必須なのではなく
    • 「テスト」が必須
  • 振る舞いが変わっていなければ OK
    • 極論、手動テストでも OK👌

###複数の副作用を前提とした処理は書かない

  • 処理中にthis.がたくさん出てきたら怪しい
    • テストしにくい
    • それ、引数と戻り値にできない?
  • 処理の単位を小さくしておけば検証もしやすい

3. コードはコピペの寄せ集め

  • 検索して出てきたソースコードをコピペ
    • 動いた!よかった!
  • こっちもコピペ
  • こっちの関数もコピペ…

スタイルがバラバラ 💣


スタイルの統一されていないソースは読みにくい

  • プログラムは保守されるもの
    • つまり長期間、何度も読まれるもの
  • 常に読み手が理解しやすい記述を心がけなければならない
    • それは他人?数ヶ月後の自分?
  • コピペをするなとは言わない
    • スタイルに無頓着ではいけない
    • 周りと整合性のないコードを紛れこませない

いいスタイルとは

  • いいスタイル
    • 変数の命名に整合性と統一感がある
    • 改行位置が揃っている
    • オブジェクトや配列の列挙時の視認性のよさ
    • …など
  • 『リーダブルコード ― より良いコードを書くためのシンプルで実践的なテクニック』

Angular ではどうするか

  • angular-cliを使えばng lintコマンドが使える
    • プログラムにソースを解析させる
      • スタイル誤りの指摘を受けられる
    • TypeScript ではtslintを使う
      • ng linttslintを内包している

Angular の最良コーディングスタイル


不明点の調べ方


ニッチな悩みすぎて全然分からないとき

  • Twitter
    • ハッシュタグ #ng_jp で誰かに頼る
  • Slack
  • ng-japan を中心に日本の Angular コミュニティがサポートします 👍

まとめ

  1. ファイルの分割粒度が分からない
  • 責務ごとにどんどん分割
  1. リファクタリングを知らない
  • 常にテストしやすさを意識して処理を書く
  • もちろん余裕があるならテストも書く
  1. コードはコピペの寄せ集め
  • スタイルルールを基に Linter のサポートを受ける

全ては保守していくため


参考図書

  • 『リファクタリング - プログラムの体質改善テクニック』
  • 『リーダブルコード ― より良いコードを書くためのシンプルで実践的なテクニック』
  • 『プログラマが知るべき 97 のこと』
  • 『プリンシプル オブ プログラミング』

この辺はもう知ってました?

  • Angular は汎用的なノウハウがそのまま活かせます
  • Angular の API を少しずつ調べながら、サンプルを見ながら、肥大化に気をつけて組み合わせていけば、大きなアプリも作れるでしょう

アーキテクチャ補助用ライブラリ


ありがとうございました

Discussion

ログインするとコメントできます