ブローガスト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
読み込み中...
関連する記事
タグ「雑談」の記事
今日は 絶好調な1日 でした。 調子と関係あるのか不明ですが、手の輪郭がかなりクッキリとした体感がありました。 手に持つものや、タイピングなどの手の操作も、どれも体の一部 かのような不思議な感じでした。 調子が良いのはなんででしょうか？ 天
2026年10月01日
今日はお休みなので、いろいろと用事を済ませていました。 エアコン掃除 仕事部屋のエアコンを6年ほど掃除をしていませんでした。 外見からでも汚れがよく見えるぐらいちょっと汚いなと思い、ダスキンに依頼しました。 滋賀県でダスキン業者がとても少な
2026年09月30日
こぶりー でぼーっと眺めていたら、以下の記事を発見しました。 https://tthrr.com/article/2026-09-24/ 「なるほどね。疲れた時に『これやれば自分は元気出るよ』っていうリストか！」 コーピングリストは、元気に
2026年09月25日