$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
プロジェクトへ途中参加した際 早めにやっておくと良さそうな事
Search
hayashiyoshino
October 16, 2019
Programming
6
1.4k
プロジェクトへ途中参加した際 早めにやっておくと良さそうな事
hayashiyoshino
October 16, 2019
Tweet
Share
More Decks by hayashiyoshino
See All by hayashiyoshino
コードレビューで大事にしたいこと
hayashiyoshino
0
1.3k
How to be a better Rubyist
hayashiyoshino
0
2.4k
Other Decks in Programming
See All in Programming
Atomics APIを知る / Understanding Atomics API
ssssota
1
230
Microservices Platforms: When Team Topologies Meets Microservices Patterns
cer
PRO
1
670
AI時代もSEOを頑張っている話
shirahama_x
0
190
「文字列→日付」の落とし穴 〜Ruby Date.parseの意外な挙動〜
sg4k0
0
320
20251127_ぼっちのための懇親会対策会議
kokamoto01_metaps
2
230
乱雑なコードの整理から学ぶ設計の初歩
masuda220
PRO
32
15k
分散DBって何者なんだ... Spannerから学ぶRDBとの違い
iwashi623
0
140
開発15年のAIネイティブでない 巨大サービスのAI最適化
rapicro
0
110
最新のDirectX12で使えるレイトレ周りの機能追加について
projectasura
0
310
UIデザインに役立つ 2025年の最新CSS / The Latest CSS for UI Design 2025
clockmaker
2
850
モビリティSaaSにおけるデータ利活用の発展
nealle
1
670
WebRTC と Rust と8K 60fps
tnoho
2
980
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
80
6.1k
Practical Orchestrator
shlominoach
190
11k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
The Cult of Friendly URLs
andyhume
79
6.7k
Speed Design
sergeychernyshev
33
1.3k
Writing Fast Ruby
sferik
630
62k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Bash Introduction
62gerente
615
210k
How STYLIGHT went responsive
nonsquared
100
5.9k
Thoughts on Productivity
jonyablonski
73
4.9k
Agile that works and the tools we love
rasmusluckow
331
21k
Side Projects
sachag
455
43k
Transcript
プロジェクトへ途中参加した際 早めにやっておくと良さそうな事 2019/10/16 Ebisu.rb#25 林佳志乃
自己紹介 名前:林 佳志乃 良く行くコミュニティ:Tama.rb 所属:エーテンラボ株式会社 作ってるサービス:みんチャレ 新しい習慣を身につけたい人が5人でチームを組 み、チャットで励まし合いながらチャレンジする、三 日坊主防止アプリです。
目次 1. なぜこのテーマにしたか 2. 確認しておくべき事柄 3. まとめ 4. 感想
目次 1. なぜこのテーマにしたか 2. 確認しておくべき事柄 3. まとめ 4. 感想
なぜこのテーマにしたか 10月から新しいプロジェクトへ途中参加。 「早めにxxしておいたほうがよかったかも!」という気づきがあった ので忘れないうちにまとめておきたいと思った。 ※ 正解か自信ない & 完全にできている訳ではない & 皆様にとっ
て当たり前のことかもしれないのでツッコミやご意見お待ちしてま す!!
目次 1. なぜこのテーマにしたか 2. 確認しておくべき事柄 3. まとめ 4. 感想
情報がどのツールにまとまっているか把握する • 最初にどの情報がどのツールにまとまっているか知っておくと 調べごとしやすい。 ◦ 例:ドキュメントはesaで、実装するタスクの詳細はGithub 上で、画像などの素材は、、、など ◦ どこかに「入社したらこれしてね」というドキュメントがある ならそのページ&リンク先をしっかり読む。
プロジェクトの流れの大枠を掴む • どのくらいのスパンで事業やプロジェクトの計画を立てている のか、もう少し細かい単位での進捗の確認はどのように行なっ ているのか等把握する。 ◦ 例:3ヶ月ごとに大きい目標&指標を決め、進捗確認や振り 返りは1週間ごと行なっているなど。 • 今開発中の機能は何のためなのか等、ビジネス的な部分の
理解がしやすくなり優先順位の判断もしやすくなる。
関係者を把握する • 社内の人&社外の人について、それぞれの人がどんな立場で 関わっているのか把握する。 ◦ プロダクト作る際や、関係者とコミュニケーションとっていく 上で関係者を把握しておく必要がある。 ◦ 早い段階で理解しておく方がいい。
システムの全体像を把握する • プロダクトがどんな環境で何を使用して動いているのか知って おくと良い。 ◦ 右のような図。 • よくわからない サービスがあったら 概要調べる。
実際に動いているシステムを触る • 動いているサービスを実際に使ってみる。 ◦ システムの動きがわかる。 ◦ ユーザー目線に立てるという意味でも実際に動かして使い 込んでみるのは良い。
使用している技術を把握する • フレームワークやライブラリについて何を使っているか一通り 確認。 ◦ Gemfile一通り確認。 • 知らないものがあったら概要調べる。
環境構築済ませる • 以下のことを済ませておくとタスク割り振ってもらった時スムー ズに進められる。 ◦ ローカルで動かせるようにする。 ◦ 初期データ入れる。 ◦ テスト流してみる。
本番反映までの流れを把握する • gitフローやgithubフローを知っておいた上で、プロジェクトのや り方を知っておく。 ◦ 完成前からリモートに上げておいたほうがいいのか。 ◦ x 人以上のレビューOK出たらデフォルトブランチへマージ するのか。
◦ develop, staging, masterなど各環境の位置付け。 ◦ master反映は基本的にいつ行うか(行わないか)。
名前の付け方を確認する • ブランチ名、プルリク名、コミット名、メソッド名、変数名など。 • 一般的に良いとされる命名方法(リーダブルコードで書かれて いるような)を知った上で、そのプロジェクトでのやり方を把握 する。 ◦ ドキュメントや他の人のやり方をいくつか見て真似る。
コミット粒度を確認する • プルリク出す段階でコミットはどのくらい綺麗にまとめてあるか ◦ 他の人のやり方を参考にするのが良さそう。 ◦ レビュアーさんがコミット単位でみてくれるなら紛らわしいコ ミット残しておくのは良くない。 ◦ かといってコミットが大きすぎても良くない。
調査の仕方を確認する • 何か問題がおきたとき、ログの確認をどのように行なっている か。 ◦ システムの全体像を把握しておくと「このサービス使ってロ グ見れる」というのも気づきやすい。 ◦ 先輩に聞くと効率良いやり方を早く知れそう。
目次 1. なぜこのテーマにしたか 2. 確認しておくべき事柄 3. まとめ 4. 感想
まとめ プロジェクトへ途中参加した際早めにやっておくと良さそうな事に ついて。 • 情報がどのツールにまとまっているか把握する • プロジェクトの流れの大枠を掴む • 関係者を把握する •
システムの全体像を把握する • 実際に動いているシステムを触る
まとめ • 使用している技術を把握する • 環境構築済ませる • 本番反映までの流れを把握する • 名前の付け方を確認する •
コミット粒度を確認する • 調査の仕方を確認する
目次 1. なぜこのテーマにしたか 2. 確認しておくべき事柄 3. まとめ 4. 感想
感想 • 全て把握してからというのは厳しい(自分は出来てない)。 • 一般的に「こうあるべき」という事を知った上でそのプロジェクト のやり方を確認し、自分だけでなくレビュワーさんや周りの 方々にとってスムーズに開発進められることを目指したい。
ご静聴 ありがとうございました