AI にコードを書いてもらうと、動くものはかなり速く出てきます。 でも、あとから差分を見て「あ、これ依存の向きがまずい」「境界を越えて直接呼んでいる」「この変更、障害が横に広がりそう」と気づくことがあります。 そのとき本当に知りたいのは、コードが動くかだけではありません。その変更で何のリスクが増減したのかです。循環依存は消えたのか。境界違反は減ったのか。障害は広がりにくくなったのか。 だから、AI が出した差分を「設計として大丈夫か」と診断するための物差しが必要になります。 この研究で中心に置く定理の名前は、アーキテクチャ零曲率定理です。 少し正確に書くと、次の形を目指しています。 ここで A は対象のアーキテクチャ、L は採用した設計ルールのまとまりです。 Lawful(A, L) は、A が L に対して健全であること NoRequiredObstruction(A, L) は、要求さ
職業エンジニアを始めてから,ソフトウェア設計論についての議論が多く目につくようになりました.それらは,よいシステムを作るうえで有用である一方で,周りのエンジニアの向き合い方に違和感を覚えることも多いです. たとえば SOLID 原則や DRY / YAGNI や OOP / FP や TDD / DDD といったソフトウェア開発における作法や経験則が,あたかも絶対的な真理であるかのように語られ,コンピュータサイエンス的に正しい,アルゴリズムとしてこうあるべきだ,原則に従っていないので誤りだ,といった強い言葉で,システムやコードの良し悪しが断罪されるような光景です. 私はその違和感を,そのまま言葉にして投稿しました. これらの投稿には,思いのほか多くの反響がありましたが,同時に「CS 学部のカリキュラムに含まれているのだから CS だ」や「実用的な工学もサイエンスの一部だ」といった反論も寄せ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く