ブローガスト3日目: Technology Radar Vol. 34 所感
今更ですが、Technology Radar Vol. 34 が今年の4月に公開されていました。
前回の記事は、こちらです。
Vol. 34 は前回同様 AI 周りばかりでした。
そんな中で気になったものをいくつかピックアップします。
ミューテーションテスト
プロダクションコードの一部をランダムに書き換えて、テストが失敗したらテストコードが正しいと判断し、
逆にテストが成功してしまったらテストコードが誤っている、という判断になります。
ミューテーションテストで有名な StrykerJS は、過去以下の記事で取り扱っていました。
それが再浮上したのは、昨今のAIによる品質保証を担保する方法の1つとして有効かもしれないからです。
AI はテストコードを大量生成されますが、私はこれを最近嫌っています。
以下で理由を述べています。
このミューテーションテストは、テストコードをテストするようなもので、
大量テストコードの質を上げるためのツールとして悪くないかもしれません。
とはいえ、ノールックな大量テストコードには嫌悪していて、
同様にミューテーションテストで足りないテストコードを大量追加する というのも嫌悪しています。
（じゃあ何がいいんじゃいは、時間が足りないので書きません）
アーキテクチャ検証
AI コーディングでのアーキテクチャを検証するツールというのがありました。
記事では、Spectral, ArchUnit, Spring Modulith の3つが例として上がっていました。
ArchUnit は過去に試した記事がありました。
レイヤードアーキテクチャやモノレポのアプリケーションでは、依存関係を整える必要があります。
この依存関係を無視してプログラムを書かれないように、ArchUnit などのようなツールで検証する、という具合です。
ArchUnit じゃなくても、ESLint などのルールでも定義することができます。
先のミューテーションテストと同様に、AI コーディング を守る為のガードレールです（イマドキはハーネス）。
私もこういった検証パターンをいくつも用意していますし、
AST 解析によるオレオレリントで守りたい形を制限していたりします。
これは私がプログラムを理解する為に欠かせないもので、
守られているルールをたくさん用意しておけば、
コード理解を邪魔するものが減ってメンテしやすいと思っているからです。
終わりに
AI 関連の流行り廃りは異常なので、AI 増幅器として力を発揮できるように UI デザインを徹底して勉強しています。
好きだからというのが一番です。
-
s※ ログイン不要で投稿できます。
※ 同じブラウザから投稿を削除できます。
0
読み込み中...
関連する記事
タグ「雑談」の記事
稼いだお金は、使ったからこそ価値があります。 使わなくても保持しているだけで、精神的な安定性に繋がる良さもあります。 だからといってずっと持っているよりも、それを使って得る体験には、何物にも代えがたいものだったりします。 老いるとできること
2026年08月23日
今日の投稿で、連続投稿300日目です。 もう2ヶ月続ければ、1年です！ 連続投稿して気づいたことについて、書こうと思います。 ネタは尽きない 連続投稿7日目ぐらいに、書くネタが尽きるかなと思っていました。 田舎暮らしだし、外出も多くないし、
中学生の頃、所属する剣道部の顧問がとんでもなく怖い先生だったのですが、 とても感謝している恩師の一人です。 そんな恩師との思い出を書こうと思います。 跨って竹刀で叩く 剣道での練習の中で、掛かり稽古 があります。 10分間など時間内に、1対
2026年08月21日