プログラミングは難しすぎる？対策方法とキャリアの方向転換まで解説！

// ❌ 基礎レベルの思考（アプリ開発で破綻する書き方）
// 変数がバラバラで、どこで誰が書き換えるか予測できない
let todoTitle = "買い物";
let isDone = false;

function finishTodo() {
  isDone = true; // どこからでも書き換えられてしまうためバグの温床に
}


// ⭕ アプリ開発レベルの思考（型を使って状態をパッケージ化する）
// 実務では必ず「データの設計図（interface）」を先に作ります
interface TodoItem {
  id: number;
  title: string;
  isCompleted: boolean;
}

// データと処理を分離し、安全に新しい状態を作り出す（不変性を保つ）
function toggleTodoStatus(todo: TodoItem): TodoItem {
  return { ...todo, isCompleted: !todo.isCompleted };
}

// アプリケーション全体で一貫したデータ構造を保てる
let myTodo: TodoItem = { id: 1, title: "TypeScriptの学習", isCompleted: false };
myTodo = toggleTodoStatus(myTodo);
console.log(myTodo.isCompleted); // true

interface UserData {
  name: string;
  age: number;
  email?: string; // 任意項目
}

// ❌ 英語のエラーにパニックになる初心者の例
const user: UserData = {
  name: "田中",
  // 🚨 ここでエラーが出ます：Property 'age' is missing in type '{ name: string; }' but required in type 'UserData'.
};

// 初心者の間違った解決法：エラーを読むのが怖いので any に逃げる
// const user: any = { name: "田中" }; 


// ⭕ エラー文を冷静に読み解く（実務での正しいアプローチ）
// エラー翻訳：「'{ name: string; }' というデータの中に、UserDataで必須とされている 'age' が見つかりません」
// 解決策：言われた通りに 'age' を追加するだけ
const correctUser: UserData = {
  name: "田中",
  age: 25, // 💡 エラーの指摘通りに追加すれば即解決！
};

// ⭕ 暗記を捨て、TypeScriptの補完機能（サジェスト）に頼る書き方
const prices: number[] = [1000, 2500, 500, 4000];

// 💡 ここで `prices.` とドットを打った瞬間、VSCodeが次のような候補を出してくれます
// - filter
// - map
// - reduce
// - find
// ...etc

// 「条件に合うものを抽出する関数ってなんだっけ？」と思い出せなくても、
// 候補の中から filter を選ぶだけで良いのです。
const highPrices = prices.filter((price) => {
  return price >= 2000;
});

console.log(highPrices); // [2500, 4000]

// ❌ 逆に暗記に頼ってタイポ（打ち間違い）をする例
// JavaScriptの場合、間違ったメソッド名を書いても実行するまで気づけませんが、
// TypeScriptなら書いた瞬間にエラーで教えてくれます。
// const errorPrices = prices.fliter((price) => price > 1000); 
// 🚨 エラー: Property 'fliter' does not exist on type 'number[]'. Did you mean 'filter'?

// 💡 TypeScriptの環境設定（tsconfig.json）がもたらす難しさの例

// ❌ 厳しい環境設定（strictNullChecks: true）で初心者がパニックになる状況
// HTMLの要素を取得するだけのコードなのに、設定が厳しいとエラーになる
const myButton = document.getElementById("submit-btn");

// 🚨 エラー: オブジェクトは 'null' である可能性があります。
// 初心者「ボタンは絶対あるのに！環境構築した途端に意味不明なエラーが出た！」
// myButton.style.backgroundColor = "blue";


// ⭕ 挫折しないためのアプローチ
// 環境設定のルールに従い、「もし要素がなかったら（nullだったら）」の分岐をしっかり書く
if (myButton !== null) {
  myButton.style.backgroundColor = "blue"; // これで安全に実行できる！
}

// もしくは、モダンな「オプショナルチェーン」を使う
// myButton?.style.setProperty("background-color", "blue");

// 商品カートのデータ型
interface Cart {
  items: string[];
  totalPrice: number;
}

