Tatsuya Sato

Passionate Programmer / Father for two kids / MOSH’SH MATE

自動車業界の中でも有名なデンソーさんが、新横浜に独立した内製の開発組織を作っていて、その部署とクリエーションラインさんの共催イベントの第一回目に行ってきました。 Attractor社の吉羽さんがコーチに入っているという話を以前に伺っていて、昨年のデブサミでも講演していたり、大企業の中でアジャイル開発の導入を取り組んでいることは知っていました。 このイベントでは、1年半前のオフィス立ち上げから携わっているエンジニアの方々の話を聞くことができました。

connpass.com

オフィスの一室のでっかいテーブルとでっかいディスプレイをわいわい囲んで、ひさびさに「勉強会」っぽさあるミートアップでした*1。

RoR未経験なのに、3か月でプロトタイプ開発した話 @hiroky_814

最初はGoで書いていたサービスを酔った勢いで本人も使ったことが無かったRailsにしようという提案が採用されて、そこからどういった開発や学びの話でした。 チームで意思決定できる環境で、新しいことにチャレンジしやすい反面、過去に作ったものが負債になってしまうということや、機能ごとに実装した人しかわからなくなってしまうような属人化があるなど、スピード重視で作ったときのあるある感がありました。 しかし、開発の途中から「品質を優先」として、rubocopを入れたり、OSSを読んだり、外部からRubyistを呼んでRails Wayを学ぶといった取り組みをしたそうです。 新しくチームが立ち上がった時に、レビューには他のチームの人たちを招待するという取り組みはとても面白いと思いました。

AWSの機能が増えすぎて、Ruby実装をやり直した話 @じゅんじゅん

パブリッククラウドのアップデートと開発との追いかけっこしてしまった話でした。 作ったり、作ってる最中にほしかったものがリリースされるのありますねーｗ

テスト駆動開発(TDD)の紹介 @安井 力(やっとむ)

昨日は、TDDBCの資料をベースに、TDDの説明とFizzBuzzを例に実演をしてくれました。

TDDBCの資料はこちら。 speakerdeck.com

  • 動かない汚いコードから、きれいで動くコードへ向かう道は二通り。きれいにしてから動くようにする、もしくは動くようにしてからきれいにする。
    • 前者はきれいにすることにいくらでも時間を注いでしまいがちで、きれいにしてから動くようにする時にうまくいかないことがわかったりする。
    • 後者はTDDのとる道。動くようにし、動くとは何かをテストで書いて、それを維持したままきれいにしていく。
  • まずはToDoリストを作るところから始める。
  • テストの方が負債化しやすい。だから意味のあるテストを残し、それがわかりやすいようにする。
    • RSpecではdescribeのネストができるので、それを使って、ToDoとの関連を記述していたのは学びだった！例えば、 describe "3の倍数"みたいに。
  • テストを取り除けるのは書いたあとすぐ。時間が経つと除去していいのか不安になる。そして他人が書いたコードとなるとさらに不安。

TDDってコードだけではわかりづらくて、どう書いているか流れを見たかったので、こっそり動画に撮ってたんですが、アプリが固まって保存できてなかった… 一昨年に出た新訳のテスト駆動開発は、サンプルコードに差分が載っていて、どう変更していったのかが追いやすくなっていると教えてもらいました。

テスト駆動開発

テスト駆動開発

懇親会とふりかえり

クリエーションラインさんからヤッホーブルーイングのクラフトビールの差し入れをいただき、懇親会。 自己紹介したり、今やってることの話しをしたり、TDDの話をしたり、ワイワイしてた。

第1回目のふりかえりは、@yattom さんがいたので、もちろんここはFun-Done-Learn。

やっとむさんとFDLの話ができて楽しかった。

次回は秋葉原のクリエーションラインさんで開催するみたいな話が出てました。

おまけ

爪痕を残した(๑•̀ㅂ•́)و✧

*1:勉強会っぽさって何だよ、というツッコミはお控えください。

You May Also Enjoy