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.2k
プロジェクトへ途中参加した際 早めにやっておくと良さそうな事
hayashiyoshino
October 16, 2019
Tweet
Share
More Decks by hayashiyoshino
See All by hayashiyoshino
コードレビューで大事にしたいこと
hayashiyoshino
0
910
How to be a better Rubyist
hayashiyoshino
0
2.3k
Other Decks in Programming
See All in Programming
MCP with Cloudflare Workers
yusukebe
2
270
週次リリースを実現するための グローバルアプリ開発
tera_ny
1
770
Beyond ORM
77web
11
1.5k
サーバーゆる勉強会 DBMS の仕組み編
kj455
1
200
PSR-15 はあなたのための ものではない? - phpcon2024
myamagishi
0
360
ドメインイベント増えすぎ問題
h0r15h0
2
540
Zoneless Testing
rainerhahnekamp
0
150
為你自己學 Python
eddie
0
500
EC2からECSへ 念願のコンテナ移行と巨大レガシーPHPアプリケーションの再構築
sumiyae
3
550
情報漏洩させないための設計
kubotak
5
1.2k
開発者とQAの越境で自動テストが増える開発プロセスを実現する
92thunder
1
220
AppRouterを用いた大規模サービス開発におけるディレクトリ構成の変遷と問題点
eiganken
1
410
Featured
See All Featured
GraphQLとの向き合い方2022年版
quramy
44
13k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.4k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Docker and Python
trallard
43
3.2k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
Music & Morning Musume
bryan
46
6.3k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.2k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
A designer walks into a library…
pauljervisheath
205
24k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.1k
How STYLIGHT went responsive
nonsquared
96
5.3k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
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. 感想
感想 • 全て把握してからというのは厳しい(自分は出来てない)。 • 一般的に「こうあるべき」という事を知った上でそのプロジェクト のやり方を確認し、自分だけでなくレビュワーさんや周りの 方々にとってスムーズに開発進められることを目指したい。
ご静聴 ありがとうございました