makeplexによる
2009年09月17日 3時36分の掲載
自己研鑽は欠かさずに部門より。
自己研鑽は欠かさずに部門より。
あるAnonymous Coward 曰く、
奈良先端科学技術大学院大学の森崎助教らによると、ソースコードの読解力は個人差が大きく、実験では同じソースコードを理解するための時間に6倍もの差があることが確認できているそうだ(「2,000行のJavaソースコードを読むのに何分かかりますか?」)。
といっても、自分の「ソースコード読解速度」が速いのかそれとも遅いのか、なかなか立ち位置を知るのは難しい。そこで森崎助教らは、研究の一環としてオンラインでのソースコード読解ハンズオンを公開した。これにより自分のソースコード読解能力が他人と比べてどの程度なのかをチェックできるとのこと。また、集計されたデータは個人情報を除去した上で公開されるほか、ソースコードの差分(パッチ)とその理解に必要な時間(コスト)との関係を明らかにする研究の題材にもなるそうだ。
コード読解力 (スコア:5, おもしろおかしい)
職場に異様にコード読解力の高い人がいます。
どんなに絡みあった電源コードやLANコードもあっという間に解いてしまいます。
#えっ違う?
コメントを書く
1げっと (スコア:3, 興味深い)
逆に同じところを何度も何度も見ていることもあるが、大事な箇所だったんだろう
あと目をひいたのは、ファイルを先頭から最後まで(読まないなりも)目を通していたところかな
コメントを書く
楽譜の読み方とおなじ (スコア:3, 興味深い)
定型的なパッセージは詳しく読まなくても弾けますが、個性的な部分や技術的に難しい部分には、自然に目がとまります。
そのような読み方ができるかどうかも、演奏技量に依るところが大きいということも。
コメントを書く
親コメント
それは内容ともご相談ではないのか? (スコア:3, すばらしい洞察)
たとえば自然言語だと…
先日読んだの『若き魔道士』by 菊池秀行 の場合、読み終わるのに3時間でした。
しかし、ほぼ同じ分量のはずの『思考の整理学』by 外山滋比古 の場合、3日かかっています。
もちろん、菊池秀行の文章の方が、内容は少なく、読みやすさ最優先で書かれている、というのもありますが、それでも8倍強の違いが、同じ人が違う内容を読んだ場合でも発生するわけです。
.
プログラミング言語だって同様ではないでしょう。
という3つがそろってなお、読む人の読解力が問われる。読解力も、
などが互いに絡んで速度を決めるはずで、一朝一夕には定まらないでしょうし、本当の差は6倍ではすまないのではないか、と。
.
さらに、周囲のコードから何をしているのか判った場合、汚いので、もう読む気がしない。書き直したほうが速い と、そこまでで受け取りを拒否する確率も、速く・正しくコードを書ける人ほど高そうです。そういう人の読解速度は鍛えられることなく、遅いままじゃないか…という気もします。
fjの教祖様
コメントを書く
あるべき論 (スコア:2, 興味深い)
平易なものであるなら利用者の問題に帰結するのは仕方ないが、言語自身の難解さが
読解力に多大な影響を及ぼしている場合は、言語もしくは開発環境自身の改善が必要。
難しくしている代物をわざわざ人間が解きながら読み進めるのは本末転倒と言えるだろうし。
と、言いたくなる程、プログラミング言語自身の難解度は上がってると思うんだ。
パターンが複雑になっているにも関わらず、相変わらず1次元的に上から下に書いていく
エディタを使ってソースを書いていかなきゃならないのはもう止めにしたいものじゃないか?
GUIエディタはパーツを置いていく二次元化が進んでいるけど、ソースの二次元化は
まだまだ未熟だと思うし。
#ここで言う「次元」はあくまで記述の流れと空間の使い方を主眼に置いた時のもの。
#ソースコードって上から下に流れる様に書くけど、GUIエディタみたいに行を意識しない
#書き方ってしないじゃない、という意味で。
つまり、そういう書き方ってオブジェクト指向の言語にはたしてマッチしているのだろうか?とね。
根本的な記述方法が難解さを増しているならそれは人間の読解力に起因するものじゃなく、
言語やその記述方法の問題だと思うんだ。
#ま、今はそれを使わなきゃならないから、しょうがないけどさ。
#と書いてみる。
コメントを書く
Re:あるべき論 (スコア:4, おもしろおかしい)
> 上から下へ書いて
そんなときこそgoto文ですよ
えっ?違うって・・・
コメントを書く
親コメント
Re:あるべき論 (スコア:4, 興味深い)
えー。こんなのがいいんですかあ。>ソースの二次元化
Rail : Hello, world! [voxelperfect.net]
# よーし、パパこれでほんとのスパゲッティコード書いちゃうぞう。
コメントを書く
親コメント
Re:あるべき論 (スコア:2, すばらしい洞察)
2次元的に扱うようになったのがそもそも読解の難解度を上げた原因じゃないのかな。
いろいろな方の読み方を横から見ていると、エントリポイントを最初に探す方が多いです。
そこから、どこで枝分かれしながら処理が行われているのか調べながら、時間軸に沿って、本を最初のページから読んでいくように、1次元的に理解を進めようとします。
その線で考えると、コードの2次元化は、書くのを容易にし読むのを難解にしている、と思うのです。
コメントを書く
親コメント
Re:あるべき論 (スコア:2, すばらしい洞察)
私には2次元でものを考える習慣ってものがないです。
どのように考えるのかすら想像がつきません。
これまで私が読んだ説明書も数学の教科書も全て、上から下の1次元構造だったのです。
木構造やグラフ、図形などを2次元の図として表すのは有用かもしれません。
しかし、図だけに詳細な説明や方法を盛り込んでしまうのは難しいように思えます。
1を聞いて0を知れ!
コメントを書く
親コメント
Re:あるべき論 (スコア:3, すばらしい洞察)
私はもっと古くさく、エディタだけですべてを完結させたい、
IDEでさえも気持ちが悪い日曜プログラマです。
旧式のプログラミングだと、ソース(やMakefileなど)さえ
見ればすべてが記述してある、という安心感があります。
IDEだと、メニューのどこにどんな設定があり、それによって
同じソースでも違うバイナリができるとか、あと自動生成
されたソースなんて読む気にならないし(これは言語や
ライブラリ側の問題で、自動生成できるようなコードなんて
1行で記述可能にするべきです)。
次元という話をすれば、1次元が2次元になったところで
たかが知れているという気がします。ブロックダイヤグラムの
ようなものは書きやすくなりますが、ちょっと複雑になると
すぐに2次元の紙の上では線が結べなくなります。1次元
よりはちょっとまし、くらいの感じでしょうか。それくらいなら、
そんな五十歩百歩の2次元はばっさりと切り捨てて、自然言語に
近くテキストエディタがそのまま使える1次元構造を
守った方がいいと思います。
コメントを書く
親コメント
Re:あるべき論 (スコア:2)
>個人的には、CADを使って図面を書いていく経験があると
>ソースコードの記述も2~3次元の記述が楽なCADでやりたくなりますね。
プログラミングをCADで例えるのは、
ソフトウエア開発を建築で例えるのと同じくらいに大間違い。
>・階層構造の記述が基本。拡大縮小により、全体を俯瞰するのも細部を見るのも一画面。
プログラムは階層構造ですよ。
#やっぱり分かってない。
コメントを書く
親コメント
Re:あるべき論 (スコア:2)
>CPUにフェッチされる順序を記述しているんじゃないかなぁ。
そういう意味ではマルチCPUの並列マシンは二次元的と言えるなあ。
難易度は古典的な一次元的プログラムの比ではないけどね。
>プログラミング言語自身の難解度は上がってると思うんだ。
むしろ下がってます。
きっとこの人は本物のプログラミングをやったことがない人なんだろうな。
#「ツールを使っている人」ではなく「ツールに使われている人」。
コメントを書く
親コメント
読む力、読ませる力 (スコア:2, 興味深い)
ソース読む人に何か書いてもらって、それを別の人たちに読んでもらって……
読むのがうまい人は、読みやすいコードを書ける人が多いのか?
読みやすいコードを書く人は、読みにくいコードを読めるのか?
といったことも調べてみてほしいです。
# 読みやすいコードを読めない人は、読みにくいコードを書く人だろうなぁ。
1を聞いて0を知れ!
コメントを書く
研究の果てにあるものは (スコア:2, おもしろおかしい)
コード読解力が数値化されて
「コード読解力、たったの5か…ゴミめ」
といわれて首を切られる(or不採用にされる)世界。
RizaSTAR ( =ω=) is here.
コメントを書く
テストを書くんだっ (スコア:2)
テストを書いてないから(n+1)を適用するのは問題がありますっ!(キリッ
ですよねー。
#テストケースを理解してからのほうが元ソースも理解しやすいと思うんだ。
コメントを書く
書いた人による個人差も大きい (スコア:1)
ソースコードの読解力はソースコードを書いた人の能力や、書いた人と読む人の相性による部分も大きいと思う。
#ジェネリックプログラミングで書かれたコードは苦手です。
コメントを書く
お決まりですが (スコア:3, すばらしい洞察)
>書いた人の思考が想像の範囲外の時も読みにくかったですね。
それが実は昔の自分が書いたものだったりするんですよね。
コメントを書く
親コメント
火消し屋のコード読解力 (スコア:1, 興味深い)
若い頃はいわゆる「火消し」の仕事を多くしたのですが、そこで読まされるコードは「ぐちゃぐちゃ」で「仕様書は無いor嘘が書かれて」いて、そして「短納期」だったですね。
この頃の自分みたいに「火消し」専門職の方々は、コード読解力は高いのではないでしょうか?
(自分はもう、この能力は衰えました)
プログラム自体の理解もですが、何らかのフレームワークを使っている場合やプロジェクト固有の作法がある場合もあって、そういう部分の理解も必要ですね。
プログラム書いた人の性格とかクセを分析する事も必要でした。
このテの仕事で必須の道具はfind、grep、コード整形ツールですね。
特に自分の場合コード整形ツールは重要で、必ず(C言語なら)K&R様式に整形していました。
コメントを書く
ライトオンリー (スコア:1)
その程度の規模で、そのクオリティなら、コードを読むより一から作り直した方が速い・・・ってな回答は無しかな?
# ただし役に立たない一発芸として
コメントを書く
読解力と言うけど (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
コメントを書く
palletが気になった。 (スコア:1)
コメントを書く
脳内コンパイラ (スコア:1, 興味深い)
コードを読みながら脳内スタックに各変数をプッシュしていく。
で、各命令文において、各変数の値を変化させて行き、
結果、次にどの処理が流れるか、というのを脳内でシミュレートしていく。
こういうロジカルな思考が得手か不得手か、という話だよね。
コードレビューとかしていると、やはりこの思考の速度の差を痛感する。
話が早過ぎて、こちらがついて行けない人の説明と、
遅過ぎて、話が進む前にこちらで言いたい事がわかっちゃう人と。
逆に発言していても、こいつは話について来れてないな、
とか、話に納得してくれているな、とか。
観察していると、やはりこの思考の早い人が、
プログラマとしての総合力(早く書けるだとか、バグが少ないだとか、
書いたコードが読みやすいだとか)が高い気がする。
その中でも特に、書いたコードから発生するバグが少ない気がする。
コメントを書く
プログラム (スコア:1)
特にオブジェクト指向で作られたソフトウェアだと、静的なコードリーディングだけだとインタフェースにある関数を呼び出してても実際にどのクラスのコードが実行されるかを特定するのが難しいですし。
コメントを書く
IOCCC (スコア:1, おもしろおかしい)
コード読解力を鍛えられるサイト貼っておきますね
http://www.ioccc.org/main.html [ioccc.org]
コメントを書く
結果をいただいた方には中間集計結果をフィードバックできるようになりました(奈良先端大 森崎) (スコア:1)
奈良先端科学技術大学院大学 森崎と申します。
ページに多数の来訪をいただきました。ありがとうございます。
また、結果を送付いただいた方にも感謝いたします。ありがとうございます。
属人性、非属人性、全体傾向を明らかにするために、より多くの結果を集めようとしています。11/4, 11/24の祝日明けを締切りに設定していますので、ぜひご参加ください。
現在、結果を送付いただいた方にはこれまでの中間結果をフィードバック中です。
詳しくは、http://se.aist-nara.ac.jp/html/review/code_review_cost_estimation/html/ [aist-nara.ac.jp]まで。
コメントで議論いただいた内容は次回への参考として検討します。議論いただいた方にも感謝いたします。
コメントを書く
Re:たった6倍か (スコア:1)
地球上では出来のいいプログラマでも、宇宙から来たプログラマに「戦闘能力、たったの6か。ゴミめ」とか言われちゃうんですね。
(戦闘能力1=読解能力の最小単位)
コメントを書く
親コメント
Re:たった6倍か (スコア:1, すばらしい洞察)
文字通り「できない」人との間になら無限大の差が開くと思うよ。
コメントを書く
親コメント
Re:たった6倍か (スコア:1, すばらしい洞察)
え~と通常、作業は1回では終わりませんよ? 繰り返されるものです。
なので差は n乗で効いてきます。
コメントを書く
親コメント
締切(9/27,10/12)などが追記されました (スコア:2)
だそうです。
コメントを書く
親コメント