🐶

新卒3年目になって変わったコーディングへの考え方

2022/12/19に公開

ポエム

はじめに

気づいたら新卒3年目になっていました、Toshです。
今日は、12月19日月曜日、さて昨日は一体何があったでしょうか？W杯決勝？いえ違います！そうです、M1の決勝がありました！個人的には、真空ジェシカのちょっと教養を必要とするはいコンテキストなお笑いが好きですが、やっぱり大衆受けとなると難しいのでしょうか。。。このままのスタイルを突き抜いて来年こそは優勝してくれることを期待しています！頑張れ、真空ジェシカ。

そろそろ本当にちゃんと初めに

さて、本題に入りますね。。。
普段はアドベントカレンダーには技術的なことを書くことが多いのですが、新卒3年目も後半戦半ばを迎える師走のこの頃、ちょっとポエムを書いてみようかと思いまして。新卒として、3年間も同じ会社で働いていると、結構コーディングへの向き合い方、考え方というのも変わってくるなと思います。今日は、この三年間での、そんな変化を書いていこうかなと思います。

コーディングへの考え方

0年目

いや、0年目ってなんやねん。と思うでしょうが、学生時代の話をここにまとめておきます。特に大学四年生の１年間はアルバイトとしてとあるアプリの制作に携わらせていただいていました。
結構この頃のコーディングへの考え方は、割と仕様を実装するものというだけでした。仕様の動きを体現できたら、PRを出す、それをただひたすら繰り返していました。
あまりコードレビューを受けた記憶もないので、ただPRを出せるか出せないかの二択でしかなかったように思います。

1年目

さて、1年目。ピカピカのランドセルを背負ったエンジニア1年生です。この頃のコーディングの考え方を一言で言うと、無邪気な牛丼チェーン店ですね。
新卒1年目、エンジニアとして本格的に業務に取り組むことにワクワクしていた当時は、とにかく早く量をこなすことが重要だと考えていました。つまり、早い、安い、うまいこそが正義であると言う考え方です。実際には、早い、雑、汚いが売り文句になっていたような気もしますが、そこはご愛嬌。
そんな考え方も、初めて受けたコードレビューでボコボコにされていました。とはいえ、まだまだ青い新卒、本音を言ってしまうと、レビュワーの提案するコードと自分のコードの優劣を理解できていませんでした。自分の作った料理がうまいのと同じ理論で、やっぱり自分の書いたコードは完璧に見えていた気がします。
そう言ったところで言うと、かなり書いては直されて、書いては直されてを繰り返していた気がします。時には、PRの実装を一からやり直した記憶もあります笑。もう少し設計に、時間を使ってみたらどうかと言うアドバイスを受けましたが、当時の自分では到底理解のできるようなことではなかったです。
それでも無邪気に、自分の実力を知ることもなかったので、かなり攻めた挑戦をして、プロジェクトを炎上させかけてかなり先輩方にお世話になってましたね、、、懐かしい。。。

2年目

さて、2年目です。　この頃のコーディングの考え方は、お客さんの前でバナーで炙るタイプの炙りしめ鯖を作ってる厨房ですね。はい、意味がわからないですよね、ちゃんと説明します。
2年目ともなると、無邪気な少年もさすがに、自分の実力を身測れるようになってきます。そう言った意味で言うと、無謀すぎる挑戦というのは減ってきます。自分の全く勉強していない技術を使ってコーディングをしよう、目についたところはとりあえずリファクタリングを入れるみたいなことはしなくなってきます。一方で、シニアなメンバーとの実力差にも気づいてきます。つまり、この時点で思っていたことは、自分のコードはなんであれ、レビューが入ることでしか完成しないと思うようになっていました。つまり、自分の出すしめ鯖は炙っていない状況で、レビュワーが炙ってくれることによって完成する料理。たとえ、ちょっと出来が悪くても炙られる段階で指摘が入ることでお客さんに出せるまでのクオリティまでは引き上げてくれるそんなイメージがついていたような気がします。
かといって、悪い面しかなかったのかというともちろん、そんなことはなくて、新しく見えてきたものもあります。2年目になると、内定者としてアルバイトをしていた後輩ができたこともあり、彼らのコードレビューをする機会も新たに発生してきました。レビューされる側からレビューする側に移ってみて、初めて今までの見えてこなかったレビュワーの視点というものも見えてきたように感じます。

3年目

