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
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
gessy0129
February 28, 2024
Technology
56
1
Share
リポジトリリーディング手法
gessy0129
February 28, 2024
More Decks by gessy0129
See All by gessy0129
Takumiから考えるSecurity_Maturity_Model.pdf
gessy0129
1
190
Head of Engineeringが現場で回した生産性向上施策 2025→2026
gessy0129
0
260
プロダクト成長を支えるSRE 役割の変遷と今後の挑戦とは?
gessy0129
1
430
◯◯エンジニアになった理由
gessy0129
1
2.7k
30代エンジニアのキャリアを語る納涼LT!
gessy0129
1
63
Findy様戦略発表会登壇資料
gessy0129
1
55
急拡大組織のハードシングス〜100名組織〜
gessy0129
1
38
ANDPADの攻めと守り
gessy0129
1
67
急拡大してる組織が新卒採用やってみた
gessy0129
1
99
Other Decks in Technology
See All in Technology
AWSアップデートから考える継続的な運用改善
toru_kubota
2
300
CARTA HOLDINGS エンジニア向け 採用ピッチ資料 / CARTA-GUIDE-for-Engineers
carta_engineering
0
47k
おいらのAWSアップデートの追い方〜Slack×AgentCore〜
yakumo
1
110
マンション備え付けのネットワークとLTE回線を組み合わせた ネットワークの安定化の考案
harutiro
1
140
AI飲み会幹事エージェントを作っただけなのに
ykimi
0
230
2026-05-14 要件定義からソース管理まで!IBM Bob基礎ハンズオン
yutanonaka
0
170
Terragrunt x Snowflake + dbt で作るマルチテナントなデータ基盤構築プラットフォーム
gak_t12
0
430
React Compiler導入から21ヶ月、いま始めるならこうやる
astatsuya
2
250
パーソルキャリア IT/テクノロジー職向け 会社紹介資料|Company Introduction Deck
techtekt
PRO
0
220
インプロセスQAのための要因から捉えるプロジェクトリスクマネジメントnano #1 開発リソース効率状態への対処 #jasstnano
barus_qa
0
170
[みん強]AIの価値を最大化するデータ基盤戦略:Self-Service型Data Meshへの転換とAgentic AI Meshに向けた取り組み with Snowflake他
y_matsubara
1
130
Redmine次期バージョン7.0の注目新機能解説 — UI/UX強化と連携強化を中心に
vividtone
1
170
Featured
See All Featured
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
1.1k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
820
Design in an AI World
tapps
1
210
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
118
110k
Taking LLMs out of the black box: A practical guide to human-in-the-loop distillation
inesmontani
PRO
3
2.2k
Bash Introduction
62gerente
615
210k
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
Git: the NoSQL Database
bkeepers
PRO
432
67k
SEO for Brand Visibility & Recognition
aleyda
0
4.5k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.5k
Test your architecture with Archunit
thirion
1
2.2k
Transcript
技術支援に関わる上でリポジトリをど うリーディングしているかについて語 る(仮) 2024/02/22 gessy0129
Yoshiharu Geshi BIRTH: 1983/01/29 BEFORE:ANDPAD NICKNAME:gessy、げっしー LIKE:焼肉、温泉、ハンバーガー、日本酒、ビール OTHER:#墨田区 #浅草 #既婚
#息子 #小学生 #マンション住み #EX-CA #EX-ヤフー #EX-アンドパッド gessy0129
【PR】過去の登壇とか(はてブが励みです) https://www.wantedly.com/companies/forstartups/post_articles/419125 https://levtech.jp/media/article/column/detail_232/ https://logmi.jp/tech/articles/328464 https://flatt.tech/magazine/entry/20230615_andpad_interview https://andpad.connpass.com/event/243436/ https://note.com/ivs19/n/n3ec29dd72f95 https://aws.amazon.com/jp/blogs/startup/cto-night-and-day-2022-nagasaki-day2/ https://www.itmedia.co.jp/news/articles/2206/22/news058.html https://www.itmedia.co.jp/news/articles/2207/04/news030.html
アジェンダ Hackとは リポジトリリーディングについて
Hackとは?
ライフハック 2004年頃、プログラマーの間で広まった仕事術です。人に見せられないくらい簡単なスクリプト や習慣を1日に数回実行することで、 20分、30分と時間を節約し生産性を上げていきます。 元々は、『こんなやり方があったんだね』と驚いたり、『これはいいね』とニヤッとすることをハック と言うんですが、これを繰り返すことで大きな成果となり、人生が変わっていくということで、ライ フハックという言葉が生まれました。 (引用元:デジタル整理スタイル| ライフハッカー堀正岳さんの、小さな習慣で毎日の仕事が楽 になる情報整理術)
◯◯ハック 仕事の効率を高めて、人生を変えよう!
◯◯ハック 仕事の効率を高めて、人生を変えよう! 物事の効率を高めるためのコツ・ノウハウ ex : グロースハック この人はハッカーではなく、クラッカー
PR【synthesia】 冒頭の動画で使わせていただいたサービスです。 社内向け研修動画などがテキスト流し込むだけで作れるという Hackもついでにご紹介でした。
リポジトリリーディングHack
後から参画したPJのソースコードはどこから? Survey 1. ER図から? 2. API仕様書から? 3. config 系のファイルから? 4.
依存関係管理ファイルから? 5. その他? アンケート取ろうと思ったのですが、 会場が見えないので SKIPします
注意! これからお話するのは僕の手法です 絶対にこうすべきという話ではありません 自分だったらどうかな? を思い浮かべながら聞いて下さい
Hack 全てのコードを読もうと思わない 全体を俯瞰しながらポイントを見つける 役割を理解する
全てのコードを読まない 過去の自分の関わったプロジェクトなどを思い浮かべて欲しい 毎日、全てのコードに触ってましたか? いつも触るものって決まってませんでしたか? 全然触ってないものとかありませんでした? ER図も、API仕様書にも言えること 利用頻度や改修頻度が低いものまで熟読して理解する必要はない
全てを読もうと思うと圧倒される どこから手を付けて良いの? 周りのエンジニアなんで読めるの? 凄すぎでは・・・ 量が多すぎて何も理解できない
全体を俯瞰しながら見る 重要ポイントはどこになるのか? 重要ポイントを探す旅をする
重要ポイントを探す旅① CIの実行環境を見る このサービスで使う重要なソフトが全て書いてある
重要ポイントを探す旅② CIで動くJobを見ておく 開発するうえで気にしなければいけないことが載ってる
重要ポイントを探す旅③ CIで動くWorkflowsを見ておく Deployやブランチ運用が書いてあったりする
CI の設定は見れるようになっておこう 日常的に運用すること 開発時に気にしなければいけないこと デプロイ周り ほぼ全てがそこに詰まってる
CI が何も書いてなかったら?
ER図も見てみよう! ER図が生成されていたらラッキーぐらいの温度感でいよう 生成されてなかったとしても、 SchemaSpyとかで数分で作れるので嘆かない! ER図で見るべきポイントはここ
【再掲】全てを読もうと思うと圧倒される どこから手を付けて良いの? 周りのエンジニアなんで読めるの? 凄すぎでは・・・ 量が多すぎて何も理解できない
【再掲】全てを読もうと思うと圧倒される どこから手を付けて良いの? 周りのエンジニアなんで読めるの? 凄すぎでは・・・ 量が多すぎて何も理解できない 全てのテーブル名、カラム名が 表示されてないといけないのは幻想
ER図はここを見よう Relationshipの数が多ければ多いほど重要な情報 プロジェクトの中でどこに重要情報が保存されてるかを理解する
監視ツールを見に行こう
監視ツールで見ること 何をMonitorしてるの? Dashboardにはどんな情報があるのかな? Metricsはどんなものがあるかな? 過去の障害など経験が詰まっていて 気にしておくと安全に開発出来る!
エラートラッキングを見に行こう
ここまで見たらほぼ完璧 サービスの根本や各種ルールなどは一通り理解できてる状態だと思います。 後は、issue に沿って開発をしていきましょう! ドキュメント化されてなかったら あとから来る人のためにOutputとして ドキュメントを残しておきましょう!