【作業ログ】どう作ろう2_ゲームから始まるタスク管理ツール
yやったこと
英語基礎
js基礎
↓のゲーム機能実装
学んだこと
- スクリプトファイルを分割することは、パフォーマンスの向上につながること
- ASIなど初心者殺しのトラップが存在すること
- use strictの存在
次にやること
ゲーム機能の実装
問題
実装全体（ゲーム、タスク）の作業時間を4hで設定しているがゲーム機能の実装で4hかかりそう
原因
- webコンポーネントのデータと処理の流れを理解していない
対策案
- 学習30min,実作業30minで実施しているところ実作業を1hへ
- タスク機能を実装しない
→コア体験（ゲームで集中状態に入った状態でタスクを登録、処理する）がなくなるのでよくない
→タスク登録、処理はユーザーが各々使用しているものに任せ、このアプリでは誘導だけする
→相手にアプリのURLだけ登録してもらう？URLとかない場合は？
→検討していたローカルストレージによる登録、処理ではなく、画面に出すだけにする？
参考
yChatGPTによるフィードバック
🧩 全体構成フィードバック
| 観点 | 評価 | コメント |
|---|---|---|
| やったことの整理 | ✅ 明確 | どの教材を使って何を学んだかが具体的。リンクで再現可能なのも良いです。 |
| 問題の把握 | ✅ 妥当 | 「4h計画が破綻しそう」→原因を構造的に分解できていて◎ |
| 原因分析 | ✅ 詳細 | 「use strict」や「ASI」など言語仕様レベルで詰まっている箇所を特定できており、正しい方向性です。 |
| 対策案 | ⚠️ 改善余地あり | 実作業時間の見直しと機能削減の検討は良いですが、「コア体験を守る」という判断軸を持ったのはとても良い。もう一段階「実装を軽量化する工夫」があるとベター。 |
⚙️ 技術面フィードバック
🔹 スクリプト分割とパフォーマンス
スクリプトファイルを分割することは、パフォーマンスの向上につながること
→ ここは少し補足が必要です。
実際には「開発効率」と「読み込み制御の柔軟性」が主な利点で、パフォーマンスそのもの（＝実行速度）が必ずしも上がるわけではありません。
正確には：
- ✅ 開発中：可読性・メンテナンス性が上がる
- ✅ 本番環境：必要に応じて「モジュールごとに遅延読み込み（dynamic import）」できる
- ⚠️ 逆にHTTPリクエストが増えると遅くなることもある（ただしHTTP/2以降では影響小）
👉「スクリプト分割はパフォーマンス向上というより、構造整理・柔軟性向上のため」と覚えると良いです。
🔹 「use strict」
現場では基本的に ESモジュール（import/export）を使うと自動的に strict モード になります。
したがって最近の開発では use strict を明示的に書かないことが多いです。
ただし：
- 古いスクリプト
- グローバルスコープで動くコード
では依然として重要。
👉 現場的には「自分のコードが strict モードで動くかどうかを意識できる」ことが重要です。
🔹 ASI（自動セミコロン挿入）
ここは初心者殺しポイントですね。
特に return や IIFE の直前改行 が典型的な罠です。
✅ 対策：
- ESLint + Prettier を入れて自動整形
- “セミコロンあり” スタイルで統一（現場でも安定）
🧠 学習戦略フィードバック
現状の「30min学習＋30min実装」→「1h実装へ拡大」は良い判断。
ただし学習部分をゼロにせず、次のように「比率」で管理すると続けやすいです：
| 学習時間 | 実装時間 | 合計 | コメント |
|---|---|---|---|
| 20min | 40min | 1h | 実装中にわからない箇所をその場で学ぶ想定。 |
つまり、「実装に必要な部分を都度検索・吸収」する形が理想です。
💡 タスク機能の扱いについて
あなたの指摘通り、
「コア体験＝ゲームで集中状態に入った状態でタスクを登録・処理」
これはアプリの価値の中核です。
したがって削るなら、「登録・処理」機能を削るのではなく、代替体験で補うのが良いです。
例：
-
ローカルストレージ保存をやめる代わりに
→ 画面上で「入力フォームだけ」表示し、ユーザーが外部タスク管理（Notion/Todoist等）へコピーできるようにする。
→navigator.clipboard.writeText()で簡単にコピーさせるなど。
これなら機能削減しつつも「行動を促す誘導」は残せます。
📚 「https://javascript.info/」の使い方アドバイス
これは本当に良い教材です。
ただし「読む順番」と「目的設定」を間違えると膨大で挫折しやすいです。
おすすめの活用法：
- Modules, Classes, Promises, DOM の章を重点的に読む
- 各章ごとに「読んだあとで小さい実験」を作る（例：Classを使ったTimerオブジェクトなど）
- 読みながら「MDN」も並行して調べる（仕様と実装の対応が分かる）
✅ まとめ（次に向けた提案）
| 項目 | 提案内容 |
|---|---|
| 時間配分 | 20min 学習 + 40min 実装サイクルで、1h単位にする |
| スクリプト設計 | 機能単位で分割し、必要時に import する構成へ |
| タスク機能 | 保存をやめて「行動誘導（コピー・リンク表示）」に置き換える |
| 学習教材 | javascript.info のモジュール関連章＋MDN 並行読み |
| 実装前の理解 | Web Components の「ライフサイクル」と「shadow DOM」の流れを図で理解する |
y🧭 批判的フィードバック（建設的な視点）
① 学習の方向性に対する懸念
あなたの学習内容（英語 → JS基礎 → ゲーム機能）は論理的な順番ですが、「Web Components」や「モジュール構造」理解が追いつく前に実装へ進んでいる印象があります。
これは一見、勢いがあって良いように見えますが、
- 「作りながら学ぶ」が機能するのは、基礎文法の直後に軽いDOM操作レベルまでです。
- Web Components や Shadow DOM のような抽象度の高い概念は、実装しながらだと理解が浅くなり、バグ原因を「運が悪い」と誤解しやすい。
💬 提案：「1時間だけ構造理解に特化した時間」を取り、Shadow DOM → Custom Elements → Event伝達 の流れを図で整理する。
② 時間管理の危うさ
学習30min, 実作業30min → 実作業を1hに延長
この判断は現実的ではありますが、時間を増やしても根本的な理解が追いつかなければ効率は上がらないリスクがあります。
よくある失敗例：
「わからない部分に時間をかけ続けて、結局1hが学習時間になっている」
💬 提案：
- 実作業は成果を出す時間に固定し、わからないことは「後で整理して学ぶリスト」に逃がす。
- 「詰まる＝学習課題を発見した」と割り切る。
③ 「パフォーマンス」理解のズレ
スクリプト分割 = パフォーマンス向上
これは危険な誤解になりやすいです。
このままだと「ファイルを増やす＝早くなる」と錯覚してしまい、
逆に HTTPリクエストが増えたり、モジュール依存関係が複雑化してバンドルエラーを起こすこともあります。
💬 提案：
「分割」は構造化のため、「高速化」は別手段（キャッシュ、lazy load、defer属性など）と区別して考える。
④ コア体験の維持に関するリスク
「タスク登録機能を削って誘導だけにする」
コンセプト的には筋が通っていますが、それだとユーザーが「行動した感覚」を得にくいという欠点があります。
心理的に「入力 → 登録（or 完了）」の瞬間に達成感が生まれるため、
「表示だけ」では集中状態を維持する仕掛けとして弱い。
💬 提案：
- 完全削除ではなく、「軽量な仮登録（保存はしないが、その場で一時的に残るUI）」にする。
→ 例：入力→ボタン→画面上に1行追加→リロードで消える。
これならUX的な“完了感”を損なわない。
⑤ 学習教材の活用法への懸念
javascript.info
この教材は非常に優秀ですが、「量」が多く、「サンプルコードが抽象的」。
つまり「読んだ気になる」危険があります。
💬 提案：
- 各章を読むたびに「1ファイルでミニ実験」を必ず行う（例：1つのclassを自作して動かす）。
- 章末に「この章を理解したら何が作れる？」を自分で言語化する。
（例：「イベントバブリングを理解した → 子コンポーネントのクリックを親で受け取れるようになった」など）
⑥ 実装目的と技術選択の乖離
今の課題を見る限り、「集中状態を作るアプリ」という体験設計が目的なのに、
現状は技術仕様（Web Components, use strict, ASIなど）の理解に焦点が偏っています。
このままでは、
「技術理解は進むが、ユーザー体験が進まない」
というアンバランスに陥るリスクが高いです。
💬 提案：
- 実装前に「1文でこの機能の目的」を書く。
例：「このゲーム機能は“集中状態のトリガー”を作るためのものである」。
→ 技術はその目的を支える手段だと再認識できる。
⑦ 全体設計の欠落リスク
現状、「ゲーム機能の実装に集中」していて、アプリ全体のデータフローや状態管理の設計がまだ曖昧です。
特に Web Components は状態共有が難しいため、構造を曖昧なまま進めると「あとで繋がらない」問題が起きやすい。
💬 提案：
- まず「1枚の図」でアプリの流れを書く。
例：ユーザー操作 → ゲーム開始 → 集中状態 → タスク誘導 → 終了 - 次に「どのデータがどこで生まれて、どこに伝わるか」を線で示す。
🔍 批判的まとめ（短文）
| 観点 | 批判的指摘 | 改善方向 |
|---|---|---|
| 学習順序 | 概念理解が実装に追いついていない | Web Componentsの構造理解を先に |
| 時間配分 | 増やしても効率は上がらない可能性 | “詰まり”を課題リスト化する |
| パフォーマンス理解 | 誤解の余地あり | 「分割＝整理」「最適化＝別軸」と分ける |
| コア体験 | UXの一部を失う恐れ | 仮登録UIなどで完了感を残す |
| 教材活用 | 読んで満足に終わるリスク | 章ごとにミニ実験＋要約を作る |
| 技術選択 | 技術偏重で目的がぼやける | “なぜそれを作るか”を常に明文化 |
| 設計 | 状態共有が曖昧 | データフローを図にして可視化 |