この一年で読んだ本 2012 ビジネス書部門

昨年に引き続いて、この1年間（XP祭りを起点にしています）で読んできた本を振り返ってみようと思います。一言レビューも添えてみました。技術書部門はひとつ前の記事です。

読了した本

主体的に動く アカウンタビリティ・マネジメント

出現する未来 (講談社BIZ)

リーダー塾の課題図書。これと、

さあ、才能(じぶん)に目覚めよう―あなたの5つの強みを見出し、活かす

自分の小さな「箱」から脱出する方法

を含めた4冊が自分の世界を変えていった。

パンツを脱ぐ勇気

いつもお世話になっている美容院のお客様が書かれた本と聞いて読んでみた本。タイトルは変態臭が漂うのだけど、中身は熱い。「ぐちゃぐちゃ言ってないで、リスクを取って、何かにチャレンジしなさい」という言葉は、僕達エンジニアに対しても言えることだろう。

偏愛マップ―キラいな人がいなくなる コミュニケーション・メソッド

@Akiyahさんに教えてもらって購入。いつか偏愛マップで自己紹介できる日が来ることを願う。

プレゼンテーションzen

エバンジェリスト養成講座 究極のプレゼンハック100

スティーブ・ジョブズ 驚異のプレゼン

わかりやすく〈伝える〉技術 (講談社現代新書)

この本に

パブリックスピーカーの告白 ―効果的な講演、プレゼンテーション、講義への心構えと話し方

を加えた5冊は、ライトニングトーカー五大図書だと思っている。このあたりのテクニックを身につけたら、プレゼンターとしての能力が数倍アップすること間違いない。
そのエッセンスは、僕らのLT本502 Bad Gatewayにて出しています。

レバレッジ時間術―ノーリスク・ハイリターンの成功原則 (幻冬舎新書)

時間管理系の本に関しては、ポモドーロ・テクニックよりも、エンジニアのための時間管理術よりも好きな感じ。時間を投資するという考え方は僕らエンジニアにとって重要だと思う。

減らす技術 The Power of LESS

ある人に頂いた本。この本を読んで「もっとシンプルに！」という風になりつつあります。

一部読了した本

イノベーションの神話

「イノベーションは、後からふりかえってイノベーションなんだよ」っていう本。世界を変えたいなら読んでおくべき。（俺もちゃんと読まないと）

考具 ―考えるための道具、持っていますか?

発想法の本。コラム書いたりするようになってますます重要度が増してきているので、本気で一冊読了しておきたい。

プロコーチのコーチングセンスが身につくスキル (スーパー・ラーニング 3)

リーダー塾で必要になって購入。スクラムマスター@ayaya1024さんのオススメ本。コーチングする立場になってみて、わかることがいろいろ。もちろんこの本の通りにいくわけじゃないけど。

リーダーになる人に知っておいてほしいこと

人生と仕事について知っておいてほしいこと

ブックオフで安かったので購入。松下幸之助さんのいうことに納得。松下政経塾出身の政治家連中（某N田とか）は、この本のマインドを学ばなかったのかと憤るなど。

采配

落合監督の本。プロスポーツのマインドと、エンジニアのマインドって似るところがあるよなぁと。

簡単に振り返る。

昨年末くらいまでがビジネス書偏重だったんだなぁと痛感しました。しばらくぶりに本格的に技術書を読み始めたのは今年に入ってから。しばらくは技術書偏重でいきたい。（そうすればバランス取れるはず）

あと、読了した本より、読みさしの本が倍近くあることにびっくり。ちゃんと読まないとなぁと。

そして、この裏には買ったけど読んでない本がまだまだあって。どうしましょうかねぇ。

この一年で読んだ本 2012 技術書部門

昨年に引き続いて、この1年間（XP祭りを起点にしています）で読んできた本を振り返ってみようと思います。一言レビューも添えてみました。今回は技術書部門とビジネス書部門に分けてみます。

読了した本

Clean Coder プロフェッショナルプログラマへの道

