読者です 読者をやめる 読者になる 読者になる

Create a new world

きっと誰もが新しい世界を作り続けているんだよ。

たった一人で数万ステップを扱う変態プロジェクトを支えた技術

この記事は変態アドベントカレンダー in Summer : ATNDの6日目です。*1

昨日の記事はアラウンドエイリアスでbefore_destroyの挙動を変える - zephiransasのチラシの裏です。

いま携わってる一人プロジェクト。始まって約1年。ようやく終わりが見えてきつつある今日この頃。すでに頭の中では詳細は分からなくなっている。
そんな状態のなか、ふと「このプロジェクトのソースコード、どれだけ書いたのだろう」と気になりました。

一説によると、一人で扱えるステップ数は10000と言われており*2、間違いなくこの基準は超えているだろうなぁ感じていました。*3

そこで先日、初めてコードの行数を調べてみました。すると・・・

  • サブシステムA 19000行
  • サブシステムB 5000行
  • サブシステムC 6000行

合計30000行のVB.NETによる実行コード。
ここにSQLやらJavascriptやらaspx(asp.netにおけるビュー)のコードを足すと、おそらく50000行を超える。*4
しかもこれを全て一人で同一プロジェクトとして管理。

「・・・これじゃあ、詳細なんて分からなくなるわけだ。」

そう感じました。

それでも、なんとかプロジェクトの終わりまで大炎上することなく*5やってこれました。

今日はこの、個人で扱うにはあまりに膨大なため変態と化したソースコード。これをなんとか支えることが出来た戦術について書いてみようと思います。
*6

ソースコード戦術

メソッドは小さく

ごく一部(ビューに対する表示を制御する部分とか)のコードに関しては数百行になってるものがあるかもしれませんが、大半のメソッドは50行以内に収めるようにしていました。
100行を超えたら間違いなく赤信号(特に業務ロジック)。50行で怪しい匂いが。。。*7
メソッドを切り出せるところは切り出すようにしていました。

もっと細かく出来たかも。。。

適切な名前付け

メソッドを小さくする上で大切なのは名前付け。メソッド内で扱う変数にしても、何にしても名前付けは重要です。自分の名前付けがどこまで適切なものだったかはわかりませんが、間違いなく名前付けのおかげで助かっていたように思えます。
このメソッドが何をしているのか。このコントロールは何なのか。この変数はなんのために使っているのか。それが伝わってくるような名前でないと、一人で数万ステップものソースコードは扱えないでしょう。

この2つで、システム主要部分の理解はメソッド単位まででなんとか保てていました。

設計戦術

業務の切り離し

以前やったプロジェクトで、複数業務をまたいでの継承とかやってしまい痛い目にあった自分。今回は業務単位での独立性を保つようにしていました。
特定業務の結果から別業務に連動するような場合もありましたが、それに関しては別業務側に連動用のファサードを用意していました。

ドメイン駆動設計はちょっと読んで積読になってしまった自分。それでもシステム設計日記*8の教えで覚えていた部分は守るようにしていました。

層の分割

自由度がやたら高いASP.NET。データベースアクセスすらイベントメソッドにSQL直書きすらできてしまう。一方、MVCアーキテクチャのように層の分離をしようとするとあまりにも辛い。
そんな状況ではあったもの、ビューを弄る部分と、業務ロジック、データベースアクセス部分は切り離すようにしていました。
さすがに、システム設計日記で出てくるモデルのような感じ*9にまで分割することはしていません(というかASP.NETなんかじゃ出来ないと思う。)

管理戦略

管理と言っても一人プロジェクトですが。それでも、バージョン管理とタスク管理はしていました。

バージョン管理

Gitが流行っているなかのSVNでしたが、使っていました。実際のところ、いつ何の変更をしたかという記録をつけているような感じはありましたが、その記録があっただけで助かった場面もけっこうあったように思います。

タスク管理

最初はRedmineを使っていましたが、いちいちチケットを切るのが面倒になってしまいました。最終的に落ち着いたのはToDoリスト。必要に応じてToDoリストを作って一つ一つ潰していく。
見積りはプランニングポーカーにならっての相対見積りで予想工数を出していました。
その予想工数に対して実工数も記録。体でベロシティを把握していたので、見積りから大きくずれることはなく。残業時間もタスクが溢れた一時期以外は数時間なんて月も結構ありました。

