プログラマの多くは開発者コミュニティから 50 % 以上の情報を集める 35
ストーリー by reo
リファレンス不要論とかではない 部門より
リファレンス不要論とかではない 部門より
taraiok 曰く、
2010 年 9 月の時点で、MSDN ライブラリはマイクロソフト関連の技術および製品マニュアルを約 1600 万トピックほど提供しているという。こうしたドキュメンテーションの作成にはかなりの労力とコストが必要になる。とくに API に関するドキュメンテーションの作成はまとめるのに苦労するとされている (doi: 10.1109/MS.2009.193) 。しかも、こうして労力をかけて作成された文書類は実際に利用される機会がかなり少ないとされている (doi: 10.1109/MS.2003.1241364) 。
ninlabs research が Android 開発者 1316 日分の閲覧履歴を調査したところ、開発者コミュニティである Stack Overflow が 9234 回であったのに対し、Android 用の公式ドキュメントへのアクセスは 2547 回であったことが分かった。結論としては、開発者の必要な情報の約 50 % は Stack Overflow から取得できるうえ、公式サイトよりも必要な情報が手に入るとしている。また、Web 検索からは公式資料よりも 2 倍 ～ 10 倍ほど Stack Overflow へのアクセスの方が多かったとしている (ninlabs research の記事、本家 /. 記事より) 。
実際の利用を前提した説明とAPIの作例 (スコア:3)
だと実際の利用を前提としたソースとかの方が確かに便利だとは思う。
もちろん公式のAPIに沿ったものを必要なのでケースバイケースだとは思いますけど。
個人的には言語の壁は大きいので、公式が英語のみとかだと情報量が少なくても日本語のものを探してしまうというのはたまにある。
# いろいろ彷徨ったあげく欲しい情報が2chに書かれてたとかよくあるし
Re:実際の利用を前提した説明とAPIの作例 (スコア:1)
日本のプログラマの多くは開発者コミュニティから 50 % 以上の情報を集める
と称して2chに入り浸る
継続的にマニュアルに反映させる努力が必要 (スコア:3)
継続的にコミュニティの交流結果をマニュアルに反映させる努力が必要ですね。
努力というか精度づくり。そのほうがローコスト。
それに、必要な部分から先にマニュアルが整備されていく。
コミュニティの方には、「このトピックはマニュアルにマージされたのでそちらを見てね」てきなrefを残して置けるようにして。
# と言っても自分では作らないw
新人。プログラマレベルをポケモンで言うと、コラッタぐらい
リファレンスとQAの需要の差では？ (スコア:2)
Webで情報を調べようと思うのは、何か解決したい問題や実装したい機能があって調べるから
「したいことを実現する」APIの使用例や、「発生したエラー」に対して何を調べるか
を教えてくれるページの方が有益と考えるのは仕方がないとおもいます。
公式情報だと情報が網羅的に列挙されているように見えてしまうので
自分のやりたいことにフォーカスした情報が嬉しいんでしょうね。
Re: (スコア:0)
QAの方がこういう理由で役に立つというのは皆さんおっしゃる通りだと思いますが…
確認のために一次資料も見てほしいところ。
「ブログで見た」とか言って、意味を理解せずおかしなコードをコピペする奴が多い。
Re:リファレンスとQAの需要の差では？ (スコア:1)
リファレンスは疑問があった時に調べるのでしょう。
私も多くの場合で、そうします。
まずコードを書いてから、スタートする事が多いですね。
複数のブログエントリの内容に食い違いがある場合は慎重になります。
でもリファレンスをいきなり当たるよりも有益であることが多いです。
リファレンスを見てよくしてしまう勘違いとかが含まれている場合も少なくないからです。
ただのバージョン違いで発生した差異の場合もありますが、
この場合も、バージョンによって推奨される書き方が違うという情報を得ることができます。
と言う事情で、リファレンスはどうしてもはじめに当たる情報である機会が少なくなってしまいますね。
あと、MLなどで機能を実装する前や試験実装したときのやり取りなどもリファレンスよりもためになります。
これに関しては、オープンソースではリファレンス情報がちゃんとまとまってることが少ないからでしょうかね？
実装のほうが先に行ってることが多くて。
Re: (スコア:0)
リファレンスの出来次第なんですが、エラーや例外とか、引数の取りうる範囲とか、本当は全部確認しておくべきことなんですよね。
コードの大部分ってそういうのですから。
ただ、初めにあたるものでないのはその通りです。あれってAPIから動作を引くものでしょ。
でも、まず必要なのは動作からAPIを引くこと。
まずリファレンスにあたるってのは、英訳のときに英和辞書引くようなもの。
頭にフレーズが浮かんで確認のために英和辞書引くのはわかる。でも、普通は和英辞書、もしくは例文集。
今の時代なら機械翻訳できる。
ただ、機械翻訳そのままってのはない。そこから英和辞書ひいたり再翻訳したりして確認する。
リファレンス引くのもそういうことで、ググって用例見つけたら、改めてリファレンスで確認したいところ。
でもそのリファレンス信用できないと結局テストコード書いて検証するんだけどね。
フィルタリング効果 (スコア:2)
コミュニティの情報は、そうした苦労をした先人の知恵が集まっている訳で、膨大な公式情報から色々なユースケースに対応してフィルタリングされた情報があるので、まずこれを参照するって事になるのでしょう。
でも最後は公式情報で裏を取る、最新情報を確認する、ってのを怠ると痛い目にあうかも。
マニュアル読むよりも、似たようなコードをコピペしたほうが早い (スコア:1)
既に動いているコードをコピペしたほうが効率的なんですよね
＃一通り試してから、確認のためにマニュアルを読む、みたいな
Re:マニュアル読むよりも、似たようなコードをコピペしたほうが早い (スコア:2)
＞そもそもマニュアル自体、あまりアテにならないことが多々あるので、
＞既に動いているコードをコピペしたほうが効率的なんですよね
結局これだと思うんですよね。
「それっぽいものをコピペした方が早いじゃん」みたいな。
ただ、ここで「出来る人」と「出来ない人」の差が出てくると思う。
出来る人 ： そのコードを参考に（一部抜粋など）して、最終的に自分のロジックにする。
出来ない人： そのコードを丸写しして、後はその前後を整えて完成。
ググるのは良いけど、
そこで見つけた資料を見て「考える」という行為をする人としない人の差は大きいと思います。
＃いつも皆様のコードを参考にさせてもらっています。
＃本当にありがとうございます。
＃＃そういや、ここで日記書き始めた切っ掛けって、
＃＃備忘録にするつもりで始めたはずだったのに、気がついたら変な方向に・・・
Re: (スコア:0)
そもそもこういうプログラマ自体、あまりアテにならないことが多々あるので、
既に書かれている設計書からかけ離れたコピペコードを書いておきながら、設計書に文句をたれるサマは非効率的なんですよね
＃一通りマニュアル読んでから、設計書の不備を指摘してからだろ、みたいな
Re: (スコア:0)
Re: (スコア:0)
なんでもいいけど「マニュアルをミスリードして」ってのはなんか気持ち悪い言い回しだ。
いやmisreadってのがあるのは分かるんだけども。
Re: (スコア:0)
自分がコミットしたくせに、内容について聞くと、コピペしたから分からないとかほざく輩もいますよね
Re: (スコア:0)
＞＃一通り試してから、確認のためにマニュアルを読む、みたいな
あー、その通りの動きしてますね、私。
何で動くか（自分では動かせなかったか）わからないと怖いですし。
聞いたほうが早いってこと？ (スコア:1)
社内でもマニュアル用意したり、ポータルで告知しても、電話やメールで直接問い合わせる人は減らない
階層構造 (スコア:1)
質問サイトで回答をコピペするだけのプログラマ→たくさんいる
公式ドキュメントを読んでて質問サイトで回答するプログラマ→少ない
というだけのことではないかと。アクセスが少ないからって公式ドキュメントを廃止すると回答する人がいなくなってしまうのでコピペプログラマも困ることになる。
Google先生万歳 (スコア:0)
誤：プログラマの多くは開発者コミュニティから 50 % 以上の情報を集める
正：プログラマの多くは検索エンジンの結果から 90 % 以上の情報を集める
検索結果がStackoverflowに集中しているというだけで、これは結果論では。
そこは本質じゃないんでは (スコア:1)
半分以上を発売元の用意した情報源ではなく横のつながりから入手している、ドキュメント作るの手間
かかって大変だけどみんな読まないよねという話なんだから、検索エンジンの検索結果が偏ってるか
どうかなんてどうでもよいのでは。
Stackoverflowはコミュニティの実例として比較に上げてるだけでしょう。
検索結果に偏りがあれ、現在コミュニティから必要な情報の大半が得られるならコストをかけてドキュ
メント整備するよりコミュニティを育てる方に力を入れた方が良いかもしれないわけで。
個人的には1回ダウンロードしとけばいい公式ドキュメントと、随時更新される相談サイトのアクセス数
比較に意味があるのか？と思うけど。
それぞれの保有してる情報のタイプも違うしね。マニュアルとケーススタディはどっちも必要で、比較
するようなモノじゃない。
いいアドバイスくれる優秀な開発者も、まず公式ドキュメントを読んで実装してみるところから始めてる
んだし。
説明はあるけれど… (スコア:0)
リファレンスはある程度知っていれば何が書いてあるかわかるけど、
所見では何の事やらさっぱりなことが多い。
概念的な説明が不足していると感じる。
Androidのだとクラスのメンバ一覧の説明があってもそのクラスがどういう役割で
他のクラスとどう関わるかみたいなところが見えてこない。
#オンラインは遅いからリファレンスはローカルで見てるだけだったりして
Re:説明はあるけれど… (スコア:1)
そのＡＰＩを通して向こう側が何をするのか、を知った上でこちらの
アプローチを考える、べきだと思うので「お前はなにをするの？」が
知りたいと思うのだけど、「呼び出し方はこうよ」の情報で終わって
いることが多いと思う。＞MSDN ライブラリ
そういう読み物を書くのが大変だという気持ちはわかるし、そのような
読み手は想定していないのかもしれないが。
Re: (スコア:0)
だから、まずサンプルなりを見て、なるほどこういう流れで処理するんだ！というのを把握した上で読むと理解できるけど、いきなりAPIだと、でどうすればいいの？って感じになる。自分の場合。
Re: (スコア:0)
APIの説明なんて、そういう書き方しかできないでしょ。
サンプルとの役割分担で問題ない。
ネジの説明に用途を色々と書くようなもんで、基本的には仕様のみで良い。
読みづらい (スコア:0)
たとえばWin32APIを検索キーにしてヒットするMicrosftのサイトだけど、これがまた書かれている内容が色んなページに分散していて読みづらい。
VC2.0の頃だったかにWindowsHelp形式のマニュアルがあったと思うけど、それが一番便利だった。
そのちょっと後のWeb版も、日本語化はされてなかったけど不便ではなかった。
今の形式は不便すぎる。
Re: (スコア:0)
バグなのか仕様なのか・・・。
Overviewとかはほとんど何も書いてないに等しかったりしますし。
あと、COM APIだと、対応するWindowsのバージョンすらよく分からなかったり・・・。
英語版でも十分酷いが、日本語版は使えたもんじゃない。ググって日本語版が先頭に来ると殺意を覚えます。
Re:読みづらい (スコア:2)
ページ左側の目次部分のことだったら、コツがあります。英語版を読んでいるのにURLにja-jpが入っていたらダメで、そこをen-usに書き換えてあげると目次が現れることがよくあります。
ほかにも、/en-us/library/……/xx00000(v=xx.XX).aspxの……部分を正しいものに書き換えないと目次が現れない場合もありました（これはちょっと例をすぐに思い出せない）。
Re: (スコア:0)
しばしば否定と肯定が逆になってるんで、ウチではMSDNの日本語版は絶対に見るな、が規約になってますです。
# 機械翻訳なのになんでなんだろね
Re: (スコア:0)
確かにローカルのヘルプファイルの方が使いやすかったなあ。
WinhelpからHTMLHelpに変わって以降、ヘルプの作り込みが粗雑になったような気がする。
あのレスポンスの悪さも作業効率を下げてそうだし。
#とはいえ加除式リファレンスの利便性も捨てがたい
それもあるけど (スコア:0)
たまに記述が間違ってることがあったり、でそれに対する回答を得るには、インシデント持ってないといけなかったり（向こうのミスだったら後で返してくれるけど）、回答に時間かかったり（自分⇔日本MS⇔米国MS）…そういうところもMSDNライブラリはネック。
結論：ぐぐるな (スコア:0)
間違ったコード(この場合は設定ファイルだが)が広まるのでぐぐるな、て話もありますね。
http://ya.maya.st/web/RTFM.html [ya.maya.st]
2ch へのアクセス禁止で開発効率が大幅に低下 (スコア:0)
> 1. 2ch へのアクセス禁止で開発効率が大幅に低下
http://blog.livedoor.jp/lalha/archives/50156986.html [livedoor.jp]
これって本当なんですかね。
プログラム板とか、そんな仕事でどうこうみたいな書き込みとかすくなさそうだけど。
Re: (スコア:0)
自分の経験では、具体的に何かが書いているわけではなくて、
目的地へのキーワードとかヒントが見つけられる事が多いです。
Re: (スコア:0)
ム板は知らないけどWeb制作板だとよくあるけどね。
わざわざ仕事で云々なんて言わなくても、こういう仕様でなければいけないとか、納期があと何日とか言うからすぐにわかる。
developer.android.comはね… (スコア:0)
androidの場合はドキュメント読むより
ソース読んだ方が理解できるからなー
読んだ結果のスポイルがstackoverflowなんだろうし
更新履歴もなくjavadocも記載されてないような
公式サイトじゃそうなるよね
近頃はhangoutばっかりで更新自体滞り気味だし
利用率≠重要度 (スコア:0)
オープンソースなら公式資料にに不備があってもソース読んでどうにか出来るけど、プロプラで公式資料腐ってると絶望的だと思うんだよね。
結局プロプラで、野良情報が潤沢に見つかるのはしっかりとした公式資料が整備されてるからなわけで、そういう意味では Microsoft Good Job ! って話だと思うんだわ。
Android の現状は良く分からないけど、10年くらい前の OpenCV なんて野良資料少ないし、マニュアルも舌足らずで、逐一ソース当たんないと関数に渡すポインタのどれがユーザーの責任で malloc/free されるべきかすら分からん状況だったよ。