ボブおじさんの若き日の厨二病っぷりにびっくり。それが世界に名だたるエンジニアとなり、プロフェッショナルの流儀を説いているのです。学ばなければならないことは山ほどあります。

たのしい開発 スタートアップRuby

iOSアプリケーション開発入門 (即戦力エンジニア養成講座)

@ITエンジニアライフの書評を書くために頂いた本。スタートアップRubyはただいま書評執筆中。iOSアプリケーション開発入門に関しては晴読雨読＠エンジニアライフ: 『iOSアプリケーション開発入門』――「iOSアプリの1本でも作っておきたい」エンジニアの指南書を。

100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊

デブサミスピーカーたちによる書籍ガイド。読んでみたい本が山ほどあります。

一部読んだ本

Titanium Mobileで開発するiPhone/Androidアプリ (Smart Mobile Developer)

パーフェクトJavaScript (PERFECT SERIES 4)

iPhoneアプリ設計の極意 ―思わずタップしたくなるアプリのデザイン

Titanium Mobileでアプリを作っていた時に、お世話になった本たち。これらの本がなければ、アプリを作れてなかったです。

知る、読む、使う！ オープンソースライセンス - 達人出版会
Titanium Mobileでアプリを出した後、ソースコードをGitHubに載せたらMoonGiftさんに「ライセンス書いてないよ」と突っ込まれてあわてて買った。でも、まだライセンスは明記していない。。。

Head First JavaScript ―頭とからだで覚えるJavaScriptの基本

Titanium Mobileをやる前かな。Javascriptを勉強しなきゃなぁと思って、震災セールで買ったこいつに手をつけました。正直な話、Titanium Mobileでコード書いたりしたお陰でJavascriptがそれなりに書けるようになってしまったので・・・。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

ふりかえりのバリエーションを知りたくて購入。実践できてないのが悔しい限り。

ゲームストーミング ―会議、チーム、プロジェクトを成功へと導く87のゲーム

創造的な会議をするための方法がいろいろと。アジャイルレトロスペクティブズと組み合わせるのもよさそう。こちらも実践できていなくて悔しい。

RailsによるアジャイルWebアプリケーション開発 第4版

Rails写経といったらこの本が定番と聞いて。写経していくうちにタイプミスが積み重なったのだろうか。エラーが解消できなくなっていって辛くなった。
でも、Rails勉強したいなら、この本を写経するのはいいと思います。

プログラミングScala

Scalaスケーラブルプログラミング第2版

Scalaもちょっと触ってみようと思って買った本。鈍行電車で写経するために、いまはプログラミングScalaがメインになっている。
Scalaスケーラブルプログラミングは電子書籍が欲しい。

SQLクックブック ―データベースエキスパートのための実践レシピ集

SQL Hacks ―データベースを自由自在に操るテクニック

仕事でお世話になっている本。震災セールのときに購入。これが無かったら今のプロジェクトは完遂できなかった。

デザイニング・インターフェース 第2版 ―パターンによる実践的インタラクションデザイン

これも仕事でちょっとお世話になった本で、震災セールのときに購入。フォームデザインのあたりは、VBでWindowsフォームな仕事でも十分使える。

データベース・リファクタリング

興味本位で買ったけど、俺にはレベルが高すぎた・・・。読書会があるらしいので行ってみたい。

言語設計者たちが考えること (THEORY/IN/PRACTICE)

震災セールのときに購入。仕事中のビルド待ちの間にちょっと読んでた。ちゃんと読みたい本。

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

DB設計アンチパターンのあたりは良い感じ。手元に置いておきたい。前半部は、類書と変わらず。

プログラミングGROOVY

アジャイルサムライ横浜道場の常連メンバーのうち何人かで、この本の読書会が始まった。それを「やったらいいじゃん」と背中を押したらいつの間にか巻き込まれてしまい購入。Rubyと比較してみると面白いかも。

Being Geek ―ギークであり続けるためのキャリア戦略

お察しください。

エンジニアの生産性を実測してみた。

