自己紹介
- 実務経験4ヶ月目~(PHPからRubyに切り替える)
- フロントエンド開発(React,Next.js)に初参画。バックエンドでは初のテスト実装。
- QiitaでやZenn技術やマインドの記事を発信し、300記事以上投稿
- 未経験時代に共同開発をやっていた時に経験者と未経験がいる中でリーダーを務めた
- オンラインコミュニティーで勉強会を主催する
情報発信
QiitaやZennに300記事以上投稿し、アウトプット。
概要
細かい詳細は都合上書けないのですが、可能な範囲で書いたのでご了承ください。
自身2度目の開発案件(株式会社DEPARTURE)に参画した。
1.受講生を管理する教育サービスの開発案件。
バックエンドとフロントエンド担当。こちらがメインの案件です。
・人数(4名)
リーダー1名、レビュアー2名
環境
- テキストエディタ
VSCode
- インフラ
Docker
AWS
JavaScript
TypeScript
React
Next.js
Ruby
Ruby on rails
ngrok
受講生が質問したり、日報を書いたりした時に履歴を管理できるサイトで、
受講生の進捗状況なども確認できるサイト。
2.飲食店向け農産物の販売サイトの開発(RSpecを使ったテストの担当)案件。
・人数(9名)
・バックエンド8名
リーダー1名、レビュアー2名
⚫︎環境
- テキストエディタ
・VSCode
- インフラ
・Docker
- サーバーサイド
Ruby(3.1.0)
Ruby on Rails(7.0.4)
RSpec
RuboCop
多種多様な新鮮野菜などを、スマホやPCから注文すれば。
自社およびパートナー便により、
首都圏を中心に全国主要都市の飲食店に直接配送するためのサイト。
タスクやスケジュール管理などのツール
共通で以下のツールを使っていました。
1.GitHub
2.Slack
3.Postman
タスク(フロントエンド)
フロントエンド開発は初参画でした。
⚫︎フロントエンドの環境構築
リーダーの方が作ってくれた環境に沿って構築する際に環境構築がうまくいっていない人にもアドバイスをするようにした。経験年数が長いエンジニアでも環境構築は苦労するので、どういう意図でこのような環境を作ったのかを考えていきたい。
●Footerの修正
MUIコンポーネントを使った実装でした。Tailwindを初めて使用した。
TailWindを使った実装を身につけることができた。
⚫︎PR履歴の作成
かなり時間がかかるチケットで、20ファイル以上変更したのは開発現場に入ってから初だった。
PR一覧のテーブルのbodyとheadの両方も作ったので、1人で3人分のタスクでした。
⚫︎PR履歴のhead追加
上のタスクでこなす
⚫︎PR履歴のbody追加
上のタスクでこなす
⚫︎インポートエイリアスを使ったリファクタリング
コードを見やすくするためにコードの整形をして、他の開発者やリーダーからもコードが読みやすくなったと現場から評価をいただいた。
⚫︎ISSUEの作成
初めて自分でISSUEを作った。今どういうISSUEが必要なのかを考えて、現場の業務改善に務めていきたい。
⚫︎interfaces/index.tsを個別ファイルに分割
ファイル構成も見やすくするにはどうするかを学んだ。
⚫︎ボタンの共通化
共通化の概念を理解できた。
⚫︎PRの一覧をfetchを用いてPRデータを取得して表示するように修正
まだバックエンドを作っていなかったので、ダミーデータを作成してapiフォルダを作って、
fetchを用いてデータを取得。
フロントエンド開発で学んだこと
1.Tailwindを使ったこと
Tailwindを初めて使い、CSSよりも便利だと感じた。
2.実装のやり方はプロジェクトに合わせる
動作上問題無くても、コードの書き方は現場に合わせることが大切と学んだ。
3.React,Next.jsの基本
インプットしかしていない状況での開発だったのバックエンドの業務よりかなり苦戦した。
4.TypeScriptを使った案件に参画
実務でやる機会がなかったので今回初めて実務で扱うことができた。
5.PRを出す前にESLintやPrettierを使うこと
コードの品質のためにもコードの整形は毎回やることが大切だと学んだ。
6.importエイリアスを使うこと
コードが圧倒的に読みやすくなる。
7.useStateやuseEffectなどの基本を理解できたこと
実践で使って使い方が理解できました。
8.Issueの作り方
今何が問題なのかを考えて作るので、かなり学びが多かったです。
9.フロントエンドでAPI関連の実装
自分が実装した段階ではバックエンドの開発はできていませんでしたが、
API関連の実装を学べました。
10.どうすればコードが読みやすくなるかを考える
自分より経験がある人のコードを読むことができたのが収穫でした。
11.Issue通りに実装すればいい訳ではないこと
間違っていることもあるし、それをフォローするのがエンジニアの仕事。
ロボットみたいにIssueを捌くのではなく、どうすれば売上が上がるかも考えてやっていく必要がある。
苦戦したこと、指摘されたこと、反省点、改善点(フロントエンド)
1.Footerはfixedやabsoluteで固定しないこと
Footerを画面の下に固定するとユーザー体験が悪くなります。基本どのサービスもフッターはflexやabsoluteを使わないです。当たり前だが、初めてフロントエンドの実装をした時に指摘された。(フロントエンド1ヶ月目)
2.pagesフォルダの中のusersフォルダの中にユーザーのみが利用できるコードを使う
PRの履歴ページを作っているときにpagesフォルダにPR履歴ページを作るためのファイルを作っていたのですが、これだとユーザーしか閲覧できないようにならず、ユーザー以外も見れてしまうと指摘が入った。(フロントエンド1ヶ月目)
3.commonファイルはnavやheaderなどのどの画面でも使うファイルでしか使わない
ファイルで再利用することと勘違いをしてしまっていたので指摘が入りました。
headerやnavなどが共通ファイルにすることが多いと学んだ(1ヶ月目)
4.他の実装者のコードを参考にして書き方を合わせる
バックエンド開発でも指摘されたのですが、フロントエンド開発でも同じでした。
5.インポートする際にライブラリの順を分けておくこと
reactならreact、TableはTableで分けておくという意味。
import React from "react";
import { useState } from "react";
import Table from "@mui/material/Table";
import TableBody from "@mui/material/TableBody";
6.チケット以外の変更はPR欄に書いておく
チケット外の対応でインポートaliasをサービスのファイル全体に適用させることになった時、
PR一覧に書いていなかったのがPRで指摘が入った。
後削除したファイルの理由もちゃんと書くべきだった。
7.ISSUEを作る時に苦戦したこと
以下のことを指摘される。
1.他の人が1ヶ月後にやることを意識して書く
2.わかりきったことは書かない
3.概要を書く時はWHY 実行手順はWHAT で書く
特に1が難しい。
コツは文章が長すぎると伝わるけど、短すぎても伝わらない。
この中間をうまくやることが大切。
だから日々日報やドキュメントを書いて言語化するトレーニングが必要だと痛感した。
8.export default Buttonじゃない場合
1つしか処理がない場合はexportでまとめる。
タスク(バックエンド)1の案件
⚫︎RuboCopの導入
bundle installをコンテナ内でやらなかったら不要なファイルまで変更されてしまった。
この点が反省点だった。
⚫︎ユーザーの日報一覧取得APIの作成
コンソールの使い方やJWTの検証など、BaseControllerの継承などを学ぶ。
テスト環境の設定やcredentials、FactoryBotを使ったrspecの実装などを
学んだ。
⚫︎日報一覧取得APIの作成
RSpecのテストの実装の理解が浅いせいで、このチケットは苦戦してしまいました。
タスク(バックエンド)2の案件
RSpecやRuboCopを使ったテストの実装が多かった。
⚫︎RSpec/NestedGroupsの修正
このタスクではRuboCopを起動した時にネストが深すぎて、RuboCopがあまり通らなかった。
テストでも開発でもネストをあまり深く使いすぎるとコードの品質に影響が出ると学んだ。
⚫︎Style/CommentAnnotationの修正
このタスクではRuboCopを起動した時にコメント欄でエラーが発生した。原因は# 〇〇:~とコメントを書く時に# 〇〇:の後にコメントを書いていなかったことが原因。
動作上問題無くてもコメントもわかりやすく書くべきだった。
⚫︎ RSpec/SendPdfService.insert_logの修正
異常系テストのタスクだった。現場に入った時に書いてあったコードにミスがあり、
そのミスに気がつかず、テストが通らず大苦戦し、オンスケにならなかった。
もっと全体的な処理のつながりを見ていけば速く解決できた。
⚫︎RSpec/pdf.rbの修正
FactoryBotを現場で使っていなかったのが苦労した。
テストコード、テストデータ、コードのどれが間違いでテストが通らないのかがわからず苦戦した。
デバックを使いながら考えられる原因を1つずつ潰していった。
どういうコードは見づらいのかを自分でも気づくことができた。
⚫︎RSpecのテストコードの修正
ネストなどがごちゃごちゃになっていたので綺麗にコードをリファクタリングをした。
バックエンド開発で学んだこと
-
現場によってルールが変わること
現場によってルールが変わるので今後も上長や先輩に確認したい -
デバックの手法はbinding.pryだけではない
binding.pryしか知らなかったので新しく知れたので良かった。
3.git addやcommitの取り消しなど
前回は使用しなかったが、今回初めて使用した。今後も使うことが増えそう。
4.PRを出す前にRuboCopを使ってコードの整形をすること
RuboCopを起動してからPRを出した方がいいと学んだ。
5.細かい空行などに気を配り、プロ意識を持つこと(PRを出す前に自分でレビュアーをやる)
コードは長ければいい訳ではない。短いと後から来た人が読みやすいようにする。人のために書く意識を持つこと。リーダブルコードにも載っていたのでしっかり身につけていきたい。
ex)
誰が読んでもわかるコードにコメントはいらない。複雑な処理にはコメントを書く。など
5.ハッシュを使うとわかりやすくなること
マージされてしっかりとチケットをクリアできましたが、1点アドバイスをいただいた。
RSpecのテストの中で以下のようなコードがあった。(実際のコードとは変えています。)
context '不正な値が入力された場合' do
context '〇〇がnilの場合' do
before { order[:details][0][0] = nil }
この[0][0]は現場にいればわかりますが、全くの初見だとわかりづらいです。
ハッシュとかにすると初見の人でもわかりやすいみたいです。
7.バグを見つけたらバグ報告をする
Issuesを作ってBugやコード改善の報告をすることを学んだ。
自分からコードの改善をもっとできるようにしたい。
8.バックエンドのAPI開発は基本curlかPostmanで挙動確認する
最初ブラウザに表示されなかったので、かなり苦戦していたが、
実際はcurlでJSON形式でデータを取得できればよかった。
9.railsコンソールの使い方
ユーザーデータがない時はコンソールでデータを作るということを最初思いつかなかった。
今回の案件で使いこなし方がわかってきた。
10.credentialsやenvの環境変数などのtest環境の意識があまりなかったこと
当初test環境ができていないにもかかわらずrspecが通らずに苦戦してしまっていた。
開発環境、テスト環境、ステージング環境、本番環境に対する意識ができるようになったのがよかった。
苦戦したこと、指摘されたこと、反省点、改善点(バックエンド)
1.コマンドが入力できず苦戦した
最初のタスクでRuboCopを使用した時に、コマンドが入力できなかった。
$ make bash
を入力した後にRuboCopのコマンドが使用できた。
現場によって環境が変わるので先輩に必ず確認をこれからすべきと思った。
2.日報などを書くときは数字を使う
数字で何件終わったとかではなくて残り何件など上長が把握しやすいようにコードを書くべきだった。
3.チケットの背景までを上長に「何が目的で、どう取り組むか」を整理できていなかった。
ただ目の前のチケットをこなすのではなく、このチケットの目的などを考えながら実装していなかったと反省した。
(案件参画1ヶ月目)
4.コメントも細かいとこまで綺麗に書く
RuboCopを起動時に、コメントの空欄でエラーが出た。細かいとこだけどコメントの小さな空行なども気をつけたい。
5.マージした後ほissueをcloseすること
チケットが終わったにもかかわらずチケットをオープンにしておくと
チケット管理ができなくなるので次回からは気をつける。
6.デバックを使いこなすこと
テストコードの修正をしている時になかなかエラーの原因がわからずに苦戦していたところ、
「デバックをもっと使いこなせる」と指摘された。実際は開発するより、デバックしている時間の方が長い。
7.元々書いてあったテストコードが汚かったのでバグがでてしまい、エラーの解消に苦戦したこと
以前テストコードを書いた方のコードのインデントやネストがぐちゃぐちゃだったために、
エラーが出てしまい、その後処理に苦戦をした。
この経験からコードを綺麗に書かないと他のメンバーに迷惑がかかると学んだので
コードは綺麗に書こうと思った。
8.PHPの書き方から頭が抜けなかったこと
前回の現場がPHP,LaravelだったのでRailsで開発にもかかわらずLaravelの書き方をしてしまった。
新しい言語やフレームワークにも慣れていくのが大切だと思った。
9.FactoryBotを使わずにテストをしていたこと
現場ではFactoryBotを使われていなくて手動でテストデータを作成したのが大変だった。
10.配列が多い時は%Wを使うこと
11.繰り返し同じメソッドなどが使われる時はリファクタリングして後の人が見やすいようにすること
何回も同じメソッドがあると他のエンジニアがコードを読みづらくなるので、
他の人が読みやすいコードを心がけたい。
12.これからやりたいことを言語化する
これができないとそもそもコードを書くことなんかできないです。
実装する前にまずはやりたいことを言語化するために2行程度の簡単な言葉で説明する。
そしてコードを説明しながら書く。
13.APIのデータ取得はcurlかPostmanがメイン
上記のことの認識がなかったので不要な作業や時間がかかってしまった。
ゴールを確認するのと、上のことを認識した上で実装していきたい。
14.タスクのゴールを明確にすること
想定の挙動になっているにもかかわらず、想定通りになっていないと勘違いをしてしまい、
余計な労力を使ってしまった。ゴールはどうすればいいのかを必ずチケットの作成者に確認を入れるようにしたい。
15.今自分がいる環境を意識すること
開発環境、テスト環境、ステージング環境、本番環境の意識を持つことが大切だった。
テスト環境のenvやcredentialsがないのにテストを通らないのは当たり前だった。
この辺の認識をしっかりと持ちたい。
16.問題の切り分けをやること(いきなり手を動かすのではなく、まずは考える)
APIの実装でcurlでちゃんとデータは取れていて、テストで問題があったにもかかわらず、
モデルに問題があるみたいにエラーの特定で仮説を立てることができなかった。
17.簡単なコードなら変数は不要。
orderしたりwhereなどして、長くなる場合は変数に入れるといい。
class Api::V1::Web::POstController < ::Api::V1::Web::BaseController
def index
posts = Post.all
render json: posts, status: :ok
end
end
を
class Api::V1::Web::POstController < ::Api::V1::Web::BaseController
def index
render json: Post.all, status: :ok
end
end
みたいにする。
-
APIのバックエンド開発でブラウザにて挙動テストするものだと思っていた。これは覚えていく。
-
railsのコンソール操作が不慣れだった。(データ作成してってなってもすぐにはできなかった)
実際にコマンドを打って練習して行きたい。 -
curlを実行して
{"status":500,"error":"Internal Server Error","exception":"#\u003cNoMethodError: undefined method `daily_reports' for nil:NilClass\n\n daily_reports = @current_user.daily_reports.all\n ^^^^^^^^^^^^^^\u003e","traces":{"Application Trace":
#中略
のエラーを勘違いしていた。
サーバーエラーというよりかはアプリのコード内で発生しているエラーです。
undefined method `all' for nil:NilClass
は@current_userがnilにもかかわらず、
allで呼び出そうとしているのが原因です。
エラーの原因はここだった。
daily_reports = current_user.daily_reports.all
@current_user がnilになってますが、どうすればnilじゃねくてデータが入るようにするにはどうすればいいでしょうか。railsコンソールとかで入れるべきだった。
自分でこのエラーは何と言語化していきたい。
21.エラーが起きた時にエラーの意味を考えることができなかった。いきなりChatGPTを使わないようにしたい。
22.***ISSUEにこういうテストをしてほしいと書いてあった。(コントローラーに)
# ISSUE: 実装。@current_userから日報一覧を取得して返す
# 1. テストを作成する。
# 2. 実装してテストする。
違う趣旨のテストになってしまった。チケットの意図をまず考えて、質問する(書いてあることも多いのでその辺りも確認)。
23.Multi Environment Credentials関連のエラーの仮説がうまく立てられていなかったので、
仮説を立てる時なぜを毎回考えるようにしていきたい。
24.いきなりChatGPTを使ってしまうことがあるので、まずは実装する時毎回言語化する。(コメントを書きながら実装)
25.デバックでresponse_dataが取れているかまで確認すればよかった。エラーが出た時は毎回デバックを使う(脱ChatGPT依存症)
26.何のデータとテストをしたいかを何に対してテストしたいかを把握する
27.状況整理！ 仕様理解！(紙に書くようにした)
28.User.firstを勘違い。id1とは限らない
29.ネストは２つまで
30.レコード作成したが全部とれないような状況ですか？ 最後の一つだけ取れるような状況でしょうか？
という返事に対してわかりづらいと指摘されたこと
***ソースコードやスクショなどを使って説明していきたい。
成長したこと(バックエンドとフロントエンド)
1.Git操作に慣れてきたこと
Git操作で困ることは無くなっていました。
git rebaseなどのコマンドはまだ使いこなせていないが、PR出すまでの流れはわかってきた。
作業中のpullなど前回苦戦したことが今回からはできていた。
2.コンフリクトを自力で解消できたこと
前回はコンフリクトが起きた時に慌ててしまっていたのですが、今は「コンフリクトが起きそうだな」と予想ができたり、
コンフリクトが起きても冷静に対処できた。
3.PRはなるべく早く出せたこと
何も上がってこないと他のメンバーがの進捗が把握できなくなる。
PRを早めに出してフィードバックをもらいながら改善していくことが大切だと前回学んだのでそれを実践できた。
4.コードの改善の提案をするようになったこと
初月の時は任されたタスクをやるだけになってしまっていたが、わかりづらいコードがあったので、もっとこういうふうにした方がいいのではと経験が浅いなりにも自分なりに提案したのは成長だった。
5.コードを説明しながらコードを書くようになったこと
最初の頃は、何も考えずにただコピペしているだけだったが、
今何をやっているのか、何をしたいのかを言語化しながらコードを書くことができた。
6.新しくISSUEを作ったこと
自分で必要な点を提案してISSUEを自分で作ることができた。もっと大きなシステムになっていく時でも、今現場では何が必要かを考えていきたい。
7.チケット以外でインポートaliasを書き換えてコードが読みやすなり現場から感謝された
読みやすいコードを意識するようになった。そのためリーダーに提案して、 採用された。
-
コンソール操作で何をやっているか理解できるようになってきた
-
A server is already runningのエラー対応ができるようになってきた
-
class Api::V1::Web::Users::DailyReportsController < ::Api::V1::Web::BaseControllerに修正したことで、エラーが解決。継承の理解ができた。
-
既存のコードでcurrent_userがどのように取得されているかは理解できた(リクエストの Authorization ヘッダーからトークンを取得していて、特定のトークンが使われた時に、Userモデルから最初のユーザーを取ってくる)
12.前と比べたら自問自答できるようになった
ブランチのルール
developブランチからブランチを切ってfeatureブランチ作成
ex)
feature/〇〇
3ヶ月目からの感想
.今回の案件からRuboCopやRSpecなどのテストやコードの整形などのタスクが振られたこと
前回の現場は開発だけだったが、今回からは開発以外のタスクをやることがあった。
これから実務で取り組みたいこと
1.問題意識を持つこと
言われたタスクをやるだけではなくて業務改善提案などもできるようになっていきたい。
2.後から入ってきたメンバーに教える立場になっていきたい
1年以内に仕事に慣れて、後輩などができた時に自分が教える側になっていきたい
3.3年以内にチームリーダーになれるようにしたい
タスクがこなせるようになるのは1年以内で、2年以内には教える立場になり、3年以内に開発リーダーになれるようになりたい。
4.AWS(インフラ)の仕事もできるようになり、Infracture as Codeもできるようになりたい
インフラを学び、アプリがどう動いているのかを深く知りたい。
あと、今回はAWSの環境での開発ではなかったのでAWSを使って実務をこなしていきたい。
最終的にはフルサイクルエンジニアを目指していきたい*。
その他アドバイス
- responseデータはカレントユーザーのデータだけ
- createだから最後に作る
- User.first 配列の要素 id1とは限らない
出口を決める
ワーストケースを決める
テスト弱いチーム多い
弱いとこ見つけてあげる
レビューがないチーム多い
実務に入る上での有益資料
1.学習と実務の違い
学習とプログラムの違いをベテランエンジニアでスクールメンターの方の説明が載っています。
Rubyですがソースコードも見ることができます。
2.実務にアサインされたらどうするのか？
実務にアサインされたらまずどうするのかについて細かい説明が載っています。