DIP Advent Calendarの21日目です。
TL DR;
挫折せずにMarkdownを身につけられたのも or 読み書きできるようになったのも、
会社のGitリポジトリを壊していないのもTILのおかげ。
初心者こそTILをはじめよう。
はじめに
はじめまして、 rik.cacaoholicです。
文系新卒として今年ディップに入社し、現在phpで採用支援ツールの開発に携わっているエンジニアです。
入社当初は複数人で本格的な開発した経験はなく、
Markdownの書き方も、Githubの仕組みもわかりませんでした。
そんな今思うと危うく右も左もわからない状況から
- Githubの運用方法/注意点
- Markdownの書き方
を身に付けさせてくれた仕組みとして、
日報がTILで良かった！
と思ったことを開発初心者視点で共有させていただきます。
参考になれば幸いです。
TILとは
Today I learnedの略。
「今日、私が学んだ/知った」ことをmarkdownファイルに文章でまとめ、githubのレポジトリで管理していくこと。
TILのやり方
TILを日報にするには
TILのPull Request(PR)に日報を記載します。
新卒全員で以下のルールで運用していました。
運用の流れ
- 出勤したらmasterから
アカウント名/今日の日付のブランチを作成する。 - 業務中に
学んだこと、知ったことをMarkdownでまとめて、リポジトリに追加する。 - 退勤前にcommit/pushし、PRに日報を書く。
- 翌日出勤時に、他の新卒とお互いの日報PRをComment/Approveでフィードバックする。
- 最後にApproveした人がに過去の日報ブランチをMergeする。
- 各自でMergeしたブランチを削除する。
日報がTILのメリット
Google DriveやDocbaseで共有する日報でなく、
日報をGithubで共有し、Markdownで書くTIL形式だったお陰で
以下のメリットがありました。
Githubでやるメリット
- githubの使い方・運用の練習ができる
- github運用で注意すべき点を練習できる
- 作業ブランチの最新化
- PRのマージ先ブランチ、コードの差分確認
- 共同作業しているファイルのコンフリクトの解消
- 失敗しても実業務に影響が出ない
- 突然push, pullができないパニックになる
- 誤ってmasterブランチにマージしてしまった
- 間違ったリカバリー方法を実行してしまい、ファイルが消えた
- 定常作業の効率化を意識して行動できる
- PRのテンプレートを作成し、すぐに日報が書けるようにした
- .gitignoreで余分なファイルをcommitしないようにする
- どういうフィードバックをしたらいいか学べる
- チームのコミュニケーションの雰囲気がわかる
- 指摘/質問対応で何を明確にしたらいいかわかる
Markdownで書くメリット
- Markdownの書き方が身につく
- 毎日日報を書くので次第にMarkdown記法を覚える
- 内容がある程度決まったものを更新するので、成長がわかる
- テキストエディタを使いこなそうとする
- linterを入れて編集しやすくする工夫をする
TIL方式のメリット
- 振り返りやすい資料作り/管理の練習ができる
- PR=日報(１日の記録)、TIL=開発/業務知識で粒度を揃えた管理が便利なことに気づける
- フィードバックで他の人が読みやすい資料かわかる
- 記録しやすい資料作りを試行錯誤できる
- 自分にとってまとめやすい方法を試行錯誤できる
日報がTILだったから
実際に今開発をしていて、
「TILでやっててよかった！」
「TILでの失敗があるかもだから、開発では気をつけよう！」
という学びがあって、入社後まだ会社のGitリポジトリをまだ壊していません。
また、書く内容が決まっている日報からMarkdownで書くようになったので、
「１日の業務の流れはテーブルをつかう」
「順番がわかりやすいように目次をつける」
「項目の粒度がわかるように＃の個数を考える」
具体的な書き方のイメージがつきやすく、挫折せず毎日続けられ、Markdownを覚えることができました。
日報をTILにしよう！と考え、仕組み化した先輩方のおかげでGithubやMarkdownを挫折せずに習得できました。本当にありがとうございます。
最後に
開発初心者的に、
TILの日報なら、GithubとMarkdownを使うから、挫折せずに開発業務で即使える経験ができる！
と思っています。
ここまで、読んでいただきありがとうございました。