よくエンジニアの生産性は10倍とか100倍とか開きがあると言われます。
僕自身、「そうだろうなぁ」と薄々は感づいていました。ですが実際に比較してみたら本当に10倍以上の生産性が出るんだなぁと実感したことがありました。今回はその比較について書いておこうと思います。

比較対象としたのは、自分が現在携わっているプロジェクトと、保守をしているプロジェクトの２つです。

定量的に測ってみる。

ソースコードの行数で測ってみました。ステップ数とかいろいろ言われますが、実際に測れるものはこれくらいだったので。
現在携わっているプロジェクトの手書きステップ数は約30000行。
それに対して、保守をしているプロジェクトの手書きステップ数は約10000行。

開発期間は、現在携わっているプロジェクトが約12ヶ月。
保守をしているプロジェクトは15ヶ月〜18ヶ月。
開発期間に関しては、要件定義フェーズから始まり、仕様変更や不具合が落ち着いてくるまでの期間としています。

この時点で生産性は3倍強〜4倍強。

定性的な要素も加味していく。

保守をしているプロジェクトでは、SQL文もソースコード内に直書き。実測内に含めていないストアドプロシージャが、おおよそ2000行程度でしょうか。
現在携わっているプロジェクトでは、SQL文はTableAdapter内に記述しているので、実測の対象範囲外となっていました。
SQL文の総行数は多分1万行を超えます。TableAdapterでは扱い切れないSQL文を扱うためにビューを作っていたりしたので、それも含めるとあと2000行くらい増えそうです。

画面数は、保守しているプロジェクトが20画面弱。
現在携わっているプロジェクトでは3サブシステムで100を超えるはず。

テーブル数も、保守しているプロジェクトでは20程度。
現在携わっているプロジェクトでは3サブシステムの合計が100を超えます。

案件自体の難易度も違います。
保守しているプロジェクトは、受注と出荷のデータを登録するだけというもの。
現在携わっているプロジェクトでは、勤怠管理・人事評価・給与計算のためのデータ集計の3サブシステムを開発。
法律や細かい運用ルールなど考慮すべき点の多さが違います。

開発人員は共に1人ずつ。ただし、保守しているプロジェクトは、1回交代があった後カットオーバーを経て自分が不具合解消・保守をやるようになりました。

生産性の違い

いったいどれだけの生産性の違いがあるのでしょうか。現在保守しているプロジェクトでは、どのようにして開発が進んでいったかはわかりません。ですが、定性的な要素も加味すると、10倍は超えてくるのではないでしょうか。
いや、決して自分が優れたプログラマというわけではありません。むしろ、普通にプログラムを書けるエンジニアと、コピペエンジニア（CSSとかひどかった。）の間での生産性がこれだけあるわけです。

普通にプログラムを書ける程度のエンジニアと、ハッカークラスのプログラマの間では、ここからさらに数倍、数十倍の生産性があるのでしょう。
それを考えると、ハッカークラスのプログラマとコピペプログラマの間の生産性が100倍以上になることも、納得がいくというものです。

フィボナッチ数は変態です。（変態アドベントカレンダー in Summer 最終日イブ）

この記事は変態アドベントカレンダー in Summer : ATNDの最終日イブな記事です。
最終日じゃないかって？いやいや、僕らの時間軸は5時〜29時なので。

前の記事は、@razonさんのJavaの痛IDE用画像が欲しい(2) - SHI-Zoneでした。

このごろ巷に流行るもの。

さて、ここ数日FizzBuzzな記事が盛り上がっているようでして。
そんななか、Twitterで

FizzBuzzより、「素数のときだけ"JOJO!"って出力するプログラム」のほうがネタ的にもいいと思う。 [うさみみ＊´×｀＊エンジニア]

— きょん＠おやすみモードさん (@kyon_mm) 8月 11, 2012

というつぶやきを見かけて、やってみようかなぁと思ったらすでに書かれていて・・・

素数のときだけ"JOJO!"って出力するプログラムを作ってみた - くりにっきがまずあって、
我らが@daiksyさんが素数のときにJoJo - scala - | 言葉をポッケに持ち歩こうと書かれて、
そこに食いついた@mike_neckさんが、mike、mikeなるままに…: 素数の時にEnrico Pucciと出力するプログラムを書いてみたという記事を書かれて。

