よちよち.rb 第23回 #yochiyochirb

第23回は、銀座のbeezさんでした。

概要

自己紹介(何か一言でつらい報告が多かった…)
Railsチュートリアル(リスト3.1より)

GitHubのIssueでグループワークの記録をとった

前回まで、グループワークの中であがったこと(疑問質問便利情報などなんでも)を
IdobataのRailsルームで発言して、
共有タイムでそれを発表するというかたちをとっていたんだけど、
そこであがってくることが「流れて」しまっていて、
もったいないな〜というのもあるし、
けっこうあとで追うのがむずかしいなと思っていました。

そこでゆかおさんが、GitHubのIssueを利用して、
グループごとにIssueをたてて、そこでコメントしていこうと発案されました。
なんて素晴らしいアイデア!!!!!!!ネ申!!!!!!!!!!!!!!!

ということで、今回からトライ。

グループごとにまとまっているので、
後から読み返ししやすくて、すごくいいなと思いました。

コメントするとIdobataに通知が飛ぶので、
Idobataを見ていれば他のグループの様子もわかるし。


ちょっと気になったのは、この調子で毎回Issueがたつと、
他のIssueとごっちゃにならないかな?
グループワーク用のリポジトリをたてたほうがいいのかな?

あと、いつクローズするのか?


赤から緑になると「よし!」ってアガる

チュートリアルは、いよいよはじめてのテストを実行しました。

チュートリアルのとおりに、テスト書いて、赤い結果が出るのを確認して、
実装して、もう一度テストをすると通って緑になる!!

この緑の結果をみると、わーい!やった!よし!!となるね、と話しました。

今回はまだ小さい小さいテストですが、
これが新しい機能の実装とかになってくると、うれしいだろうなぁ。


どうして先にテストを書くのか?

グループワークをしながらあがった言葉。
先に実装してからきちんと動いているのを確認することも、もちろんできるけれど、
それって「バグを探すためにゲームをプレイする」みたいになって、効率悪い。

実装する機能がとおるテストを書いて、
まずはそのテストが通るコードを書く!
そしてテストが通ることを確認したら、リファクタリングすると
きれいなコードができあがる、とのことでした。

その、テストが通った後にリファクタリングして、ていうのがちょっと「?」となって。
リファクタリングしたら壊れちゃってテスト通らなくなっちゃったってことはないの?と思ったんだけど、
たまにあるみたいで、そしたらまたテスト通るように直すわけですよね。
なんかそこのフローがちょっとピンとこなかった。

もうちょっといろいろ体験してみたいです。


次回はデイタイムで、TDDをお勉強予定なので、そこでまたクリアになるのかも!?

次回

6/21(土)のデイタイムよちよち.rbです!
TDDです!