【6週目】未経験からTECH::EXPERTでプログラミングやってみた
最終週（最初のプロジェクトの）
仕上げ
現在同時進行で二つのプロジェクトが進んでいて、そのうちの一つは今週いっぱいで終了でした。アジャイルチーム開発を初めてやった案件なので、なんか思い入れがあります。
今週は軽微な修正とテストとデプロイがメインでした。軽微と言っても使う側から見ると軽微でも開発側から見るとけっこう手間かかったりするんですよね…。
- AjaxでのレスポンスとHTMLでのレスポンスでコメント表示の見た目が違う
- 各ポストにはタグ付けができ、作成されたタグの一覧を（きれいに）表示する
- Newest / Popular機能
- ポスト投稿時にアップロードする画像をプレビュー表示させる
- アップロードした画像をポスト編集時に表示させる
このような点を今週は修正していきました。
ユーザーからすると当たり前に感じる機能ですが、いざ実装しようとすると「あれ？どうやってやるんだっけ？」ってなったりしました。一回実装したのに他でバグが出て泣く泣く削った機能もありましたが、なんとか最終形に持っていくことができてよかったです。
テスト
テストコードを書くのは自分が担当しました。正直あまり得意じゃないので、チャレンジしようと思って自分から名乗り出ました。やめとけばよかった。
- 投稿機能
- ポストへのコメント機能
- ポストへのタグ付け機能
- ポストへのLike機能
それぞれ「投稿ができる」「削除ができる」「編集ができる」ことをテストコードで保証しなければなりません。
カリキュラムで習った通りrspecでテストコード書き始めました。投稿と編集については問題はなかったんですが、どうしても削除のテストがうまくいきませんでした。
削除はログインしていないとできないようにしているので、deviseというgemを使ってログインをしてから削除をするという行動をテストで再現します。
そこの絡みかFactoryGirlなのかわかりませんが、email has been already takenというエラーをずっと回避できないままタイムアップでした。database_cleanerをインストールすればいいみたいな話もあったんですが、解決までには至らず…めっちゃ悔しいです。
テストってものを作り上げていくわけではないので、同じコードを書くにしても機能を実装してる時とかなり意識が違うなと感じます。好き嫌いが分かれると思いますが、個人的にはテストが通った時の気持ち良さはけっこう癖になる気がしてます。気がしてるだけですが。
Pairsクローン
メッセージ機能実装
Pairsを使ったことがあって相手からちゃんと返事が返ってくる人ならわかると思いますが、Pairsには素晴らしいメッセージ機能が備わってます。この機能を僕が担当することになりました。
実際開発者目線で見ると新たな発見がいろいろあります。今パッと思い返すだけで以下のような機能があります。
- 自分と相手のメッセージで見た目を切り替える
- 同じ日付のメッセージには重複して日付を表示させない
- それぞれの相手との最新のメッセージをサイドバーに表示
- 一通目以外は画像投稿ができる
などなど。
正直言って、めっっっっっっちゃ苦戦しました。
- それぞれの相手との最新のメッセージをサイドバーに表示
これ！こいつ！これをRailsだけでどうやったらできるのか、かなり悩みました。ここはビューをどういう構造にするのかにも関わるので、影響が及ぶ範囲が大きくて大変でした。
いやーーー丸三日間作っちゃ壊してを繰り返してやっっっっっとこの機能できた！最新のメッセージをユーザーごとに表示するとこなんだけど、検索してもハマるやり方がなかったからフルRailsで自力で作った！！！素晴らしい！！！！！自分で自分を褒めるスタイル！！！！！！！！！！！ pic.twitter.com/FpFTFZJPSu
— 金子幸三郎@未経験エンジニア (@Kosaburo_Kaneko) 2018年6月7日
夜ガチャガチャいじってて突然閃いた勢いでツイートしちゃいました。あと日付もeach_with_indexとか使ってごにょごにょやるとできるということに気づけました。ググっても出てこないんすよここら辺。そのうち記事にしようかなと思います。
難易度が上がれば上がるほどピンポイントでの解決法はGoogle先生も知らないことが増えるので、蓄えた知識と経験を応用させて解決しなきゃいけません。これができたことがすごく嬉しかったです。あーエンジニア面白いなーって改めて思いました。
スプリントレビュー
毎週月曜から土曜までを1スプリントとして区切っていて、土曜はメンターさんのレビューが入ります。Pairsでは初めてのスプリントレビューでした。
僕が作ったメッセージ機能をメンターさんに見せたところ、
メ「Ajaxですか？」
僕「違います」
メ「Ajaxにしましょう」
〜終了〜
…
裏側の苦労とかは別によくて、必要なのは機能なんですよ（泣）
基本的な機能は実装できてたから突っ込むところは特になかったのでこんな感じであっさり終わったんだろうという超ポジティブ思考でいきます。
工数見積もり
見積もり失敗
第一スプリントが終了したのでチームで振り返りをしました。
結果的に僕が担当したメッセージ機能も完成はできず、各機能も部分的にしか実装することはできませんでした。それ自体はまあ、それはそれで仕方ないのですが、問題はこれが当初の見積もりと大幅な差があったことです。
先週各機能の見積もりをやったという話をしましたが、その時には第一スプリントで各自が担当した機能は全て完璧に実装完了して、プラスAWSにもデプロイした状態でスプリントレビューを迎えられるだろうという見積もりでした。
実は一度見積もりをみんなで出してみた後に「う〜ん、これって余裕がありすぎない？」という雰囲気になって開発する機能を追加したという経緯がありました。
なぜここまで見積もりと現実が乖離したかというと、各機能に必要な要素を把握しきれてなかったからだと思ってます。
僕が担当したメッセージ機能を例にとると、僕自身過去にメッセージ機能を開発した経験があったので、見積もり段階ですでに具体的な開発手段のイメージがついてました。
ですが、実際に開発を始めると
- 同じ日付のメッセージには重複して日付を表示させない
- それぞれの相手との最新のメッセージをサイドバーに表示
これらのような、「あ、これも実装しなきゃいけないじゃん。しかも実装した経験ないわ。」というものがポロポロ出てきました。なので結果的に当初の見積もりよりも実際の工数の方が多くなってしまったんですね。
対策
以下の二つの対策案にたどり着きました。
- 見積もり精度を上げる
- バッファーを見積もりに入れる
まずそもそも初回の見積もり時に把握できてなさすぎたことがあると思います。なんとなくメッセージ機能ってこうだよね、ぐらいの感覚で見積もってたのかなーと。見積もりにはもう少し時間をかけてチームとコミュニケーションをとりながら機能の全容を把握していってもいいと思いました。
ですがそれでも完璧に見積もるというのは不可能だと思います。
前職が機械メーカーだったので、納期を見積もってお客さんに出すのは日常茶飯事でしたが、最低でもプラス一週間は多めに出していました。だいたい海上輸送で機械を日本に持ってくるので、まず製造自体が遅れるリスクもあるし、海上輸送がどこかでストップしたり税関で止められるリスクもあるからです。
つまり予期しないことが発生することを見込んで、最悪そうなった場合でも支障なくプロジェクトを進められるように見積もりをしていました。まあ実際支障は出ますけど、最低限に抑えられるようにバッファーをかませていました。
なのでそのやり方をこっちにも持ち込もうと思います。
終わり
もう何百回も言ってる気がしますが、スクールに通う醍醐味はこのチーム開発だとつくづく思います。なんかもう得るものが大きいです。一人じゃ絶対に得られないものを得られます。
実際に転職する前に体験しておけばかなりスムーズに業務に移れるんじゃないかと思います。
書いてて思い出したことで、なぜ見積もりポーカーするときの数字がフィボナッチ数なのかという疑問があったんですが、いい記事をみつけたので貼っときます。
絶対にPairs完成させたいと思います。