もう、正直素数で書く必要は無いなぁと。
じゃぁ、何で書こうかと思ったときに、ちょうど読んでいた

たのしい開発 スタートアップRuby

を思い出して、「フィボナッチ数でやってみよう！」と思ったわけでございます。

フィボナッチ数でFizzBuzzしてみる

フィボナッチ数でFizzBuzzしようとしてみて気づいたのは、単純な判定式を書けないこと。
で、どうしようか考えてみたら、フィボナッチ数を先読みして配列化。そこから、与えられた数がフィボナッチ数かを判定してみようという感じでした。
ソースはこんな感じ。全然慣れていないRubyで書いたので結構めちゃくちゃな気がする。

で、実行すると、

% ruby fib_exist.rb
"HENTAI!"
"HENTAI!"
"HENTAI!"
"HENTAI!"
4
"HENTAI!"
6
7
"HENTAI!"
9
10
11
12
"HENTAI!"
14
15
16
17
18
19
20
"HENTAI!"
22

といった感じになりました。

変態アドベントカレンダーのトリは誰が飾ってくれるのでしょうか・・・。企画された@Kuchitamaさんとか、関西が誇る変態の@daiksyさんにやってほしいなぁと思うわけですが、どうなんでしょ？

「iStockPhoto乞食」という変態プレゼンターな生き方

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

一つ前の記事は@issps2009の変態アドベントカレンダー in summer - dpsでした。

きっとこの記事を見ている皆様はLTとか大好きなことと思います。人前に立って、自分の変態っぷりを晒すのが大好き。そうじゃないですか。少なくとも、僕はそうです。
そんな僕が願うこと。皆様が願うこと。・・・自分のLT、もっと良く見せたいですよねー。きっと

プレゼンテーションzen

とか

パブリックスピーカーの告白 ―効果的な講演、プレゼンテーション、講義への心構えと話し方

なんかも読んでますよねー。
それらを読んで、LTに取り込んで何度もやった。それでもなお、クオリティを上げたい。そう願って努力していませんか。

そんな皆様におすすめしたいのが、「iStockPhoto乞食」という変態プレゼンターな生き方です。
この生き方を実践すると、一ヶ月に一回、たった数分の努力で、しかもお金を1銭も払わずに、LTをより魅力的にすることがができます。
今日はその生き方について書いていきたいと思います。

「iStockPhoto乞食」とは何か

「iStockPhoto乞食」とは僕が勝手に生み出した造語です。iStockPhotoというストックフォトサイトがあるのは皆様知っておられるかと思います。高品質な写真やイラスト・音源・映像など、プレゼン・フライヤーに役立つ素材を提供しているサイトです。（http://nihongo.istockphoto.com/）
このサイト、高品質な素材をロイヤリティーフリーで提供してくれているのはいいのですが、いかんせんお値段が張ります。
高い価格の写真画像をL判で買ったりすると軽く数千円が飛んでいくという・・・。
お安い奴もありますが、それでも数百円は飛んでいきます。

仕事としてプレゼンをするような人は、経費で落とせるのでしょう。けれども、僕らはそういう人達ではないはず。
そんな僕らでも、このiStockPhotoの高品質素材を手に入れ、プレゼンに使える方法があるのです。

実践 iStockPhoto乞食

iStockPhotoは毎週1つの高品質写真を無償で提供してくれています。提供期間は1つ4週間。つまり、ひと月に1回のダウンロード作業をするだけで、4〜5つの高品質写真が手に入ります。
それだけではありません。iStockPhotoでは毎月1つ、高品質ベクター画像を無償で提供してくれています。こちらの提供期間は3ヶ月。
つまり、ひと月で5つ〜6つも、高品質な素材が手に入るのです。
僕は使ってないのですが、音源や映像も無償提供があります。これも含めると、ひと月でいろいろな高品質素材が手に入るのです。

