1. 並列Streamにおける“副作用と順序性”の見落とし

JavaのparallelStream()は、forループの並列化代替として誤って使われやすい機能です。
しかし実際には、副作用がある処理・順序を期待する処理との相性が非常に悪く、レビューで構造的に破綻を検知できるかが問われます。

1.1 順序性の喪失による誤動作

list.parallelStream()
    .forEach(x -> System.out.print(x)); // 順序保証なし

このコードは、Listの順序通りに出力されるとは限りません。forEachOrdered()を使用しなければ、並列処理の実行順は不定です。

list.parallelStream()
    .forEachOrdered(x -> System.out.print(x)); // 順序保持

1.2 副作用による競合と非決定性

List<String> output = new ArrayList<>();
list.parallelStream().forEach(output::add); // 非同期競合

上記はスレッドセーフではないコレクションに対し、同時にaddを実行しており、ConcurrentModificationExceptionの原因になります。並列streamで副作用を含めることは原則避けるべきです。

レビュー観点

• parallelStreamが使われている場合、副作用を含む処理・順序依存の処理がないか必ず確認
• 並列性のメリットが期待されている処理か？（軽量ループであればむしろ逆効果）

2. Collector拡張とレビューアーが注視すべき構造判断

Stream APIの中でも、collect()は終端操作として構造を決定づける機能です。特にカスタムCollectorを定義している場合、構造的ミスが見逃されやすく、レビューでの理解とチェックが必須です。

2.1 標準Collectorの構造を理解する

List<String> result = stream.collect(Collectors.toList());

これは実質、以下のような構造を暗黙に持ちます：

Collector.of(
    ArrayList::new,       // supplier
    List::add,            // accumulator
    (l1, l2) -> { l1.addAll(l2); return l1; }, // combiner
    Function.identity()   // finisher
);

つまり、どのように値を蓄積し、並列処理時にどう結合し、最終形式に変換するかを一つの構造として持っているのがCollectorです。

2.2 カスタムCollectorのレビュー例

public static Collector<User, ?, Map<String, List<User>>> groupByDept() {
    return Collectors.groupingBy(User::getDepartment);
}

この程度なら安全ですが、以下のような独自ロジックが入ったCollectorはレビューで注視が必要です。

Collector<String, Set<String>, String> joiningSet = Collector.of(
    HashSet::new,
    Set::add,
    (left, right) -> { left.addAll(right); return left; },
    set -> String.join(",", set)
);

レビュー観点

• combinerが並列処理対応かつ破壊的でないか（mutableなSetやMapを返す構造に注意）
• finisherがnullを返さない設計か／Optional化すべき構造か
• 中間状態と最終結果の型が乖離していないか

3. 自作Function／Predicateの構造化と再利用可能性

ラムダ式は匿名関数として便利ですが、テスト性・再利用性・構造の透明性を犠牲にしやすいです。レビューでは、ラムダが繰り返されていたり、副作用混在やif多発の兆候があるときに、関数オブジェクトへの昇格を検討すべきです。

3.1 通常の使い捨てラムダの問題点

stream.filter(x -> x.getAge() > 20 && x.isActive())

このような複合条件をその場で書いてしまうと、同じ条件を別の場所でも繰り返す可能性が高くなります。

3.2 Predicateの昇格例

public class IsAdultActiveUser implements Predicate<User> {
    public boolean test(User user) {
        return user.getAge() > 20 && user.isActive();
    }
}

使い方：

stream.filter(new IsAdultActiveUser());

これにより、以下の利点が得られます：

• 条件に名前がつく
• テスト可能になる
• 他のフィルタでも組み合わせ再利用が可能

レビュー観点

• 同じようなラムダ式が複数箇所に見られる → 明示的な関数化を提案
• 複合条件が匿名のままになっている → 読解負荷・再利用性の観点で命名されたPredicate化を検討

4. Stream構造と非同期処理の設計的違い──並列≠非同期を読み間違えない

Java Stream APIは並列実行可能な構造（parallelStream）を提供しますが、これは非同期処理（Future/CompletableFutureなど）とは本質的に異なります。
ここを混同すると、「async処理のつもりでstreamを書いているのに期待通りに非同期にならない」という設計破綻を生みます。

4.1 並列処理と非同期処理の違い

4.2 レビュー観点

• 並列Streamで“非同期合成”のような使い方をしていないか？
• streamでやろうとしている処理は、CompletableFutureで記述した方が構造的に明確になるのではないか？

5. Streamの“見えない流れ”を可視化する構造と設計判断

Streamのコードは見た目が短く、全体の流れが見えにくいというデメリットがあります。とくに以下のようなケースでは、構造を可視化する工夫がレビューで推奨されるべきです。

5.1 peek()とログ出力は可視化の道具だが、運用には向かない

stream.peek(System.out::println)

これは一時的には便利ですが、副作用と誤解されやすく、実行保証もないため、レビューでは構造的ログ出力の可視化戦略として次を推奨します。

5.2 明示的な“トレーサ関数”を挟む

public static <T> Function<T, T> trace(String label) {
    return x -> {
        System.out.println(label + ": " + x);
        return x;
    };
}

// 利用例
stream.map(trace("after mapping"));

レビュー観点

• peekが使われている場合、「開発中の一時的ログ」なのか「構造的ログ」なのかを区別できるよう設計されているか？
• ラムダの中でSystem.outが混ざっていないか？ → trace関数に昇格できないか？

6. まとめ──Stream APIをレビューで評価する“設計的な読み方”を身につける

本記事では、Stream APIの応用的な使い方とそれに伴う構造的な設計判断に焦点を当てました。最後に、レビューアーとしてStreamをどう読むかを観点別にまとめます。

✔ レビューアーの視点チェックリスト（応用編）

ベストプラクティスの再整理

• 副作用と構造操作は分離すること：map/filterは純粋に
• 構造の断片（関数・predicate）を明示的に部品化：再利用とテストがしやすい
• Collectorやtraceなど、設計での“見えやすさ”を重視：構造の意図が伝わるコードに

Stream APIは、ただ短く書くための道具ではありません。
それは「処理の構造を定義するDSL（ドメイン特化言語）」のようなものであり、レビューアーはそこに副作用の混在・構造の歪み・目的とのズレがないかを、構文だけでなく構造全体の視点で読み取るべきです。

構造を読む目こそが、Stream設計を支える本質的なスキルです。