あなたの「コード読解力」はどれくらい? 72
ストーリー by makeplex
自己研鑽は欠かさずに 部門より
自己研鑽は欠かさずに 部門より
あるAnonymous Coward 曰く、
奈良先端科学技術大学院大学の森崎助教らによると、ソースコードの読解力は個人差が大きく、実験では同じソースコードを理解するための時間に6倍もの差があることが確認できているそうだ(「2,000行のJavaソースコードを読むのに何分かかりますか?」)。
といっても、自分の「ソースコード読解速度」が速いのかそれとも遅いのか、なかなか立ち位置を知るのは難しい。そこで森崎助教らは、研究の一環としてオンラインでのソースコード読解ハンズオンを公開した。これにより自分のソースコード読解能力が他人と比べてどの程度なのかをチェックできるとのこと。また、集計されたデータは個人情報を除去した上で公開されるほか、ソースコードの差分(パッチ)とその理解に必要な時間(コスト)との関係を明らかにする研究の題材にもなるそうだ。
コード読解力 (スコア:5, おもしろおかしい)
職場に異様にコード読解力の高い人がいます。
どんなに絡みあった電源コードやLANコードもあっという間に解いてしまいます。
#えっ違う?
Re:コード読解力 (スコア:1)
ウチの職場にもいます。
そして私の配線は美しくないです。
スパゲティコードという言葉を知って暫くの間、
結線のことだと思い込んでました。
#ごめんなさい、ごめんなさい、ごめんなさい
☆大きい羊は美しい☆
Re: (スコア:0)
1げっと (スコア:3, 興味深い)
逆に同じところを何度も何度も見ていることもあるが、大事な箇所だったんだろう
あと目をひいたのは、ファイルを先頭から最後まで(読まないなりも)目を通していたところかな
楽譜の読み方とおなじ (スコア:3, 興味深い)
定型的なパッセージは詳しく読まなくても弾けますが、個性的な部分や技術的に難しい部分には、自然に目がとまります。
そのような読み方ができるかどうかも、演奏技量に依るところが大きいということも。
Re:1げっと (スコア:1, 興味深い)
>あと目をひいたのは、ファイルを先頭から最後まで(読まないなりも)目を通していたところかな
そりゃそうだ。
前からたどっていくよりも「あ、あんな記述あったっけ」って
思える方が、早いからね。
IDEで、プログラムの構造がツリーになって見えていたとしてもやっぱ見ておくかな。
でもやっぱり、同じ所を何度も見てるってのは
プロフラムの目的が分かっているからだと思います。
どういう部分が胆か、想定してかかっているからですね。
自分ならキーになるAPI(いくつか候補はありますが)を叩いている部分を探したりして特定すると思います。
それは内容ともご相談ではないのか? (スコア: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:あるべき論 (スコア:1, 興味深い)
アウトライン機能や、使用箇所、定義箇所にジャンプする機能などを使っているからか、あなたの言う次元を意識した事はありません。
#個々のメソッドがコンパクトにまとまっている良いコードである事が前提です
Eclipseに限らず、IDEを使っている人、エディタを鍛えまくっている人は同じ事を感じているのでは無いでしょうか。
で、こういう支援機能を外付けするためには、元となるソースはプレーンなテキストであった方が有利なのだと思うのです。
いわゆるビジュアル言語が、簡単と言われながら主流とならないのは、外側から支援機能を付け足すのが困難だからという側面もあるのでは?
Re:あるべき論 (スコア:3, すばらしい洞察)
私はもっと古くさく、エディタだけですべてを完結させたい、
IDEでさえも気持ちが悪い日曜プログラマです。
旧式のプログラミングだと、ソース(やMakefileなど)さえ
見ればすべてが記述してある、という安心感があります。
IDEだと、メニューのどこにどんな設定があり、それによって
同じソースでも違うバイナリができるとか、あと自動生成
されたソースなんて読む気にならないし(これは言語や
ライブラリ側の問題で、自動生成できるようなコードなんて
1行で記述可能にするべきです)。
次元という話をすれば、1次元が2次元になったところで
たかが知れているという気がします。ブロックダイヤグラムの
ようなものは書きやすくなりますが、ちょっと複雑になると
すぐに2次元の紙の上では線が結べなくなります。1次元
よりはちょっとまし、くらいの感じでしょうか。それくらいなら、
そんな五十歩百歩の2次元はばっさりと切り捨てて、自然言語に
近くテキストエディタがそのまま使える1次元構造を
守った方がいいと思います。
Re:あるべき論 (スコア:2)
>個人的には、CADを使って図面を書いていく経験があると
>ソースコードの記述も2~3次元の記述が楽なCADでやりたくなりますね。
プログラミングをCADで例えるのは、
ソフトウエア開発を建築で例えるのと同じくらいに大間違い。
>・階層構造の記述が基本。拡大縮小により、全体を俯瞰するのも細部を見るのも一画面。
プログラムは階層構造ですよ。
#やっぱり分かってない。
Re:あるべき論 (スコア:1)
長大関数はイカンとレビューで指摘されたら、一連の処理を3つくらいにぶった切った人がおりました。
hogeFunc()が処理の流れもそのままに hogeFunc1(), hogeFunc2(), hogeFunc3() に分裂しただけでしたが。
Re:あるべき論 (スコア:1)
オフトピ気味だけど
アステリアとか使ってみるといいと思うよ
ttp://japan.cnet.com/blog/kenn/2005/05/18/entry_asteria/?cmode=tlist
ここでは、ビジュアルプログラミングが成功するのは難しいとか
この本(言語がってこと?)は萌えないとか書いてあります。
私は、ビジュアルプログラミングって気持ち悪いけどね
Re: (スコア:0)
> ここでは、ビジュアルプログラミングが成功するのは難しいとか
> この本(言語がってこと?)は萌えないとか書いてあります。
リンク先ではなくて、献本された人の感想ですね。
> 私は、ビジュアルプログラミングって気持ち悪いけどね
リンク先でも、難しいことをやらせるとぐちゃぐちゃになると正直に書いてあります。
MacのAutomatorもプログラミング環境というには非力ですが便利ですよ。
Re:あるべき論 (スコア:1)
あなたの人生の物語を思い出した。
曼荼羅みたいな表現でぐにゃぼやーっと部分ではなく全体の理解に至る言語のお話だから、
プログラミングの理想とは正反対なのかな。
私は純文系の道を歩んでいて仰っている事のほとんどが理解できてないと思うけど。
Re:あるべき論 (スコア:1)
ソースって二次元の画面に書いたものしか見たことないなー。
ソースが上から下へ並んでて、コマンド情報が横に書かれてて、さらにインデントで深さがあるから、三次元じゃない?
大体、computerの中でも、一次元のaddressに命令と参照address情報が入ってて二次元になっているんだし。
the.ACount
Re: (スコア:0)
Re: (スコア:0)
ソースの2次元化っていうのはどうなんだろう。ちと想像できない。
どんなプログラミング言語でも結局は、CPUにフェッチされる順序を記述しているんじゃないかなぁ。
これって、どこまで行っても線形なんだよね。
Re:あるべき論 (スコア:2)
>CPUにフェッチされる順序を記述しているんじゃないかなぁ。
そういう意味ではマルチCPUの並列マシンは二次元的と言えるなあ。
難易度は古典的な一次元的プログラムの比ではないけどね。
>プログラミング言語自身の難解度は上がってると思うんだ。
むしろ下がってます。
きっとこの人は本物のプログラミングをやったことがない人なんだろうな。
#「ツールを使っている人」ではなく「ツールに使われている人」。
読む力、読ませる力 (スコア:2, 興味深い)
ソース読む人に何か書いてもらって、それを別の人たちに読んでもらって……
読むのがうまい人は、読みやすいコードを書ける人が多いのか?
読みやすいコードを書く人は、読みにくいコードを読めるのか?
といったことも調べてみてほしいです。
# 読みやすいコードを読めない人は、読みにくいコードを書く人だろうなぁ。
1を聞いて0を知れ!
研究の果てにあるものは (スコア:2, おもしろおかしい)
コード読解力が数値化されて
「コード読解力、たったの5か…ゴミめ」
といわれて首を切られる(or不採用にされる)世界。
テストを書くんだっ (スコア:2)
テストを書いてないから(n+1)を適用するのは問題がありますっ!(キリッ
ですよねー。
#テストケースを理解してからのほうが元ソースも理解しやすいと思うんだ。
書いた人による個人差も大きい (スコア:1)
ソースコードの読解力はソースコードを書いた人の能力や、書いた人と読む人の相性による部分も大きいと思う。
#ジェネリックプログラミングで書かれたコードは苦手です。
動的型付けと静的型付けの違いも (スコア:1)
私の場合は型付けの方式の違う言語間をスイッチするとしばらく混乱します.
そういうスイッチングが早くできるということもコードを理解する能力なのかな.
屍体メモ [windy.cx]
Re: (スコア:0)
書いた人の思考が想像の範囲外の時も読みにくかったですね。
不具合修正での話ですが
・計算やデータの比較チェックで合わないから、原因を追究することなく直前に比較する値を代入して比較するコードに修正。
・エラーがでてしまうので、エラー処理そのものを単純削除(エラーそのものがでない仕組みならうれしいですが)
・コメントが半分嘘。(コメントが間違いかソースが間違いか悩む。はじめから半分嘘ってわかっていればまだよかったのですが。)
まさか、そんなことするわけないって思ってどこかにちゃんとした修正があると思い何度も読み返しました。
お決まりですが (スコア:3, すばらしい洞察)
>書いた人の思考が想像の範囲外の時も読みにくかったですね。
それが実は昔の自分が書いたものだったりするんですよね。
Re: (スコア:0)
>不具合修正での話ですが
このリストに自分の感覚を追加すると
・変数名に意味のある名前がつけられている時は其れが嘘でも読みやすいです、逆に他の変数と似通った名前だったりすると読みにくい
ぶっちゃけ区別が付くか付かないかが重要だったり(意味が真逆に付いた変数名とかは許すけど意味が真逆のbool is*()はムカツク)
#意図がわからないコードはバグのある意図の通じるコードより困る
火消し屋のコード読解力 (スコア: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]まで。
コメントで議論いただいた内容は次回への参考として検討します。議論いただいた方にも感謝いたします。
長い (スコア:0)
ハンズオン記録用フォーマットのページ数を見ただけで読む気なくしました(爆)
C/C++ (スコア:0)
と思ったけれど、defineとテンプレートとoperatorを駆使し始めるとカスタムし放題で凄まじい事になりそうだ。
どの程度生成的技法を使うかで分類した上でケースを作っておかないと誤差が激しすぎるな……
いや、なんか、もう・・・ (スコア:0)
リンク先に飛んで説明文を読む時点で読解力の無さを痛感しました。
その先、コードまで読む気がしねぇや。
前提がおかしいんじゃ? (スコア:0)
自然言語だって人によって読解力に差があるのは当たり前なんだから、人工言語である
プログラミング言語に読解力は個人差が大きい事に、どんな発見が隠されているのか理
解出来ないし、6倍がそもそも「個人差が大きい」と言い切れるのかが謎です。
日本語の読解力の低い人と高い人の差が6倍程度で収まるのか?
オレなんか間違いなく下の方に位置するけどね>日本語読解力
たった6倍か (スコア:0)
せいぜい6倍程度か、思っていたほど差はないってことでしょうか。
できる人とできない人の間には数百倍の差が開いてもおかしくないと思ったんだけど。
Re:たった6倍か (スコア:1)
地球上では出来のいいプログラマでも、宇宙から来たプログラマに「戦闘能力、たったの6か。ゴミめ」とか言われちゃうんですね。
(戦闘能力1=読解能力の最小単位)
Re:たった6倍か (スコア:1, すばらしい洞察)
文字通り「できない」人との間になら無限大の差が開くと思うよ。
Re:たった6倍か (スコア:1, すばらしい洞察)
え~と通常、作業は1回では終わりませんよ? 繰り返されるものです。
なので差は n乗で効いてきます。
logをとった単位にして・・・ (スコア:1)
んー。じゃ、計算が面倒だからlogをとって10倍して単位を(デシモリサキ)にでもしてスッキリさせてと・・・6倍だと約8(デシモリサキ)ほど違いがあるんですね。
それで、力の比が約8(デシモリサキ)のときに、圧力の比に換算すると約16(デシモリサキ)になっているのでしょう。
/* 座布団1枚とモデして欲しいモード */
大槻昌弥(♀) http://www.ne.jp/asahi/pursuits/ootsuki/
Re: (スコア:0)
実際の現場には、このレベルの人がゴロゴロいます。
本人が言っているのだから間違いない。
(恐ろしいことに、職場では「技術力の××さん」で通っています)
締切(9/27,10/12)などが追記されました (スコア:2)
だそうです。