10
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

RUNTEQAdvent Calendar 2024

Day 21

個人開発時にも気をつけておけばよかった、と感じたこと

Posted at

はじめに

初めまして。今回「RUNTEQ Advent Calendar 2024」の21日目を担当します、sayaと申します。

2024年1月にプログラミング未経験でRUNTEQに入学し、2024年11月から都内自社開発企業にてWEBエンジニアとしてキャリアをスタートさせました。
現時点で働き始めて約1ヶ月、現在も絶賛研修期間中となりますが様々なことを学ばさせていただいております。

今回、RUNTEQアドベントカレンダーのテーマが『プログラミングでの"ワクワク"』となります。私は働き始めて1番ワクワクしたことは、「他のエンジニアの方々と1つのサービスを作り上げることで、これまでになかった新しい視点を手に入れられたこと」です。これまで個人開発を中心に行っており、チーム開発経験0で入社いたしました。
そのため、個人開発時にはあまり深く考えてこなかった事柄も多く学ばせていただいております。

今回アドベントカレンダーに記事を寄稿するにあたり、個人開発時にも気をつけておけばよかったと感じたことを書きたいと思います。
記事を読んでくださる方の参考になりましたら幸いです。

この記事は、WEBエンジニア歴約1ヶ月の若輩者が記事を書いております。
内容に誤り等ございましたら、優しくご指摘のほどお願いいたします。

エディタはVisual Studio Codeを使用しております。

目次

  1. 脳死状態で「$ git add .」コマンドを使用することの弊害
  2. 他の方が書いたコードを削除等してしまった時の対処方法

1. 脳死状態✖「$ git add .」コマンドを使用することの弊害

先述の通りRUNTEQで受講中、個人開発をメインで進めておりチーム開発へ携わったことはありませんでした。
そのため、個人開発では常に「$ git add .」で、修正ファイルをステージングに上げコミットを行っておりました。

入社して学んだことは、余計なファイル・余計なコードはコミットをしないということです。なぜなら会社で、チームでひとつのサービスの開発を行っており、どのような意図を持ってそのファイル・コードをコミットしたのか、ひとつひとつに意味を持つからです。

例えば下記のようにrails gコマンドで一気に関連ファイルを生成したとします。

Image from Gyazo

個人開発を行っていた際は、ターミナル上で$ git add .を入力し、何も考えず全ファイルをコミット、PR作成しマージまで行っていました。
そのため、入社してPR作成時も同様に「$ git add .」を実行し、そのPR内容とは関係ないファイル・コードまでコミットしておりました。

その際メンターの方に教えていただいたことが、「余計なファイル・余計なコードはコミットをしない」ということです。当たり前の内容かと思いますが、これまで個人開発しか経験してこなかった私にとってはとても勉強になりました。

現在はVSCの左側、上から2番目に配置されている「Gitのソース管理」上から、タスクに関係するファイル・コードのみをステージングに上げコミットしております。(「6」と付いているマークがソース管理ボタンです。)
Image from Gyazo

例)今回のタスク要件に関わってくるのはcontrollerとviewファイルのみなので、2ファイルのみをステージングに上げてコミットする。
Image from Gyazo

必要コード・ファイルのみをコミットすることにより、他の方がPR内容を見た時に何故今回はこのファイルとコードを修正・追加したのか?というのが一目瞭然です。
反対にタスク要件外のRSpecファイルなどが入っていると、なぜ入っているのか?と
不要なファイルやコードが増えてしまうと、他のエンジニアの方の時間を奪ってしまいます。

2. 他の方が書いたコードを削除等してしまった時の対処方法

こちらに関しても、入社してから学んだ視点です。
個人開発の場合、自分のコードなので何を書いたのか遠い記憶でもうっすら覚えていること、また最悪多少コードの書き方が違くともなんとかなってしまいます。(バグが起きても、コード内容を忘れてしまった自分に責任があるので)

しかし会社のコードはそういきません。
まして入社1ヶ月で会社全体のコードを把握しているわけもなく、誤って削除してしまった...なんて時には、ましてそれが他機能に影響のあるメソッド定義箇所であったりしたらもう大変です。
そんな時に会社の先輩に教えていただいたのが、VSCの拡張機能のGitLensです。

GitLensの特徴は、こちらの記事にわかりやすくまとめられておりますので、ここでは割愛させていただきます。
今回は、前回のコミット時のファイルと現在のファイルの変更箇所の差分を確認できる「Open Changes with Previous Revision」の機能に関してのご紹介です。

下記、例としてviewファイルのコードの一部を消してしまった時の対処法です。

⚫︎正しいコード
Image from Gyazo

⚫︎誤って一部コードを削除してしまった
Image from Gyazo
1枚目と2枚目を比較するとわかりますが、if文を誤って削除してしまったとします。
すぐに気がついてcmd+Zで戻せる可能性もありますが、他の方の書いているコードだと消してしまったことすら気がつかないことも多いと思います。(私自身はそうでした....)

そんな時この拡張機能が入っていると、右上に表示される「Open Changes with Previous Revision」で、
前回のコミット時のファイルと現在のファイルの変更箇所の差分を確認できます。(左から2番目のボタン、VSC全体では右上に表示されます)
Image from Gyazo

このボタンを押すと、左側に前回のコミット時のファイル、右側に現在のファイル変更箇所が表示されます。
Image from Gyazo

このように表示することにより、誤ってコードを削除してしまったり、元のコードに戻したい時にも確認することができます。
一人で開発していた時には使用しなくても何とかなりましたが、今は入れていてよかったなと思う拡張機能の1つのため今回記事にいたしました。

最後に

RUNTEQではチーム開発を行っている方も多いですが、私のように個人開発しか取り組めない方も多いかなと感じたので今回の記事を書きました。
最後までご覧いただきありがとうございました。

10
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
10
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?