それを半年続けるとどうでしょうか。
少なくとも30個くらいは高品質素材が手に入ります。
30個の写真・ベクター画像があれば、一回のプレゼンで何枚かは使えそうな画像が出てくるかと思います。それをスライドに使うのです。それだけで、見た目がよくなります。

さすがに毎回同じ画像を使っていては飽きられるかもしれません。ですが、ひと月に一回、新たに5つの高品質素材が手に入ります。貯まっていけばいくほど、選択の幅が広がるので「また同じ画像！」ということもなくなってくるでしょう。

そうやって作り上げたLTスライドがこちら。

たのっち流コラムの書き方 from Daiki Tanoguchi

このスライドの画像の半分近くはiStockPhotoの画像を使っています。
（もう半分はThe Leading Source Of Free Stock Photos - stock.xchngを使いました）
きっとiStockPhotoの画像とそうでない画像の見分けがつくのではないかと思います。

たった一ヶ月に数分の努力で、プレゼンの品質を上げることができるiStockPhoto乞食という変態的な生き方、いかがでしょうか。「いいね！」と思ったら、今すぐiStockphoto LP - 404 Errorにアクセスして、無料素材をダウンロードしましょう！そして、iShockPhoto乞食の生き方を実践しましょう！

追伸
この記事の初稿は、とある勉強会の帰り道に書きました。懇親会でがっつりお酒を飲んだあとに書いたので、文章がだいぶひどかった。まぁ、そうやってブログのネタを作るのも変態だよね。

Titanium mobile の Alloyでエロい（？）アプリをつくる。(変態アドベントカレンダー in Summer 16th Day)

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

一つ前の記事は@razonさんのJavaの痛IDE用画像が欲しい(1) - SHI-Zoneでした。

さて、僕の前回の記事は”変態”といいながら大真面目なことを書いてしまったので、今回は変態なことを書いてみようと思います。

Alloyとは何か

Titanium Mobileというプロダクトがあります。iPhoneアプリとAndroidアプリをワンソースで書けるというものです。
このTitanium Mobileの開発元であるAppcelerator社がTitanium Mobile用のMVCフレームワークを開発しています。それがAlloy。
このAlloy。残念ながら今はまだUnstableすなわち不安定版です。よって、これを触る=人柱確定なフレームワークです。
しかしそこは変態。人柱上等！・・・いや、喜んで人柱になります！な人こそ、変態だと思うのでちょっと使ってみました。

それでは、エロい（？）アプリを作って行きます。

今回のアプリ

今回は、妹にタッチしたら「おにいちゃんのえっち！」って言われる、そんな変態にとってたまらんアプリにしてみたいと思います。ちなみに僕は妹萌えではありません。リアル妹がいるので。どちらかというと姉萌え属性をもった変態です。リアル姉がいないので。まぁ萌え属性なんてそんなもんさ。

AlloyのインストールについてはTitanium と alloy ではじめるスマートフォンアプリ開発 :: Crocos Engineering Blogを参考にしてください。node.jsでnpm install alloyってしてあげるだけです。

プロジェクトを作る

では、プロジェクトを作っていきましょう。プロジェクト名はTiElloyとしておきます。

で、次の画面に行きましてSingle Window Applicationを選択してプロジェクトを作ります。

プロジェクトができました。プロジェクトビューはこんな感じです。

ここで、プロジェクトをAlloy用にします。

Alloyコマンドを使えるようにして・・・

$ which alloy
/usr/local/bin/alloy

プロジェクトのディレクトリに移動して"Alloy New ."っと

$ cd ~/Documents/Titanium_Studio_Workspace/TiElloy
$ alloy new .

これでプロジェクトがAlloy用に変わります。

初期ソースがこんな感じ。
/app/views/index.xml

<Windowclass="container">
  <Labelid="t">Hello, World</Label>
</Window>

/app/styles/index.tss

{
   ".container":{
   "backgroundColor":"white"
   },
   "Label":{
   "width":Ti.UI.SIZE,
   "height":Ti.UI.SIZE,
   "color":"#000"
   }
}

