ある案件の前半のフロント開発を振り返る
忘れる前に某案件の前半を振り返ってみようと思いました。
いろいろご意見欲しいです。
後半についてはナレッジ共有会とかで説明されるかも。
使用技術について
Nuxt Composition API
バグはあったが、致命的なものではなかった
ローカルで困る挙動あった
Tailwind.css
人によっては慣れるまでに時間がかかっていた
→マークアップの進捗遅れに関係あるかも
デザイン上のサイズとズレが生じていた
(個人的に)慣れると楽に感じた
Vuex ORM
↑2つの学習も合わさって、学習コスト高めに感じた
過去に勉強会で扱われてました↓(勉強不足だった。。)
メンバーがあまり触ったことない技術を取り込んだ経緯は何かあったんですか?
→リーダーの好みで取り入れたと言えそう
気になったこと
社内ナレッジ少なめの技術の妥当な採用数は?
コンポーネントについて
コンポーネントの切り出し方については特筆するものはない気がする
大きく分けると、汎用とプロジェクト専用のディレクトリがあった
※ここでの汎用は別のプロジェクトにも使いまわせるという意味
→汎用にするコンポーネントの基準をリーダー以外あまり理解できてなかった気がする
→プロジェクト内で汎用っぽいやつも置かれてた
気になったこと
コンポーネントの自動インポートって活用しますか?
宣言ジャンプ使えないので、明示的にimport のほうがいいのかなとおもってました。
命名規則について
変数名・メソッド名においてケース等を特に指定しない方針だった
→アサインされたばかりの人をことごとく困惑させていた気がする
気になったこと
html内でコンポーネントを書く時、パスカルケースとケバブケースのどちらで書きますか?
明示的に import するならパスカルケースのほうが検索に引っ掛けやすいので好きですね
開発手法について
スクラム
フロントチームのみで運用
プランMTGを開催して、各スプリントの開始前にメンバー全員でタスクの見積もりをしてた
→バッファない感じの見積もりだったが、スプリントの達成度を下げる要因ではなかった印象
スプリントの終わりに成果共有MTGを開催(KPTで振り返るときもあった)
→共有はされたがレビューがあまりされてなかったかも
常にスプリントの達成度は60~70%だった
→終わらない課題は大体フロント以外の要因に影響受けていた印象
その他
途中まで画面担当者を決めずに、いろいろな画面の実装をした
※これは担当以外の画面仕様も把握するべきという考えに基づく方針
→個人的には良かったと思う
相互レビューの体制だったけど、PRが溜まっていき最終的にリーダーがレビューする流れになりがちだった
そもそもの相互レビューの目的は以下が挙げられそう
- メンバーの案件と開発の経験
- 運用上の負荷のボトルネック
気になったこと
相互レビューはうまく回っているか?
開発グループにレビュー依頼するがランダムでアサインされるのを1人にすればうまく回る
前半のまとめ
アサインされてから慣れるまでにけっこう時間を要する