行ってきた
kanazawa.rb meetup #53 - kanazawa.rb | Doorkeeper
やったこと
TDDBCの予習
背景
最近、仕事で作った社内常駐ツール(WPFアプリ)のリファクタリングをしている。ツールは運用3年目に入っていて、今まで仕様変更や追加を重ねてかなり運用が苦しくなっている。業務上の手続きの概念を扱っており、よく仕様変更される感じだ 。
当時はリーダブルコードも読んでなかったし、オブジェクト指向も今より理解してなかったし、初めてちゃんとアプリ作ったしで、ひどいコードになっている。一つ機能を加えるとあっちこっちでエラーが起こる、ようなことは無いが、自分で作ったから、影響範囲を覚えていてたまたまうまくいっているだけで、自分以外の人間がこの作業をやると大変なことになると思う。
この現状をどうにか改善したい。 ということで以下の2つに申し込んだ
toyama-eng.connpass.com
で、WPFの結合テストについてはBuriKaigiで学んでくるとして、TDDBCでは選択言語JavaScriptで申し込んだ。そこでJavaScriptの単体テストについて予習した。
学んだこと
大体以下のような雰囲気なのかと。
参考サイト:フロントエンドにテストを導入 - Qiita
サーバ側だけならkarmaはいらないって感じか。
以前試してみたことのあるサイトで、他のサイトの情報を見てみてもだいたいこんな構成がいいみたいだ。
疑問
ネット上のチュートリアルまではできるんだけど、具体的な開発段階での落とし込みかたがわからない。具体的には、
・テストを書くフェーズ
TDDだからテスト書いてから開発?それとも最初はスピード重視で、ある程度規模が大きくなってからテスト書き始める?
・リファクタリングとテスト
テストの書かれてないコードをリファクタリングしていくのつらい。こういうときはまずはテストから書けばいいの?
・テストのコスト
テストを書く人のスキルも必要だけど、保守するのもコストかかりそうだけどどうなんだろ。実際運用してる人の話を聞いてみたい。
メモ
・ブログをtextlintで書く
・オレオレUML
・sysML
・safeML
・仕様を決めるための図の仕様
・テストしやすいコード/しにくいコード
テストしやすいコードとは関数のように入出力が決まっているもの。
・Rubyはminitestが良いらしい
その他
・HoloLens触らせてもらった。近未来感がよい。
参考文献:

レガシーコード改善ガイド (Object Oriented SELECTION)
- 作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義
- 出版社/メーカー: 翔泳社
- 発売日: 2009/07/14
- メディア: 大型本
- 購入: 45人 クリック: 673回
- この商品を含むブログ (155件) を見る

- 作者: Jay Fields,Shane Harvie,Martin Fowler,Kent Beck,長尾高弘
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2010/02/27
- メディア: 大型本
- 購入: 9人 クリック: 321回
- この商品を含むブログ (50件) を見る