はじめに
初めまして。
CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！
スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。
代表的なゲームはクリプトスペルズというブロックチェーンゲームです。
今回はとあるプロジェクトでコードの移植を行ったときに、想定していたよりも大変だったことやそこから学んだことをまとめていきます。
特に実務未経験のエンジニアや実務経験数年の若手エンジニアの参考になれば嬉しいです。
それでは早速本題に入っていきましょう！
ざっくり要約
PM: 「〇〇という機能を実装することになったからよろしく！」
自分: 「わかりました！コードの移植メインですし、多分3週間くらいでできます！」
PM: 「そのくらいでできるなら嬉しい！頼んだ！」
自分: 「はい！任せてください！（やる気満々）」
===== 実装 =====
自分: 「あれ？これ思ったより時間かからない...？」
===== 数日後 =====
自分: 「あ...ヤバス...結構大変だこれ...。」
自分: 「コードの移植完全になめてたわ...」
前提
まずはどのような経緯でコードの移植をすることになったのかの前提をお話ししていきます。
実装前
自分が開発を担当している自社サービスの中に、他の自社サービス内の機能の一部を実装することになりました。
機能の一部の実装なのと、一見するとそこまで実装が難しそうではなかったため3週間くらいで設計と実装ができるだろうと見積もっていました。
実装の中身としては、フロント側の実装とブロックチェーン部分の実装があったため、まずは動作確認するためにもフロント側の実装からしていきました。
実装着手
元々フロントエンドがあまり得意ではなかったのもあり、予定より少し遅れての完成になってしまいました。
次にメインのブロックチェーン部分の実装をしていたのですが、ここで大きくつまづきました。
実装に入る前に、移植元の開発を担当しているエンジニアの方とお話しして仕組みや実装、移植先での設計について相談させていただきました。
この時までは、そこまで時間かからず実装できると考えていました。
しかし、実際に実装する中で当たり前なことに気づきました。
「コードの移植ってそのまま持ってくれば良いわけじゃないじゃん...」
そうなんです！
コードの移植は、「移植元のコードをそのまま持ってきてはい完成！」とはいかず、移植先のコードに置き換えながら馴染ませる必要があります。
この部分を頭の辺境部分にはありつつ、完全になめていたために開発完了時期に間に合わせることができませんでした。
ここから学べることがいくつかあったので、次の章から順番に紹介していきます。
学べたこと
この章では今回のコードの移植から学べたことをまとめていきます。
移植先と移植元のファイル構成が違う
移植先と移植元のファイル構成が全く同じことはそうそうありません。
大企業とかであれば社内で「こうしましょう！」と決まっているかもしれないですが、ベンチャー企業やスタートアップでは開発担当者に委ねられていることが多い認識です。
そうなってくると、「あれ？ファイル構成違いすぎて若干寄せた方が実装しやすいな🤔」となります。
特に今回自分がまだ開発経験が豊富ではないフロントエンドの実装だったため、移植元のソースコードでのファイル構成が大変参考になりました。
とりあえずの実装ではなく、このタイミングでファイル構成もアップデートをかけないと後々大変になるなと思い、急遽リファクタリングのような作業も差し込みました（移植元に合わせることで移植しやすくなったのも事実で、この部分は良い・悪いの判断が難しいです）。
全く違うというわけではなかったので、そこまで苦労せずに実装できたのは良い判断だったかと思っています。
仕様の詳細をもっと詰めるべき
今回、仕様についてざっくりの理解で設計・実装に着手していました。
頭の中ではどのような実装をすれば良いかイメージはついていたので、それでいけるだろうと思っていましたが、実際は「こっちの実装も必要」や「ここの仕組みは実際はこうなっている」など実装していく中で判明することがいくつかありました。
設計や工数見積もりの段階でこの部分を知っていれば、もう少し余裕を持った工数見積もりができたのとスムーズな実装ができたなと思っています。
なかなか仕様段階では細かいところまで知るのは難しいですが、ちゃんと理解して実装することの重要性を実感しました。
移植元のソースコードの確認に時間がかかる
この部分が一番時間がかかった部分です。
これも当たり前のことですが、一部の機能が1つのファイルに全てまとまっていることはありません。
コードが分割されてファイルにまとめられているのがほとんどです。
それにより、importしているファイルがどこにあるか確認し、芋づる式にコードを辿っていく必要があります。
もちろん1つの実装を辿れてもそれはほんの一部で、数行ごとに辿る必要が出てきます。
そうなってくると何が大変かというと、前に辿った実装コードやファイルがどれかわからなくなるということです。
タブにGithub上のファイルを開いていても多すぎてどれかわからなくなります。
ここで自分がとった行動としては、「自分が持ってきたい関数やファイル内で読み込んでいるコードは、一旦移植先の環境で同じものを作ってしまう」です。
移植先で作ってしまえば次からはそれを見れば良いですし、移植先で不要なコードについては後から削除すれば問題ありません。
もちろんこれをしたからと言って、一度見たファイルを見なくなることはないですがだいぶ効率良くコードの移植ができるようになります。
移植元のコードといい感じに統合する
前提の部分でもお話ししましたが、「移植元のコードをもそのまま持ってきて完成！」とはいきません。
移植先と移植元で全く同じような実装をしていればそれでも良いですが、多少なり実装の一部が異なります（変数とか）。
そのため、移植元のコードを持ってきて、移植先のコードの中に良い感じに落とし込む必要が出てきます。
移植元では必要だが、移植先では不要なコードもあるので、その部分を見極めて取捨選択することも大切です（不要な処理をするのはあまり良くないので）。
積極的に質問する
移植元のコードは実装したエンジニアが一番理解しています。
移植元のソースコードを読んでいてもわからないことが出てきます。
「〇〇と△△という実装方法があるが、なぜ前者の実装方法なのか？」や細かい実装についてはいくら考えても確実なことは分かりません。
それであれば、積極的に移植元のコードを実装したエンジニアの方に質問することが大切です。
確実なことがわからないことで長時間悩み続ける方が良くないです。
「質問ができないエンジニア」というのは良くないと考えています。
質問をたくさんすることよりも、質問をしないことである日取り返しのつかない状態になっていることの方が問題だからです。
まだまだ短いエンジニア経験の中でだんだんわかってきたことですが、先輩エンジニアやシニアエンジニアは質問されることを嫌がりません。
むしろ ウェルカム！ という姿勢です。
もちろん質問する上での最低限の礼儀は必要です。
以下の記事のように質問の仕方などあるので、「エラー出ました！答え教えてください！」的なものでなければ都度都度質問して問題ないと思います。
この部分は結構意識している部分なので、ぜひ自分と同じような新米エンジニアも意識してもらえると嬉しいです。
仲間に助けられている
1つ前の先輩エンジニアやシニアエンジニアの方に質問することもそうですが、リリース前に実際に動作確認をしてくれる社内の方々がいます。
実際に触っていただき、何かしら問題があれば報告してもらえる。
新機能やサービスをリリースする上では当たり前のことですが、それを当たり前のことと捉えず感謝の気持ちをもつことは大切だと実感しました。
自分の作業時間を犠牲にしてまでも、嫌な顔せずにテストに付き合ってくれて細かく確認していただけるのは、エンジニアのリリースという緊張感を良い感じに緩めてくれます。
課題点
この章では、今回の経験を通して課題に感じていることをまとめていきます。
工数見積もりは永遠の課題
以下の記事でも述べていますが、工数見積もりは永遠の課題です。
完璧に工数見積もりをすることはほぼ不可能なため、いかに誤差を少なくしていけるかだと考えています。
自分のまだまだ短いエンジニア経験において、工数見積もりで「うまく行った！」と感じたことはまだありません。
毎回毎回「工数見積もりが課題だな...」と思っています。
経験が少ないのはもちろんのこと、今回やこれからの経験をもとに徐々に照準を調整していきたいと思っています。
技術力の向上に終わりはない
技術力の向上に終わりはありません。
新しいことを知ると、それまで見えていなかったような課題点が見えてきます。
イメージとしては、山登りで頂上だと思ったとこに着いて見上げるとまだまだ頂上は上にあることを知る感じです。
登ってみて初めて知るため、どんどん新しい自分が知らない技術を学んでいく必要が出てきます。
まだまだ技術力という山を登り始めた自分は、少しずつでも毎日着実に前に進んでいくことを意識していこうと思っています。
先を考えて行動する
「実装前に〇〇さんにお話を聞こう」、「コードの実装に問題がないか〇〇さんに確認していただこう」など、今すぐではなくても必ずやらなければいけないことはあります。
この時、そのタイミングになってからミーティングの打診をするのではなく、完成の目処や「ここまでに聞かないといけない」など見通しが立った段階でスケジュールを抑える必要があります。
例えば、以下のような場面を想像してください。
自分: 「実装ができたから〇〇さんに相談しよう！」
〇〇さん: 「あ~ごめん！今日は難しいや！明日の午後とかであれば大丈夫！」
自分: 「分かりました！では明日の午後お願いします！（もう実装できているから明日まで細かい部分確認しようかな...）」
明らかに明日の午後までの時間がもったいないです。
実装の完成目処が立った段階で、ミーティングの打診をしていればもったいない時間を削減することができます。
この部分も間接的に工数見積もりに関連してくるため、徐々にできるようにしていきたいと思っています。
最後に
今回の記事では「コードの移植を完全になめていた」というテーマで、そこから学んだことや課題点についてまとめてきました。
いかがだったでしょうか？
1つでも参考になることなどがあれば嬉しいです。
誰でも失敗はしますが、そこから何も学べないのが一番まずいと思っているので記事にして刻み込みました。
ぜひ皆さんも、エンジニアとして働く中で気づくことなどがあれば記事にしてみてください！
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
採用強化中！
CryptoGamesでは一緒に働く仲間を大募集中です。
この記事で書いた自分の経験からもわかるように、裁量権を持って働くことができて一気に成長できる環境です。
「ブロックチェーンやWeb3、NFTに興味がある」、「スマートコントラクトの開発に携わりたい」など、少しでも興味を持っている方はまずはお話ししましょう！