/app/controllers/index.js

$.t.on('click',function(e){
  alert($.t.text);
});
$.index.open();

妹とじゃれあうエロいアプリにしていく

上記のソースをindex.xmlがhtmlに, index.tssがcssに、index.jsがロジック部分に相当するのはすぐお分かりになるかと思います。

この内、index.xmlに書いてあるWindowやLabelがTi.UI配下のオブジェクトに相当するようです。
なので、画像を表示するImageViewを使いたければ、LabelをImageViewとすればよさそうです。

/app/views/index.xml

<Windowclass="container">
  <ImageView id="i"></ImageView>
</Window>

tssファイルを使って画像を表示します。プロパティもそれぞれのオブジェクトで規定されているやつを使えばよさそうです。
画像はapp配下ではなく、/Resource/iphoneの中に入れなければ表示されませんでした。
/app/styles/index.tss

{
".container": {
"backgroundColor":"white"
},
"#i": {
    "image": "nc25761.png",
"height": 350,
"width":150,
"top":0,
"left":0
} 
}

ロジックは、ImageViewをタッチしたときにアラートを出せばいいので、こんな感じ
/app/controllers/index.js

$.i.on('click',function(e) {
alert("おにいちゃんのえっち！")
})
$.index.open();

で動かすと、こんな感じの画面が・・・と思ったらスクリーンショットを用意していなかった。
とりあえず、これで動きます。でも、せっかくここまで出来上がると欲望は膨らむばかりで。自分の名前で「えっち」と呼んでほしいですよね。

もっと俺好みのエロいアプリにしていく

妹には自分の名前を教えないと呼んでくれないので、教えられるようにテキストボックスを追加しましょう。

/app/views/index.xml

<Windowclass="container">
<ImageView id="i"></ImageView>
<Label id="l">おにいちゃんの名前は？</Label>
<TextField id="t"></TextField>
</Window>

テキストボックスの表示が"#t"のようになって・・・
/app/styles/index.tss

{
".container": {
"backgroundColor":"white"
},
"#i": {
    "image": "nc25761.png",
"height": 350,
"width":150,
"top":0,
"left":75
}, 
"#l": {
"top":350,
"left": 50,
"height":50,
"width":200,
"color": "#000"
},
"#t": {
"top":400,
"left":50,
"height":50,
"width":200,
"borderStyle":Ti.UI.INPUT_BORDERSTYLE_LINE 
}
}

alertを呼ぶところで、妹は自分の名前をわかってくれるんですな。
/app/controllers/index.js

$.i.on('click',function(e) {
	alert($.t.value + "おにいちゃんのえっち！");
})
$.index.open();

では、妹に「たのっちおにいちゃんのえっち！」と言ってもらいましょう！
シミュレータを起動するとこんな画面が。

で、自分の名前を教えてあげて妹に触れると・・・

よしよし、偉いぞ。

やっぱりまだまだ発展途上

さて、こうして実際に人柱になってみたのですが、なってみてしんどかったことがありました。
構文エラーをチェックしてくれません。なのでtssファイルでカンマ一個忘れただけでコンパイルエラーが出ます。
しかもパーサーエラーとしか出なくて、どこがエラーを起こしているか教えてくれない。

これで、どこがおかしいのか調べるのがしんどかったという・・・。
本リリースのときにはなんとかなっているよな。

最後に

妹の画像は舞太 - ニコニ･コモンズから頂きました。
今回のアプリはdproject21/TiElloy · GitHubで公開しています。

明日の変態アドベントカレンダーは@soudai1025さんの予定です。投稿なかったら勝手にパスしてだれかやっちゃってもいいんじゃないかな。

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

この記事は変態アドベントカレンダー 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
メソッドを切り出せるところは切り出すようにしていました。

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

適切な名前付け

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

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

設計戦術

業務の切り離し

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

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

層の分割

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

管理戦略

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

バージョン管理

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

タスク管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

追記(2012.7.23)

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

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

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

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

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

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

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

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

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

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

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

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

*8:システム設計日記

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