担当者が変わるAngularのソースコードはどうなるのか？

担当者が変わるアンギュラーのソースコードはどのように成 長するのか？ まつもと かづまさ

自己紹介 ・まつもとかづまさ ・年齢は35歳 ・趣味は崩壊スターレイル（フレンド枠空いてます） 最近やっていること ・勉強会コミュニティのんかろりーの運営 ・Nest.jsのチュートリアル開発 ・パチンコスロットの収支管理DXツールの開発（Angular） ・アルゴリズムイントロダクションの読書会 ・パタヘネ本の読書会

本資料の内容 ・長いプロジェクトで担当者がころころ変わると どのようなソースコードになるのか？

プロジェクト参画の経緯 ・納品日にデプロイしていなかったので、その火消し対応で急遽参加

該当のプロジェクトのサマリ ・Angularを使っている（v14） ・実施している機能は伝票のCRUD処理機能のアプリケーション ・バックエンドはFirebase ・伝票データをブロックチェーンに記録する

該当のプロジェクトの時系列

さて本題 ・担当者がころころ変わるAngularのソースコードはどうなるのか？ 1. テストコードがない 2. コピペからの派生コードになる（HTMLは4000行ぐらい、TSは2000行ぐらいになっていた。） 3. PoCの段階で開発者がドメインの知識を全くなしで開発していたので、そもそもの設計と要件がず れている。（アプリ動いておおーすごいやん！となっている） 4. ドキュメントをだれも残さない（せめてコメントでも残してほしかった） 5. 使っているサービスに適したコードを書いていない（データを全部取得してフロントエンド側でク エリしていた）

対応したこと 1. あやまる 2. ドメイン理解 3. 要求整理 4. 要件定義 5. バグ修正 6. あやまる 7. CI/CDの構築（できる人のスカウト） 8. Cypressでのテスト（できる人のスカウト） 9. コンポーネント作成

意外とよかったところ 1. 基本的にコピペコードなので、設計思想が「入っていな い」ため、最初の設計思想がすべて反映されている。こ れはコード理解がわかりやすかった （メンタリティ的に変更するリスクをとる人がいなかっ た） 2. 自分の問題解決能力に気が付いた

しんどかったこと。 1. 現状把握が大変だった 2. 前任者の言い訳を聞くのは疲れた 3. 一緒にzoomをつないで作業手伝ってる感を出すメンバーはつ らかった。 4. 要求整理とドメイン理解の出張から帰ってきて、バグが修正 できていませんという報告があり、出張帰りからバグ修正を する朝の4時はしんどかった 5. 家族との関係が悪くなる（障害対応とかで夜間も仕事するこ とになるので）

まなび 1. 振り返ると楽しかった。 2. 自信につながる