イテレーション 10 ふりかえり¶
概要¶
| 項目 | 内容 |
|---|---|
| イテレーション | 10 |
| 対象言語 | Scala |
| 期間 | Week 19-20（2 週間） |
| 計画 SP | 13 |
| 実績 SP | 13 |
| 達成率 | 100% |
主要指標¶
| メトリクス | 値 |
|---|---|
| テストファイル | 3 ファイル（FizzBuzzSpec, TypeSpec, CommandSpec） |
| テスト数 | 34 テスト（全パス） |
| ソースファイル | 4 ファイル（FizzBuzz, Type, Model, Command） |
| 記事 | 12 章 + index（13 ファイル） |
| コミット数 | 7（環境構築 + 4 部 + 複雑度チェッカー + CI Nix 移行） |
| scalafmt / WartRemover 警告 | ゼロ |
| 循環複雑度違反 | ゼロ（22 関数、閾値 10） |
| CI ワークフロー | scala-ci.yml（Nix ベース） |
| 総変更量 | 38 ファイル、+2,287 行 |
KPT 分析¶
Keep（継続すること）¶
- 部ごとのコミット分割が成功（IT9 改善適用）
- IT9 の Problem「単一コミットでの全体完了」を改善し、7 コミットに分割
- git log で進捗が明確に追跡可能になった
-
コミット: 環境構築→第 1 部→第 2 部→第 3 部→第 4 部→複雑度チェッカー→CI Nix 移行
-
Nix 環境の安定利用（10 イテレーション連続）
nix develop .#scalaで Scala 3 + sbt + Metals + scala-cli を一貫して使用-
CI も Nix ベースに移行し、ローカルと CI の環境差異がゼロ
-
IT9（Clojure）からの JVM 知見の有効活用
- プロトコル→トレイト、マルチメソッド→パターンマッチの対応づけが効果的
-
JVM 上の関数型プログラミングパターンが Phase 3 テンプレートとして確立
-
複雑度チェッカーのカスタム実装（IT9 Try 適用）
- IT9 のふりかえりで「他の関数型言語にも複雑度チェッカーを用意」を提案
scripts/complexity.shを作成し、Makefile のcheckタスクに統合-
22 関数すべてが閾値 10 以内を確認
-
品質ゲートの一貫した適用
make check（scalafmtCheck → compile → complexity → test）で品質を統一管理-
scalafmt / WartRemover 警告ゼロを達成
-
.gitignore ファースト戦略の継続成功
target/、.bsp/、.metals/、.bloop/を最初に除外設定- 不要ファイルの誤コミットがゼロ
Problem（問題点）¶
- scala-cli が Nix 環境外で利用不可
- 複雑度チェッカーを最初 scala-cli スクリプト（
.sc）で実装しようとしたが、Nix 外では動作しない - 結果的に bash スクリプトで代替し問題なく動作
-
.scファイルが不要な成果物として残存 -
CI ワークフローの初期構成が非 Nix
- 最初の CI（scala-ci.yml）は
actions/setup-javaベースで作成 - 後から Nix ベースに移行する追加コミットが発生
-
最初から Nix ベースで構築すべきだった
-
bash 複雑度スクリプトの正規表現制約
- bash の
grep -cによる正規表現マッチングは簡易的で、コメント内の if/for 等も誤カウントする可能性 - Scala 3 のインデントベース構文ではブレース（
{}）に依存しないメソッド境界検出が必要 -
現状は十分に機能しているが、より正確なパーサーベースの実装が望ましい
-
Codex サンドボックスでの sbt 実行制約
- Codex エージェントに記事生成を委託した際、sbt の実行確認ができない
- 記事内コードと実装の同期は手動確認が必要
Try（次に試すこと）¶
- CI ワークフローを最初から Nix ベースで構築
- IT11（Elixir）以降は初期構築時から Nix CI を採用
-
actions/setup-*系のアクションは使用しない -
scala-cli スクリプトの整理
- 不要な
.scファイルを削除、または Nix 環境内専用として明示 -
bash スクリプトを標準ツールとして位置づけ
-
Elixir での BEAM 固有パターンの準備
- Scala の OOP/FP ハイブリッドとは異なり、Elixir は純粋な関数型 + アクターモデル
-
OTP（GenServer、Supervisor）の概念をどう 12 章構成に組み込むか事前検討
-
Phase 3 テンプレートの確立
- IT9（LISP 系）と IT10（OOP/FP ハイブリッド）の経験から、関数型言語の記事テンプレートを標準化
- IT11（Elixir）、IT12（Haskell）に適用
ベロシティトレンド（10 イテレーション実績）¶
| イテレーション | 言語 | 計画 SP | 実績 SP | 達成率 |
|---|---|---|---|---|
| IT1 | Java | 10 | 10 | 100% |
| IT2 | Python | 10 | 10 | 100% |
| IT3 | Node（JS/TS） | 13 | 13 | 100% |
| IT4 | Ruby | 13 | 13 | 100% |
| IT5 | Go | 10 | 10 | 100% |
| IT6 | PHP | 10 | 10 | 100% |
| IT7 | Rust | 10 | 10 | 100% |
| IT8 | C#/F# | 13 | 13 | 100% |
| IT9 | Clojure | 13 | 13 | 100% |
| IT10 | Scala | 13 | 13 | 100% |
| 平均 | 11.5 | 11.5 | 100% |
累計: 115/149 SP 完了（77.2%）
次のイテレーションへの引き継ぎ¶
IT11（Elixir）への申し送り¶
.gitignoreを最初に作成する（_build/、deps/、.elixir_ls/の除外）- Nix 環境（
nix develop .#elixir）を必ず使用する - CI は最初から Nix ベースで構築する（IT10 の Problem を踏まえた改善）
- 部ごとにコミットを分割する（IT9 改善→IT10 で成功、継続）
- Scala のトレイト→Elixir のプロトコル/ビヘイビア、パターンマッチ→Elixir のパターンマッチの対応づけを活用
- BEAM/OTP 固有の概念（GenServer、Supervisor）を第 3-4 部に組み込む
- GitHub Issue #11 の同期を忘れない
- 複雑度チェッカーは Elixir 向けにカスタム実装する
Phase 3 進捗¶
- IT9（Clojure）: ✅ 完了（13 SP）
- IT10（Scala）: ✅ 完了（13 SP）
- IT11（Elixir）: 未着手（13 SP）
- IT12（Haskell + 統合）: 未着手（21 SP）
- Phase 3 合計: 26/60 SP（43.3%）
更新履歴¶
| 日付 | 更新内容 | 更新者 |
|---|---|---|
| 2026-03-03 | 初版作成 | AI |