読者です 読者をやめる 読者になる 読者になる

Nullyのぶろぐ

仙台で働くエンジニアの日記

JaSST' 15 Tohokuに参加してきました。

JaSSTとは

「Japan Symposium on Software Testing」の略称で、ソフトウェアのテストってどうやってるの?とか、こうやって解決しているよ!という学びを得られるシンポジウム。

その東北版としてJaSST'15 Tohokuが5月29日に開催されたので行ってきました!!

ことの発端

前々から「JaSST' 15を東北版でやっているから参加してみない?」と話を頂いており、「ソフトウェアのテストだけども、テストについて多少なりとも概念だったり、Web以外の業界ではどういう形でテストしているのか?」を知りたかったので参加する予定で居た。

けれど、とある日に社内の人間から「実行委員長からコードレビューされてみないって話があるけどどう?」と開催の1週間前にお話を頂き、「ソニックガーデンの方たちにライブレビューしていただける機会なんてめったに無いじゃん!!!!」ってことで、書いたコードをその場でレビューしていただけるライブレビューされる側の人間として参加してきました。

セッションの内容

セッションの内容は多分きっと他の自分よりレポーティング能力の高い方が出してくれるはずということで、コードレビューをしていただいたソニックガーデンさんのパートの話をざくっと書きます。

  1. 開発体制(月額定額制とか)
  2. 納品をなくした理由
  3. お客さんにとって嬉しいこと(要件定義なくていいとか)
  4. 開発プロセスについて(作らなくていいものは作らないようにするとか、コードレビューについて)

などなど。

特にその中で一番クリティカルにおもえたのが、4番の「開発プロセスについて」であった「スピード感を持って開発する」パート。

今まで自分の中で持っていた、もしくは世の中に出ている情報から自分なりの解釈で見ているものだと「開発速度(手を動かす早さ)を上げる」視点だったけど、いつでも改善できる状態、つまりメンテナブルなコードを書くことこそが「開発速度を上げる」ことなんだなと痛感。

手を動かすのが早いだけだったら「だはkん。、んs→jfはlくぃえfjな、mんさfはおfかえf」って打ってるだけでも早いしね。w

それともう一つあって、「コードレビューする人間」について面白いなぁと思った。

何が面白かったかというとちゃんと教育するための弟子入り制度があって「一人前」と「弟子」の関係がはっきりしていること。

また、「一人前」として働く人達にはきっちり「社内の共通認識」が刷り込まれていて、弟子にきちんと落とされるフローを確立しているのがおもしろいなぁと思った。

実際にレビューしていただいたもの

実際にソニックガーデンの西見さんにレビューしていただいたコードがこちら。

github.com

レビューしていただいたあとに手直しした後のモノ(tag切り忘れてた)ですが、概ねこのまま出してレビューしてもらいました。

実際にレビューしてもらった時点のフィードバックを列挙すると

  • Rubyらしく書くならスネークケースで。ただ、社内の開発ルールが確立されていて、それが正ならばそれに乗っ取るのがベスト
  • フォーマットするためのメソッドをクラスに設けてそっちにフォーマッティングを任せましょう。(変化に強くするため)
  • 「keys.include?(money)」と書かれている箇所などの意図が伝わらないので、メソッド建てて、該当のソースを見なくても意図が伝わるようにしましょう。
  • 書き方はきちんと統一しましょう。(ifやunlessを続々書いてスパゲッティにならないように)

です。

最後に「許可されたお金やチケットなどはどうしてクラス分けしなかったのですか?」とい質問を受け「1ファイルのほうが西見さんに見てもらいやすいかなと思いまして!(キリッ)」と言ったら

「その観点はアウトwww」 と会場を沸かせることができたので良しとします。w

ここで答えるとしたら「YAGNIであるため、今はまだそこまですべきではないと思い、1ファイルのコードとしました」という考えならOK!とアドバイス頂きました。

YAGNI:You ain't gonna need it の略でXPで定義された原則。「実際に必要になるまで追加しないほうが良い」ということ。

