ちょいAndroid。Typescriptいいよ。JenkinsとかGradleとか。APTもいいなー。 photo by http://www.flickr.com/photos/jonnygoldstein/ 裏Android Advent Calendar 2011 12/18(日)担当の@sys1yagiです。 いきなりですがproguard.cfgをいじるのってクソめんどくせーわけですよ。何が悲しくてあんな意味不明なオプションの文法を毎回ググりながらsitと言いながら書かないといけないのか。ていうか複数人でやってたらproguard.cfgをいじるタイミングがさー色々面倒でもう最後にぱっと追加するかーとか皆思っちゃってて最後にカオスになったりして＼(^o^)／とかさ、もっと簡単な方法はねーのかよ！？例えばアノテーションでさー、クラスのとこに書いたらさー、難読化されないとかさ。 あ

森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基本はチーム全員で集まってやります。最大２時間。それ以上やっても集中力が続かないので。プロジェクタで対象

アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 重厚長大なドキュメントは、動かなかったり嘘が書いてあったり現実と異なっていたり、その上肝心なこと書いてなかったりということで辛いことが多いのが現状です。 今回とある筋からドキュメントをレビューする際のポイントを教えて欲しい、という依頼を受けたので書いてみます。 なお、個人的には、ドキュメントレビューよりソースレビューの方が重要だと思っています。 とはいえドキュメントレビューで肝心なのは、 ドキュメントレビューをするなら、その投資に見合う何を得るのか？を決めておく必要がある本当にそのドキュメントは必要か？をよく考える（会社のルールだから！というのは理由にはなっていない）だと思います。