テストやビルドの自動化について
SIerにはコード記述の自動化からビルド・デリバリの自動化へのトレンドの変化を理解してほしい - 達人プログラマーを目指して
を読んでとても共感したので、
http://www.amazon.co.jp/exec/obidos/ASIN/0321601912/ryoasai-22/
に興味をもったものの、英語が出来ないので
http://www.amazon.co.jp/exec/obidos/ASIN/4774148911/hatenadairy07-22/ref=nosim/
を予約してみた。
NTTデータと真昼の対決 - yvsu pron. yas
↑このへんの議論も頭に置きつつ、SIerなんぞ働いてる立場ですが／だからこそ、「生産性の高い開発とは何か？」を考えてみようかと思います。<追記>
日本語だと、こんなのも出てるのね。
こっちは実作業っていうより、考え方が中心っぽいね、
http://www.amazon.co.jp/%E7%B6%99%E7%B6%9A%E7%9A%84%E3%82%A4%E3%83%B3%E3%83%86%E3%82%B0%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E5%85%A5%E9%96%80-%E9%96%8B%E7%99%BA%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%82%92%E8%87%AA%E5%8B%95%E5%8C%96%E3%81%99%E3%82%8B47%E3%81%AE%E4%BD%9C%E6%B3%95-%E3%83%9D%E3%83%BC%E3%83%AB%E3%83%BBM%E3%83%BB%E3%83%87%E3%83%A5%E3%83%90%E3%83%AB/dp/482228395X/ref=pd_sim_fb_4
トム・デマルコ「ゆとりの法則」を再読して
プロジェクト管理系の大御所本ですね。
まとめ・要約ではなく、管理者的視点と技術者的視点、２つの視点での「へえ、なるほど」を書き留めておきます。
１．管理者的視点
１２ページにてデマルコは「ゆとり」のことを、「変化を実現するための必要な自由度」と表現しています。
ドラッカーの「マネジメントは管理的活動だけではなく起業家的活動を行うべきである」や、
グーグルの２０％ルールなんかも通じる考え方ですね。
こういった話から、日本おけるワークライフバランス云々（ワークライフバランス概念の誤解）に話をつなげてみたかったりもするんですが、長くなりそうなので割愛。
２．技術者的視点
（１）．開発標準とか
「設計の標準プロセスは、優れた設計を考案する方法は何も教えてくれない（それを文書化する方法だけである。）」
何かと「ソースコード自動化！」とか「プロセス標準化で高品質！」みたいな銀の弾丸を煽る輩には注意したいですし、日々、自分の刃を研いでおきたいと身が引き締まりました。
結局、重要なところは職人芸ですからね。
（２）.品質管理とか
デマルコはフォトショップが以下に楽しくて使いやすいソフトかをあげ、「これぞ私にとっての高品質！」ということを言ってます・
「１ｋステップ辺りのテストケース数と不具合密度が〜〜」みたいなが所謂「品質管理」とされてたりしますが、それってエンドユーザに関係ない内部的な数値ですからね〜。
もう少し、外部に響く「品質」に意識を向けたいな、と思いました。
＜追記＞
２００４年のデマルコのインタビュー見つけた。おもすれ〜！！
トム・デマルコ氏インタビュー（完全版） | 日経 xTECH（クロステック）
大人になりきれていないのは人ではなく、企業です。これらの企業は、大人が本来持つべき、ある基本的な特徴を備えていません。「『悪いことは往々にして起こる』ことを理解している」というのがそれです。私たちはこの前提を踏まえたうえで、万一に備えて準備する必要があるわけです。
現在IT業界でよく見受けられる症状に、「失敗プロジェクトの多くは、もともとあまり意味のないものだった」というのがあります。プロジェクトが失敗する主要な理由は「そもそもそのシステムがいらなかったので、時間と金をほとんど割り当てなかった」ことにあるのです。そのプロジェクトが失敗したところで、だれも気にしません。
ibatisのresultMapをHashMapで。
単純なCrudだったら、resultClassにテーブルと対応したBeanクラスを設定するだけ（※）なんで特に考えることないけど、
複雑なjoinをする場合はこんなのが良いのかな、と。
（※その程度だったら自動生成ツールなんかでもできるし。）
<select id="memberId" resultMap="java.util.HashMap"> SELECT * FROM HOGEHOGE,FUGAFUGA WHERE (以下略) </select>
但し、型変換なので問題が起きそうな場合は面倒くさがらずに、
以下のように、Mapの中の型を明示するのが良いのかもしれない。
（ココまで来るとBeanクラスを作った方が良さそうだね）
<select id="memberId" resultMap="HOGEHOGEFUGAFUGAMap"> SELECT * FROM HOGEHOGE,FUGAFUGA WHERE (以下略) </select> <resultMap id="HOGEHOGEFUGAFUGAMap" class="java.util.HashMap"> <result column="カラム名" property="適当な名前" javaType="long"/> </resultMap>
やっぱViewつくって、Viewに対するマッパーつくるのが良いのかな？
