ブローガスト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
読み込み中...
関連する記事
タグ「雑談」の記事
最近まで、散歩コース生成のアプリに夢中で こぶりーを放置していました。 個人ブログを見つけて読んでシェアするアプリ、こぶりー。 先月に比べてアクセス数などが少し減っていて、リピーターはありがいたいことに一定数いらっしゃいます。 なにかないか
今日は2トピックを書こうと思います。 爆音花火 地元のお祭りに行ってきました。 お祭りの最後に花火をあげるのですが、爆音の音楽（J-POP）を流しながら見る形式でした。 滋賀に来てこれで3回目の花火だったのですが、過去3回とも同じ形式でした
2026年09月06日
今日、ロピア 彦根ナフコ店 がオープンしました！🎉 滋賀県初上陸です！！！ https://news.yahoo.co.jp/articles/42e97a43ba389d117d916250be9c9c37ce1ff764 https:
2026年09月04日