株式会社クリアコード > ククログ

ククログ

«reportbugを使ってバグ報告をしてみよう 最新 Mewで色付きでコミットメールを表示する方法»
タグ:

「リーダブルコード」に関する有料ワークショップ「実践リーダブルコード」を開催

2015年3月6日にアジャイルアカデミーの1講座として実践リーダブルコードという「リーダブルコード」に関する有料ワークショップを開催しました。

クリアコードでは去年からリーダブルコードに関する講師をいくつかやっていますが、それぞれ目的が違います。具体的には次のようになっています。

  • schoo:初心者向け。「こんなコードがリーダブルコードですよ」と紹介することが目的。本の内容がベース。
  • SEゼミ:学生向け。「参加者自身」がリーダブルコードを書けるようになることが目的。本の本文の内容は使わない。解説の一部を体験。
  • アジャイルアカデミー:現場向け。「参加者のチーム」がリーダブルコードが当たり前となることを支援することが目的。本の本文の内容は使わない。解説の一部の体験と現場に導入するときの障害を乗り越える方法のアドバイス。

今のところ、アジャイルアカデミーが一番高度な内容で「チーム」を対象にしています。

内容

リーダブルコードの解説では自然にリーダブルコードを書けるようになるための3つのステップを紹介しています。

  1. 実際にやる
  2. 当たり前にする
  3. コードで伝える

アジャイルアカデミーでのワークショップは「実際にやる」と「当たり前にする」の入り口あたりまでをカバーします。「コードで伝える」はさらにその次のステップとして紹介するにとどめています。

このワークショップでは、参加者にとって今までの考え方とはかなり違う考え方を伝えます。例えば次のような考え方です。

  • リーダブルの基準はチームごとに違う。基準はコーディング規約などの形で押し付けたり押し付けられたりするものではなくチームごとに育てていくものである。
  • リーダブルコードを書くためには「書き方を覚える」のではなく「コードを読もう」。ただし、コードレビューのように「間違いを見逃さないため」ではなく、「リーダブルなコードを探すため」に読もう。

参加者は「現状はリーダブルコードではない」という課題を持っていました。その課題を解決するために、「コーディング規約を作って守らせる」や「コードレビューで問題を指摘する」という方法を実施したり検討したりしているとのことです。

それらの方法と今回のワークショップで伝えた考え方はかなり違います。

コーディング規約のアプローチは作ることも大変ですし、守ってもらうことも大変だそうです。守られないことも多いそうです。

コードレビューのアプローチもコーディング規約と同じ方向の考え方かもしれません。コーディング規約は「規約を作った人たちが考えるよい書き方に書き方を制限する」という考え方ですが、コードレビューのアプローチも「レビューアーが考えるよい書き方」に制限することで品質をあげる、という考え方なのかもしれません*1

今回のワークショップで伝えた考え方は、制限するのではなく「チームでのよい」は「チームで作る」という方向です。「悪いところを指摘してチームの悪いを減らす」のではなく、「チームのよいを共有してチームのよいを育てる」。制限する方向でやってきた人は「そんなのがうまくいくはずはない」と感じるかもしれませんが、参加者は「そんな考え方があったのか」と言いながらも考え方の違いを理解しようとしてくれました。ありがたいことです。

なお、今回のワークショップで伝えた考え方は、フリーソフトウェアの開発の世界では特別なことではなく、当たり前のことです。しかし、現場では特別なことのようです。

課題

今回のワークショップの課題は、会社に戻ってからワークショップで学んだことをどう展開すればよいかの支援が弱かったことです。自分はやりたいと思うが上司を説得するのは難しそう、というケースをうまく支援しきれませんでした。

上司の説得に関しては参加者のみなさんの方が経験が多そうなので、参加者と講師を含めてうまいやり方や考え方を共有する時間を作るとよいかもしれません。

次回試してみたいことです。

まとめ

アジャイルアカデミーの1講座として実践リーダブルコードという「リーダブルコード」に関する有料ワークショップを開催したので、その内容と課題を紹介しました。ワークショップの内容はGitHubで公開しています。ワークショップ内で使ったスライドも公開しています。興味のある人はシナリオからリンクを張っているので辿ってください。

最後にワークショップの資料を作りながら思いついた標語を紹介します。

「読む人」が
読みやすいなら
リーダブル

チームで開発していて、たとえ一般的にはリーダブルコードだったとしても、チームの他のメンバーが読みやすくなかったらそれは「チームにとっては」リーダブルではありません。もしかしたらそのリーダブルコードは「自己満足なリーダブルコード」なのかもしれません。「誰のためのリーダブルコードなのか」考えてみてください。

*1 こういう書き方をするとコードレビューはいらないの?と感じるかもしれませんが、「間違いを見逃さない」というフェーズが必要ならやるとよいです。コードレビューをするなら「リーダブルなコードを探すために読む」ことはしなくてよい(あるいはその逆)、というものではなく、目的が違う独立したことなので必要なら両方やればよいです。両方やる場合は相互によい影響がでることもあります。例えば、コードレビューで指摘しなければいけないことが少なくなるということがあります。

2015-03-09

«reportbugを使ってバグ報告をしてみよう 最新 Mewで色付きでコミットメールを表示する方法»
2008|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|
タグ:
RubyKaigi 2015 sponsor RubyKaigi 2015 speaker RubyKaigi 2015 committer RubyKaigi 2014 official-sponsor RubyKaigi 2014 speaker RubyKaigi 2014 committer RubyKaigi 2013 OfficialSponsor RubyKaigi 2013 Speaker RubyKaigi 2013 Committer SapporoRubyKaigi 2012 OfficialSponsor SapporoRubyKaigi 2012 Speaker RubyKaigi2010 Sponsor RubyKaigi2010 Speaker RubyKaigi2010 Committer badge_speaker.gif RubyKaigi2010 Sponsor RubyKaigi2010 Speaker RubyKaigi2010 Committer
SapporoRubyKaigi02Sponsor
SapporoRubyKaigi02Speaker
RubyKaigi2009Sponsor
RubyKaigi2009Speaker
RubyKaigi2008Speaker