トップ 最新 追記

2012-03-07 [長年日記]

_ kanazawa.js v1.7でJSTDD Introと銘打って話します

来る 3/31(土)に kanazawa.js v1.7 が開催されます。参加申し込みはこちら!

kanazawa.js v1.7 - Back to Basics - : ATND

今回はなんと Mozilla さんと共同開催でかつ node.js 方面からも刺客(講師)が来るという豪勢な内容になっています。

そんな中で JavaScript での TDD について話すことになりました。まぁぶっちゃけ二つ返事で返しちゃったんですが、あとでプログラムを見てからアウェイ感にやられております。メインセッション扱いですが、聞く方はポカーンじゃないですかね、これ(笑

正直言うと不安はあります。

  1. 嘘を言うんじゃないか
  2. もっと良い話をできる人は他にたくさんいる

1 については、なんだかんだで自分はそんなにきちんと TDD を学んでおらず、我流ですし、ペアプロの機会にも恵まれませんので、自分を見直すことが難しい状況です。文字で読める情報はなんとか追ってはいますが、誤解を与える可能性が消えません。

まずここがいちばん怖い。

2 についてはまぁ、JavaScript x TDD x kanazawa という組み合わせになってしまうと話せる人はたぶんそれほど多くはないので、東京で話すことに比べれば気は楽です。

ということで、1 に関する不安を減らすために、

当日話す内容のスライドのレビューをしてくれる方を募集します。

3/11(日) 0:00 ( 3/10 24:00 ) までに「レビューしたる」と wtnabe at gmail dot com までお送りいただくか、メールアドレスを公開されている方は @wtnabe によこせと言ってもらえれば喜んで PDF を送りつけて差し上げたいと思います。

まぁ現時点で公開しちゃってもいいっちゃいいんですけど、一応叩いてもらってから当日に公開しようと思っています。

あ、出席予定の方は面白みがなくなるのでご遠慮ください(笑)


2012-03-08 [長年日記]

_ Jasmine gemで特定のjsファイルを除外する

みなさん、テストしてますか。得意げに Jasmine を紹介して1年以上が経ち、最近はようやくある程度 JavaScript についても TDD が回せるようになってきたかなと感じております。(いつものことながら歩みが遅い。)

さて今回のテーマは

Jasmine gemで特定のファイルを除外したい

です。

jasmine.ymlにはexclude_filesという設定がない

普通に exclude があるだろうと思ってタカをくくっていたのですが、ありませんでした。

  • src_dir
  • spec_dir
  • helpers
  • src_files
  • spec_files
  • stylesheets

しかありません。あるぇ。

src_files で頭に ! を付けると除外される

jasmine-1.1.2/lib/jasmine/config.rb を読んでいると

   def match_files(dir, patterns)
     dir = File.expand_path(dir)
     negative, positive = patterns.partition {|pattern| /^!/ =~ pattern}
     chosen, negated = [positive, negative].collect do |patterns|
       patterns.collect do |pattern|
         matches = Dir.glob(File.join(dir, pattern.gsub(/^!/,'')))
         matches.collect {|f| f.sub("#{dir}/", "")}.sort
       end.flatten.uniq
     end
     chosen - negated
   end

こんなメソッドを見つけました。ということは jasmine.yml 上ではこうですね。

ex) Railsプロジェクトの場合

src_files:
  - public/javascripts/jquery.min.js
  - public/javascripts/jquery_ujs.js
  - public/javascripts/application.js
  - '!public/javascripts/exclude.js'
  - public/javascripts/**/*.js

最初 '' で囲まずにいきなり ! を付けてしまったんですが、そうすると YAML の読み込みの段階でコケます。そらそうだ。

これでテストのときに読み込んでほしくない JavaScript を指定することができました。めでたしめでたし。

本日のツッコミ(全2件) [ツッコミを入れる]

_ hikaruworld [ちょっと気になったんですが、これってRuby経由で使う場合ですよね? jasmineをstandaloneで使う場..]

_ wtnabe [あ、なるほどそうですね。Jasmine gemと書くべきですね。]


2012-03-24 [長年日記]

_ 『リファクタリング: Rubyエディション』を読んで思い出したこと

2000年(日本語版)の『リファクタリング―プログラムの体質改善テクニック (Object Technology Series)(マーチン ファウラー/Martin Fowler/児玉 公信/平澤 章/友野 晶夫/梅沢 真史)』から10年後の2010年(日本語版)に出た Ruby エディションを読んだ。

