Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Avatar for NaotoKoyama NaotoKoyama
December 01, 2018

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

Avatar for NaotoKoyama

NaotoKoyama

December 01, 2018
Tweet

More Decks by NaotoKoyama

Other Decks in Technology

Transcript

  1. ⾃⼰紹介 • 児⼭直⼈ • 株式会社ウフル(http://uhuru.jp) n経歴 • 中堅SIer⇒会計コンサル⇒現在 • 3年ほどVSAのみ携わり、コヤマクロ

    (児⼭ + マクロ)というものがある会社には 存在する • Java,Salesforce, node.js,AWS • 現在はスクラムでRuby on Rails
  2. プロジェクト概要 • メーカーのお客様 • 数年単位のプロジェクト • 現在の対象業務は既存システムのリプレース + α •

    スクラムは初めて • 継続的にシステム開発ができるチームを作りたい →お客様から2名開発者を派遣
  3. プロジェクトチーム Devチーム • ウフル社員2名 • お客様社員2名 • 全員Railsは初めて PO •

    かなり忙しい • 元システム屋さん • ほぼ週2稼働 スクラムコーチ • コーチ業のスペシャリスト • Railsもスペシャリスト • ⾃分たちで考えさせるタイプ • 週2稼働 プロジェクトマネージャー • 基本的には放任主義 • 必要なときに⼈やスケジュールを調整 POとしての動き⽅をコーチング スクラムのコーチング Rubyも聞かれたら答える レビュー・仕様確認 Railsコーチ • フリーエンジニア • Railsスペシャリスト • 週2稼働 技術コーチング
  4. Ruby・Railsで⼾惑ったこと • 開発環境の構築 ⁃ nokogiriのエラーで全く進まない • 全般 ⁃ そもそもどういった順番で作っていけばよいのかわからない ⁃

    責務の考え⽅がなく、⼀つのモデルにやることが多すぎる ⁃ Controllerにロジックを書きがち ⁃ dryでない ⁃ オブジェクト指向ではなく、⼿続き型になりがち
  5. Ruby・Railsで⼾惑ったこと(続き) • Rails特有の記法 ⁃ 複数系、単数形 ⁃ AR・アソシエーション ⁃ 「?」って何︖ ⁃

    シンボルって何︖「:」 前につけたり後につけたり • テスト ⁃ テストを書いたことがなく、RSpec特有の書き⽅に慣れない ⁃ そもそもどこまで書けばよいのかわからず、チーム内で⼝論になる
  6. Ruby・Railsで⼾惑ったこと(続き) • 既存システムのDBのテーブルがRails Wayに乗っていない ⁃ テーブル名が複数系のキャメルケースでない 例) t_item ⁃ primary_keyが「xxx_id」という列名

    例) item_id ⁃ そもそも⽂字列で定義されている ⁃ 以下のように対応 Class Item < 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
  7. 総括 良かった点 • スクラム、Railsともに少しは慣れてきた (基盤の作成) 改善点・よくなかった点 • モノが予想より作れていない • 基礎ができていない

    • Rails本来の開発に慣れていない • ある程度⽅針をはじめに決めておいたほうが 悩むことがなかった ふりかえり板書(⼀部)
  8. 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に合うように修正 変更前と変更後のテーブルの例
  9. プロジェクトチーム Devチーム • ウフル社員4名(+2名) • お客様社員2名 • フリーエンジニア2名(+1名) • 全員Railsは初めて

    PO • かなり忙しい • 元システム屋さん • ほぼ週2稼働 スクラムコーチ • コーチ業のスペシャリスト • Railsもスペシャリスト • ⾃分たちで考えさせるタイプ • 週2稼働 プロジェクトマネージャー • 基本的には放任主義 • 必要なときに⼈やスケジュールを調整 POとしての動き⽅をコーチング スクラムのコーチング Rubyも聞かれたら答える レビュー・仕様確認 Railsコーチ • フリーエンジニア • Railsスペシャリスト • 週2稼働 技術コーチング
  10. 開発環境 バージョン • Ruby 2.4.3 • Rails 5.1.6 DB •

    PostgresSQL 9.6 コードリポジトリ • Gitlab
  11. Rails運⽤ • テンプレートエンジン → ERB • フロントライブラリ → JQuery •

    認証・ログイン → Device • 認可 → Pundit • 定期ジョブ→whenever • テスト ⁃ 単体テスト → RSpec ⁃ EtoE → Cypress(まだまだ実運⽤できていませんが、、、) ⁃ フィクスチャ → factory_bot ⁃ フロント → Teaspoon(先⽉に導⼊)
  12. 反省点 • 有識者が⼿本を⾒せる ⁃ ネットで調べてやってみても情報が古い/ベストプラクティスではなかったりする ⁃ ただし初⼼者も任せっきりはだめ、有識者が全部やるのもだめ、バランスが⼤切 • はじめに⽅針を固めておく ⁃

    Rubocop/Editorconfigを導⼊ ⁃ コーディングの⽅針を作成 • Controllerは10⾏以内(各処理をModelに移⾏) • Modelは基本Modelディレクトリに⼊れる(直下は煩雑になる為フォルダにまとめる等する。 app/model/forms など...) • 共通化できる処理はクラス化していく • Publicには基本的には外部参照する画像やエラーページで参照する画像等しか置かない など