読者です 読者をやめる 読者になる 読者になる

GitHubのコミットログをエンディングロールにするWEBサービスを作りました。

f:id:hogesuke_1:20140514053512j:plain
f:id:hogesuke_1:20140514053514j:plain

Git Ending
http://gited.net

GitHubのコミットログを映画のエンディングロールのようにするWEBサービスを作った。今回の開発の狙いと反省点をまとめておく。

狙い

今回はとにかく早く完成させることを目標とした。デザインにはこだわらず、とりあえず動けばよいという考え。

反省1:思ったより時間がかかった

当初は開発を1日で終わらせる予定だったが、実際には3日かかった。想定よりも時間がかかった理由は、自分が持っている知識だけでは対応できなかったからという事に尽きる。
見積もり時にはそのとき持っている知識で対応できると考えがちだが、実際開発を始めてみると考えていたやり方ではダメだったとか、こんなこともやりたくなったとか、必ず出てくる。だから、すべてがうまくいく事を前提とした見積もりでは意味ない。どの程度不確定要素があるかを考える必要がある。ただ、いくら考えてもそんなの分かりっこないという気もする。

具体的には以下が時間が膨らんだポイント。

1. GitHubAPIで嵌った

コミットコメントの取得に使用するAPIを間違え、それに気づくのに半日程度かかってしまった。ドキュメントを何度も読んだけれども、英語が得意でないせいか間違いには気づけなかった。試行錯誤するうちに目的のAPIではないということが分かった。

2. Promiseを使用した実装に手間取った

Promiseで同期をとる実装は以前の開発で経験していたが、配列長が未確定の配列要素数分thenで処理をチェーンする実装に手間取った。

3. 動画プレイヤーをJavaScriptから操作する方法を調べるのに時間がかかった

動画プレイヤーをJavaScriptから操作したいと考えたが、それができるのか、できるにしてもどうやるのかが分からなかった。初めはニコニコ動画プレイヤーで試したが紹介されている方法ではうまくいかなかった。仕方なくYouTubeプレイヤーについて調べたところ、SWFObjectを使えばやりたいことが実装できることが分かり事なきを得た。

反省2:コードが汚くなった

機能を増やすに従い、コードが汚くなっていった。スピードに拘りすぎて、いいやいいやでかなり適当な実装になってしまった感がある。今後もメンテしていくようなWEBサービスではないので、このやり方もありではあるが実装力を鍛える意味では失敗しているように思う。

次やること

JavaScriptのテストを書く。テストがないと動いているものに手を加えるのが抵抗になってしまう。だからリファクタリングもやらずに、いいやいいやの実装が蔓延ってしまう。メンテしない遊びのコードならば品質とトレードオフリファクタリングしないという手もありだが、仕事でメンテしないコードなどほぼあり得ないわけで、テストを書いてリファクタリングし綺麗なコードを書く力を身につけたい。