規模から見た現状

自分が作っているものの規模を確認してみた。

backgammon用自作ライブラリ(bglib)

unit testが769case, 29 fail 15 error。テストを走らせるだけで１分掛かる。
16596 Line　98file
プロプラエタリ。20Kはいきそうな気がする。

汎用自作ライブラリ(tonic)

unit test 20 case, 1 fail 2 error
1687Line 22 file
まだまだ成長の余地がある。近日中に200Lineは増えるだろう。

packaging tool (未完成)

unit test 62 case, 4 fail 9 error
2644 Line 54 file

wxpygammon, FIBSのクライアントアプリ（未完成）

unit test 3 case 2 fail(そもそもかかれていない）
2192 Line 19 file
もちろん最初に出てきたLibraryがないと動かない。
UIがあるものを効率よくテストしながら作るのは工夫が必要。
現状のままでは力尽きる。

imageserver、稼動中、image.backgammonbase.com

unit test 16 case 14 fail(メンテされてないなぁ・・・）
1010 Line 13file
２つ自作Libraryに依存。機能がシンプル（ライブラリのレンダラーを呼び出すだけ）なので、TGによって自動生成されたコードが3割くらい（？）、残りでformの処理をしている。cacheのコントロールはdecoratorとしてライブラリに切り出してある。

bglogin、未稼働 backgammonbase.com

unittest 0
572 Line 11 file
自作Libraryに依存。
OpenIDのloginとusername/passwordによるログインの両方をサポート。
データベースの設計が7割だった。このモジュールがほかのモジュールにidentityを供給する義務を負っている。

bgwiki、未完成。wiki.backgammonbase.com

unit test 0
2368 Line 12 file
履歴を持つことができるwiki。wikiの文法自体はbglibで処理している。

今日ちょろっと書いたhandicapのあるトーナメントのシミュレータ。

281 Line 6 file
bglib/statにいれるか。

svnを止めてgitに移行するためにもツールを完成させないとなぁ。もう一度、探すかなぁ。
脱線だが、gitのtagじゃなくてlatest commit のdateをとるほうがよい気がしてきた。tag timeじゃなくてtag lastcommitとかいうコマンドを用意すればいいのだろう。拡張は簡単なはずで、実装の手間の問題だ。

大規模ソフトウェアの効率的な理解（その2)によると10万行までが小規模らしい。てか、10万行を超えたくない。2万行でも負担に感じる。（10万で10人なら一人１万行の倍の量なわけで・・・）
行数を減らすために努力しているつもりだ。書き換え込みの延べ行数だと倍は書いているだろう。
大規模なソースコード、何万行までいじれますか?@/.jpというのもあるが、ライブラリの場合は名前空間が鍵になる。もちろんアプリから共通部分を抜き出してライブラリ化する行為自体も大事だ。とくに私はbackgammonのコードばかり書いているので、それを扱うのに有利なライブラリを早期に取り出し、よいデザインにしないと自分が「何度も同じことを似たようなコードで書き、バグをあちこちに埋める」というひどい目にあうことになる。ちなみにbglibの下はこんな感じに分割されている。

drwxr-xr-x 3 nori nori 4096 Jul 18 13:12 protocol
drwxr-xr-x 5 nori nori 4096 Oct 29 14:09 image
drwxr-xr-x 3 nori nori 4096 Nov 17 18:14 doc
drwxr-xr-x 3 nori nori 4096 Nov 18 19:52 stat
drwxr-xr-x 3 nori nori 4096 Dec 6 23:08 depot
drwxr-xr-x 3 nori nori 4096 Dec 6 23:08 gui
drwxr-xr-x 3 nori nori 4096 Dec 6 23:09 model
drwxr-xr-x 3 nori nori 4096 Dec 6 23:16 encoding

参考までに普段使っているOSSの規模をあげておく。

gnubg

13万行、300file(.c, .h)

python 2.4

.h 164 file 55000行、.c 1014 file 38万行、.py 1620 file 40万行

apache httpd 2.2

.c 21万行 272 file, .h 2万４千行, 136file、apr等は含まない。

linux 2.6 stable 2.26.27.7

.c 235万行、11000file, .h 100万行 11000 file、（ドライバや自動生成されたコードを含む）

apacheはおもったより小さかった。機能に比してでかいのかもしれないがその辺はよくわからない。
ちなみにカーネルはconfig項目だけで1000を超えているらしい。パンピーにはまったく縁の変なハードのドライバに関する選択肢も含まれているだろうが。

pythonは.cがコア機能の実装codeなのかC実装なライブラリ.soを生むためのC codeなのかが不明。
pythonの方が間違いない区記述能力は高いので、ライブラリのほうが言語自体よりも規模が大きい（当然か）。

gnubgはgtkでUIを実装しており、その部分がかなり大きい。neural networkの部分はそれほど大きくは無いはず。
modelに相当するgnubg.cやeval.cはそれぞれ6000行ほど。

find . | egrep "gtk.*\.c$" | xargs wc

とかしてgtkのコードを数えると30000行という答えが得られる。


もしかしたら桁を読み間違えているかもしれないので鵜呑みにしないように。

個人でやっているのでマンパワーは当然無い。だから、こういうdeployを手動でやるようなことは避けたい。

アップロードした後、プログラム名の日付やサイズが変わっているか目視チェックを行います。一人で行うとミスが発生しますので、複数の目で行います。また本数でもチェックを行い二重、三重にミスを防ぎます。今回はこれができなかったのではないのでしょうか。

とくにgnubgやMaraDNSはcentosには含まれていないので、自分でpackageしなければならない。
kernelやapache、pythonもそういう方向にするだろう（セキュリティ上の理由から)。つうわけで、packageをある程度自動化したいのです。でないと開発時間が捻出できない。

長期的な観点からはunittestの件数不足、all green状態維持をどうするかということかな。
タスク管理やDBもやら無いといけないのでこれらは5000Lineから10Kくらいだろう。