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

Anger Driven Development

備忘録でございます

kanazawa.rb meetup #53

行ってきた

kanazawa.rb meetup #53 - kanazawa.rb | Doorkeeper

やったこと

TDDBCの予習

背景

 最近、仕事で作った社内常駐ツール(WPFアプリ)のリファクタリングをしている。ツールは運用3年目に入っていて、今まで仕様変更や追加を重ねてかなり運用が苦しくなっている。業務上の手続きの概念を扱っており、よく仕様変更される感じだ 。

 当時はリーダブルコードも読んでなかったし、オブジェクト指向も今より理解してなかったし、初めてちゃんとアプリ作ったしで、ひどいコードになっている。一つ機能を加えるとあっちこっちでエラーが起こる、ようなことは無いが、自分で作ったから、影響範囲を覚えていてたまたまうまくいっているだけで、自分以外の人間がこの作業をやると大変なことになると思う。

 この現状をどうにか改善したい。 ということで以下の2つに申し込んだ
toyama-eng.connpass.com

tddbc.connpass.com

で、WPF結合テストについてはBuriKaigiで学んでくるとして、TDDBCでは選択言語JavaScriptで申し込んだ。そこでJavaScript単体テストについて予習した。

学んだこと

大体以下のような雰囲気なのかと。

参考サイト:フロントエンドにテストを導入 - Qiita

サーバ側だけならkarmaはいらないって感じか。

以前試してみたことのあるサイトで、他のサイトの情報を見てみてもだいたいこんな構成がいいみたいだ。

疑問

 ネット上のチュートリアルまではできるんだけど、具体的な開発段階での落とし込みかたがわからない。具体的には、

・テストを書くフェーズ

 TDDだからテスト書いてから開発?それとも最初はスピード重視で、ある程度規模が大きくなってからテスト書き始める?

リファクタリングとテスト

 テストの書かれてないコードをリファクタリングしていくのつらい。こういうときはまずはテストから書けばいいの?

・テストのコスト

 テストを書く人のスキルも必要だけど、保守するのもコストかかりそうだけどどうなんだろ。実際運用してる人の話を聞いてみたい。

 

メモ

・ブログをtextlintで書く

・オレオレUML
・sysML
・safeML

・仕様を決めるための図の仕様

・テストしやすいコード/しにくいコード

 テストしやすいコードとは関数のように入出力が決まっているもの。

 ・Rubyはminitestが良いらしい

 

その他

・HoloLens触らせてもらった。近未来感がよい。

 

参考文献: 

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

 

 

リファクタリング:Rubyエディション

リファクタリング:Rubyエディション