// ❌ 初心者がやりがちな「データの流れが見えなくなる」破壊的変更
function addItemBad(cart: Cart, newItem: string, price: number) {
  // 元のcartデータを直接書き換えている（破壊的変更）
  // どこで書き換わったか後から追跡するのが非常に難しくなる
  cart.items.push(newItem);
  cart.totalPrice += price;
}


// ⭕ 実務で重宝される「データの流れを予測可能にする」非破壊的変更（イミュータブル）
// TypeScriptの恩恵を活かし、常に「新しいデータ」を作って返す
function addItemGood(currentCart: Readonly<Cart>, newItem: string, price: number): Cart {
  return {
    // スプレッド構文（...）を使って、前の状態をコピーしつつ新しい要素を追加する
    items: [...currentCart.items, newItem],
    totalPrice: currentCart.totalPrice + price
  };
}

const initialCart: Cart = { items: ["りんご"], totalPrice: 150 };

// 「古い状態」から「新しい状態」が生み出される流れが、コード上で視覚的にわかる
const updatedCart = addItemGood(initialCart, "みかん", 300);

// 外部APIからユーザー情報を取得する処理を想定
interface User {
  id: number;
  name: string;
}

// ❌ ネット上の古い記事を参考にしてしまった、読みづらい非同期処理
// Promiseの .then() が連続し、型付けも曖昧になりがち
function getUserOldWay(userId: number) {
  fetch(`https://api.example.com/users/${userId}`)
    .then(response => response.json())
    .then((data: User) => {
      console.log("取得完了", data.name);
    })
    .catch(error => {
      console.error("エラー発生", error);
    });
}


// ⭕ 最新の標準的な書き方（async/await と厳格な型指定）
// 現代の記事や公式ドキュメントではこちらが推奨されている
async function getUserModernWay(userId: number): Promise<User | null> {
  try {
    const response = await fetch(`https://api.example.com/users/${userId}`);
    if (!response.ok) throw new Error("ネットワークエラー");
    
    // 取得したデータに型を適用して返す
    const data: User = await response.json();
    return data;
  } catch (error) {
    console.error("ユーザー取得失敗:", error);
    return null; // エラー時はnullを返すなど、状態を明確にする
  }
}

// ❌ 完璧主義な初心者が挫折する「最初から共通化しようとした」コード
// どんなデータでも更新できる関数を作ろうとして、型が複雑になりすぎて自滅する
function updateDataBad<T extends { id: number }, K extends keyof T>(
  data: T[], 
  id: number, 
  key: K, 
  value: T[K]
): T[] {
  // 🚨 「自分が何を書いているか分からない」状態になり、1行も進まなくなる
  return data.map(item => item.id === id ? { ...item, [key]: value } : item);
}


// ⭕ 「とりあえず動かす」を最優先にした、挫折しないコード
// まずは特定のデータ（例：ユーザー）専用の、愚直で分かりやすい関数を作る
interface SimpleUser {
  id: number;
  name: string;
}

function updateUserNameGood(users: SimpleUser[], targetId: number, newName: string): SimpleUser[] {
  // 愚直に書いてとりあえず動かす。これで全く問題ありません。
  return users.map(user => {
    if (user.id === targetId) {
      return { ...user, name: newName };
    }
    return user;
  });
}

const myUsers = [{ id: 1, name: "田中" }];
console.log(updateUserNameGood(myUsers, 1, "佐藤")); // 画面が動く楽しさを優先！

// 外部から取得したデータが、文字列か数値か分からない状況
const unknownInput: unknown = "1000";

// ❌ AIの悪い提案をそのままコピペしたコード（危険）
// AI「as number を使えばエラーは消えますよ」
function calculateTaxBad(price: unknown) {
  // 🚨 実際は文字列なのに、強制的に数値だとTypeScriptを騙している
  const result = (price as number) * 1.1; 
  console.log(result); // 実行時に NaN（計算不能）などのバグを引き起こす
}


