2011年上半期にはじめたもの

「今更か」というようなものもいくつかありますが、開発に関連するもので2011年の上半期に試してみたものをリストアップして振り返ってみました。

1.github

ここ半年間、subversionよりもgitを使う機会が増えてきたので、仕事／個人のプロジェクトも本格的にgithubで管理するようになりました。今まではsubversion+Redmineでプロジェクト管理を行ってきたのですが、git+githubはこれを遥かに凌ぐ便利さで、後述の通り大分プロジェクトの進め方にも変化がありました。

githubを使ってよかったこと

1. チケット駆動開発が定着した
2. 作業履歴が追いやすくなった
3. レビューをしやすくなった

githubを使ってよくなかったこと

結論

もはやgithubのない開発なんて考えられない。

2.チケット駆動開発

subversion+Redmineで開発していた頃も、何度かチケット駆動開発の導入を試みた事はありましたが、いまいち使い勝手が悪く効果も感じられなかったため定着しませんでした。この手の手法はメンバーのモチベーションが維持されている間に、価値を感じられなかったり逆に面倒を感じてしまうことがあると大抵定着しなくて失敗します。
githubのissueは機能自体は限定的ですが、コミットとの連動、メールでの通知機能がよくできていて、また使いやすいインターフェイスを持っていたので、定着させることができました。

チケット駆動開発にしてよかったこと

1. 開発の方向性がぶれにくくなった(変なissueが上がれば却下すればよい)
2. 管理コストが減った(誰がいつなにをしたのか把握しやすくなった)
3. コミットを探すコストが減った(issueからたどっていく事ができるため)

チケット駆動開発にしてよくなかったこと

1. 細かい調整や修正のたびにissueを登録する／しなおすのが若干面倒なのは事実

結論

もはやチケット駆動じゃない開発なんて考えられない。個人でやるのは若干やりすぎな感じがするけど、チームで開発する場合には間違いなく効果があると思います。

3.ブロック構文

iOS 3系との互換性の問題から、なかなかブロック構文を導入できずにいたのですが、「いい加減3系のサポートは終了してもいいだろう」ということでブロック構文を導入しはじめました。メソッドチェーンが簡単に書けるようになったり、後述の非同期処理のテストが書けるようになったり、色々とメリットがありました。たまにブロック構文導入以前のコードを参照することがあるのですが、あまりの可読性の低さにびっくりします。

ブロック構文を導入してよかったこと

1. メソッドチェーンを書きやすくなった(デリゲートを使いまくる実装に比べて可読性があがった)
2. 非同期処理のテストを書けるようになった

ブロック構文を導入してよくなかったこと

1. 注意しないとたまにメモリー管理関連のバグがでる
2. ブロック内で問題が起きたときに、デバッガが正しく追えずデバッグが厄介なときがある
3. あまりブロックを多用しすぎると一つのメソッドが長くなりすぎて、処理が実装されている場所を探すコストが大きくなる(特にNotificationCenterのオブザーブ等。コールバックメソッドで実装されている場合はメソッドを検索すればよいので)

結論

ブロックのない実装には戻れない。けど、多用されすぎるとちょっと困る。

4.テスト駆動開発

これは以前もポストしましたが、ブロック構文の導入に伴い非同期処理のテストを書けるようになりました。未だテストを書けない部分もかなりあるのですが、生産性とバグ発見修正のスピードは確実にあがりました。
ただ、バグが多いのはテストが書けないUI周りだったりして、さらに最近はWebViewを使いUIを実装することも多く、余計にテストが書きにくくて困っていたのですが、最近パンカク社内ではQUnitを使ったテストが実験されていて、これがなかなか面白そうな感じで期待してます。

テスト駆動開発を導入してよかったこと

1. バグの早期発見
2. バグの原因究明スピードの向上
3. 実装スピードの向上(テストケースを使って実装する方がアプリを起動して手動で動作確認するよりは大分効率がよい)
4. テストコストの削減、高速化

テスト駆動開発を導入してよくなかったこと

1. 調子にのって自動テストを走らせまくっていたらtwitterからbanされたこと

結論

HTML/JS側のテストがちゃんと書けるようになったら、より嬉しい。

5.HTMLベースUI

Androidとの共通化、AppStoreへのサブミットなしでのアップデート実現などの点から、WebViewを使ってHTMLベースのUIを採用するようになりました。残念ながらまだHTMLベースUIを使ったアプリはリリースできておらず、まだ試行錯誤の最中ですが、ここ数ヶ月の開発の中では最もチャレンジングなトピックです。

HTMLベースUIにしてよかったこと

1. 必然的にMVCがきれいに分離され、逆参照等が解決された
2. Native UIだと手間のかかるような表現もHTML/CSSで低コストで実現できたりした
3. Androidと共通化できた
4. xibに比べて管理コストが小さい

HTMLベースUIにしてよくなかったこと

1. Native UI(UIKit)に比べるとやっぱり重い
2. JSのデバッグがかなり困難でコストが大きい
3. テストが書きにくい(QUnitでうまくかけるとよいなあ)

結論

まだまだ試行錯誤中で良い部分悪い部分両方と日々格闘中です。トラブルが少なく動作も高速なNative UIが最近若干恋しくもありますが、アプリがリリースされて運用がはじまってみてから、また振り返ってみます。

まとめ

他にもいくつか細かいことは導入してみましたが、結果的に影響が大きかったのはこんなものでした。いくつかはうまくいき、いくつかはあまりうまくいっていない状態ですが、まあやっぱり新しい手法はツールを取り入れていった方が刺激があって楽しいので、下半期も色々導入していければ、と思う次第です。