どもども！人生初めての本格的なコードレビューをいただいてテンションが爆上がりしている龍ちゃんです。今まで、個人開発と修士の研究でプログラムを書いてきたのですが、コードレビューというものは存在しませんでしたね。やはり、「動く」プログラムと「管理しやすい」プログラムは明確に異なりますね。個人開発では、テストや命名レベルまで気をすることがなく観点も育たないので、異なる観点からぶん殴られて考えさせられましたね。仕事としてプログラムを書く身としては、「管理しやすい」プログラムを作るところを意識していきたいですね。次回以降のコードレビューでは、忙しい上司の手を煩わせないように気を付けていきましょう。レビューの観点はそのうちブログにまとめて書いていこうかなと思います。
さて、今回はフロントエンドエンジニアである僕が、バックエンドの領域に「こんにちは」をする話です。動機としては、フロントのさらなる技能アップのために自由にエラーコードを出せるダミーAPIが欲しかったからという理由になります。せっかくなので、何かを自分で作るという体験とブログのネタ作りでもありますね。
今回取り組んだことに関しては、Tech Blogの方で公開していきますので興味がある方は覗いてみてください。じゃあ何をブログに書くんだいということですが、「検証のための環境作りがいい具合にできたので自慢したい」という内容です。それでは本題に入っていきましょう。
本題
技術検証は一つの大きなトピックですね。新しい技術を学ぶときは、自由に環境を作っては壊しを繰り返します。検証では特に、自分がどこまでわかっていて何が課題かを認識をするために、検証内容を分割して小さく検証を繰り返していきます。
小さい検証を目的の検証に近づけていくために、必要なことは「メモ」になります。今回は特にメモが良く取れたので自慢していきます。今回は、エンジニアっぽくREADME.mdを使ってメモをしています。画像も貼っておきます。だいぶエンジニアっぽくないですか？
メモの内訳としては、以下のようになっています。
- やったことと参考記事
- これからやりたいこと・やったことで気になること
- 叩いたコマンド
この3つの観点になっています。「やったことと参考記事」に関しては、章ごとに分割していて、コミットと章が連動する方が美しいですね。この辺りは、Gitの運用とも絡んでくる部分になるのですが、Gitの運用の話をするならCI/CDの話も一緒にしないといけないような気がしてくるので、やる気がごりっと出たときに頑張って記事を作りますね。それでは、メモを取る際に気を付けていることとメモが生きてくるタイミングについてお話していきます。
メモを取る際に気を付けていること
さて、メモを取る際に気を付けていることに関して話していきます。これは、プログラムをネットで探してコーディングする際に気を付けることにつながってきますね。気を付けることに関しては以下の点を気を付けています。
- 参考にする記事は最低2記事（メイン1つ・サブ1つ）
- 1つの記事で賄えないときは複数を掛け合わせる
- 参考にする記事は執筆時期を確認する
- いい塩梅でのジャンル分けが必要
- 叩いたコマンドはすべてメモをする
- 特に詰まった点は力を入れて調べてメモをする
いろいろ書いていますが、とりあえずなんでもメモを取ることが大切だと思っています。僕自身もあまりメモを取るタイプではないのですが、同期がしっかりとしたメモを取っている内容を見せてもらってから積極的にメモを取るようにしています。そのメモはめちゃめちゃきれいにまとまってました。彼女のメモはそのまま記事にできるレベルで、実際にそれでブログ書いていたので紹介しておきますね。
プログラマーとしては重要だと思うのは、一番上の「参考にする記事は最低2記事」という部分です。これは参考にするサイトは多ければ多いですが、片手で収まる程度にはしておきましょう。複数の記事で同じ情報が書いてあれば、その情報の信頼度はグーンと上がります。プログラムの界隈でよくある話なのですが、情報が古くて動かないパターンが良くあります。そのためにも「執筆時期」と「情報を集める」ことを意識しています。
「叩いたコマンドをすべてメモする」に関しては、打ったら移すことを意識しましょう。いっそのことコマンドのLOGを取ってもいいかもしれません。これは次の節の「メモが生きてくるタイミング」につながってきます。
残りの部分に関しては、自己満で良いと思います。ジャンル分けも調べる点も満足いくまでやってください。ですが、メモはあくまでメモなのでメインにならないようには気を付けましょう。あくまで必要なのは動くコードと検証が済んでいるかどうかです。ここは重要ですので、目的と手段は混同しないようにしましょう。やりがちなので注意です…
メモが生きてくるタイミング
さて、メモが生きてくるタイミングについて話をしていきましょう。この辺は経験則になるのであまり参考にはなりませんが、メモを取ってよかった点ではあるので話していきます。
特に恩恵を感じるタイミングは、複数日にまたがる作業をする時ですね。小さな検証と言っても壁にぶち当たった際は時間を食われますし、別件作業が割り込みで入った場合でも作業は中断され、複数日にわたって作業を行います。メモがあることで作業にスムーズに復帰することができます。また、WEBで記事を検索する際に重複した検索をはじく効果もありますね。この辺りはブラウザでハイライトされるのでわかりやすいですね。
もちろん、ブログを書く時にも有用です。参考にした元記事やちょっと説明がめんどくさいときのリンクにも大活躍ですね。
「コマンドをメモする」ことのメリットですが、再現性にあります。コマンドはコピペして打つことが多いですが、何を打ったか一番忘れますね。コマンド打つとファイルは更新されるので、元のコマンドは残しておくことが安牌です。全力でコマンドを保存しておきましょう。
終わりに
うい～お疲れ様です。今回は自慢をメインにお話させていただきました。コードとは若干関係ないですが、運用の観点では超大切なので皆様もしっかり書いてください。
最後にREADME.mdはちゃんと書こうね！ってことだけお伝えしておきます。やはりちゃんと書いているプロジェクトでは、見栄えがいいですしこのまま送信できちゃいますね。昔の作業を思い出す面でも楽ですな。小さい検証の積み重ねで検証が出来上がっているので、小さな検証を組み合わせることで別のプロジェクトにも転用できたりしますので、積極的にログを残していきましょうね。最近GitHubには全然挙げれていないので悲しいです。
バックエンドの世界に片足だけ突っ込みました。実は、フロントを書いていた時期よりもバックエンド系の言語を触っている期間が長いのですが、昔々なのでもう初心者ですね。入社前なので「とりあえず動けばええやん状態」だったので、これからいいプログラマーになるために成長していきたいですね。
さて！良いプログラマーになりましょう。最近書いた「自己啓発本に書いてありそうな時間術」でも共有しておきます。
