アカウント名:
パスワード:
本文では触れられてないけど、このニュースのキモはやっぱここでしょう。静的解析ツールではいけないのだろうか…?
例えばソース診断は、品質の低いコードを探し出し、レビュー作業を省力化するツールだ。具体的にはソースコードを画像化した上で、ディープラーニング(深層学習)で分析。ネスト構造が深い、コメントが少ないといった、可読性が悪いソースコードをAIが診断する。
・関数名や変数名にちゃんと連番が振られているか。・修正部分の履歴や差分がコメント内に残っているか。・ポインターやクラスなどの理解し難い言語機能を使用していないか。
富士通製のツールならここいら辺もチェックしてくれると思う。
> ・ポインターやクラスなどの理解し難い言語機能を使用していないか。 これ↑が抽出対象の「読みにくいコード」ですね!
そんなツール使わなくても
1. エディタの倍率を下げて字を小さくする2. 黒っぽく固まってるあたりがヤバイところ
という判定方法でだいたいやばいところはわかる。あと、縮小しても数十画面にわたるくらい縦長になるソースはだいたいやばい。
あと、「すでにシステムはあるんですけどサポート切れで…」と言われて出てきた画面の画像を判定したら表計算ソフトか簡易DBソフトのようなマス目ベースの映像が映っていた場合もヤバイ。
冗談で書いたつもりが意外にマジで読まれててww
「すでにシステムは有る」の件は、聞いてみたら
・職場で昔に「できる人」が作った秘伝のAccessシステムだった・同上でExcel VBAパターン・近いものでVB4とかで作ったアプリが今頃発掘された
という、なんというかシステム開発や移行案件っていうよりは遺跡発掘に近い案件のイメージです。
こういうのってユーザーさんに「これはやばい」と説明してもだいたい納得してもらえない上、ヘタをすると「昔にこれを作った、尊敬するデキる先輩の作品を馬鹿にするんですかー!!」みたいなことになりがちなので、むしろ「いや、***社の人工知能が判定した結果なんですよー」と言って煙に巻く材料としてどっかが「考古学的システムのソース評価AI」を作ってくれないかと思ったりする。
> そんなツール使わなくても> 1. エディタの倍率を下げて字を小さくする> 2. 黒っぽく固まってるあたりがヤバイところ> という判定方法でだいたいやばいところはわかる。
富士通のシステムは,まさにこの作業をデープラーニングで自動化しています
つまりソースコードを画像に変換して> 2. 黒っぽく固まってるあたりがヤバイところと判定しています
こういう感じで「そんなツール使わなくても…だいたい判る」系のプログラマは今後どんどんAIに置き換わると思われます
>つまりソースコードを画像に変換して>> 2. 黒っぽく固まってるあたりがヤバイところ>と判定しています
に対抗して,意味のない改行やスペースを多めに入れて,モノリシックな「黒っぽい塊」を,複数の「小さな塊の群れ」へと分割することで、F痛AIに「読み易いコード」と誤認識させるテクニックが広まるんですね、分かります。
「I.C.A.(Intelligent Code Analyzer)」に対抗すべく空白や無駄コメントでソースを調整する「A.I.C.A(Anti Intelligent Code Analyzer)」が登場し、AICA対策として「AAICA」が出てきて、熾烈な電子戦がリポジトリーサーバーで繰り広げられるという未来が見えます。
流石にその作業しかしてない訳じゃないだろうと真面目に書くべきなのかどうなんだ
そんな簡単なこと・・・は、ベテランだからわかる。素人には分からないでしょう。そんなベテランの勘所をAIで真似るというあたりか。
これぞエキスパートシステム
いわゆる人工知能をやれと言われて素人がサムネのクラスタ分析以外に手を出すと手間の割に結果も出ないから必要機材を買わず事務用ノートとMNISTサンプルコードで済ませることだけを考えるのは会社人としては正しい
それをどれだけの速度でやれますか?ってのがツールを利用する目的なのですが。人間ができるのは当然で、低コストで大量に処理できるかどうかが問題。
その人工知能は低コストで大量に開発できるのですか?
言語や環境が変われば、一から学習し直しだろうに。
技術的にはCASEツールの発展版でしょう。パターン解析で不具合が頻出するパターンを列挙するんでしょう。
これ、下手をするとバグを作りまくってきた人の癖や、バグを作りまくってきた人を教育した教育課程の癖を学習して局所解に陥ってしまう可能性はないだろうか。
いざ現場に導入するとバグを作りまくってきた人のコードは何を書いてもアラートまみれで、癖を変えようと妙ちくりんなコーディングスタイルに変えた結果さらにバグが増殖したり、教育課程側が根本解決を行わずにスタイルだけ変更して、しばらくすると標的が移行するだけになったり、それを繰り返した結果様々なスタイルが入り乱れて可読性が落ちてやっぱりバグが増殖したり。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
ソースコードを画像化して判定! (スコア:0)
本文では触れられてないけど、このニュースのキモはやっぱここでしょう。静的解析ツールではいけないのだろうか…?
Re:ソースコードを画像化して判定! (スコア:5, すばらしい洞察)
・関数名や変数名にちゃんと連番が振られているか。
・修正部分の履歴や差分がコメント内に残っているか。
・ポインターやクラスなどの理解し難い言語機能を使用していないか。
富士通製のツールならここいら辺もチェックしてくれると思う。
Re: (スコア:0)
> ・ポインターやクラスなどの理解し難い言語機能を使用していないか。
これ↑が抽出対象の「読みにくいコード」ですね!
Re:ソースコードを画像化して判定! (スコア:4, 興味深い)
そんなツール使わなくても
1. エディタの倍率を下げて字を小さくする
2. 黒っぽく固まってるあたりがヤバイところ
という判定方法でだいたいやばいところはわかる。
あと、縮小しても数十画面にわたるくらい縦長になるソースはだいたいやばい。
あと、「すでにシステムはあるんですけどサポート切れで…」と言われて出てきた画面の
画像を判定したら表計算ソフトか簡易DBソフトのようなマス目ベースの映像が映っていた場合もヤバイ。
Re:ソースコードを画像化して判定! (スコア:3, 興味深い)
冗談で書いたつもりが意外にマジで読まれててww
「すでにシステムは有る」の件は、聞いてみたら
・職場で昔に「できる人」が作った秘伝のAccessシステムだった
・同上でExcel VBAパターン
・近いものでVB4とかで作ったアプリが今頃発掘された
という、なんというかシステム開発や移行案件っていうよりは遺跡発掘に近い案件のイメージです。
こういうのってユーザーさんに「これはやばい」と説明してもだいたい納得してもらえない上、
ヘタをすると「昔にこれを作った、尊敬するデキる先輩の作品を馬鹿にするんですかー!!」みたいな
ことになりがちなので、むしろ「いや、***社の人工知能が判定した結果なんですよー」と言って
煙に巻く材料としてどっかが「考古学的システムのソース評価AI」を作ってくれないかと思ったりする。
Re:ソースコードを画像化して判定! (スコア:2, おもしろおかしい)
> そんなツール使わなくても
> 1. エディタの倍率を下げて字を小さくする
> 2. 黒っぽく固まってるあたりがヤバイところ
> という判定方法でだいたいやばいところはわかる。
富士通のシステムは,まさにこの作業をデープラーニングで自動化しています
つまりソースコードを画像に変換して
> 2. 黒っぽく固まってるあたりがヤバイところ
と判定しています
こういう感じで「そんなツール使わなくても…だいたい判る」系のプログラマは今後どんどんAIに置き換わると思われます
Re: (スコア:0)
>つまりソースコードを画像に変換して
>> 2. 黒っぽく固まってるあたりがヤバイところ
>と判定しています
に対抗して,意味のない改行やスペースを多めに入れて,
モノリシックな「黒っぽい塊」を,複数の「小さな塊の群れ」へと分割することで、
F痛AIに「読み易いコード」と誤認識させるテクニックが広まるんですね、分かります。
Re:ソースコードを画像化して判定! (スコア:1)
「I.C.A.(Intelligent Code Analyzer)」に対抗すべく空白や無駄コメントで
ソースを調整する「A.I.C.A(Anti Intelligent Code Analyzer)」が登場し、
AICA対策として「AAICA」が出てきて、熾烈な電子戦がリポジトリーサーバーで
繰り広げられるという未来が見えます。
Re: (スコア:0)
流石にその作業しかしてない訳じゃないだろうと真面目に書くべきなのかどうなんだ
Re:ソースコードを画像化して判定! (スコア:2)
そんな簡単なこと・・・は、ベテランだからわかる。
素人には分からないでしょう。
そんなベテランの勘所をAIで真似るというあたりか。
Re: (スコア:0)
これぞエキスパートシステム
Re:ソースコードを画像化して判定! (スコア:1)
いわゆる人工知能をやれと言われて素人がサムネのクラスタ分析以外に手を出すと手間の割に結果も出ないから
必要機材を買わず事務用ノートとMNISTサンプルコードで済ませることだけを考えるのは会社人としては正しい
Re: (スコア:0)
それをどれだけの速度でやれますか?ってのがツールを利用する目的なのですが。
人間ができるのは当然で、低コストで大量に処理できるかどうかが問題。
Re: (スコア:0)
その人工知能は低コストで大量に開発できるのですか?
言語や環境が変われば、一から学習し直しだろうに。
Re:ソースコードを画像化して判定! (スコア:1)
本文に対応言語が書いてなかったが.
それなら,読ませてみたいものとして
1)古い(固定書式の)FORTRAN/COBOLで書かれたコード
2)whitespaceで書かれたコード
3)パンチカードとか紙テープで出力されたコード
4)プログラムの仕様書
Re: (スコア:0)
技術的にはCASEツールの発展版でしょう。パターン解析で不具合が頻出するパターンを列挙するんでしょう。
Re: (スコア:0)
これ、下手をするとバグを作りまくってきた人の癖や、
バグを作りまくってきた人を教育した教育課程の癖を学習して局所解に陥ってしまう可能性はないだろうか。
いざ現場に導入するとバグを作りまくってきた人のコードは何を書いてもアラートまみれで、
癖を変えようと妙ちくりんなコーディングスタイルに変えた結果さらにバグが増殖したり、
教育課程側が根本解決を行わずにスタイルだけ変更して、しばらくすると標的が移行するだけになったり、
それを繰り返した結果様々なスタイルが入り乱れて可読性が落ちてやっぱりバグが増殖したり。