Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Ruby関西 Rails初心者チームが約半年間がむしゃらにやったこと
Search
NaotoKoyama
December 01, 2018
Technology
0
40
Ruby関西 Rails初心者チームが約半年間がむしゃらにやったこと
NaotoKoyama
December 01, 2018
Tweet
Share
More Decks by NaotoKoyama
See All by NaotoKoyama
DevLove関西 受託開発企業ではじめてスクラムを導入した時の話
naotokoyama
0
30
【Webbased IoT勉強会】オフィスIoTをサーバーレスで作ってみた
naotokoyama
0
22
Other Decks in Technology
See All in Technology
マーケットプレイス版Oracle WebCenter Content For OCI
oracle4engineer
PRO
3
970
AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ
watany
9
2.2k
Rethinking Incident Response: Context-Aware AI in Practice
rrreeeyyy
1
130
united airlines ™®️ USA Contact Numbers: Complete 2025 Support Guide
flyunitedhelp
1
440
対話型音声AIアプリケーションの信頼性向上の取り組み
ivry_presentationmaterials
1
390
スタートアップに選択肢を 〜生成AIを活用したセカンダリー事業への挑戦〜
nstock
0
260
AI専用のリンターを作る #yumemi_patch
bengo4com
6
4.4k
CDKTFについてざっくり理解する!!~CloudFormationからCDKTFへ変換するツールも作ってみた~
masakiokuda
1
180
MobileActOsaka_250704.pdf
akaitadaaki
0
170
TableauLangchainとは何か?
cielo1985
1
120
事例で学ぶ!B2B SaaSにおけるSREの実践例/SRE for B2B SaaS: A Real-World Case Study
bitkey
1
160
IPA&AWSダブル全冠が明かす、人生を変えた勉強法のすべて
iwamot
PRO
2
190
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
510
The Language of Interfaces
destraynor
158
25k
A better future with KSS
kneath
238
17k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
A Tale of Four Properties
chriscoyier
160
23k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Transcript
Rails初⼼者チームが約半 年でがむしゃらにやったこと 2018.12.01 第84回 Ruby関⻄ 勉強会 児⼭ 直⼈
⾃⼰紹介 • 児⼭直⼈ • 株式会社ウフル(http://uhuru.jp) n経歴 • 中堅SIer⇒会計コンサル⇒現在 • 3年ほどVSAのみ携わり、コヤマクロ
(児⼭ + マクロ)というものがある会社には 存在する • Java,Salesforce, node.js,AWS • 現在はスクラムでRuby on Rails
今回の話︖ • Ruby on Rails初⼼者 • スクラム初⼼者 そんな私たちが約半年間全⼒でやったことのお話
プロジェクト概要 • メーカーのお客様 • 数年単位のプロジェクト • 現在の対象業務は既存システムのリプレース + α •
スクラムは初めて • 継続的にシステム開発ができるチームを作りたい →お客様から2名開発者を派遣
プロジェクトチーム Devチーム • ウフル社員2名 • お客様社員2名 • 全員Railsは初めて PO •
かなり忙しい • 元システム屋さん • ほぼ週2稼働 スクラムコーチ • コーチ業のスペシャリスト • Railsもスペシャリスト • ⾃分たちで考えさせるタイプ • 週2稼働 プロジェクトマネージャー • 基本的には放任主義 • 必要なときに⼈やスケジュールを調整 POとしての動き⽅をコーチング スクラムのコーチング Rubyも聞かれたら答える レビュー・仕様確認 Railsコーチ • フリーエンジニア • Railsスペシャリスト • 週2稼働 技術コーチング
開始3カ⽉ 教育に注⼒する期間
1か⽉⽬(教育) • Ruby on Rails の概要説明 • 簡単なWebアプリケーションの作成(MVC) ⁃ Railsコマンド(new/scaffold/generate/migrate/start)
⁃ Seed • テストFrameWork(Rspec) • 認可(pundit)
2か⽉⽬(本格的な開発開始) • 本格的な開発開始でチーム内もやる気が満ち溢れる • コーチがいないときはどう開発すればよいのかわからず思ったより開発が進 まない →コーチの稼働を週2→週3へ増やす • 後述する理由で圧倒的に開発スピードが⾜りない →Railsエンジニアを1名増員
開発全般で困ったこと • Gitを使った開発 ⁃ そもそもソース管理がはじめてなので、使い⽅がわからない ⁃ 間違った操作で巻き戻ったりする ⁃ 同じソースを複数⼈が編集してコンフリクト祭り •
Windows特有の問題 ⁃ WSL遅い ⁃ permissionが異なる ⁃ 改⾏コードが異なる ⁃ ⽂字コードが異なる
Ruby・Railsで⼾惑ったこと • 開発環境の構築 ⁃ nokogiriのエラーで全く進まない • 全般 ⁃ そもそもどういった順番で作っていけばよいのかわからない ⁃
責務の考え⽅がなく、⼀つのモデルにやることが多すぎる ⁃ Controllerにロジックを書きがち ⁃ dryでない ⁃ オブジェクト指向ではなく、⼿続き型になりがち
Ruby・Railsで⼾惑ったこと(続き) • Rails特有の記法 ⁃ 複数系、単数形 ⁃ AR・アソシエーション ⁃ 「?」って何︖ ⁃
シンボルって何︖「:」 前につけたり後につけたり • テスト ⁃ テストを書いたことがなく、RSpec特有の書き⽅に慣れない ⁃ そもそもどこまで書けばよいのかわからず、チーム内で⼝論になる
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
3か⽉⽬(⼀旦プロジェクトの区切り) • 新しいエンジニアとコーチで⽅針が異なることがあり、チーム内が混乱 →話し合って認識合わせ • 新しいエンジニアが⼊ってきたことである程度軌道に乗ってくる • ただ⽬標としていた成果にはほど遠くという結果に、、、
総括 良かった点 • スクラム、Railsともに少しは慣れてきた (基盤の作成) 改善点・よくなかった点 • モノが予想より作れていない • 基礎ができていない
• Rails本来の開発に慣れていない • ある程度⽅針をはじめに決めておいたほうが 悩むことがなかった ふりかえり板書(⼀部)
次の3カ⽉に向けてのアクション • ⾃分たちの習熟がわかるスキルマップを作る • コードレビューで指摘を受けた内容やコードを書いていての気づきなどを 共有する場を毎⽇15分作る • ランチ時間に勉強する場を作る • Rails
Wayに合うようにテーブルの再設計
プロジェクト全般で使⽤するスキルマップ Railsのスキルマップ
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に合うように修正 変更前と変更後のテーブルの例
4カ⽉⽬〜現在 ものつくりに注⼒する期間
プロジェクトチーム Devチーム • ウフル社員4名(+2名) • お客様社員2名 • フリーエンジニア2名(+1名) • 全員Railsは初めて
PO • かなり忙しい • 元システム屋さん • ほぼ週2稼働 スクラムコーチ • コーチ業のスペシャリスト • Railsもスペシャリスト • ⾃分たちで考えさせるタイプ • 週2稼働 プロジェクトマネージャー • 基本的には放任主義 • 必要なときに⼈やスケジュールを調整 POとしての動き⽅をコーチング スクラムのコーチング Rubyも聞かれたら答える レビュー・仕様確認 Railsコーチ • フリーエンジニア • Railsスペシャリスト • 週2稼働 技術コーチング
総括 • 教育に時間を割いたことでかなり安定してくる • Rails Guideの読書会を開いて基礎の底上げ • フロント回りが弱かったため、デザイナー・フロントエンドエンジニアを追加 • localhostではなく、きちんとした開発環境を⽤意
(後ほど構成を紹介) • リファクタリングに精を⼊れる
開発環境 ブランチ運⽤やRails運⽤のお話
開発環境 バージョン • Ruby 2.4.3 • Rails 5.1.6 DB •
PostgresSQL 9.6 コードリポジトリ • Gitlab
インフラ構成図
ブランチ運⽤ ▪ブランチモデルと開発フロー ▪環境構築の⾃動化(マニュアル実⾏) ▪環境削除の⾃動化(マニュアル実⾏) ストップボタンを押すことで ⾃動で、Elastic Beasntalk環境 を 終了することができる。
Rails運⽤ • テンプレートエンジン → ERB • フロントライブラリ → JQuery •
認証・ログイン → Device • 認可 → Pundit • 定期ジョブ→whenever • テスト ⁃ 単体テスト → RSpec ⁃ EtoE → Cypress(まだまだ実運⽤できていませんが、、、) ⁃ フィクスチャ → factory_bot ⁃ フロント → Teaspoon(先⽉に導⼊)
個⼈的なふりかえり これやっててよかったとか、もう少しこうすればよかったとか 初⼼者の⽅に参考になれば
よかった点 • 開発したいものベースで進める ⁃ とりあえず開発したいものを開発してき、主要な機能を把握してから⽬次を埋めて いくと理解度が早く進んだ ⁃ 開発したいものが⾒つかっていない⼈はRailsチューとリアルなどおすすめ • 有識者にすぐ聞ける環境
⁃ もし近くに有識者がいなかったらコミュニティに参加する • 勉強会に参加 ⁃ コード共有会/ランチ勉強会/朝活/コミュニティなど ⁃ 気分転換やモチベーションにもなる
反省点 • 有識者が⼿本を⾒せる ⁃ ネットで調べてやってみても情報が古い/ベストプラクティスではなかったりする ⁃ ただし初⼼者も任せっきりはだめ、有識者が全部やるのもだめ、バランスが⼤切 • はじめに⽅針を固めておく ⁃
Rubocop/Editorconfigを導⼊ ⁃ コーディングの⽅針を作成 • Controllerは10⾏以内(各処理をModelに移⾏) • Modelは基本Modelディレクトリに⼊れる(直下は煩雑になる為フォルダにまとめる等する。 app/model/forms など...) • 共通化できる処理はクラス化していく • Publicには基本的には外部参照する画像やエラーページで参照する画像等しか置かない など
反省点(続き) • 勉強不⾜ ⁃ RailsはWebアプリケーションフレームワーク ⁃ そもそもフロントエンド/バックエンド/オブジェクト指向などWebアプリケーションを開 発する上で必要な知識が⾜りなかったりすると、会話にすらならないときがある ⁃ フルスペックになる必要はないが、せめて最低限の知識は付ける必要があると感じ
た ⁃ ①スキルマップを作成②AsIsとToBeの定義③優先順位をつけて勉強という順で ⾏っています ⁃ 書籍やQiitaなどもよいですが、軽めに動画サービスなどもおすすめ
最後に • 皆さん⼀緒にウフルで働きませんか︖ • ⼤阪フェスティバルタワー • Rubyのエンジニア絶賛探しています︕ フェスティバルタワー 開発定例会