3年目ですね、この年は変化の年だった気がします。
一言で言い表すのが難しいのですが、ズバリでいうのであれば将棋です。僕は将棋をやったことがありませんが、イメージだけでいうと、将棋です。(?)
この頃から、かなり設計に対して時間を使うようになって気がします。頭の中で全体像を設計して、手を動かすタイミングで、全てそれをコードに落とし込む、そんなふうに変わっていきました。
1~2年目は割と、手を動かして、コーディングをしながら設計をしていた気がしますが、3年目になって手を動かしながら設計する時間が減った気がします。

どのように変化したのかを可視化してみる

あくまで、イメージですがこんな感じです。

1年目の時は設計にほとんど時間をかけておらず、コーディングをする際に設計を考えるということもあまりしていませんでした。
2年目になると、ちょっとだけ設計を考えたら手を動かす、手を動かしながら設計を考えるそんなコーディングスタイルになっていた気がします。
そして、3年目。かなり設計に時間を割くようになり、コーディングの時間は大幅に減りました。
このようにみると2年目3年目はあまり差異がないように見えるし、早いやすいうまいの1年目が一番いいのでは？とも思えてきます。
では、ここにもう一つの要素を加えてみましょう。レビューにかかる時間です。
これもあくまで体感ですがこのように変わってきます。

ここまでくるとかなり変化が見えてくるのではないでしょうか？もちろん、自分自身の技術力が1年目、2年目と比較して上がっているのもありますが、それ以上にレビューにかかる時間が減ったように感じます。
頭の中で全体を見通して設計をするようになったために、全体のフローとそれぞれの役割が明確になってからコーディングするので、実装途中での無理やりな設計変更が少なくなったというのもレビューにかかる時間が減った一因ではないかと思います。
練りに練られた思考から繰り出される一手を将棋の醍醐味とすると、練りに練られた設計から繰り出されるコード、それこそがコーディングの醍醐味だと思えるようになってきたのです。

なぜこのような変化が訪れたのか

自分自身の成長と共に、訪れる変化の一環ではあるとは思うのですが、下記の要素も大きな要因になっている気がします。

アルゴリズムとデータ構造のコーディング(競プロみたいなもの)にハマったこと

よくある質問として、いわゆるアルゴリズムとデータ構造のコーディングのようなものが業務の上でのコーディングに役に立つのかという問いがあります。まあ、確かに、iOSでコーディングしていても、計算量を意識しながらゴリゴリにロジックを書くということは少なく、多くの作業がJSONの色付け作業に寄っているともいえます。前者のような作業はそもそもframework側でもってくれていることが多く、我々はそこに多大な意識を割くことなくコーディングを行えるというのは正しいと思います。
では、一体何をここから学ぶことができるのでしょうか？それは、これらのプログラミングには、明確なinputがあり、outputがあるというコーディングです。手続型プログラミングを行っているとついつい意識から外れてしまいがちですが、結構どんなinputがあって、何をoutputするのかというのを考えていき、そのデータフローはどのように流れてるのかというのを考えると意外にもコーディングはしやすくなります。それは、業務であっても変わることはないと思います。つまり設計の時間が増えたのは、そのどんなinputがあって、どんなoutputになるのか、それらのデータはどのように流れていくのかへと意識を向けるようになったというのが大きな要因になっていました。
一見、業務には役に立たないように見える、コーディングも回り回って業務でも役に立つからこそプログラミングは面白いのです。

最後に

4年目以降はどんな変化をしていくんでしょう？と聞かれれば、自分でもよくわかりません。来年になったら、設計に時間を割くのはクソだ！とか言ってるかもしれません。(それはそれで面白いからその時は、去年の自分をdisる記事書きますw)
まあ、変化を比較するような記事を書いてはいますが、正直な話、別にどれも正解だとは思っていないです。
例えば、1年目の考え方にしても、無邪気に自分の実力以上の挑戦をしていく気持ちは大事だと思いますし、今の自分にはその気持ちがちょっと足りなくなって、巧くやろうとしすぎている気もします。まだ若いんだからもっと挑戦しないと！
こういうものは、betterはあれど、bestはないものだとは思うので、試行錯誤を繰り返しながら自分にとってのbetterを見つけていければ良いと思います。

最後の最後に

ポエムって難しいですね。
いろんな挑戦をしながら成長できて、個人じゃ体験できないような大規模なサービスの運営に関われて、お賃金をもらえる、会社員という環境は本当に最高ですね、会社員最高！