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
プロジェクトへ途中参加した際 早めにやっておくと良さそうな事
Search
hayashiyoshino
October 16, 2019
Programming
6
1.3k
プロジェクトへ途中参加した際 早めにやっておくと良さそうな事
hayashiyoshino
October 16, 2019
Tweet
Share
More Decks by hayashiyoshino
See All by hayashiyoshino
コードレビューで大事にしたいこと
hayashiyoshino
0
1.2k
How to be a better Rubyist
hayashiyoshino
0
2.4k
Other Decks in Programming
See All in Programming
Railsだからできる 例外業務に禍根を残さない 設定設計パターン
ei_ei_eiichi
0
310
CSC509 Lecture 03
javiergs
PRO
0
330
実践AIチャットボットUI実装入門
syumai
7
2.5k
monorepo の Go テストをはやくした〜い!~最小の依存解決への道のり~ / faster-testing-of-monorepos
convto
2
390
Pull-Requestの内容を1クリックで動作確認可能にするワークフロー
natmark
2
450
Let's Write a Train Tracking Algorithm
twocentstudios
0
230
Serena MCPのすすめ
wadakatu
4
900
dynamic!
moro
9
6.6k
ソフトウェア設計の実践的な考え方
masuda220
PRO
3
490
いま中途半端なSwift 6対応をするより、Default ActorやApproachable Concurrencyを有効にしてからでいいんじゃない?
yimajo
2
340
なぜGoのジェネリクスはこの形なのか? Featherweight Goが明かす設計の核心
ryotaros
7
1k
CSC305 Lecture 03
javiergs
PRO
0
230
Featured
See All Featured
Building Applications with DynamoDB
mza
96
6.6k
Making Projects Easy
brettharned
119
6.4k
How to train your dragon (web standard)
notwaldorf
96
6.3k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Speed Design
sergeychernyshev
32
1.1k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.2k
Why Our Code Smells
bkeepers
PRO
339
57k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
9
580
Site-Speed That Sticks
csswizardry
11
880
Context Engineering - Making Every Token Count
addyosmani
5
180
A designer walks into a library…
pauljervisheath
209
24k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
285
14k
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. 感想
感想 • 全て把握してからというのは厳しい(自分は出来てない)。 • 一般的に「こうあるべき」という事を知った上でそのプロジェクト のやり方を確認し、自分だけでなくレビュワーさんや周りの 方々にとってスムーズに開発進められることを目指したい。
ご静聴 ありがとうございました