はじめに
初めまして！織物産業が有名だった(最近盛り上がってきた)とある町のベンチャー企業で学生エンジニアをしているSoです。
ベンチャー企業で外注で案件をいただくようになって１年経ったので案件の取り組み方について備忘録として残します。
あくまで今段階の自分がどうやっているのかまとめたものですので、一般的には異なった方法が取られているということもあるかもしれません。
設計から行う案件はほぼなかったので、ここでは既存のサービスに対する機能追加・各種修正の案件を取り扱います。
0. 知っておいたほうがいい基礎知識
- Git
コミットやプッシュ、プルリクエストといった基本的なものに対して、その用語がどのような意味なのか知っておくと良いです。
よく使うもの- コミット/Commit
- プッシュ/Push
- プルリクエスト/Pull Request
- ブランチ/Branch
- マージ/Marge
- プル/Pull
- ターミナル操作・コマンド
Lunixの操作だけでなく、Dockerを操作するためのコマンドなどがあります。 - データベースを触る場合はSQL文
データベースはSQLが用いられていることが多いため、基本的な構文については知っておいて損はないです。
1. プロジェクト・サービス把握
既にプロジェクトについてある程度理解している上で案件に取り組む場合は別にして、初めてのプロジェクトに取り組み場合はサービスについて理解することが重要です。
なぜならサービスを理解しないと実装がうまくいかなかったという実体験があったためです。
案件をもらい、具体的にしてほしい作業が決められていればそれをすればよいだけですが、実装内容にサービス特有の機能が含まれているとそれを理解する必要があります。
ざっくりとサービスを理解するためには、
- 誰に向けたサービスであるのか
- どのような機能を提供するのか
ということを調べます。
Wikiがある場合にはそこにサービス概要が書かれていることがあります。
2. 案件理解
サービスを理解したら、次に案件について理解します。
案件の内容が要件だけの場合、実際にどのように実装してほしいかのすり合わせが行われていない状態となっています。
「すり合わせ」というと会議でも開くのかというと、そうではなくSlackやGithubで担当者に確認・質問するだけでよいです。
例えば、案件に「〇〇のリマインド送信」であれば、リマインドは何日前に送るのかとか、どういう媒体でリマインドを送るのかということが実装においては分からないこととなってきます。
流石にこの程度は要件化されていることがほとんどですが、要件から実装・機能を考えたときに分からないことがあれば質問しておきます。
3. コード確認・実装前の確認
初めてのプロジェクト・システムの場合、ソースのファイル構造が分からないこともあります。
自分が実際にどこに案件の機能を実装するのか考えておきます。
はじめのうちはメモなどに残しておくと後から見直せて便利です。
実装を進めていくと、コードの構造や１つの実装に頭がいっぱいになるので実装全体の見通しを立てておくと後で「あれ？あとやることなんだっけ」となることが少なくなります。
4. 実装
ここまで準備ができたら、いよいよ実装です。
調べ物をして、実装の見通しも立てているので、基本的にこれに沿ってコードを組んでいけば実装はできるでしょう。
コードの書き方、見やすさ、綺麗さはセンスによるところもありますが、経験によるところが大きいので初めのうちはどんどん書いていきます。
見やすさで指摘される部分としては
- インデントが不適切
- 不要なコードをコメントアウトとして残す
- 深すぎるネスト
- あまりに多すぎるコメント
などです。
5. テスト
コードの実装が完了したら、実環境でテストを行います。
特に条件分岐をしているところなどはその条件を実環境で再現して、テストを行います。
最終的には利用者がサービスを使うわけなので、そこで念入りにテストしておけばイレギュラーが無ければ本番でもきちんと動くでしょう。
テストコードを書いても良いですが、初めのうちは実際にサービスを使ってみて動くかテストすることが自分は多かったです。テストコードを書けなかったということもありますが...笑
6. PR・レビュー
これで本番環境に上げて問題ないという段階までテストを行ったらコミット・プッシュしてPR（プルリクエスト）を出します。
PRを出すときに実装内容や自分で行ったテストを示しておけば担当者の方のチェックが楽になると思います。
PRを出し、担当者がコードレビューをしてくれれば、コードの二重チェックを行えます。
いきなりmainやmasterブランチといった本番環境にプッシュをしてしまうと、CI/CDツールのデプロイやビルドが失敗してしまったり、他の人の開発に影響を与えてしまうため、行いません。
まとめ
自分が案件をもらっていつも行っている作業をまとめてみました。
まだまだ駆け出しなのでこれからもっとやりやすいやり方があるかもしれません。
Qiitaに初めて書きましたが、なかなかうまくまとめられず汚い文章ですいません！
読んでいただきありがとうございました。