はじめに
12月よりDX課から開発部の教育兼採用試験(以下「花田チャレンジ」と称する)を経て、開発部に異動してきた者です。
この記事では花田チャレンジを振り返ります。
花田チャレンジを受けた側の振り返りであり、評価した者の振り返りではありません。
花田チャレンジ概要
目標: タスクを1箇所に集約できるようなフォームの作成。(バックエンドがメイン)
背景: DX課では事業部側から日々依頼を受けている。しかし依頼の受け口が口頭、SlackのDM、スレッドと複数あるため、依頼が散らばり依頼の進捗状況や受けている依頼の量が不透明になってしまうという問題が発生している。
期間: 1ヶ月(2023年10月2日~2023年10月27日)
開発環境:
バックエンド:Golang
フロントエンド:TypeScript,React,
インフラ: Cloud Run, Cloud SQL,Artifact Registry,Firebase
その他: クリーンアーキテクチャ、軽量DDD
1日の流れ
課題説明 (30m)
Clean Architecture、DBのインデックスの適切な貼り方、Cloud Run など、その日のペアプロで使う技術・知識を提示して頂きます。
調査 (5h30m)
課題説明で提示された技術・知識について調べます。
ペアプロの事前準備 (0~1h)
ペアプロの前に済ませておく必要のある作業があれば終わらせておきます。(ローカルにDockerでDB立てて、データ保存できるようにしておくなど)
ペアプロ(1h)
コードを書きます。ただ実装するだけではなく、なぜその実装にしたのかを説明しながら進めていきます。
後始末 (0~30m)
コードを整理して GitHub へ push。
1週目
依頼、ユーザに関わるhandler,usecase,repositoryを作成し依頼の作成・取得できるようにする。
2週目
依頼に対して担当者を追加・編集できるようにする。
Cloud Run 上でアプリを動かせるようにする。
3週目
firebase を使い、認証機能をつける。
今まで作ってきたエンドポイントをtoken必須のプライベートAPIにする。
テンプレートを使い画面を作成し、バックエンドと繋ぐ。
4週目
リファクタ、抜けていたテストの作成、エラーの修正など。
花田チャレンジを通してより明確になった自分の弱み
モデリング
依頼、ユーザのモデリングを行う円滑に行うことができませんでした。例えば、ユーザの役割を依頼者と担当者で分けたい時にユーザモデルにroleを持たせるべきか、ユーザモデルを継承した依頼者モデルと担当者モデルをそれぞれ作るべきか迷いました。モデリングする時に指針となる経験や知識がなかった事が原因だと考えているので、UMLモデリングを学習しようと思います。
DB設計
作成した中間テーブルがSQLアンチパターンで紹介されているアンチパターンの1つである、とりあえずIDというアンチパターンになっていました。知識不足はもちろんのこと、テーブルを作る目的を意識しせずに作業してしまったいたことが原因です。技術は目的を達成する手段だということを忘れずに開発します。
フロントエンド・Webの基礎知識
花田チャレンジでは画面を開発部の方が作成した既存のReactテンプレートを使って実装しました。そのため、フロントエンドはあまり理解できていません。個人で、同じようなフォームをテンプレートを使わずに作ってみようと思います。
フロントエンドとバックエンドを連携に、CORSやJavaScript の非同期処理の理解の浅さが原因で時間がかかってしまいました。こちらも再度学習が必要です。
ネットワーク、クラウド
アプリを公開するために Google Cloud, Firebase を使いました。どちらも初めて使うサービスこともあり、苦戦しました。ただ、原因を振り返ってみるとこれらのサービス特有の知識が不足していたというよりは、一般的なネットワーク・クラウドの知識のなさが原因でした。
記録
うまくできた箇所・できなかった箇所や所感などの記録がなく、この記事を書くときに苦労しました。記憶力が良くないにも関わらず、記録をしないとこのような事が起こるので今後積極的にメモを取ります🙇
所感
自分の弱みを炙り出す事ができ、いい経験になりました。詰まった箇所を振り返ってみると、知識としては知っていたけど実際に手を動かしたことがない箇所が多いことがわかりました。これからはinputの学習よりもoutputの学習の比率を上げていこうと思います。