レビュー時の観点はソニックガーデンさんで定義しているコードレビューの7つの秘訣というのがあり、それに則りレビューしていただきました。

  • レビューの観点を明確にする
  • 我が身に帰ることを恐れずに指摘すること(自分もやることだけど、相手にも指摘してあげる)
  • なぜ悪いコードなのかを論理的に説明すること
  • いいコードに付いて共通認識を持つこと
  • 小さい単位でレビューを繰り返す
  • 指摘や素直な気持ちで受け入れること
  • 指摘は人格否定で無いことを理解すること

その中で今回実践すべきだなと思ったのは「いいコードに付いて共通認識を持つこと」。

良いコードって人によって違うし、場合によっては「後置if最強伝説wwwww」とかなって全部後ろにif付けられてもたまったもんじゃない。w

質疑応答

ここまで色々話を聞かせていただいた中で「新人や中途を一人前にするまではどうやって教育するのか?」「レビューは遠隔地でどうやっているのか?」と質問した。

新人や中途を一人前にするまではどうやって教育するのか?

原則的にコードレビューで育てます。

また、働き方については個別にKPTを設け、そこでソニックガーデン式ツメツメしていきます。 KPT時はKとPを対象者にあげてもらい、Tを一緒に決めて、また来週、を繰り返します。

例:

 Aさん:リファクタリングが必要なのでリファクタしたいです

 Bさん:リファクタするってことはつまりそれ仕事終わってないってことなので、リファクタする必要がなくなるコードを書くようにしましょう。

_レビューは遠隔地でどうやっているのか?

基本はチャットツールGithubをもちいてレビューしてます。

ただ、レビュワーの意図が文字だけでは伝わらない場合はTV会議などを使ってFaceToFaceでやりとりします。

情報交換会

情報交換会ではソニックガーデンさんの「レビューのやり方」の詳細を聞けたり、倉貫さんが日々行っているラジオの話が聞けた。

コードレビューのやり方

レビューする前に確認しておくことはすべてつぶし、PR上で仕様の詰めや確認は極力避ける。

問題は後で解決するのではなく先に解決する。

ワークレビュー

さっきの「働き方について」の詳細を質問したら、その中で一番刺さったのが「リファクタが発生するようなコードを書いているということはつまり、仕事が終了していないと同義。リファクタをするってことはメンテナブルなコードではないということだし。」がとても刺さった。

今まで捉えていた「リファクタ」は性能をより向上させるための改修手段として捉えていたが、そもそもプロジェクトが終了していない状態でリファクタが発生するということは、問題を抱えたままリリースしようとしていることと変わらない と感じた。

チャットの悪いところ

リモートワークが多いので、顔が見えない。

そのため、チャット上で「居ますか?」「はい、居ます」のやりとりって結構手間。

なのでremottyを使って、相手の顔が常に見える形式をとって連絡しています。

1分おきに更新されて、いちいちチャットで存在確認をする必要がない。

MVPの定義

ビジネスが1週するものをMVPとして定義している。

ビジネスが1週とは「想定しているスタートからエンドまで通してワークすること、つまりビジネス成果が生まれる状態」のこと。

JaSST'15 Tohokuに参加して

今回はじめてJaSST'15 Tohokuに参加したわけですが、こんなにクリティカルな情報が得られるシンポジウムは滅多にないなと感じました。

前半にスピーチしていただいた安達さんの「現在のレビューに必要な次の一手を把握するレビュー〜実践ウォークスルー〜」に出てきた手法の話も全然知らなかった領域の話で「こんなやりかたあるの!?」と度肝抜かれたり、「ShiftさんのChibinekoを使っている僕はKyojinです」とか「テストツールをJIRAにも連携できます」って話も、ここでしか聞けない話が多く、来年開催されるならまた参加したいと思います。

開発することも楽しいけど、テストをパスすることの楽しみってのもまた違った楽しみがあるなと感じました。

また、今回参加したことで実践できそうなものも3つほどあったので、早速実践していきたいと思います。

最後に

JaSST実行委員会の皆さん、お疲れ様でした!

また、ソニックガーデンの西見さん、今回はレビューして頂きありがとうございました!

f:id:nully:20150529174303j:plain

おすすめの本

「納品」をなくせばうまくいく ソフトウェア業界の“常識

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

システムテスト自動化 標準ガイド CodeZine BOOKS

システムテスト自動化 標準ガイド CodeZine BOOKS

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)