ブローガスト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
読み込み中...
関連する記事
タグ「雑談」の記事
今日はちょっと疲れまして、短文です。 情報漏洩・不正アクセスが日常茶飯事になっている今、今度はPHPの致命的な脆弱性が発見されたのこと。 PHP で運用されているサービスは世の中にはたくさんあり、サービス終了せざる得ないものもありました。
2026年10月22日
※ 烏野と音駒の戦いの話ではありません。 私が住むアパートのゴミ捨て場が荒れています。 1住民としてトラブルを起こしたくないので、何もしていません...。 ずっとゴミがある 高さ170cmぐらいの大きなゴミ捨て場があり、居住者全員のゴミ箱で
2026年10月20日