/プロジェクト振り返り(~202301)2023.01.15プロジェクト振り返り(~202301)Tweetこんにちは!りょた(@Ryo54388667)といいます(^o^)今回は本プロジェクトが一段落するので、その振り返りについて書いていきます。他人の反省を知りたい人つまづく部分を知っておきたい人こんな人に読んでいただけると幸いです!開発概要まず、さらっと開発の概要についてお伝えします。TypeScriptを利用して画面を構築。APIを利用してフロントにデータを渡す。インフラはAWSを利用。僕はフロントを担当しているので、画面周りのスタイリングとコンポーネント作成をしていました。振り返ってみると、環境がらみのエラーの解決に苦労していたなぁと思いました。謎のCORSのエラーまずひとつ目は謎のCORSエラーです。ブラウザでAPIコールした時に発生しました。各所担当するエンジニアの方にバックエンド、インフラ側、ともに設定をしてもらったのに、なぜかエラーが出続けていました。」データの流れを追っていましたが、どこが原因になっているのか全くわかりませんでした。結局、原因がわからず時間が経過していきました。解決のひとつのきっかけは、プロジェクトマネージャーの一言です。あるとき、プロジェクトマネージャーが別プロジェクトのチャットで、障害対応について方針を伝えていました。障害の対応は以下の順に行う原因究明ではなく、バケツの穴を塞ぐ。原因に対する正規のソリューションで対応する。これでいきましょー!と言っていました。自分のプロジェクトでも障害とはいえないまでも、エラーが原因で開発が進められない状態だったので、このフローで対応する必要があると思いました。以前までは、「原因は何だろうか??」とずっと原因究明ばかり行なっており、解決に至っていませんでした。このマネージャーの一言で、「とりあえずバケツの穴を塞ぐことを考えてみよう!」と思うようになり、方針を変えました。「バケツの穴をどう塞ごうかなー」CORSエラーはブラウザでAPIコールすると発生するので、「サーバー側でAPI叩けばいいのでは?」と思い、その方針で試みることにしました。正規のAPIをコール。これで、CORSエラーは発生せず、意図通りの挙動になりました。バケツの穴を塞ぎ、開発を前に進めることができました。このあと、原因究明をしたのですが、結局わかりませんでした。消化しきれない部分もありますが、開発を前に進められたのは非常に良かったです。初期表示が非常に遅いことがわかりました。1ページで利用するデータとコンポーネント数が多いことが原因です。バック側、フロント側の双方にパフォーマンスの改善が課題になりました。この解決策は完全に偶然でした。18の機能の「lazy()」メソッドを調べている時に「遅延コンポーネント」の存在を知りました。へー、そんなのあるんだーと思い、調べてみると、「交差オブザーバー」なるもので実現できることがわかりました。これを利用して、Next/Imageのようにビューポートに入った場合、コンポーネントをレンダリングするような仕組みを実現しました。画像の遅延処理同様に、初期表示のコストが下がり、フロントのパフォーマンスが改善されました。初期表示の改善方法は他にもありそうなので、読者の方から教えていただきたいと思っています〜環境差異のエラー解決これ系のエラーがホントにやめてほしいです。ローカルでは全く問題ないのに、テスト環境にあげた途端、503エラーが吐かれました。サーバーログをぱっと見ても全然わからず、手詰まりでした。Amplifyにデプロイしたとき、サーバーサイドの処理はどこで行なっているんだろう??」このあたりの仕組みがイマイチわかっていませんでした。ログを確認しようにも、どのサーバーにログが吐かれるのかもわからないのに確認のしようがないですね。いうことで、Amplify大先生の仕組みを調査を行うことが第一だと思い、リサーチをしました。SSRまたはISRのアプリケーションをデプロイすると、以下のようなLambdaが作成されるようです。Lambda参考サイト(Zenn)Lambda@Edgeが作成されるんですね!それまで全然知りませんでした!これらのキーワードとリソースネーム(ARN)を元にそれらしきLamdaとログを発見できました。結局原因は、ローカルで利用しているNodo.jsのバージョンとLambdaのランタイムのバージョンに差があり、利用できない組み込みメソッドが存在することでした。今振り返ると、これはログの確認ができないと絶対発見できなかっただろうなーと思いました。エラーから学ぶと言うのはホントのことですね!AWS周りの勉強にもなりましたし、むしろプラスでした。今後の課題コードレビューをして、双方の意見に甲乙つけ難い場合、どちらを採用するのか?これが最も大きな課題かなと思っています。現在、僕を含めジュニアのエンジニアでフロント部分を作成しているのですが、ちょくちょくディスカッションで詰まる時があります。どの方法もメリットとデメリットがあり、決め手に欠けるケースです。これみなさん、どうしてるのでしょうか?CTOやテックリードの人がいれば、意見を求めることもひとつの方法だと思います。僕のチームには、現在そういった役職の人がいません。この場合の対応をどうするかが、課題だなーと思っています。現在、採用を考えているのは、「機械的に順に採用していく」ということです。「双方の意見に甲乙つけ難いので、今回はAさんの意見、次に同じケースになったら、Bさんの意見を採用する」というような形式です。うちではこうしているよー!とか事例があれば教えてください!最後に振り返っていると、楽しくなってたくさん書いてしまいました。SOA-C02(SysOpsアドミニストレーター)に落ちました。