月末の kanazawa.js v1.7 - Back to Basics - : ATND の JSTDD Intro の準備の過程で、本当に言いたいことってなんだろう?とずっと振り返りをしていた。せっかくなので気になってた本を読んでみた。そしてようやく思い出した。自分のやりたかったことはリファクタリングだったのだと。

年代的にも日本語版で言うと

  • 2000年 リファクタリング
  • 2003年 テスト駆動開発入門

であり、Red/Green/Refactoring のサイクルはこのリファクタリングの中に出てくる。*1

コードの振る舞いを変えずに中をクリーンアップする。重複を削り、責務を明らかにする。その結果メンテナンス性が上がり、新機能の追加や変更、修正を行いやすくなる。確かに自分のやりたかったことはこれだった。

脱線してなぜ自分がリファクタリングを望んでいたのかを書いておこうと思う。

それは10年前に目の前の圧倒的にヒドいコードに打ちひしがれていたから。そこで思ったことは大きく二つ。

  1. リファクタリングしたい(言葉は知っていた)
  2. オレのコードもいつか捨てるしかないと思われるのではないか

それからオブジェクト指向を勉強し直したりUML描けたら設計がうまくなるかなと思って試したりしていたが、新規開発でなければやはり実際に動いているコードを相手にする力が必要だと思い知らされる。

「動いているコードをいじるな」

というのはよく言われる最もダメな姿勢の一つだが、不用意に加えた変更でシステムに致命的なダメージを与えたことも何度もある。悲しくもなったし、悔しい思いをしたし、目の前のコードを恨んだ。

ところが実際に自分の書くコードも誉められたものではなかった。今思えば、『リファクタリング』に出てくるダメな例の典型である「多すぎる引数を持った関数」も書いていた。当時の自分はオブジェクト指向は名前を知っている程度だった。オブジェクト指向の本は何冊も読んでいたが、結局のところclassを使えばオブジェクト指向だと思っているようなもんだった。

それでも諦めずに戦っていれば少しずつでも上達する。テストなんて書いたことなくたってより良いコードを目指すことはできる。でもやはり安全で確実なリファクタリングはできなかった。テストがなかったから。コードを書くことで上達はしたがコードが増えたらメンテナンス性は落ちる。

やはり自分に必要なものは確実にリファクタリングできるスキルだった。

TDDはこのリファクタリングを、特別な機会に行うものではなく毎日の開発の中に組み込む手法である*2。今ならこう説明できる。リファクタリングはできればやった方がよいものではなく、毎日自然に行うもの、テストもできればやった方がよいものではなく、毎日自然に行うもの。今ならやっと言える。

テストなしにどうやってリファクタリングするの?

10年掛かったよ。もし師匠がいればもっと早くたどり着けたかもしれない。でもぼっちでも10年頑張れば少しは何かがつかめる。それは分かった。

さて最後に紹介を少々。

本書はリファクタリングそのものの紹介、リファクタリングした方がいいコードの特徴、そしてテクニックカタログである。オリジナルが出版されて10年以上経った今読むと、すでに動いているコードにも反映されてるテクニックがいくつもあったりするので、ちゃんとたくさんのコードを読んでいれば自然と気づくものも多い。それでもこれだけまとまったカタログがあると心強い。いくつかは Ruby の特徴を本当に活かしているので他のカタめの言語ではマネできないものもあるが、ほとんどのものはオブジェクト指向言語であれば適用可能だ。

動的なLLでコードを書くすべての人はお守りとして辞書として持っていていい。個人的にはデザインパターンよりも前に読むべきだと思う。具体的でかつ覚えなければいけない用語は少ない。最初から理想的なコードが書かれているわけではなく、あーあるあると思うことが多いのですんなり読めると思う。

いちばんピンときそうなのはやっぱり条件式の単純化の辺りかな。これは分かりやすくて効果がすごく大きいと思う。個人的に今回あーなるほどと思ったのはクラスアノテーションの導入から名前付き引数の流れと、恥ずかしながらやっとしっくりきたNullObjectパターン。これ使えばあちこちで .present? とか書かずに済むんだなー。

Tags: Book Ruby TDD

*1 原書ではeXtreme Programming Explainedが1999年、Refactoringも1999年であり、この段階でこのサイクルは完成しているとみてよさそう。

*2 それでいてXPほど厳格な「プロセス」ではない。