give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

動いたからそれでOK、のその先へ 〜フィヨルドブートキャンプのメンターとして僕が大事にしていること〜

fjordbootcamp よもやま話

はじめに

これは「フィヨルドブートキャンプ Advent Calendar 2021」26日目の記事です。
adventar.org
adventar.org

すいません、ウソつきました。
昨年末はバタバタしてたのでアドベントカレンダーを書く時間が取れず、結局カレンダーも全部埋まってしまったので、本来ならアドベントカレンダーに書いていたであろう内容をこのタイミングで書きます。
なので、僕の中では勝手に「26日目の記事」ということにしています。はい。

僕がメンターとして大事にしていること

フィヨルドブートキャンプでメンターを始めてからもうすぐ2年になります。
メンターとしてどんなことをやっているのか、どんなことを感じているのか、というのは2020年のアドベントカレンダーに書いたのでそちらを参照してください。
細かい部分では変わっているところもありますが、根本的な部分は大きく変わっていません。
blog.jnito.com

今年（2021年のアドベントカレンダーだから去年か？）はメンターとして僕が大事にしていることを書いてみようと思います。

フィヨルドブートキャンプでは「ボウリングのスコアを計算するプログラム」や「lsコマンドをRubyで再現するプログラム」を生徒さんに作ってもらい、それをメンターがコードレビューする、というプラクティスがあります。

自分で言うのもなんですが、僕のコードレビューは結構細かいです。
「相手はまだプログラミング初心者なんだし、まだそのへんはちょっと手加減してもいいんじゃない？」と僕自身が半分自覚しつつも、「いや、でもやっぱり」とついレビューコメントを入れてしまいます。

プログラミングを今までやったことのない人が「ボウリングのスコアを計算するプログラム」や「lsコマンドをRubyで再現するプログラム」を作るのはそれだけでめちゃくちゃハードルが高いと思います。
なので、僕自身も「プログラミングを始めて間もないのに、動くものを作れただけでもすごい！！！」と感じています。

ただ、その一方で、フィヨルドブートキャンプはプログラマとして就職を目指していたり、プログラマとしてもっと腕を磨こうとしたりしている人が集まっています。
それゆえ、「実務でこのコードを見かけたら、自分だったらどう思うか」ということを考えてしまうんですよね。

となると、たしかにちゃんと動きはするが、「ロジックに重複があってDRYになってない」とか「配列の変数名が単数形になっているのは誤解の原因になるぞ」といった点が気になってきます。

学習用のプログラムと仕事で書くプログラムは何が違うか

プログラミングスクールで学ぶプログラムと、仕事で書くプログラムは同じプログラムでもいろんな点が異なります。

具体的には、

  • 仕事で書くプログラムはめちゃくちゃ規模が大きく、仕様も複雑である
  • 自分一人ではなく、チームで開発する
  • プログラムの寿命が長い

といった点です。この話は以前Qiitaに詳しく書きました。

qiita.com

上のQiita記事の中で、僕は学習用のプログラムと仕事で書くプログラムの違いをジェンガに例えてみました。

学習用のプログラムは自分一人で遊ぶ背の低いジェンガです。
ジェンガを触るのは自分一人だけですし、背が低いのでめったなことで倒れません。


しかし、仕事で書くプログラムはその何十倍、何百倍もの高さを持つ背の高いジェンガです。
しかも、自分一人でなく、他のチームメンバーと一緒に積み上げていく必要があります。
下手な積み方をすると、すぐにぐらぐらとバランスを崩して倒れてしまいます。
よって、バランスが崩れないよう、「しっかり安定させながら、きれいにブロックを積み上げていくスキル」を身につける必要があるのです。

【新人プログラマ応援】学習用のプログラムと仕事で書くプログラムは何が違うか - Qiita

f:id:JunichiIto:20220103095509j:plain

子ども相手に遊ぶジェンガであれば「はーい、よくできたね。パチパチパチ〜👏」でいいのですが、僕らは仕事でお金をもらいながら毎日ガチのジェンガを積み上げているので、「はい、よくできました〜」で終わらせることはできません。

ジェンガで例えるなら、

  • ちゃんとジェンガは安定しているか？
  • まだ抜き取れるブロックは十分残してあるか？
  • このあとに積み上げる人のことを考えた置き方になっているか？

といったポイントがどうしても気になってきます。

たとえプラクティスで扱っているのが学習用の小さなジェンガであったとしても、「このあとに実務で3メートルのジェンガを組む仕事が待っている」ということを考えると、「いや、待て待て。このまま合格を出すわけにはいかないぞ」と思ってしまうんですよね。

その結果、コードレビューがついつい細かくなってしまう、というわけです。

「きれいなジェンガを組み上げられるプログラマ」を増やしたい

僕は人一倍「コードの可読性や保守性」にこだわってしまうのですが、それは前職や前々職で「なんじゃこりゃあ！？」というようなコードをたくさん見てきたから、という理由も大きいと思っています。

つまり、あるプロジェクトに配属されたら「ぐらんぐらんの3メートルのジェンガ」が目の前にあって、「はい、伊藤さん、これからよろしくね」とそのジェンガのメンテナンスをお願いされたことが何度もあるわけです。

そのあたりのエピソードは昔このブログに書きました。

blog.jnito.com

こういうプロジェクトに当たってしまうともう苦痛しかありません。そんな仕事は楽しくないですし、僕は楽しく仕事がしたいので、「きれいに組み上げられた3メートルのジェンガ」を作りたいと思っています。

ちなみに、僕が何かに付けて「テストコードを書け」とうるさいのも同じ理由です。テストコードがあればジェンガが実際に崩れてしまう（＝本番リリース後に大きな不具合を出す）前に「ここが危ないよ！ほら見て、崩れかけてるよ！」というのをテストコードが教えてくれるので、ジェンガの安定性に大きく寄与してくれます。

せっかくプログラミングスクールで「未来のプログラマ」を育成しているんだから、それであれば僕は「きれいなジェンガを組み上げられるプログラマ」を増やしたいです。そのために僕が持っているノウハウを僕はコードレビューを通じて受講生のみなさんに伝えていってるつもりです。

参考：きれいなコードってどんなコード？

ところで、きれいなコードってどんなコードなんでしょうか？

「メソッドの命名が〜」とか、「クラスの凝集度が〜」みたいな個別のテクニックはいろいろあるのですが、究極的には

初めて見たコードでもなんとなく意味がわかるコードになっていること

です（この考えの元ネタとなる動画はこちら）。

逆にいうと、ぱっと見ても意味がわからないコード（無駄に長かったり複雑だったりするコード）や、読み手の誤解を招きやすいコードはNGです。

そのあたりの話は以前Twitterであれこれつぶやいているので、こちらも参考にしてみてください。



まとめ

というわけで、このエントリでは「フィヨルドブートキャンプのメンターとして僕が大事にしていること」というテーマで、普段どんな考えで提出物のコードレビューをしているのか、という話を書いてみました。

「伊藤さんのコードレビュー、細かいから大変だわ〜」と思っている受講生の方がもしいたら、「あ、そういうことなのね」と思ってもらえると幸いです（笑）。

PR：お正月の学習応援キャンペーンやってます

そういえば、ちょうど明日（2022年1月4日）までフィヨルドブートキャンプではお正月の学習応援キャンペーンをやっています。

キャンペーン中は通常3日間の無料体験期間を7日間へ延長していますので、興味がある方はこの機会に無料体験してみてください！

prtimes.jp