2013年の振り返り。
今年は、去年（2012年）に培ったものを別のプロジェクトに適用していくなど、改善にフォーカスした一年でした。
まったくの新規技術といったものには触れてはいませんが、去年本格的に導入しだしたもの（Jenkins、WebDriver、Gradle）を引き続き導入・深く掘り下げてることが多く、裏方寄りのお仕事が中心になってる状態です。
そういった意味では去年の振り返りの後半に書いた方向に、少しは舵取りできてるのかもしれません。（アプリ単体ではなく、運用・保守までトータルしたクオリティを向上させ、疲弊しない開発やプロジェクト運営というレールをしけるようになっていきたい）
技術的なものは、以下のウェイトが多かったと思います。
- Jenkins x WebDriver
- ソース自動生成
・Jenkins x WebDriver
社内的には、自動テストが受けがいいようで、WebDriverの方が受けがいいのですが（苦笑）、個人的にはJenkinsさんにいろいろ頼るのが好きです。去年は、初めて導入という感じでしたが、だいぶ回し方も慣れてきたようで、新しいプロジェクトではどうJenkinsを活用してビルド＆デプロイ、テストをうまくこなしていくかを考えれるようになりました。（導入するのが当たり前になった）
Jenkinsはある程度テンプレ的に構築できるのですが、WebDriverをうまく活用していくのはアプリの特性やくせもあるので、まだ一概にすっと導入できるかというと、まだ難しい部分もあります。
対して、あらかじめWebDriverなどブラウザ自動テストを行う前提で設計をしておけば、バッドノウハウも少しずつ溜まってきているので、ハマりどころが少なく抑えれるかなと思います。
・ソース自動生成
僕自身も、諸手を挙げて賛成というわけではありませんが、きちんと適用範囲を決めて導入するのはアリだと思っています。
基本スタンスとしては、すべてを自動生成とか、設計書と同期とりますとか、GUIでノンプログラミング、というのはよほど簡単なシステムでないと難しいと思っています。
しかしながら、数百画面レベルの規模だと、さすがに一画面ずつ一からというのは非効率なため、ある程度パターン化して、可能な範囲で雛形を生成していくのは一定規模だと必要かなと思っています。
このあたりをソース自動生成用のフレームワークをベースにして、アプリに特化した対応をすることによってうまく適用していくというのが今のところの現実解かなと考えています。
とはいえ、やりすぎると自動化ハイ（自動化が目的になる）となるので、
- 可能な範囲の見極め（頑張り過ぎない）
- 書き換え可能（その後は各自でエンハンス可能、ツールによっては編集禁止とかもあるので。。）
- テストも合わせて雛形生成（デグレ検知＋テスト自身の作成も負荷になる場合もあるので）
というくらいのカジュアルな方針でいいと思っています。
実際、これくらいの方針でもちゃんと母数が多いと効果はでるので、アリかなと。
また、自動生成されるコードは、キレイなコード（可読性を意識＋あらかじめユーティリティや抽象クラスを活用する設計）を心がけているため、コピペコードの防止という面も合わせてあります。（プロジェクトの都合でどうしても、きちんとしたコードを書ける要員が集めれないという場合は助かります）
・来年（2014年）
ひとつ楽しみとしては、gitを社内で利用できるようにしました。
2013年後半から徐々に準備しており、年明けごろからはgitベースで開発できるようにしたので、来年はそちらの方面で楽しく開発できそうです。
subversionでもいいじゃんという話もありますが、結構リリースが複雑になりそうなプロジェクトがあるので、ブランチ、マージがより柔軟なgitでチャレンジすることにしました。もう一つは、出遅れ感はややありますが、chefなどのサーバ管理ツールをなんとかねじ込みたいですね。数はそんなにないとは言え、似たようなサーバを構築することはそこそこあるのでこのあたりのフローも省力化していきたいです。
# あとはもう少し、勉強会の参加を増やしていきたいところです。
# 下手すると来年はデブサミが勉強会始めとなるかもしれません。
