ブローガスト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
読み込み中...
関連する記事
タグ「雑談」の記事
寒くなりましたね。 我が家ではついに暖房を解禁しました。 11月7日は、気象庁の区分では秋ですが暦の上では 立冬 と呼ばれる冬の始まりのようです。 お鍋や肉まんが食べたくなりますね。 スタバにて 毎週通っているスタバにて、注文時にいつもの店
2026年11月07日
なんとなく原点回帰したい気分でしたので、今の職業を目指した理由を思い出してみます。 なんとなくIT学科へ 中学でいじめられていた背景により、高校ではひたすら勉強して良い大学に行こうとしていました。 親も応援してくれていて、早い段階で塾通いを
2026年11月06日
今日は下呂温泉に来ていますので、スマホから書いています。 スマホからだと画像とか細かいことができないのは、改善ポイントですね。 下呂に来ると、とにかく足湯の多さが目立ちますね。どこもかしこも観光客が足湯を堪能しているので、足湯しようと椅子に
2026年11月03日