LoginSignup
41
16

More than 1 year has passed since last update.

2年目のペーペーが1年目のペーペーにアドバイスするよ

Posted at

はじめに

エンジニアになってから1年がたち、4月からは新人の方たちも入ってきました。
新人のコードをレビューしていると「うわ〜これ自分もやっちゃってたな〜...」と思うことが度々あるので、新人のあなたが同じ過ちを犯さないで済むようにこの記事で紹介していきたいと思います。
ベテランのあなたは読まなくて大丈夫です。

書かなくてもいいコメントを「(自分が)分かりやすいから」と残しがち

結構あるあるなんじゃないでしょうか?
そもそもコメントは少ない方がいいですが、必要に応じて残す場合もありますよね。最初はこの「必要に応じて」がどのくらいのレベル感なのか掴めず、不要なコメントを量産している人は少なくないはず。
私もかつてはゴミコメント生産機でした。こんな具合に。

# 初期化
def initialize
  ...
end
# 繰り返し処理を実行
array.each do |item|
  ...
end

とは言っても最初はコメントを残すべきかどうかの判断がなかなか難しいかもしれません。
とりあえず、処理の内容をそのまま書いたようなコメントは残さないようにしましょう。

コードの修正に伴うコメントの変更忘れ

これ1回やらかさないと意識できない気がします。
修正箇所のすぐそばにあるコメントならまだしも、ファイルの冒頭に書いてある全体を説明しているようなものにはなかなか目がいかないですよね。
最後に見直す時は、修正箇所だけでなくファイル全体に目を通す癖をつけるといいかもしれません。

メソッド名や変数名が地獄

プログラマーには生涯付きまとうであろう、命名問題。
半分慣れな部分もあるよな〜と思いつつ、でかいテーマであることに変わりはないので挙げさせてもらいました。
最近はChatGPTに命名候補をいくつか出してもらうなんて人もいるようですが、まずは自分で考えてみることをお勧めします。特に最初のうちは。

自分が書いたコードが通るようなテストケースしかない

テストがテストになってない問題。これ難しいですよね、、、
どうしても自分が書いたかわいいコードを前提にテストを書いてしまう。しょうがないっちゃしょうがないですが、許すわけにはいきません。
個人的に、他人が書いたテストのケース漏れを指摘するのは非常に難しい気がします。なので、テストは慎重に冗長に書きましょう。「このケースいるかな?」と迷ったらとりあえず書いときましょう。
通るケースを想像するのは容易いので、「こんな場合だと通らないかもしれない」を意識的に考えるようにしてみるといいかもしれないですね。

不要になった定数やメソッドの消し忘れ

こうやってゴミコードが増えていくんですね〜。
定数やメソッドを消す修正をした時は必ず全件検索して、他に使われている箇所がないことを確認したうえで全世界から消し去りましょう。
使われていない定数やメソッドに遭遇した時、人は「これ本当に消していいのか?」と削除するのを躊躇います(よね?)。なので、使われなくなったその瞬間に消すのが最も理想的です。
逆にこれができていると、「お、よく見ているな」と思慮深い人間だと思ってもらえます。

デバッグコードの消し忘れ

あるあるですが犯罪です。思慮の欠けた人間だと思われます。
最後にコミット内容を確認するようにしましょう。

最後に

コードを書くときの基本的な心構えを知りたい人は、『リーダブルコード』という本を読んでみることをお勧めします。プログラマーなら読んでおいて損はないんじゃないかと思います。
他にもやりがちなミスがある人はぜひ教えてください。

41
16
1

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
41
16