2️⃣
今年の 4 月から GMO ペパボでエンジニアとして働いています。
8 月 18 日から SUZURI 事業部に配属され、エンジニアとして SUZURI の開発をおこなっています。 二ヶ月ほど実際に業務をしていくなかで学んだことなどを書いていきたいと思います。各内容で影響を受けた記事やおすすめの記事があれば貼っておきます。
CS さんが使う管理画面の改良を行なっていました。誤操作をソフトウェア側で防げるような仕組みを開発していました。 エンジニアは管理画面の一部機能しか使わないため、自分の思っていた運用フローと CS さんが行なっている運用フローが違いました。システムの一部の処理では処理がさまざまな制約から直感的に考えうる仕様とは異なっており、自分の知らないことが多くありました。
今回は CS さんでしたが、実際に利用している方からフィードバックをもらう事で、自分の知らない事に気づけました。 決済、発注、画像合成など触ったことのない領域は、詳しい人に聞くことで、問題が即座に解決できました。また、自分の理解がそもそも誤っていることにも気づけました。 悩んだことや、わからない事は積極的に聞くべきだと、あらめて実感しました。
タスクは、工数見積もりをして、期限を設定します。しかし、工数見積時は想定できていなかった部分にも手を加える必要が出てきて、期限通りにタスクを終わらないことがありました。 1 on 1 で相談したところ、 「期限の前日に期限に間に合いません！」ということが起きないよう、タスクの進捗を見ながらチームで相談し、期限を随時アップデートしていく事も期限との向き合い方として大事と教えてもらいました。 それからは、進捗を定期的に伝えることを心がけました。また、期限をアップデートするために、自分が過去の作業でどのくらいの時間をかけたのかを意識するようにしました。実際に最近のタスクでは、プルリクを出すまでにかかった日数を記録しています。 そのお陰もあり、最近のタスクでは工数見積した工数でタスクを終えることができました 👏
Ruby on Rails でバックエンドの実装を行なっている際、命名に悩む場面が多く、コードレビュー中でも命名について、いろいろ教えていただきました。
Railsアプリ野生のカン pp.38-58 にあるように名詞で調整することで REST に思想則った書き方をすることを学びました。 わかりやすく、思想に則った命名ができるようにしていきたいです。
WEB ＋ DB PRESS vol.129 で React17 から React18 にバージョンアップされた際、React17 の Strict Mode に適合したコンポーネントは React18 において問題のある挙動の発生を免れたとありました。このように、フレームワークの思想に則ることで、バージョンアップで動かなくなることや、メンテナンスコストの増加を防げることがわかりました。
上記のカイゼン瓦版にもあるように、デザイン詳細ページの OG の実装をしました。 OG の実装が頻繁に行われないため、仕組みを理解している人が少なく、OG を庭にできました。 その後、OG についての質問や相談に対応できるようになりました！
庭と表現してるのはこの記事にとても影響を受けているからです。
コードを書いたら、テストも書きますが、テストについてわからないことが多く、調べていくうちに結構時間を使っていました。もっと、スムーズにテストを書けるようになりたいなと思いました。
テストで一番今のところためになったのがtravel_toです。テストの実行時に時刻を固定することで、テストの実行した日時に影響を受けず、テストを実施できます。
仕事をしている時に、困ったら調べ、断片的な知識は得ることができてますが、なかなか技術書を読んだりということができていませんでした。 最近は WEB+DB PEESS を読んでいて、ある程度の体系的な知識を得るようにしています。 1 つのトピックに対して、まとめられている本はどうしても途中で読まなくなってしまうため、技術雑誌を読みながら、慣れていきたいです。
管理画面、OG、画像合成など、2 ヶ月の内に様々なものに触れることで、多くの学びや自分に必要なことがわかりました。 今後も、もりもり頑張っていきたいです！！
SNSへシェアする