エンジニアの実務1年目でコードレビューとかで指摘をもらったことを列挙

2023/04/28
2024/03/25

プログラミング

まんじ

ういっす、まんじです。

今回はギリギリ覚えてるうちにエンジニア実務1年目で指摘されたこと（していただいたこと、みたく言う）を書き残しておきたいと思います。

記事書いてる時点で1年くらい経過してしまったので、正直もうあんまり覚えてなかったりしますけど。。。

変数系

命名: それは本当に〜なのか？

Reactのコンポーネントで、なんか変なcontrollableなリストを<List>みたいに適当な名前をつけたら指摘されました。

「具体的にこれはなんなのか？」ってのを少し考えてから命名すると指摘は消えました。

説明変数入れてくれ

わりとガッツリいろいろ処理しないといけないコードでは意味不明になってくるので変数を省略しないで、値がなんなのかを読んで分かるようにしてくれってことでした。

1行でも短いほうがカッコイイ気がする時期もありますが、徐々にどうでもよくなっていって、分かりやすいし途中で名前つけよう、って感じになっていきます。

関数系

メソッドに切り出そう

これは定番ですが、何度か使う処理風だったり見通しがよくなる場合にはメソッドに切り出そうって指摘でした。

React系

memo化: これ最初しか更新されなくない？

console.log()で変数の中身を見たら再レンダリングされまくっていたのを発見して、これはuseMemoやでって思ってノリで使ったところ指摘されました。

とりあえずこの頃はReactが全く分かってなかったのによく労働してたなと思います。シンプルにいたら邪魔なだけです笑。

ちなみに依存配列ってやつです。

その他

今年見たコードで1番ひどい

あれは確か夏になる少し前の頃、初めてプログラミングで労働し始めて3ヶ月ぐらいの頃に言われました。

当時は「ハ？なんだこいつ」と内心思ったんですが、振り返ってみると確かにひどいというか、めちゃくちゃなコード（命名とかもReactのstateに全部ウンタラStateみたいな感じの完全に作法をよく知らない命名）でした。

あと短期的に見るとオブラートじゃない言葉でディスられるとムカつくんですが、中長期的に見ると思いっきりそのまんま直接的に激しめの指摘をもらうほうがなんだかんだで自分の糧になる気がします。

今の自分をちゃんと否定してもらえると考えるキッカケになる、てきな自己啓発を入れます。~~自己啓発セミナーは100万円からです。~~

コンテナは1個

これはBootstrapの話で、classのcontainerは1画面1個でいいよねみたいな話で、Bootstrapで激しくレビューが通らずに詰まったところでした。

確かに公式ドキュメントを見ると1個でいいって書いてあるけど、個人的には別に何個あってもデザイン面は変わらないことが多いのでどうでもいいなと思いつつ、これはレビュアーの主観かと思います。

ただ、公式ドキュメントに書いてある通り書く方が責任をそこに押し付けられるので、良いなとは最近思います。

workaround(迂回作)する場合は理由を書いてくれ的な

ちょっと明らかに無理やりとか変な実装をする時には理由を書いてくれればどうしても無理な場合は許す的な指摘でした。

たまにコード書いてると意図した実装ができなくて自分でも内心「ちょっと変だな〜」とは思いつつ実装することがあるんですが、そう言う場合はコードかGithub(lab)にコメント書こう！みたいな感じ。

ただ、ちょっと変な場合はworkaroundできるだけしない実装を探すことを必死こいてやってからじゃいとレビューで詰まって死ぬなと最近も思います。

参考にしたとこ書いてくれ的な

こちらも変な実装が必要になったり、今までと少し変わった実装をする時には、Stackoverflowのコメント欄でもいいから参考にしたところを書いてほしいって言われました。

確かEslintのファイルを設定する時に今はcommon.jsだとダメだったか動くかECMAScriptだと動くか、、、みたいなそういうのがあって、その時に指摘されました。

ちゃんと言われた通りセットアップしてくれ（キレ）

なんか外部のシステムとかアプリとかを使う場合に手順通りにセットアップする時があったんですけど、それが難しそうだから自己流でやって詰まって「詰まった〜〜〜助けて〜〜〜〜」ってSlackで叫んでいたら上司からキレられました。

プログラミングで労働してから何回かキレられることがあったんですが、そう言う時は金玉周辺がシュッとなります。

とはいえ、確かにキレる理由も分かります（笑）。

m1かよ😡

これはランキングベスト1位で、m1のCPUアーキテクチャで動かないDocker Containerをあんま知らずに起動しようとして詰まって、さらにあの頃は問題解決能力も低くてDockerも使い慣れてなかったので、「ウワ〜〜〜動かないよおお〜〜〜〜」ってSlackで暴れていたら上司からキレられました。

セットアップ系は仕様書っぽいものとか開発環境構築手順みたいなものをちゃんと読むのが大事とは思いつつも、とはいえ、うまくいかない時はログやらに原因も出てたりするので、やっぱ開発経験が大事な気がします。（あんまよく分からない時はそういう原因を探していくのができなかったりする）

動くのも大事だけど、、、

実務労働1ヶ月目ぐらいの時にバグ修正のタスクをしていたんですけど、そもそも何も分かってない状態でバグ修正というむしろおれがバグらせるてきなことを思いつつ、ノリでとりあえず動くようにしてプルリクエストを出した時に「動くのも大事だけど、意味を理解しよう！」みたいなことを指摘もらいまして、その通りすぎてぐうの音もでませんでした。

とはいえ、意味を理解できないからノリでやっちゃうってのはあるんで、結局、経験と慣れな気がします。

エラー文読んだり、ログ見たり、システムの全体像から原因を特定することだったり、そういうのは明らかにエンジニアの実力の部分で、正直マインド次第ではどうにもならないと思ったりします。