はじめに
弊社ではMicrosoft Azureの勉強会や資格試験対策勉強会などを通して社員が各々技術力の向上に取り組んでいます。ですが、勉強したことを実際に仕事で活用できるようになるにはまだ壁があると感じていました。
そこで私の所属する課では実際に社内用システムを作りながら学習を行うことにしました。先輩社員がレビュー等を行い、設計や開発は若手社員で行いました。
同じようにチームの技術教育で苦労されている方の参考になれば幸いです。
作ったもの
今回は「社内図書管理システム」の開発を課題として取り組みました。弊社には書籍購入補助制度があり、オフィスの本棚に自由に借りれるように本が置いてあります。借りる際は紙の名簿に名前を書く運用ルールとなっており、これをシステム化しようというのが今回の開発ターゲットです。
借りたい本のバーコードをバーコードリーダーで読み取り、自分の社員番号を入力して本を借ります(本当は社員証から社員情報を読み取りたかったけどそこは頓挫)。返す際は社員番号を入力すると現在借りている本が表示されるので、返す本を選びます。
使ったミドルウェア・フレームワークとか
- PostgreSQL
- Vue3+Vuetify
- Spring Boot
準備
ソースコード管理
今回はGitLab CEをサーバにインストールして使用しました。
開発環境
VSCode+WSLの定番の環境で開発は行いましたが、WSLはなかなか面倒が多いので(ネットワークがうまくつながらないとか)ここは他の方法のほうがよかったかなと思います(Linuxマシンを使えるのが理想的)。環境構築の手順はソースコードと同じようにGitLab上で管理するようにし、新人メンバーが入っても対応できるようにしました。
反省点・振り返り
設計・開発を行ったメンバーとレビューを行った先輩メンバーからのコメントです。
DB設計
NOT NULL制約の検討
NOT NULLがあるべきだったカラムにNOT NULL制約がついてなかった。設計中は見落としがちですが、気を付けるようにしたいですね。
本の貸出と返却の履歴を別テーブルに分離
「今借りている本」と「これまで借りた本(返却済)」を別テーブルで扱うように設計していました。
一つのテーブルで「今借りている本」と「これまで借りた本(返却済)」両方扱う設計とすることもできますが、こうすることでまだ返していない本の一覧を取得するAPIでは貸出状況テーブルの内容だけをselectすればよいことになるので、設計がシンプルになります。設計したメンバーはそういったメリットをあまり意識してなかったようですが。
API設計
RESTful APIな設計でなかった
レビューの際にも気になってましたが、ここで指摘して全部直させると結局「先輩に言われた通りに作った何か」になってしまうと思ったのであまり口出しはしませんでした。今後設計のメリットとデメリットを理解していってくれればいいと思います。
実装
実装が一つのクラスにまとまってしまっていた。イメージは以下のような感じ。
@Controller
public class MainController {
@RequestMapping(method = RequestMethod.GET, value = "/...")
public ResponseEntity<ResBean> api1(/* リクエスト */) {
// データベース処理...
// レスポンス用に加工とか...
}
@RequestMapping(method = RequestMethod.GET, value = "/...")
public ResponseEntity<ResBean> api2(/* リクエスト */) {
// ...
}
}
徐々に実装を進めていったので、リファクタリングするタイミングがなかったのも原因の一つだと思うので、今後は見直すタイミングを入れるようにしたいと思います。
その他
今回の課題は業務の合間に取り組んだため、誰がどこまで作業して次のタスクが何か把握しにくいとの意見がありました。私はGitLabのissueやwiki機能をもう少し活用してくれればいいかなと思いましたが、ここは課題を始める際に明確に指示したほうがいいかもしれません。
まとめ
NEOSYSTEMではこんな感じで楽しく(?)学習に取り組んでいます。一緒に働く仲間を募集中です。