この講座の目的は、書籍「リーダブルコード」の解説を読んでチームでリーダブルコードを実践したいけどできていないプログラマーが、「自分の開発チームにリーダブルなコードが当たり前な文化の作り方を持ち帰る」ことです。
- 10：00〜 アイスブレイク
- （いつも通りコードを書ける状態にするためにちょっと手を動かす。）
- 10：15〜 イントロダクション（講義）
- （どうしてリーダブルコードが必要なのか、リーダブルコードを当たり前にするためにはどうしらよいか、そのためにこの講座では何をするかについて説明する。）
- 10：45〜 課題を実装
- （各自課題を実装する。このとき、今の自分で精一杯のリーダブルコードで書くこと。）
- 12：15〜 昼食
- （講師も交えながら昼食をとる。午前中やってみて感じたことなどを講師に相談したり、参加者同士で共有する。）
- 13：15〜 午前中に参加者が書いたコードをの中から講師がリーダブルコードを紹介
- （講師が実際のコードの中から「リーダブルコードを見つけること」の実例を示す。）
- 13：30〜 コードを交換して引き続き課題を実装
- （午前中に実装したコードを他の参加者が実装したコードと交換する。午後は、交換したコードをベースに開発を継続する。他の参加者が書いたコードから「リーダブルコードを見つけながら」開発を進める。）
- 14：45〜 休憩
- 15：00〜 各自自分が見つけたリーダブルコードをグループ内で紹介
- （グループを作り、グループ内で自分が見つけたリーダブルコードを紹介する。実際のコードの中から「リーダブルコードを見つけること」を実践する。）
- 15：30〜 グループで共有したリーダブルコードを全体にも共有
- （グループ毎のリーダブルの基準を全体に共有する。「リーダブルの基準を共有」を実践する。）
- 16：00〜 まとめとこれからやるべきこと（講義）
- （この講座でやったことを再確認し、「リーダブルコードを見つけること」ができるようになった後にやることを説明する。）
- 16：30〜 質疑応答
- （講座中で疑問に感じたこと、これからどのように行動していけばよいかといったことに回答する。）
- 17:30- コードの感想戦
- （時間があれば、講師が参加者の重ねたコミットを順に読みながらコメントする。講師のコードの読み方やリーダブルなコードの見つけ方の参考にしてもらう。）
いつも通りコードを書ける状態になること。
- 参加者がリラックスすること
- 同じグループの人たちがなじむこと
- 講座の会場でいつも通りGit・GitHubが使えることを確認すること
- 問題があったらこの時点で解決しておきたい
- 声をだすこと
icebreaker/以下にあるスライドを参照。
- 自分のGitHubアカウントで 「${自分のアカウント名}-readable-code」 というリポジトリーを作る。
- 「README.md」を作り、そこに開発言語を書いてcommit & pushする。
- プログラムを書く時に使うテキストエディターやIDEを使うこと。
- pushしたら手を上げてチューターに自分のリポジトリーを確認してもらう。
- 「${自分のアカウント名}.md」を作って、簡単に自己紹介文を書いて
commit & pushする。
- プログラムを書く時に使うテキストエディターやIDEを使うこと。
- 誰でも見れる状態になるので、公開情報だけ書くように注意喚起すること。
- pushしたら手を上げてチューターに自分のリポジトリーを確認してもらう。
- #1 に
自分のリポジトリーのURLをコメントする。
- コメントしたら手を上げてチューターに自分のリポジトリーを確認してもらう。
- チューターは参加者と話をしよう。（うまくできましたか？いつも通りコードを書けそうですか？）
- 参加者に声をだしてもらうため。
- 参加者が質問しやすくするため。
- 講座の目的を共有
- 目的を実現するためにやること・やらないことを共有
introduction/以下にあるスライドを参照。
- 午後の作業の布石
- 課題の仕様を理解するため
- 読まれることを意識して書かれたコードを用意するため
- いつもより意識してリーダブルなコードを書く
- 自分が工夫した点をメモに残す
- 各自、課題を確認する
- 仕様1を実装したらチューターに確認を依頼する
- チューターが仕様1の完了を確認したら仕様2の実装へ進む
- 仕様2以降は随時確認してもらう必要はない
- 参加者は気になったこと、わからないことを随時質問してよい
- チューターは、参加者の様子に気を配り、困っていそうなら声をかける
- 講師は、随時、自分がリーダブルコードを書くために工夫した点をメモに残すことを促す
- メモの残し方はスライドにして常に表示しておく。こうすることで参加者はいつでも参照できる。
implementation/以下にあるスライドを参照。
- 空腹を満たす
- 午前中に感じたことを共有する
- ご飯を食べる
- 講師・チューターも一緒にご飯を食べる
- 午前中の感想を聞いてみる
- 疑問点があるなら回答する
- 参加者が「リーダブルコードを見つける」ときの実例を提供する
- 参加者が「リーダブルコードを紹介する」ときの実例を提供する
- 講師は午前中に参加者が書いたコードを確認し、リーダブルコードを発見する
- 講師は発見したリーダブルコードの書き方に名前をつけて紹介する
- リーダブルなコードを探す
- リーダブルかどうかの基準は読む人。「読む人」が読みやすいならリーダブル。
- 参加者が「リーダブルコード」を見つけること。
- 後でまとめるので、「リーダブルコード」と判断した理由や、どのようにして「リーダブルコード」を見つけたか（どうやって気付いたか）もメモしておく。
- 見つけた「リーダブルコード」をその後の開発に役立てること。
- 「リーダブルじゃないコード」ばかりに目がいかないようにする。
- 他の人が見つけていない凝ったコードを見つけるのは目的ではない！単純なコードでもリーダブルなコードを見つけること。
code-change/以下にあるスライドを参照。
- グループの誰かのリポジトリーをforkする。
- 誰のリポジトリーをforkするかはチューターから指示がある
- forkしたリポジトリーがやっていたところから課題を再開する
- コミットログなどを参考にする
- 午前中と同じ仕様を実装することになるかもしれないけど、OK
- ベースが違うので違う実装が適しているかもしれない
- よいコードを見つけたら「memo.md」にどうしてそのコードがよかったかをメモしていく。
- 前の人が作った「memo.md」があればそこに追記。なければ新しく作る。
- ヒント: メモは後で他の人にどうしてそのコードがよいのかを説明するために使うので、次の情報も含めること。
- 対象のコードへの参照（GitHubは特定のリビジョンのコードに対するURLがある。）
- どうしてそのコードがよいと思ったか
- そのコードがよいと気づいたきっかけ
- チューターは、参加者が「リーダブルじゃないコード」ばかりに目がいってしまって「リーダブルコード」を見つけることができないときは、「リーダブルコード」を見つけるこつを教えてあげること。
- リーダブルの基準を共有する
- 参加者が自分が見つけた「リーダブルコード」を整理して他の人に説明する。
- グループ内でリーダブルの基準を作る。
- 複数の人が「それは自分もリーダブルだと思う」となるなら、それはそのグループにとってリーダブル。
retrospective/以下にあるスライドを参照。
- グループ毎に、参加者はそれぞれリーダブルコードとその理由を他の参加者に共有する
- チューターはグループが悪いコード自慢に終始しないようにいい感じに誘導する
- 共有したリーダブルコードを発表できるようにまとめる
- スライドは用意しないで、メモを用意する（メモはGitHubにpushする）
- だれか1人を選んでグループ用のメモをまとめるリポジトリーにする
- そのリポジトリーに「group-memo.md」を作って、そこにグループで共有したメモをまとめる
- 発表では実際のコードとメモを使いながら説明。
- 発表時にコードをプロジェクターに映す人を1人決めること。
- 進め方:
- 15:10-15:30: 3-6人のサブグループにわかれて時計回りで自分が見つけたリーダブルコードを他の人に説明する。このとき自分のノートパソコンの画面にコードをうつして、それを他の人に見せながら説明すること。
- 15:30-15:50: グループ毎に全体に自分たちが見つけたリーダブルコードを紹介する。気になったことがあったら随時質問する。
- 講座でやったことの復習
- 参加者が講座で学んだことを日々の開発に取り入れるために明日から何をすればよいかがわかる
conclusion/以下にあるスライドを参照。
- 講座での疑問を解消する
- 学んだことを日々の開発に取り入れる障害を取り除く
- 質疑応答を受け付ける
- 参加者から質問がでない場合は順番に感想を聞く
時間があれば。
- 講師のコードの読み方やリーダブルなコードの見つけ方の参考にしてもらう。
- 講師が参加者の重ねたコミットを順に読みながらコメントする。