【技術者教育 資料】第1章 Rails中級者への道 〜クラス設計編〜
あらすじ
新人用の教育資料を作って、Qiitaで公開しまくっていたある日、中途の中級者向けにもアウトプットしてくださいと話があったので、更新頻度低めで、ボチボチ書いていこうと思います。
※後々、リクエストに応じて更新することが多いのでストックしておくことをおすすめします。
自分はプログラム開発における鉄板はあっても正解なんてないと思っている人です。1人で開発をしている分には好き勝手に納得行くまで極めて自分の世界で生きればいいと思いますが、実際複数人で開発してチームで動くようになると自分の趣味や好みの領域は押し殺す必要も出てきます。
このシリーズでは、ゆるーくこんな感じで考えるといいよっていう内容を紹介していこうと思います、
| No. | 記事 |
|---|---|
| 1 | 【中途教育 資料】第1章 Rails中級者への道 〜クラス設計編〜 |
| 2 | 【中途教育 資料】第2章 Rails中級者への道 〜オブジェクト指向の法則(SOLID)編〜 |
| 3 | 【中途教育 資料】第3章 Rails中級者への道 〜未定〜 |
クラス設計の考え方
おすすめの勉強方法
UMLなどを使って、業務モデリングが終わった後Railsを使ってシステム上で表現をするかを考えますよね？
はじめからデザインパターンを調べてから開発するのもいいのですが、自分で経験して初めて身に沁みると思うので焦らず以下の順序で学習してみることをおすすめします。
- scaffoldで作るプロトタイピング
- Fat controller
- Skinny Controller, Fat Model
- Controllerからdecoratorsの切り出しとModelからvalidatorsの切り出し
- Controllerからparametersの切り出しとModelからActiverecord使わないオブジェクトの切り出し
「1. scaffoldで作るプロトタイピング」は自分1人で学習が進むのですが
「2. Fat controller」を学習するまでに辿り着くには、自分で実装する機能を増やしていかないといけないので挫折しがちですね。
いつも思う事は、プログラムは漢字と同じようなものだなと感じます。
GEMやOSSが公開されていて、Github覗けば素敵なソースが見れる時代になりました。
ただし、漢字と同じでプログラムも読んでいるだけでは、読めるようになったとしても、実際書くとなると筆が止まってしまいます。
クラス設計の仕方
前工程でUMLなどを用い、業務洗い出しをして、システム範囲を確定させた後
クラス図上の一つ一つのクラスをRails上でどのように表現しようか考えます。
以下のようなフローを使っています。
黄色い背景はアプリケーション層、赤い背景の四角はドメイン層を示しており
信号に合わせて、赤いほど、ドメイン(業務)との結びつけが強くなるため、後々の修正が難しくなることを示しています。
RMDBSへのアクセス回数をいかに減らすか？突発的なアクセスをどの程度予測しおくかななどの拡張性要件、性能要件、可読性と保守性を何処まで求めるかなどで、さじ加減をしましょう。
場合によって、上記に合わせてFormsクラスやCachコントローラークラスなどを追加で検討します。
アーキテクチャ設計を別途検討をしつつ、DBに持たせる必要があるのか、さらに抽象化出来ないのか？粒度は適切か？などを検討していきます。
リファクタリングする機会がある人もない人も、一度お試しあれ
あとがき
中級、上級のネタになればなるほど、本業の業務内容に近づいてくるため、必然的に公開出来るないようが少なくなるのでネタに困りますね。書ける範囲で本記事も更新していこうと思います！
今回のネタもUMLとかのモデリングは必要な知識になるのでこちらも御覧ください
次回はRailsにおけるSOLIDの考え方をご紹介したいと思います。