Hatena::Groupbugrammer

蟲!虫!蟲!

Esehara Profile Site (by Heroku) / Github / bookable.jp (My Service)
過去の記事一覧はこちら

なにかあったら「えせはら あっと Gmail」まで送って頂ければ幸いです。
株式会社マリーチでは、Pythonやdjango、また自然言語処理を使ったお仕事を探しています

 | 

2012-04-19

[]一人でチケット駆動開発もどきをやっていることの感想など 04:35

 最近は、一人でWebゲームみたいなものをコツコツと作って1ヶ月くらいになるんですけど、だいぶ自分なりにやってきた開発が手に馴染んできたころかな、と思い始めたので、セーブがてらにメモしてみる。

チケット駆動開発もどき」について

f:id:nisemono_san:20120420042349p:image

 正直、自分で「これがチケット駆動開発か」と言われると、正直自信がないところなので、「チケット駆動開発の方法を自分なりにアレンジして運用している」という意味もこめて、「チケット駆動開発もどき」ということにしておく。

 「チケット駆動開発」とは何か、というと、自分が理解したところだと、「チケットをタスクとして扱う」ということと、「まずコミットするときにはチケットを発行すること」の二つを守るという開発手法ということと理解している。で、これらの「チケット」は、バグ管理システムであるTracRedmineを使って管理する。Redmineも素晴らしいシステムだとは思うものの、自分の場合は、個人プロジェクトでも、それほど大規模な開発にならない/できないという点で、Tracサーバーに入れて使用している。

チケットの作り方

f:id:nisemono_san:20120321000231p:image

 で、一般的な「チケット駆動開発」については、上記の説明でいいような気がするんだけど、じゃあ実際にどのように「チケット」を作っているか、といえば、二重のプロセスにて管理をしたりしている。

 GithubのIssureは、基本的にメモ扱いにしておいて、「実装するべきかどうかわからないもの」であったり「思いつき」をプールしている。自分の場合、Webゲームで、プレイヤーと一緒にテストプレイをしたり、ログを読んだりしたりすることが多く、そのさいに「こういう要望があるんだな」ということで、とりあえずGithubに登録しておく。これは、まだ実際に実装できるかはわからない、未整理の状態。

 で、未整理の状態から、改めて「問題点」や「改善点」が書けそうなチケットに関しては、Tracに改めて整理していく。ここでは、何らかの形で、「この機能はなぜ実装するのか」、「この機能が必要なワケ」をメモしておく。また仕様がある程度固まったら、その意図も書いておく。二段階にしている理由は特には無いけれども、TracよりはGithubのほうが登録しやすいということと、実際のチケットならTracのほうが便利かなという感じで、現状は使い分けている。最近は落ち着き出したので、Tracに直接チケットを発行していることも多い。

チケットを最初に登録するという方法を試して思ったこと

 で、自分の場合は鳥頭であることを自覚しているので、「実装するべきこと」であったり、「現在わかっているバグ」という点について、なかなか覚えられなかったりする。また、「アレあったらいいよね……」と思いつつも、気がついたら忘れていることも多かったりする。そういう場合に、二度も三度も思い出すコストをかけるくらいだったら、最初から何かしらにメモをしておくという習慣は必要だな、と思ったので、チケット管理システムにまかせることにした。

 また、自分は曖昧だったりするので、たまにチケットを発行せずに勢いでコードを書いたりするのだけれども、そういう場合も「あれ、あとどれくらいの作業が必要なんだっけ?」というのがわかりにくかったり、最悪なときには「あれ、これ何のために必要なんだっけ?」とか「このコードの意図ってなんだっけ?」みたいなバカみたいな疑問が沸いてしまうこともあったりした。まず走り始める前に、どういう道筋を通るべきなのか、みたいな作業手順と、意図、「こういうコードが必要だよ」というのを自分の中で明確化し、記録してくことで、コードも書きやすくなったし、自分の作業も、メモを読み返せば、何をしているのかがわかるようになったりした。言語化するという作業の大切さを改めて知る感じ。報告しているときでも、「あれ、まだこれ必要なんじゃないかな」と思い返すこともできるし。

 あともう一つとして、自分は決して賢くプログラミングできていないと思っているので、コードが肥大化することも多くなってくる。肥大化すると何が起きるかといえば、コードの全体像がわかりにくくなったりするんだけど、そういうときに解決チケットを見返せば、だいだい「ここの部分は終わってるのか」というのもわかるようになる。それもいいところ。

 あとは、単純に課題が片付いていくのって気持ちいいというか、いつの間にかチケット番号が70とか80とかになっているとやった気持ちになるのはいいよね、とかそのあたりです。

まとめ

 割と自分は天然ボケの気が大きいのですけれども、こういう感じで、「チケットをまず作る」ということを実践することで、曖昧に突っ込んで粉砕するということが少なくなるという点では、落ち着いて作業ができていい感じなので、今日も一人でチケットを書いて、報告して、閉じるという作業を繰り返すのでした。

 |