そんな感じで切り回していたプロジェクト。一方でミスも結構ありました。

テストなんて書けません!

ASP.NETってテスト書きづらいものでして。ビューを弄る部分のコードは、実際に起動させないと触れないことから、ユニットテストは不能。
VB.NETはモックテストとか書きづらくて既に諦めていました。
そんななかでのステートフルな実装で大半はテストを書けず仕舞い。バグも結構出ました。

このあたり、業務の、特に何らかの値を計算するような部分はステートレスに仕立て上げれば、テストも楽々書けて、もっと楽が出来たと後で気づき大後悔しました。

そうやって人は成長していくんですよね、きっと。

ビューならjQueryを使えばいいじゃん!

今回のプロジェクトは、どこかのSIerが作ったシステムのコピーを作るようなプロジェクトでした。「さわり勝手も近づけて」という話が出ていたので、「それを実現するためにはjQueryを使うのが一番楽だなぁ」・・・と思って使い始めました。そしたらこれが爆弾でした。
jQueryからASP.NETのイベントをフックするのがやたら難しく。代わりにWebサービスクラスを大量に作るような感じでして。
BasicASP.NETでのjQueryは茨の道と悟りました。

出力のイメージなんて出来ません!

さすがに実行コードが30000行あって、そこにいろんなものがくっついてくるともう出力の状態なんて想像出来ません。そこに社内からUI改善要望がゴロゴロ出てきて。全部対応するのは無理とハナから諦めてました。
それでも、それなりには対応していました。使いづらいとかやたら言われてましたが。
悔しいのはデザインを学んでいなかったこと。俺デザイナーじゃないしと思って逃げてたツケがきました。


というわけで言い訳もいろいろ挙げてみました。

混沌を秩序に変えようとしていた一方、自ら混沌を生み出してしまった変態プロジェクト。
そんな状況でも一つだけ自信を持って言えることがあります。
それは「実装から管理まで、ほとんどの判断の理由を言うことができる」ということです。
ただの言い訳なものも多々あると思いますが、それでも何らかの理由をいうことが出来る。
実はそれが、今回の変態プロジェクトを支える最も重要なものであり、これを守れれば変態だろうがなんだろうが、大抵のプロジェクトは炎上することなく乗りこなせるのではないかと思います。

惜しむらくは、VB.NET, ASP.NET, Oracle, jQueryなんて構成を選択してしまった自分の不勉強さと、そんな構成を選択せざるを得ない状況でしょうか。そして、それに対してマトモな理由がつけられないことが何より情けないと思っています。

さて、明日の変態アドベントカレンダーは@さんです。
変態と称しながら実際は当たり前すぎた内容だった僕のエントリとは違って、強烈にとがった変態っぷりを披露してくれるんじゃないかなぁと期待しております。

追記(2012.7.23)

予想以上に反響があってびっくりしてます。Twitterはてブで見かけた意見に対してちょっとだけ書いておきます。

  • 30000行という数値について

これは、あくまで手入力した実行コード部分のみです。
自動生成コードを含めると18万行に達します。

  • ASP.NETでも慎重にやれば出来る

この意見は正しいんですが、周囲のスキルや引き継ぎの難易度を考えると現実的には出来ないと僕は感じてしまいました。

*1:なんか一日早く進んでいる気がするのですが、気にせずに書いてみます。

*2:ソフトウェアシステムの分割法 - ある組込みソフトエンジニアの日記

*3:「コードたくさん書いてるんだぜえっへん」というわけではなく、「コード書きすぎた死にたい」と言いたい。

*4:どこまで含めていいのやら・・・

*5:一時期ちょっと燃え上がったりはしましたがピークで1ヶ月60時間弱

*6:一人で数万ステップを扱っている時点で戦略としては間違いなく間違っていると思うので、戦術としました

*7:脳に優しいC#のメソッド設計 - give IT a try

*8:システム設計日記

*9:ドメインモデル駆動開発の実践 | システム設計日記