🅰️
脱 Angular 初心者 - 次に進むための設計、コーディング
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">
- はちさん
- ng-kyoto 代表 / ng-japan スタッフ
- Twitter: @armorik83
- GitHub: @armorik83
Angular 2.0.0 released! :tada:
脱初心者してこ 💪
ここでの初心者の定義
- あらゆる問題に対して、解決方法が分からない
- 解決できず挫折
- 抱えきれず破綻
- API を知らない = 初心者ではない
- いくらでも調べればいい
- 調べ方が分かっているなら、知らなくてもいい
- ※ 知っているに越したことはない
中級者へ進む方法
- あらゆる問題に対して、一つ一つ適切な解決法を知る
- 解決法の根拠を理解する
初心者あるある
1. ファイルの分割粒度が分からない
- チュートリアルの一部を、自分の作りたいものに変えてみた
- チュートリアルにはない機能を足してみた
- 足してみた
- 足してみた
- 足してみた
神クラス 👼
ソースファイルを分割しよう
- 大きいと、どこを変えて何が変わるか把握しにくい
- どうやって分割する？
- 機械的にソースの行数が n 行になったら分割すればいい？
- 🙅
- 機械的にソースの行数が n 行になったら分割すればいい？
- 責務分割の意識を持つ
単一責任原則 (SRP)
-
Single Responsibility Principle
- 変更する理由が同じものは集める
- 変更する理由が違うものは分ける
- 出典
- SOLID 原則
- プログラマが知るべき 97 のこと
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 lintはtslintを内包している
-
- プログラムにソースを解析させる
Angular の最良コーディングスタイル
- この辺に従って真似しておけば間違いないです
不明点の調べ方
- まずは公式を読もう
- teratail で検索、質問
ニッチな悩みすぎて全然分からないとき
- Twitter
- ハッシュタグ
#ng_jpで誰かに頼る
- ハッシュタグ
- Slack
- https://ng-japan-invite.herokuapp.com/
- Slack の ng-japan チームに参加し質問チャンネルから質問
- ng-japan を中心に日本の Angular コミュニティがサポートします 👍
まとめ
- ファイルの分割粒度が分からない
- 責務ごとにどんどん分割
- リファクタリングを知らない
- 常にテストしやすさを意識して処理を書く
- もちろん余裕があるならテストも書く
- コードはコピペの寄せ集め
- スタイルルールを基に Linter のサポートを受ける
全ては保守していくため
参考図書
- 『リファクタリング - プログラムの体質改善テクニック』
- 『リーダブルコード ― より良いコードを書くためのシンプルで実践的なテクニック』
- 『プログラマが知るべき 97 のこと』
- 『プリンシプル オブ プログラミング』
この辺はもう知ってました？
- Angular は汎用的なノウハウがそのまま活かせます
- Angular の API を少しずつ調べながら、サンプルを見ながら、肥大化に気をつけて組み合わせていけば、大きなアプリも作れるでしょう
Discussion