23
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

初心者が先輩のコードを真似してはいけない理由

Last updated at Posted at 2020-02-04

(※この記事の会話や例は、事実に基づかない説明用のフィクションです)

チームに新人が入った際の、最初のコードレビューでのやりとり

先輩「var変数ではなくconst変数を使ってください」
後輩「既存のコードに合わせてvarにしたんですけど」
先輩「既存のコードは真似しないでください」
後輩「ハァ!?既存のコードってのは、先輩が書いたコードですよ!?それを真似しただけなのに何で叱られなきゃならんのですか!?やってられませんよ!!」

「初心者は既存のコードを真似すればOK」「優秀なプログラマーは、常に良いコードを書く(悪いコードが書かれたのは、プログラマーが劣っていたから)」と、素朴に信じている人はそこそこいるようで、「そうではない」と訂正した経験が何度かあります。皆さんもあるのではないでしょうか?

しかし、よく考えると 「なぜ既存のコードを真似してはいけないのか」 を文章にしたものは見たことがなかったので、そこで思考の整理がてら書き起こしてみました。

なお、この記事で言いたいのは 「既存のコードに囚われず常にベストのコードを書いてください」 ということで、むやみに先輩を疑えと言いたいわけでも、自分の過去の過ちを糊塗したいわけでもありません。

理由1:「チャンネル回し」とか言ってた

プログラミングの常識は時代と共に変わります。

例えば、今ではどの言語にも for x in list のような「リストの要素を走査するfor文」がありますが、かつてはメジャーな言語機能ではありませんでした。

コーディングのレベルでは、「早期return」は現在では常識ですが、「returnは関数の最後に1回だけ書くべき」という説が'90年代ごろまでは幅を効かせていました。

そんなわけで、当時としては当たり前を書き方をしたのに、今から見るとベストではなくなってしまっていることはよくあります。

理由2:紅顔の美少年だった

5年前にコードを書いた時、先輩は5歳若かった。

今でこそKotlin界のデストロイヤーと呼ばれている先輩も、そのコードを書いた時には、まだ未熟なJava1年生だったのです。コード品質が低くとも無理はありません、

「あの先輩のことだから、この奇っ怪なコードにも意味があるに違いない!!」と思い込まずに、素直に「なぜこうしているんですか」と聞きましょう。

理由3:現場はマンションの一室だった

既存のコードが書かれた当時、会社のシェアは何%だったでしょうか?会社住所は社長の自宅マンションだったのではありませんか?

初期の企業がシェアを獲得するにはスピードが大変重要です。そして、急ぐ時には品質が犠牲にされがちです。 不具合があっても致命的でなければリリースしたし、可読性なんか問題ではなかったのです。

質とスピードはトレードオフではないという話もありますが、昔はトレードオフだと信じられていました)

理由4: フフフ・・・それは残像だ

最後に。忘れがちですが商用のコードは複数人で開発しています。

git blame で俺の名前が出たとしても、それはインデントを変えただけで、オリジナルのコードを書いたのは3年前に辞めたクソ野郎なので、俺を責めるのはやめろください。

キレないで :heart:

以上のように、なぜ既存のコードがクソ(なこともある)のか説明しました。

ところで、記事冒頭の会話文のように既存コードを真似しているのを指摘するとキレる人が時々います。キレるパターンには2種類あるようです。

まず、自信が無い人のパターン:

「ここでは letを使ってください」
「私は既存のコードを真似しただけなんです! 私は入社1年目の初心者なんですよ!? そんなに言わなくてもいいじゃないですか!?」

コードレビューはあなたの人格を責めているのではありません。あくまでコードの問題や、あなたの誤解を指摘しているのです。だから、たくさん指摘されたからと言って、凹む必要はありません。

(レビュワーがコミュ障で、言い方がムカつくというケースもありますが、それは別の問題です)

一方で「初心者であること」は、コードがクソであることの言い訳にはなりません。製品にクソコードが組み込まれてしまうのは、あなた1人の問題ではないからです。いやしくも職業プログラマーなら、常にベストのコードを書くように務めてください。

また、自分の技量が不足していると感じているなら、上司と交渉して、コードを書く前に勉強時間を確保したり、先輩に教わる機会を設けたりしてください。上司も、初心者がいきなりコードを書けるとは思っていないので、Noとは言わないはずです。

キレないで :heart::heart:

もう一方のキレるパターンは、自信がありすぎる人のもので:

「ここではletを使わないでください」
「才能ある俺様が、わざわざお前のクソコードに合わせてletを使ってやったんだぞ!? それに文句つけてんじゃねーよ!」

このパターンでは レビュワーもキレ出して収拾がつかなくなりがち なので、キレないでください。

クソコードが今そこにあるのは、上述のような様々な経緯があるのです。そこの事情を慮ってあげてください。また、 ソフトウェア開発の成果は、個人ではなく、チーム・組織に属するものです。 個人の有能さ・無能さには意味はありません。チーム全体のアウトプットを向上させることに注力してください。

むすび

繰り返しになりますが、この記事で言いたいのは 「既存のコードに囚われず常にベストのコードを書いてください」 ということで、むやみに先輩を疑えと言いたいわけでも、自分の過去の過ちを糊塗したいわけでもありません。

また、この記事はまともな職場を想定しています。狂った職場では別の対処をしてください。

23
11
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
23
11

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?