Ruby関西 Rails初心者チームが約半年間がむしゃらにやったこと

Transcript

1. Rails初⼼者チームが約半 年でがむしゃらにやったこと 2018.12.01 第84回 Ruby関⻄ 勉強会 児⼭ 直⼈
2. ⾃⼰紹介 • 児⼭直⼈ • 株式会社ウフル（http://uhuru.jp） n経歴 • 中堅SIer⇒会計コンサル⇒現在 • 3年ほどVSAのみ携わり、コヤマクロ (児⼭ + マクロ)というものがある会社には 存在する • Java,Salesforce, node.js,AWS • 現在はスクラムでRuby on Rails
3. 今回の話︖ • Ruby on Rails初⼼者 • スクラム初⼼者 そんな私たちが約半年間全⼒でやったことのお話
4. プロジェクト概要 • メーカーのお客様 • 数年単位のプロジェクト • 現在の対象業務は既存システムのリプレース + α • スクラムは初めて • 継続的にシステム開発ができるチームを作りたい →お客様から2名開発者を派遣
5. プロジェクトチーム Devチーム • ウフル社員2名 • お客様社員2名 • 全員Railsは初めて PO • かなり忙しい • 元システム屋さん • ほぼ週2稼働 スクラムコーチ • コーチ業のスペシャリスト • Railsもスペシャリスト • ⾃分たちで考えさせるタイプ • 週2稼働 プロジェクトマネージャー • 基本的には放任主義 • 必要なときに⼈やスケジュールを調整 POとしての動き⽅をコーチング スクラムのコーチング Rubyも聞かれたら答える レビュー・仕様確認 Railsコーチ • フリーエンジニア • Railsスペシャリスト • 週2稼働 技術コーチング
6. 開始3カ⽉ 教育に注⼒する期間
7. 1か⽉⽬（教育） • Ruby on Rails の概要説明 • 簡単なWebアプリケーションの作成（MVC） ⁃ Railsコマンド(new/scaffold/generate/migrate/start) ⁃ Seed • テストFrameWork(Rspec) • 認可(pundit)
8. 2か⽉⽬（本格的な開発開始） • 本格的な開発開始でチーム内もやる気が満ち溢れる • コーチがいないときはどう開発すればよいのかわからず思ったより開発が進 まない →コーチの稼働を週2→週3へ増やす • 後述する理由で圧倒的に開発スピードが⾜りない →Railsエンジニアを1名増員
9. 開発全般で困ったこと • Gitを使った開発 ⁃ そもそもソース管理がはじめてなので、使い⽅がわからない ⁃ 間違った操作で巻き戻ったりする ⁃ 同じソースを複数⼈が編集してコンフリクト祭り • Windows特有の問題 ⁃ WSL遅い ⁃ permissionが異なる ⁃ 改⾏コードが異なる ⁃ ⽂字コードが異なる
10. Ruby・Railsで⼾惑ったこと • 開発環境の構築 ⁃ nokogiriのエラーで全く進まない • 全般 ⁃ そもそもどういった順番で作っていけばよいのかわからない ⁃ 責務の考え⽅がなく、⼀つのモデルにやることが多すぎる ⁃ Controllerにロジックを書きがち ⁃ dryでない ⁃ オブジェクト指向ではなく、⼿続き型になりがち
11. Ruby・Railsで⼾惑ったこと(続き) • Rails特有の記法 ⁃ 複数系、単数形 ⁃ AR・アソシエーション ⁃ 「?」って何︖ ⁃ シンボルって何︖「:」 前につけたり後につけたり • テスト ⁃ テストを書いたことがなく、RSpec特有の書き⽅に慣れない ⁃ そもそもどこまで書けばよいのかわからず、チーム内で⼝論になる
12. Ruby・Railsで⼾惑ったこと(続き) • 既存システムのDBのテーブルがRails Wayに乗っていない ⁃ テーブル名が複数系のキャメルケースでない 例) t_item ⁃ primary_keyが「xxx_id」という列名 例) item_id ⁃ そもそも⽂字列で定義されている ⁃ 以下のように対応 Class Iteｍ < ApplicationRecord self.table_name = ʻt_itemʼ self.primary_key = ʻitem_idʼ belongs_to :manufacturer, foreign_key: :manufacturer_id has_many :parts, foreign_key: :item_id … end
13. 3か⽉⽬（⼀旦プロジェクトの区切り） • 新しいエンジニアとコーチで⽅針が異なることがあり、チーム内が混乱 →話し合って認識合わせ • 新しいエンジニアが⼊ってきたことである程度軌道に乗ってくる • ただ⽬標としていた成果にはほど遠くという結果に、、、
14. 総括 良かった点 • スクラム、Railsともに少しは慣れてきた （基盤の作成） 改善点・よくなかった点 • モノが予想より作れていない • 基礎ができていない • Rails本来の開発に慣れていない • ある程度⽅針をはじめに決めておいたほうが 悩むことがなかった ふりかえり板書（⼀部）
15. 次の3カ⽉に向けてのアクション • ⾃分たちの習熟がわかるスキルマップを作る • コードレビューで指摘を受けた内容やコードを書いていての気づきなどを 共有する場を毎⽇15分作る • ランチ時間に勉強する場を作る • Rails Wayに合うようにテーブルの再設計
16. プロジェクト全般で使⽤するスキルマップ Railsのスキルマップ
17. Rails Wayに合うようにテーブルの再設計 t_item item_id item_name item_kbn … registerd_date updated_date items id item_code name item_kubun … created_at updated_at • テーブル名を複数系に • Rails⽤のUUID列を作成 • もともとのIDはcodeに変更 • items.item_nameのように冗⻑に ならないように列名を修正 • kbnのような⼀般的でない省略形は 使わない • ⽇付もRailsに合うように修正 変更前と変更後のテーブルの例
18. 4カ⽉⽬〜現在 ものつくりに注⼒する期間
19. プロジェクトチーム Devチーム • ウフル社員4名(+2名) • お客様社員2名 • フリーエンジニア2名(+1名) • 全員Railsは初めて PO • かなり忙しい • 元システム屋さん • ほぼ週2稼働 スクラムコーチ • コーチ業のスペシャリスト • Railsもスペシャリスト • ⾃分たちで考えさせるタイプ • 週2稼働 プロジェクトマネージャー • 基本的には放任主義 • 必要なときに⼈やスケジュールを調整 POとしての動き⽅をコーチング スクラムのコーチング Rubyも聞かれたら答える レビュー・仕様確認 Railsコーチ • フリーエンジニア • Railsスペシャリスト • 週2稼働 技術コーチング
20. 総括 • 教育に時間を割いたことでかなり安定してくる • Rails Guideの読書会を開いて基礎の底上げ • フロント回りが弱かったため、デザイナー・フロントエンドエンジニアを追加 • localhostではなく、きちんとした開発環境を⽤意 （後ほど構成を紹介） • リファクタリングに精を⼊れる
21. 開発環境 ブランチ運⽤やRails運⽤のお話
22. 開発環境 バージョン • Ruby 2.4.3 • Rails 5.1.6 DB • PostgresSQL 9.6 コードリポジトリ • Gitlab
23. インフラ構成図
24. ブランチ運⽤ ▪ブランチモデルと開発フロー ▪環境構築の⾃動化（マニュアル実⾏） ▪環境削除の⾃動化（マニュアル実⾏） ストップボタンを押すことで ⾃動で、Elastic Beasntalk環境 を 終了することができる。
25. Rails運⽤ • テンプレートエンジン → ERB • フロントライブラリ → JQuery • 認証・ログイン → Device • 認可 → Pundit • 定期ジョブ→whenever • テスト ⁃ 単体テスト → RSpec ⁃ EtoE → Cypress(まだまだ実運⽤できていませんが、、、) ⁃ フィクスチャ → factory_bot ⁃ フロント → Teaspoon(先⽉に導⼊)
26. 個⼈的なふりかえり これやっててよかったとか、もう少しこうすればよかったとか 初⼼者の⽅に参考になれば
27. よかった点 • 開発したいものベースで進める ⁃ とりあえず開発したいものを開発してき、主要な機能を把握してから⽬次を埋めて いくと理解度が早く進んだ ⁃ 開発したいものが⾒つかっていない⼈はRailsチューとリアルなどおすすめ • 有識者にすぐ聞ける環境 ⁃ もし近くに有識者がいなかったらコミュニティに参加する • 勉強会に参加 ⁃ コード共有会/ランチ勉強会/朝活/コミュニティなど ⁃ 気分転換やモチベーションにもなる
28. 反省点 • 有識者が⼿本を⾒せる ⁃ ネットで調べてやってみても情報が古い/ベストプラクティスではなかったりする ⁃ ただし初⼼者も任せっきりはだめ、有識者が全部やるのもだめ、バランスが⼤切 • はじめに⽅針を固めておく ⁃ Rubocop/Editorconfigを導⼊ ⁃ コーディングの⽅針を作成 • Controllerは10⾏以内（各処理をModelに移⾏） • Modelは基本Modelディレクトリに⼊れる（直下は煩雑になる為フォルダにまとめる等する。 app/model/forms など...） • 共通化できる処理はクラス化していく • Publicには基本的には外部参照する画像やエラーページで参照する画像等しか置かない など
29. 反省点(続き) • 勉強不⾜ ⁃ RailsはWebアプリケーションフレームワーク ⁃ そもそもフロントエンド/バックエンド/オブジェクト指向などWebアプリケーションを開 発する上で必要な知識が⾜りなかったりすると、会話にすらならないときがある ⁃ フルスペックになる必要はないが、せめて最低限の知識は付ける必要があると感じ た ⁃ ①スキルマップを作成②AsIsとToBeの定義③優先順位をつけて勉強という順で ⾏っています ⁃ 書籍やQiitaなどもよいですが、軽めに動画サービスなどもおすすめ
30. 最後に • 皆さん⼀緒にウフルで働きませんか︖ • ⼤阪フェスティバルタワー • Rubyのエンジニア絶賛探しています︕ フェスティバルタワー 開発定例会