SyntaxHighlighter

2012年12月31日月曜日

2012年の振り返り


2012年の振り返り。

今年は、いくつか新しいことに取り組む機会があり、特に技術的にはいろいろ得られた年でした。
自分が中心となって開発したものが、一気に採用されてかなり忙しい一年でしたが、よい一年だったと思います。


技術的なものは、以下のウェイトが多かったと思います。

  • Jenkins
  • WebDriver
  • Spring + Thymeleaf

・Jenkins

個人的にはちょこちょこ触ってみてはいましたが、今年、2012年に初めて実プロジェクトの運営で使いましたが、自分の関連プロジェクトはだいたい使うようになりました。

リーダポジションの人で、ある程度アプリケーションの全体像や品質を考えなくてはならない立場の人には結構、受けがいいですが、まだ経験が浅いような若手だとまだあまりメリットを感じれていない人もいます。
(まぁ、Jenkinsがあった開発となかった開発を両方経験しないと、ないときの不便さがわからないというのもありますが。)

具体的に何がいいの?とたまに言われるのですが、自分としては以下の点が気に入っています。

・変更に対するしきいが飛躍的に下がった
Jenkinsで、コミット時に自動的にテストが実行されることにより、気軽に変更したり試したりできることを実感しました。

これには当然、ユニットテストを書く必要があるのですが、Jenkinsではいままでの履歴も保持しており、テスト自体の成長の記録もわかるので、テストを書こうという気にさせてくれます。

過去のプロジェクトの多くでは、ユニットテストを書いてるけどだんだんメンテナンスされていかなくなる、というのを幾度か経験しましたが、Jenkinsでは、自動実行される事により、プロダクションコードと、テストコードが乖離すると、すぐにテストがエラーになるので、修正しなければ先に進めなくなる点も(強制な面はありつつも)気に入っています。

体感的な効果はテストをないがしろにしがちな人も多少、意識が変わってきているという認識です。
いままではテストの話など全然しなかった人が、これはどういう風にテストするといいと思いますか?など言ってくれたりしてくれるようになりました。


・メトリクス関連のツールと組み合わせての品質の予防
checkstyle、findbugsのような静的解析、cobetruaのようなカバレッジツールと組み合わせてある一点で品質を観測するのではなく、連続的にいつでも最新のコードの品質を確認できるようになりました。

自動でメトリクスを取得するので、ある程度システムが出来上がってくると、checkstyleなどをさぼっていると警告数がどんどん増えて行きます。

自分で取得するのではなく、Jenkinsが取得するので手間ではなく、かつ見たときに、あ、細かい部分をさぼってるな、対応しなきゃ、という気にさせてくれます。

もちろん、メトリクスが取る事が目的ではないので、場当たり的な対応やテストコードにならないように注意する必要があり、その部分はまだ浸透はしきれていない部分はあるというのはまだまだ実感しています。


Jenkinsは(というかCIツールになりますが)、自分の中では、なくてはならないものというか、すでにあって当然というスタンスでいます。


・WebDriver

Webアプリの場合、ブラウザ操作を自動化したり、画面の処理結果などを検証したいという場合が数多くあります。

WebDriverはコードでブラウザ操作を行うライブラリで、ブラウザ操作の自動化や、検証についてこれをかなり使っています。

他の候補として、firefoxプラグインとして自分で操作したものを記録し、テストコードを出力してくれるSelenium IDEなども検討してみましたが、なんだかTDDじゃないなぁと思ったり、生成されるコード中にURLや入力値がハードコードされてしまうので、見送りました。

ただし、WebDriverはそのまま使うのではなく、多少ラップして、Excelに手続き的に書いたシナリオをJUnitから自動実行するようにしています。

その他、テスト前のデータ初期化やREST APIの呼び出しなどもテストシナリオに記載できるようにしています。

Excelはプログラマには結構嫌われてしまう面が強いのですが、それなりの規模のプロジェクトではJUnitテストコードをまともにかける人ばかりではないので、Excelで、テストシナリオを書くとWebDriverのテストがかけるというのは結構便利なんじゃないかなと思っています。Excelなら「なんとなく」なら使える人も多いですし。

またJenkins + maven cargo + coberturaと組み合わせて自動テスト時に、ブラウザ操作をしつつ、カバレッジも取るという事もしています。(もちろんこのテストはスローテストになるので、コミット単位ではなく、定期的に実行しています)

webアプリでテストコードだけでカバレッジを取るというのは難しいので、これも助かっています。


・Spring + Thymeleaf

Springは今年ではなく、ここ数年は継続的に扱っています。

Spring関連は組み合わせや自由度が高く、どれを使っていいのか迷う面もありますが、いろんな逃げ道があったり、後発のフレームワークと組み合わせたりできるってのはアーキテクチャを決める側としてはうれしいものがあります。

また、後方互換性にもかなり気を使っているので、バージョンアップの際にも安心感があります。(反面、内部のコードはキレイと言いがたい部分も結構あったりするのですが。)

後方互換性に気をつかいつつ、新しい仕様への対応も継続的に続けているプロダクトはそうそうなないんじゃないかなと思います。

Springは一部、拡張してSeasarやSlim3のように開発モードとしてhotRelaodingライクなことをできるようにしており、Spring MVCでもサクサク開発ができて便利です。(Spring3.1 -> 3.2 のServlet3.0対応周りでちょっとハマりましたが)
 
最近は、spring-loadedというプロジェクトというもの出てきてるようで、Grailsでフォーカスされているようですが、もしかしたら本家側でもhotReloadingのようなものも対応してくれたりするとうれしいですね。(有償?でJRebelというのもあるようですが、これもどんな感じか気になります)

  https://github.com/SpringSource/spring-loaded

ビューは、Spring MVCと組み合わせで、ThymeleafというHTMLベースのテンプレートエンジンと組み合わせて使っています。

  http://www.thymeleaf.org/

TeedaやFaceletesのような同じHTMLベースのビューフレームワークを探していたのですが、印象はよいです。
HTMLベースがよかったのは、お客様向けのモックを見せる段階で作成したHTMLをなるべく活かしたいなと思っていたのが大きな理由です。

TeedaはS2前提なのと、Faceletesは、内部的にはJSFだったので見送ったのですが、ThymeleafはSpringと組み合わせることも考慮されており、使いやすいと思っています。

Thymeleaf1.xのころから使い始めていたので、そのころはマイナーだったようですが、最近は日本のブログでもみかけたり、Springのカンファレンスでもセッションがあったようで、今後、広まってくれるとうれしいなぁという気持ちです。




その他、プロジェクト運営の観点からも、今年はわりと自分の中でもいいターニングポイントになったかと思います。

世の中は、キレイなアーキテクチャや運営などできているところもあると思いますが、
今年は多くのプロジェクトを見る機会があったせいか、まだまだ整備されていない形の開発や運営があるのを実感しました。

社内外をみていて強く感じたのは、プロジェクト初期の判断ミスによって運用、保守フェーズへのしわ寄せがいったり、残される人への負担を増やす対応とか、自分が最後まで面倒見ないからといって、後続に負債をもたせるようPM、PLとか、。。。ですねぇ。
(そしてその運用が当たり前と思うような保守も)

理想と現実と、組織の制約のバランスをとって現実解を探していくのもおもしろいかと思います。

アプリ単体ではなく、運用・保守までトータルしたクオリティを向上させ、疲弊しない開発やプロジェクト運営というレールをしけるようになっていきたいです。
今後はそこのニーズが合うかどうかもどう仕事して行くかの基準になるかと思います。

0 件のコメント:

コメントを投稿