大規模なソースコード、何万行までいじれますか? 165
ストーリー by yoosee
言語やコードの種類にもよりますけどね 部門より
言語やコードの種類にもよりますけどね 部門より
Kachi曰く、"サンのWebページ「Sun&Users」に筑波大学の加藤和彦教授のインタビューが掲載されている。この中で、『数は少ないんですけれど、大規模なソフトウェアを我々の想像を超えていじっちゃう人たちが現れてます。(中略)…昔よりも、ソフトの生産性は上がっているんですね。(中略)…最近の若い人の非常に生産性の高い人は、1万行なんて割と軽々越えるんですね。1万行、3万行は、全然苦にしない。10万行でも苦にしない。』と発言している。
さて、あなたは、どのくらいのソースコードに立ち向かうことができるだろうか。ちなみに投稿者は、アマチュアなので万年Hello worldどまり。"
苦行 (スコア:5, おもしろおかしい)
>10万行でも苦にしない。
苦行に耐える現代の行者ですね。 頑張って徳を積んで下さい。
Re:苦行 (スコア:5, おもしろおかしい)
Re:苦行 (スコア:3, おもしろおかしい)
Re:苦行 (スコア:2, おもしろおかしい)
このインタビューに書いてあること (スコア:5, 参考になる)
インタビューを読んでもらうと分かりますが、まずUNIXを自分たちでいじっていた話が出てきます。「UNIXバージョン6のソースコードって1万行だったんです。当時、だいたい人間が理解できるソースコードの限界は1万行だよ、と言われていた訳です。 BSDの場合は、1万行を越えてコアの部分で3万行ぐらいで、周りまで入れると10万行位になりますから、あれはもう、いじる限界を越えちゃってていじれないと取られられていたんですね。」
もうひとつは、現在取り組んでいる開発プロジェクトのこと。CRESTプロジェクトで、仮想マシンを利用して、障害があっても自力で生き延びるソフトウェア環境を作ろうとしていたり。こちらでも仮想マシンを利用して、Winnyなんかでへこたれないソフトウェア環境をしていたり。
で、単に時間をかければコーディングできるかということではなく、ソフトウェアの生産性が20年前から10倍になっているかという話なのです。
軽々一万行 (スコア:5, 興味深い)
DF [nifty.com]程度のプログラムでもソースは21,229行もありますが把握できないという訳ではありません。全体の行数はあまり関係が無くて、分割統治ができているかどうかが肝で、十万行の塊ひとつだと厳しくても、一万行の塊が十個になっていればたいしたことはないように思えます。
他人の書いた一万行よりも自分で書いた十万行の方がわかりやすいというのもあるので解らないものを苦労して読解するよりも「自分で書いてしまう」というのも選択肢としてはありですよね。
行だけで言われても (スコア:4, すばらしい洞察)
10万行の関数がひとつなのかしらん。
仕様上 (スコア:4, おもしろおかしい)
やっぱり (スコア:3, おもしろおかしい)
一応印刷して1ページの66行までは対応可
Re:やっぱり (スコア:2, 参考になる)
あとは、横に２段打ちとか。
Re:やっぱり (スコア:4, おもしろおかしい)
うん。紙がもったいないと思うのなら、印刷しないので。
印刷待ちをしている間にソース眺めると、途端にミスが見つかるという法則 ;-)
タブレット中毒者。
行数と生産性の関係 (スコア:3, すばらしい洞察)
＞1万行なんて割と軽々越えるんですね。
＞1万行、3万行は、全然苦にしない。10万行でも苦にしない
肝心の時間(工数)が抜けているので何ともいえない。
生産性 = 作業量(ここでは行数) / 時間
==========================================
投稿処理前プレビュー確認後書込処理検証処理前反映可否確認処理後……
Re:行数と生産性の関係 (スコア:3, おもしろおかしい)
# はっ、生産性が0にっ
Re:行数と生産性の関係 (スコア:2, すばらしい洞察)
Re:行数と生産性の関係 (スコア:3, 興味深い)
つまり、労働集約的な生産性と知識集約的な生産性の違いで、労働集約の世界の比較じゃありませぬ。
たしか『ハッカーと画家』に、普通の人が10個程度のことしか記憶しておけないのに、凄腕のハッカーは百くらい記憶できるとかいう話があったけど、それと同じような話かと。
Re:行数と生産性の関係 (スコア:2, 興味深い)
昔のコードで何万行っていうと、そりゃあ辟易だ。
Re:行数と生産性の関係 (スコア:2, 興味深い)
それは可読性向上のためでしょう。
明らかに異常に長い関数等であれば問題かもしれませんが、
可読性が高いのであればそう行数増えても苦にもならないのでは。
また、最近では最早オブジェクトで組むのがほぼ当然となってきていますし、（勿論適さない場合もありますが）
そうなると１度に見る部分は極めて限られますから結果的に何十万行でも問題ないと思います。
最早行数でプログラムを推し量る時代ではないのかもしれないと思います。
Re:行数と生産性の関係 (スコア:2, おもしろおかしい)
コメントをステップ数に数えてはいけません！
あ、ステップ数じゃなくて行数の話題か。
失礼しました。
-----
しょうもないコメントなのでAC
言語やコードの種類よりIDEによって決まるかな (スコア:3, 参考になる)
あとクラスビューはクラスの関係を一目でわかるように出来ているし,クラスやソースの管理は楽です。
こういう環境が出来てきたから大き目のソースでも扱えるようになったかな,と感じています。
行数という計算 (スコア:3, 参考になる)
ただ、同じような処理が結構あったりしていたので、うまくやれば結構減らせたのかなってのはずいぶんありましたね。
# VBでXULランタイムもどきを作って突っ込んだりしていて、余計行数は増えてたのはノーカウントでお願いします(謎
なので、行数がどれだけあるとすごいってよりは、そこからどれだけ無駄を省くかって方がよっぽどすごいなぁと思います。
自分なんて、一つのクラスで5000行以上なんての書いた事ありますもん...orz
ちなみに、VBでの1万行とC++での1000行では、前者の方がわかりやすいと思います。そういうのも比べないとあまり意味がないかなぁと思います。
三日風呂に入らなかったら、あなたはすめるまんです。
行数ではなく複雑さ (スコア:3, 興味深い)
1万行以上のコードなら扱ったことは何度かあるけど、
綺麗なコードなら10万行でも平気。
スパゲティプログラムなら1千行でも拷問。
さらにそういうコードだと変数名も関数名も意味
不明だったり、コメントさえもなかったりする。
>VBでの1万行とC++での1000行では、前者の方がわかりやすいと思います。
CのマクロやC++の演算子オーバーロードを乱用したコードは
最悪ですね。Perlあたりで行数を減らすためにハックした
コードなら、おそらくそれ以上になります。Javaは分かり
やすい方だけど、それでもUML屋さんが『設計』すると
スパゲティ=継承プログラムのために解読不能になって、
プロジェクトが破綻したことがあります。
Re:行数ではなく複雑さ (スコア:3, 興味深い)
「ここは関係ない」
って解るからね。
そうなっていると、あとは必要部分を負えば良いだけなんで、実質的に見なければいけない行が激減するんですよね。
＃かといって乱雑なソースを一概にそれを非難すると、実は自分のものだったりする事も。
後は、やっぱ「俺仕様」的に変にこだわりを持ったのも読み辛かったりする事がありますので、自分では気を付けているつもりです･･･が、俺仕様ってのは当然自分では「正しい」と判断されるものですから、ちとむずいかも。
Re:行数ではなく複雑さ (スコア:2, 興味深い)
つい最近、他の人の作ったものを改造するために見たVBのソース。
「どこどこをなになにする。正常終了0異常終了1（引数1,・・・）」
という漢字かな混じり関数（or変数）で満ちあふれていました。
最初は「なんか読みにくいコメントだなぁ」と思ったんですが、コメントじゃなかったんですねぇ。
これぞ本当の日本語BASICだと感心しましたが、ソフト担当の人に「頑張ってね」としか言えませんでした。
ソフト屋じゃなくてよかった。
Re:行数という計算 (スコア:2, おもしろおかしい)
# そして、後を引き継ぐ人がデスマーチorz
誤読（「書く」!=「いじる」） (スコア:3, すばらしい洞察)
タレコミの引用している前後はこう。だから「書く人もいるし、数万行のコードを『いじる（編集する）』」って意味。
#先週書いたソースコード約5500行
##うち「}」だけの行約400行
Re:誤読（「書く」!=「いじる」） (スコア:3, 参考になる)
って言ってるようにも読めますよね。
ちなみに私の手元で保守ってるプログラムは、総行数11万行です。
WEBベースのプログラムで、JSP内の行数は数えないでこれだけになります。
ちなみに、もともと16万行だったのを、二ヶ月かけて全体的に見直して減らした結果の行数でもあります。
その対象プログラムで扱っているものの複雑度合いにだいぶよりますけど、一般的なプログラムを「弄る」程度ならば、10万超えててもあまり苦にはならないとおもうのですが、いかがでしょう。
そりゃ…「よくわからないグローバル変数が多用されている」、10万行を超えるコードは、いじることすら困難でしょうが。
Re:誤読（「書く」!=「いじる」） (スコア:2, おもしろおかしい)
書くから大丈夫。
「いじる」と「書く」 (スコア:3, すばらしい洞察)
数万行のソースを書くのでは話が違う。
いじるのに生産性は関係ないんじゃないかなー。
Re:「いじる」と「書く」 (スコア:2, 参考になる)
かなりの労力を必要とします。
その労力をどれだけ減らせるか、という意味では、
生産性は大いに関係あると思います。
元のソースを書いたのが自分であれ、他人であれ、必ずついて回る話です。
# 明日の自分は他人とも言う。
「いじる」が示すものがどの程度のハックなのかは分かりませんが、
加藤先生が言うくらいですから、
低いレイヤーまで網羅した高度なものなんでしょう。
Lions Commentary (スコア:3, 参考になる)
という話が載ってますね。インタビュー記事にUnixバージョン6が
1万行とかの話が出てくるのは、まさしくその話だと思います。
その、冗長なソースコードを・・・ (スコア:3, おもしろおかしい)
「恥ずかしいコード禁止」
「えぇーっ」
千行/日 (スコア:2, 参考になる)
1日あたり10時間だと1時間あたり100行です。一見、多いように見えてそこそこな数字です。
あとは自動化ツールが手元にあれば1000行/日というラインはそれなりに楽に越えられることが可能でしょう。
まあこのインタビューの趣旨は単に作業量を分かりやすい単位で示しただけなので、
実際の行数換算はあまり意味が無いですけどね。最終的な生成量というよりは、
作業量としての行数換算として考えた方が望ましいかもしれません。
Re:千行/日 (スコア:2, 参考になる)
10k超えるとサチって、逆に全体の行数が減ったり、ソースを捨てたりする向きになるかと。（このへんはコーディングスタイルの話か
でも、10k位って普通では？
＃１関数15000行超のアプレットとか、見たことはあるけど、逆に単純なつくり。触る時の間違い確率が大きくなるだけですね。
Re:千行/日 (スコア:2, 参考になる)
1日1000行はなんとか可能なラインですが、それを毎日続けるのは、 ソースコードジェネレータで作ったソースとか、コピペの嵐とかで ない限り無理では？
コピペの嵐ではなく、共通処理を適宜くくりりだした、それなりの 品質を保ったコードを書こうとすると、1ヶ月で1万行、1ヶ月の労働日を 20日として、1日あたり平均500行ぐらいが限界でしょう。
3日で1万行はありえないペースだと思います。
さらに、この1日平均500行というのは、相当に生産性の高い人の値で あって、すべての人で平均をとると、もっとはるかに下になります。
たとえば東洋大学の野中先生の資料 [toyo.ac.jp] によると、 中央値は 469行/月 とありますから、一日あたりだと 20数行程度にしかなり ません。ただし、コーディングだけはなく、設計やテストなど全フェーズを 平均した値ですが。
もちろん、コピペの嵐で作れば、1月数万行書くのも簡単ですが、そうすると 保守の段階になって最悪の事態になります。
圧縮してみるとか。 (スコア:3, 興味深い)
コピペしまくりのソースは圧縮するとスポンジのように小さくなりそう。
use Test::More 'no_plan';
１０００行でギブアップ (スコア:2, 興味深い)
正確には１０００行のソースコードではなく１０００行の関数ですが。
自分には伝説のネバー・エンディング・ファンクションを見た思いでしたが、
見る人が見ればまだまだ甘っちょろかったのかな。
doxygen (スコア:2, 興味深い)
大きくても全然気にならない。
だけど、超巨大なプロジェクトに限って、doxygen が
エラーで止まってしまうのが困りものです。
ソースコードブラウザ関連の話題が (スコア:5, 参考になる)
まぁ、知ってる人も多いとは思うけど、
GNU GLOBAL [tamacom.com]、gonzui [sourceforge.net] 、koders [koders.com]等
を挙げておきます。
ソースコードブラウザあれば、
マウスでサクサクリンク到ってくだけで、
簡単に処理の流れ追っ掛けられるので、
他人のコードの読解が非常に楽になります。
未体験の人は、是非試してみるべきです。
とは言え、適切なモジュール化とコメント付けは必要ですが、、、
条件次第では、
数万行程度ならばあまり苦痛ではないんじゃないでしょうか？
uxi
行数自慢されても… (スコア:2, すばらしい洞察)
もちろん程度によるけど。
Re:行数自慢されても… (スコア:2, すばらしい洞察)
>> でないと、誰もサポートできないようなコードになってしまい、その仕事が自分の手から離れないので。
> そのためにはわかり易い設計書を残しておくとかしたほうが有用ですね。
確かにその通りなのですが、現実は理想とはほど遠いのが世の常で。
(a) 設計書が行方不明。
(b) その会社の設計書作成指針に完璧に沿ってはいるものの、中身がクズ同然（何が書いてあるのか全く分からない）。
(c) ソースコードと設計書が同一のモノに言及しているのではないので、設計書がソースコードを読むための助けにならない。（設計書の更新忘れでも、これが発生する）
(d) ソースコードがぐちゃぐちゃで、設計書があっても何の役にも立たない。ソースコードと設計書がどう相違するのかを確認するだけでも一苦労。
極めて属人的な要素で仕事をこなしている小さな所は、こういう問題を抱えてしまうケースが多々あります。問題の原因となるのは、仕様書を整備するという様な技術的側面では無く、仕様書を正しく作成し維持管理すると言う管理的側面なのですから。
しかし、システマチックな対応がされているとされる大きな所でも、この様な問題を抱えてしまうケースは皆無とは言えません。と言うか、小さな所と同じ位問題を抱えていて、下手に規模が大きくなっているために壊滅的な状況に陥っている場合もあります。例え、その会社がCMMIのレベル5達成とか豪語していても、ですね。(a)など起こりうるはずも無いのが、実際には起こってしまうのです。
この様に考えた場合、最終ドキュメントとして通用する可読性を非常に考慮したソースコードは、最良の解決策とは言えないまでも、上の問題の幾つかを未然に防ぐ働きを持つ簡便な方法論です。一考の余地は十分にあると考えます。
# まあ、行数だとかステップ数だとかで費用算定をして管理コストを一切考えないとか、
# 単純に金額の多寡だけで発注を決定するとか、
# そういう様な事をやっている内はダメでしょうけどね。
5000Stepのグローバル変数 (スコア:2, 興味深い)
ってか、本当に泣いた。
私「いじったときの影響度とかどうやって判断してるんですか？」
リーダー「テストでカバー」
その仕事が原因でITから足を洗いました。
**やっぱりITやるか。しょうがない。**
Re:5000Stepのグローバル変数 (スコア:4, 興味深い)
＞ってか、本当に泣いた。
そこまで酷くはないけどあったなあ。
とある用件でC++Builderのプログラムを引き継いだのですが、作った人がVBでしかプログラムを作ったことがなかったらしく、BASICくさいコードにグローバル変数の嵐！嵐！我が名は嵐！変数なんじゃこりゃ嵐！検算！でした。
しかも未完成でバグだらけ。開発途中でスキルが追いつかなくなってこちらに丸投げしたってのが見え見えでした。
なんと関数がことごとくグローバル変数を参照していて引数なし。戻り値なし。い、いやな予感・・・い、いた、やっぱりいたよgoto！ gotoが1個あったら20個あると思えーっ、なコードでございました。
思わずSEに「・・・これ、一から作り直していいですか？ きっとそっちの方が早いです・・・」って泣き入れましたよ。
結局画面周りだけ流用してソースはほぼ全書き換えしました・・・。
おふとぴ、では、１行にかけた最大の時間は。 (スコア:2, 興味深い)
でも、一日あたり何行書いたとか、何万行なら把握できるとかいう議論はあきました。
そこで、「あなたは一行にどのくらいの時間をかけたことがありますか。」
と問いましょう。
分母の"一行"にそれほど深い意味はありません。10行でも千行でも多分同じ。
ちなみに私はある一行に、一ヶ月を費やしました。
それは私の無能の証。でも私の生涯で最良のコード。
Re:数万行のコード (スコア:5, おもしろおかしい)
"Patriotism is the last refuge of a scoundrel." - Samuel Johnson
Re:数万行のコード (スコア:2, おもしろおかしい)
そして現在の自分よりもだいぶ優秀ですね
感心してしまいます、マメなコーディングに・・・・
# あぁそうです、今の怠け具合がひどいだけなんです・・
# 短期記憶量と集中力が今とは比較にならなかったようで・・・
Re:数万行のコード (スコア:2, 興味深い)
「一ヵ月後の自分が見てすぐ分かるように書け」
だったりします。
それくらい経つと、程よく忘れてますからねぇ。
＃つい最近分からなかったことがあるのは内緒
Re:ところで (スコア:2, 参考になる)
だと、サブディレクトリ下のファイルが計れないっすよ。
とはいえ、
> find . -type f | xargs wc -l | awk '{l += $1}END{print l}'
これはダメですね。wc は、引数の個々のファイルについての計測結果とは別に、最後に調査したファイル全部の合計も表示しますから、出てる数字全部足したら2倍の数字が出てしまいます。
そんなにファイルが多くないなら、
find . -type f -print0 | xargs -0 wc -l | grep total
で十分でしょう。ファイル数が多いなら、
find . -type f -print0 | xargs -0 wc -l | grep total | awk '{l += $1}END{print l}'
で。
コメントは重要なんだけど (スコア:3, 興味深い)
「実装にコメントを書くな」
なんて言う過激で衝撃的なお告げもあります。
JUnit 実践講座 - プログラミングスタイルガイド [morijp.com]
曰く、実装にコメントを書くと、
リファクタリングの妨げになるので、
書くならテストにコメントを書けと、、、
言いたい事は分るのだけど、
これをこのまま鵜呑みにして良い物かどうかは
判断し兼るところです、、、
確かにリファクタリングは楽になるんでしょうけど、
javadoc さえも書かない方が良いと言っているのはどうかと、、、
どうしても API ドキュメントのような物が必要な場合は、
なるべく開発工程のいちばん最後に書けと言うのですが、、、
# それはそれで面倒かつ効率悪い気が、、、(- -;;;)
私は頭が古いせいか、
テストコードを見ないと、詳細が分らないのは
流石にちょっと行き過ぎだろ！？と思えていけません、、、(- -;;;)
また、いくらリファクタリング優先とは言え
最低限、実装読解の助けとなるコメント
(参考文献、アルゴリズムやデータ構造等の名称等)は
実装側に必要なんじゃないかと思うんですよね、、、
実装とドキュメントを分離するのは管理コストが増えるからこそ
javadoc のような物を有難く思えるわけだし、、、
まぁ馬鹿正直に全て受け入れる事もないんでしょうけど、
XPやってる方々の率直な意見も聞いてみたいところです、、、
uxi
Re:コメント部分 (スコア:2, すばらしい洞察)
Re:500行の Fortran (スコア:2, 参考になる)
たとえば、何の予備知識もなしにFFTのコードを見て、
それが「フーリエ変換」をするコードだとわかる人はそうそう居ないと思います。
まあ、FFT といった有名な最適化手順なら、それを予備知識として知っていればなんとかなるでしょうけど、
独自の問題について、その問題を定式化し、それを数式の上で最適化した上で、コーディングしていた場合、
「簡単な手順に変換したもの」だけを見て「元の複雑な手順」を復元するのは難しいでしょう。
そういうのが出てくるのは数値演算に限りませんが、数値演算はそういうのが多いと思います。
私はそういうコードを書くときだけは、元の数式と式変形の過程をコメントに残すようにしてます。
過程をメモし忘れると、後から見た時に「確かにその式で正しい結果が出るみたいだが、なぜそういう式が導出されるのかよく分からない」なんてことも。
「数日前の自分は他人」とはよく言ったものです。