アカウント名:
パスワード:
ライブラリってのは自分でも作れるけど同じもの書くなら出来合いのもの使ったほうが色々手間が省けるよねっってのが本来の使い方ではないかと。
必死に不具合の回避策を探したり、
プログラマにとって、再利用によって得られるのは「楽」であることは誰にでも理解できる が実は
再利用にかかる(調査・改造)工数が新規作成にかかる工数よりも必ずしも小さいとは言えない. それを承知で再利用を強行するのは賭けだったり, 苦痛を通り越して破滅をもたらすパンドラの箱だったりすることも少なくない. だとすれば, たとえ「苦」であることが分かっていても, その限度が見切れる方を選ぶというのもプロとしては合理的なんですよね. その点, 目処がつかなければ捨てることができるアマチュアとは判断基準が異なるわけで.
もう一つは, 自分が作ったプログラムを自分で再利用する場合と, 他人の再利用を考慮した場合とではドキュメントを含めた製造コストが大幅に異なることでしょうか. 将来の定かではない多くの「楽」のために再利用できるようにしようとすると, 今の「苦」あるいはコストが少なくとも確実に増えるというのは, 再利用のモチベーションを落とすための強力な要因になると思います. このあたりは多分Easy Cultの一流派とも言えそうですけど.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
あれ? (スコア:1)
Re:あれ? (スコア:0)
自前のXMLパーサーのメンテで働いたつもりになるのはマジでやめてほしい.
そういうのが趣味なら余暇でやってくれよと.
Re:あれ? (スコア:5, おもしろおかしい)
GPLに「汚染」されたなんていうんですよね。
GNUのソース盗んどいて、仕事ができたことにするのはマジでやめてほしい
そういうのが仕事ならヤクザやってくれよと
Re:あれ? (スコア:1)
Re:あれ? (スコア:1)
プログラミングにおけるカルトなのでは?
Re: (スコア:0)
再利用カルト と すべて自前カルト
で,最悪がコードを書かずにどのカルトが最悪か延々議論すること.
さ, 今日から仕事仕事.
Re:あれ? (スコア:3, おもしろおかしい)
たしか「NIH症候群」とか言われてますよね。
"Not Invented Here"の頭文字を取ったもの。
古い世代のプログラマーほど罹患しやすい病気だそうで…。
clausemitz
Re: (スコア:0)
やばい、当てはまってるかも…
インタフェースが気に入らないって理由だけで、
コードを全部書き直してつかったりしてる。
テストだるいのが歯止めになってやらない事がおおいけど、
元から信憑性の低いコードでは嬉々として書き直す事がおおい。
Re:あれ? (スコア:1)
> 自前のXMLパーサーのメンテで働いたつもりになるのはマジでやめてほしい
xercesを使ったときは二週間かかって全体の一割くらいしか理解出来なかったけど、
“オレSAX”を作ったときは、三日くらいかかって、ほぼ完璧に動作した。
車輪の再発名だし、最初は不安定化もしれないけど、自分自身が書いたコードだからこそデバッグしやすい。
ヒトの作ったライブラリを習得して、生半可な理解で使ってるような暇があったら、自分で書いた方が速い/早い/正確ってことはある。
私に言わせれば、XMLをパースすることが目的なのであって、既存ライブラリを利用することが目的なのではないと思ったりする。
既存ライブラリを利用するのは「手段」、オレ様ライブラリを自作するのも「手段」
どちらの手段を採用するかは、時と場合による。「自前のXMLパーサーのメンテ」の方が後々楽だと判断すれば、躊躇せずにそうする。再利用が常に最適解だとは限らない。
Re:あれ? (スコア:1, 興味深い)
XMLパーサなら1時間で作れる。
ってよりは字句解析及び構文解析ライブラリ
ライブラリって実績のあるライブラリを利用することで質を高めるって面もあると思うけれど、
ライブラリを理解することでライブラリを作った人の思想を理解すると言う面もあると思うんだ。
それは自分のプログラムの幅を広げることでもあるし、
上記のboost::spiritは特にその発想に驚愕したライブラリだったりして、
そのライブラリコードに感銘を受けることはやっぱり大事だとおもうんだ。
Re: (スコア:0)
(似非)XMLパーサなら1時間で作れる。
ってか、なんか論点ずれてね?
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
あれを駆使したコード、渡せる人は周りにいますか?
と聞きたい。
永久メンテナ志望ならいいですが、コードよりも自分の人生の方が大事。
Re: (スコア:0)
まあ、確かに感銘は受ける。
俺は一生かかってもこんなコードを書けるレベルには達しないだろうな。
Re:あれ? (スコア:1)
↓ごめん、そうは思えなかった…
「車輪の再発名」「最初は不安定化も」
Re:あれ? (スコア:2, 参考になる)
・自作のライブラリは実装に時間がかかるが、楽しいことが多い。
・他人のライブラリはまあまあ安定しているが、万一問題があったときに対処が難しい。融通が利かないことが多い。
・自作のライブラリは最初は不安定かもしれないが、その場ですぐデバッグしやすい。用途に応じて柔軟に対処できる。
しばしば、頭ごなしに車輪の再発名を非難したがる人がいますが、私は、車輪の再発名は、エンジニアが成長する糧としても、実益の面でも、有効(な場合もある)と言いたいだけです。
Re: (スコア:0)
まあ、作れるけど作らない奴が「車輪の再発明」って言うのと、そもそも作れない奴が言うのじゃ
話が全く違ってきますしね。
作れない奴が言ってたら単なるピエロ。
Re: (スコア:0)
s/車輪の再発名/車輪の再発明/g;
あと、「自分のライブラリ」を「他人がメンテする」、ってあたりのところを意識的にか無意識的にかスルーしてるのも気になるところ。
確かに、自分のプログラムを自分だけがいじる小規模なプロジェクトなら、あなたの言うことも正しいとは思うのだけど。
Re:あれ? (スコア:1)
訂正しなかったのは私の責任ですが、間違えたのはATOKのせいです(笑
> 「自分のライブラリ」を「他人がメンテする」、ってあたりのところを意識的にか無意識的にかスルーしてるのも気になるところ。
ライブラリに限らず、プログラミングに限らず、あらゆる業務の「引き継ぎ」に関して、一般論として言えることだと思います。
ちゃんとドキュメントを書いて説明するのは、作者の責任なのは理解しているつもり。
ただ、既存ライブラリを採用したとしても、後任者もそれを習得するコストとメンテナンスするリスクを負わなければならないわけで、「既存ライブラリを採用したら解決!」という簡単な話ではありません、時と場合とライブラリの種類によるでしょう。
Re:あれ? (スコア:1)
利点/弱点を深く理解するには必要な事。
>再発名
まあ、非難されるだろうな。
the.ACount
Re: (スコア:0)
でわ、ATOKを書き直すんだ!
Re:あれ? (スコア:1, すばらしい洞察)
いや, あんただけがそのコードのメンテを永遠に担当するならおおいに結構,ご自由にどうぞ(納期だけはまもってね)なんですが,
他人が書いたオレ様ライブラリを解釈してメンテ・拡張させられるチームの身にもなりなさいって.
そのプロジェクトが自分の手を離れた後も, その俺様XMLパーサーなりの機能拡張とドキュメント化を黙々と
勤務時間外にやってくれるならいいんですけどね.
新たな機能を実装するためには, 往々にして他人が結局汎用ライブラリに差し替える作業を強いられると思うのよ.
パーサー程度ならまだしも, スピード(メモリー)クリティカルな操作だと規模がおっきくなると俺様ライブラリは
使いもんにならんということもままあるでしょう.
(自分もすべては自分で作りたい派だし, 学生時代は3Dライブラリとか数値計算ライブラリを自分で作ってチューニングして
やれフリーなlapackのへぼ実装よりだんぜん速いぜとかやってましたが, それは趣味であって, チームの仕事じゃない.)
それでも俺の方が汎用ライブラリよりよっぽど洗練されたインターフェースのものを短時間で書けるというのであれば,
あなたは独立ベンダーにでもなれば大儲けできると思うよ.
Re:あれ? (スコア:1)
暗号化通信しようと思ったら、さすがに私の手には負えないから、OpenSSLなりWinInetなりを使います。
でも、XMLパーサ程度だったら、所詮文字列処理とコード変換くらいだから、自前の方がやりやすい。
とか、あくまでも、必要に応じて、っていう話。
Re:あれ? (スコア:1, すばらしい洞察)
>> 他人が書いたオレ様ライブラリを解釈してメンテ・拡張させられるチームの身にもなりなさいって.
で言ってるのは、「たとえばあなたが、プロジェクトの元メンバが書いたオレ様XMLパーサとそれを使っているコードを渡されたらどう感じるか」って話だと思うが、それでも
> でも、XMLパーサ程度だったら、所詮文字列処理とコード変換くらいだから、自前の方がやりやすい。
って言えるのかな?
自前で作るなら、自分には確かに分かりやすいのは当然。しかし、 オレ様コードは、書く人は一人でその人にとっては最高なだけで、使う人・メンテする人にとっても最高とはならないんですよ。googleで検索するだけでトラブルシューティングやリファレンス検索、サンプルコード参照できる既存ライブラリに比べ、オレ様ライブラリは作者がそばにいない限りは足枷にしかなりません。もっとも、既存ライブラリがマイナーでメンテされてるかも良く分からないとか、コードが若くてバグが大量にありそうな場合はオレ様ライブラリでも良いとは思いますが。
なので、チーム開発ならメジャーな既存ライブラリがある場合そっちを使うべきです(再実装することが手に負えるか手に負えないかじゃなくて、あくまで既存ライブラリがメジャーかそうでないかで使い分けるべき)。
# などと言いつつ、私も他人の作ったオレ様ライブラリ(一応社内標準)を拒否して自分作ったオレ様ライブラリで置き換えることが良くあるのですが…
## だって他人の作ったオレ様ライブラリのデバッグなんてご免やし。
Re: (スコア:0)
Re:あれ? (スコア:1)
Re: (スコア:0)
カルトじゃなくて原理主義でしょ。あの攻撃性は。
「俺の宗教に異を唱えるおまえはサタンだ」とゆう感じで怖いですね~
Re:あれ? (スコア:1)
フリーにしろそうでないにしろ、既製品の有名なライブラリは多機能すぎることが多い。
リヤカーで十分なのに、大型トラックを引っ張り出してくることもあるまい。
Re: (スコア:0)
お前バカだな。
誰が書いたかわからん既存のライブラリと、奴(paprika氏)が書いたライブラリで、
メンテ・拡張する側になんの違いがあるって思うんだよ。
汎用ライブラリより専用ライブラリの方が、
要件に洗練されて最小限の実装になるのは当たり前だろう。
汎用って言葉の意味知ってるのか?
> パーサー程度ならまだしも, スピード(メモリー)クリティカルな操作だと規模がおっきくなると
そんなでっかい奴を自前で書くわけないだろ。
論外な例を持ち出してくるなよ。
Re:あれ? (スコア:1)
よくよく考えて欲しい所ですよね。
『みんなが使ってるライブラリなんだから、正しい動作をするだろう。出力は正しいのだろう』
などという妙な断定で使うなら、問題が発生したときは泥沼化すること請け合いです。
ライブラリってのは自分でも作れるけど同じもの書くなら出来合いのもの使ったほうが色々手間が省けるよねっってのが本来の使い方ではないかと。
なので使い方理解するのに一週間かかるようなライブラリなら、3日で作れる俺コードで正解だと思いますけどね。私は。
まぁ、もちろんデバッグ込みでの話ですが。(3日で作ってデバッグに10日では本末転倒
# いっぺん自分で書くとライブラリの有難味もまたひとしおだしね。
Re: (スコア:0)
Re: (スコア:0)
言いたいことは分かりますが、ほどほどにしないと、後任や補佐が付けられなくて、休めない、辞められない、昇進しない、という泥沼にはまります。
まあ、後任も俺様ライブラリを書ける人なら良いんですけどね。
Re: (スコア:0)
自分のコードが完璧であって、自分のコード以外で「汚染」されたものは嫌がる。
ただ、なぜかあまり人の仕事を読まない人もいて、そのために自分のコードへの自信にかかわらず再利用しようという発想自体が無い人もいる気はする。
Re:あれ? (スコア:1)
それって、どうなのかな、とか思うことも多いです。確かに、バグとかあったら恐いのはわかるんですが、開発の労力を考えると、既存のライブラリや人のコードを使う方がはるかにいい方法だとは思うんですけどね。
Re:あれ? (スコア:1)
用意するなら用意するで、本来はそれをどのように用意するか考えておくべきなのに、当初の予算にもスケジュールにも組み込まれていない
簡単に見えるものほど当たり前のものを見落としがちでデバッグが難しい
そして、結局はどこかで拾ったコードを使う事になる
ああ恐ろしい……デスマーチの足音が聞こえる……
Re: (スコア:0)
自分たちの内部での瑕疵なら仕方ないと思えても、顔も性格も知らない、せいぜい名前くらいでしかも本名かもわからない、そんな馬の骨の作ったものに自身の責任をゆだねられるほど、人は強くないでしょ。
一度でもライブラリのバグで苦しんだり、責任者の立場になればわかるよ。
Re: (スコア:0)
#ソース弄るという手段が使えるのは、責任を全うするという意味においては
#意外と心の拠り所となってたりします。
Re:あれ? (スコア:1)
だから、欠陥の多いプロプライエタリ製品を組込んでいる限り、カーゴ・カルトを信奉
するのがいちばん安上がりで、事実上これしかない方法になる。
オープンソース製品だけを組込んでいる場合にも、コストを考えれば第一選択はカーゴ・
カルトになる。欠陥に突き当たれば、大抵はちょっと回避するのが手っ取り早い。
ソースが弄れるというのは、本当に困ったときはカーゴ・カルト以外の手段も使えるぞ、
という最後の精神的拠り所となるに過ぎない。
Re: (スコア:0)
面倒くさかったんで会社やめた。
Re:あれ? (スコア:1, 興味深い)
流れを若干無視しますが、私の場合は簡単なことをしたいだけなのに、パワフルなライブラリを嫌がって自分で書くことはあります。確かにライブラリはよくできているものがたくさんありますが、そのために依存関係が厄介だとか、パラメータが多いとか困った点もあります。
また、私がよくやることですが、プロジェクトの中でルーチンを作り、せっかくだからライブラリとして他人に使ってもらおうと欲をかいて、そのためには汎用性があって・・・とかやっていくと、プロジェクトのためにライブラリを作っていたのが、ライブラリを作ることが目的化してしまうことがあります。そうして作ったライブラリは思いの外使い勝手が悪く、再利用しないことも結構あります。
まあつまりダメプログラマってことですけど。
Re: (スコア:0)
が実は
- 自前によって得られるのが 「快楽」 or 「苦痛」
- 再利用によって得られるのが 「快楽」 or 「苦痛」
というマトリックスが存在して、対極の人がいるということは、容易には
理解されない。でも本当は苦痛だと感じる者にとっては、耐えがたいほどの苦痛なんだ。
プロなら再利用したことも自前で作ったこともあるだろう、発想自体が無いわけじゃない。
Re:あれ? (スコア:3, 興味深い)
再利用にかかる(調査・改造)工数が新規作成にかかる工数よりも必ずしも小さいとは言えない. それを承知で再利用を強行するのは賭けだったり, 苦痛を通り越して破滅をもたらすパンドラの箱だったりすることも少なくない. だとすれば, たとえ「苦」であることが分かっていても, その限度が見切れる方を選ぶというのもプロとしては合理的なんですよね. その点, 目処がつかなければ捨てることができるアマチュアとは判断基準が異なるわけで.
もう一つは, 自分が作ったプログラムを自分で再利用する場合と, 他人の再利用を考慮した場合とではドキュメントを含めた製造コストが大幅に異なることでしょうか. 将来の定かではない多くの「楽」のために再利用できるようにしようとすると, 今の「苦」あるいはコストが少なくとも確実に増えるというのは, 再利用のモチベーションを落とすための強力な要因になると思います. このあたりは多分Easy Cultの一流派とも言えそうですけど.