// ⭕ AIを賢く使い、安全なコード（型ガード）を学ぶ
// 開発者「asを使わずに、typeofなどで安全に型をチェックする方法を教えて」とAIに聞き直す
function calculateTaxGood(price: unknown) {
  // TypeScriptの真骨頂：実行時に本当に数値かどうかをチェックする（型ガード）
  if (typeof price === "number") {
    // 💡 このブロックの中では、price は確実に number 型として扱われる
    console.log(price * 1.1);
  } else {
    console.error("エラー: 数値を入力してください");
  }
}

// 💡 自分が本当に欲しい超シンプルなアプリの例
// 例：「1日に飲んだ水の量（ml）を記録するだけのアプリ」

// ❌ 挫折する人のアプローチ
// いきなりユーザー認証やデータベースの型を作ろうとする
interface DBUserSession { ... } // 難しすぎて手が止まる

// ⭕ 楽しむためのMVP（最小限の製品）アプローチ
interface WaterLog {
  date: string;
  amount: number;
}

// データはひとまず配列（メモリ上）に持たせるだけでOK
const dailyLogs: WaterLog[] = [];

function drinkWater(amountMl: number) {
  const today = new Date().toLocaleDateString();
  dailyLogs.push({ date: today, amount: amountMl });
  
  // 配列のreduceメソッドを使って、今日の合計を計算
  const todayTotal = dailyLogs
    .filter(log => log.date === today)
    .reduce((sum, log) => sum + log.amount, 0);

  console.log(`🚰 今日は合計 ${todayTotal}ml の水を飲みました！`);
}

// 実行してみる
drinkWater(200);
drinkWater(150);
// 出力: 🚰 今日は合計 350ml の水を飲みました！

// 💡 Webデザイナー（コーダー）とフロントエンドエンジニアの「実務での連携」を示す例

// ❌ エンジニアが困る、デザイン優先で構造がバラバラなHTML（イメージ）
// <div class="box1">山田</div>
// <p class="text-red">25歳</p>
// 🚨 クラス名に一貫性がなく、どれが何のデータかわからないため、TSでのデータ流し込みが困難に。


// ⭕ 実務で喜ばれる、データの流れ（型）を意識したコンポーネント構造
// TypeScript側であらかじめ定義したデータ構造（型）に合致するよう、HTMLのクラス名や構造を整える

interface UserCardProps {
  name: string;
  age: number;
}

// コーダーが以下の構造（BEM設計など）でHTML/CSSを組んでおけば、
// エンジニアはTypeScriptを使って安全かつスムーズにデータを流し込めます
function renderUserCard(user: UserCardProps): string {
  return `
    <div class="user-card">
      <h3 class="user-card__name">${user.name}</h3>
      <p class="user-card__age">${user.age}歳</p>
    </div>
  `;
}

const activeUser: UserCardProps = { name: "鈴木", age: 28 };
// 💡 HTML/CSSが綺麗に構造化されていれば、型に従って一瞬で画面が完成する！
console.log(renderUserCard(activeUser));

// 💡 曖昧な仕様（要件）が、エンジニアをいかに困らせるかを示すTypeScriptの例

// ❌ 技術を理解していないディレクターが出しがちな「穴だらけの仕様」
// 要件：「ユーザー登録には名前と、あと任意で連絡先（メールか電話のどっちか）を入れてもらって！」
interface LooseUserRequirement {
  name: string;
  email?: string;
  phone?: string;
}
// 🚨 この型定義だと、emailもphoneも「両方空っぽ」という最悪のデータが許可されてしまい、
// 実務では「連絡先がなくて通知が送れない！」というバグが発生します。


// ⭕ プログラミングの概念（型）を理解しているディレクターが定義する正しい仕様
// 「どちらか一方は必須」というビジネスルールを、ユニオン型（Union）の概念でエンジニアに伝える
type ContactInfo = 
  | { email: string; phone?: string } // メールが必須で、電話は任意
  | { email?: string; phone: string }; // 電話が必須で、メールは任意

interface StrictUserRequirement {
  name: string;
  contact: ContactInfo; // 💡 どちらかが必ず存在する構造を保証
}

const correctData: StrictUserRequirement = {
  name: "佐藤",
  contact: { phone: "090-1234-5678" } // どちらかが入っていればTSもOKを出す
};