TDD Boot Camp Fukuoka 2013 行ってきました
6月15日，16日に開催されました，TDD Boot Camp Fukuoka 2013に行ってきました！ 2日間の濃密なBoot Campだった+ぺーぺーの学生だったので，それはまあ学ぶことが多かった週末となりました．全てをまとめると大変な量になってしまうので，学生なりの視点で参加したいきさつやこれからの決心に焦点をあてます． ということで，後先考えずに模造紙に描きながら考えてみました．
そもそもTDDについては，学部3年の頃にかじっただけで，ほとんど経験がありません．最近ようやくテストを書くようにはなったのですが，なかなか思う通りに書けず悩んでいました．そんな時に開かれるTDDBC，ということで，熟練者のノウハウを盗みに，また昔わからなかったTDDのことも知れるなら一石二鳥だと思い，参加した所存です．
TDDBCは基調講演+ペアプロ+コードレビューの3つのプログラムで組まれていましたが，今回は印象に残った部分について注目しました．
黄金の回転を素早く回すことで，安心して開発を行うことができるのだと感じました．また素早く回すために，粒度を細かくしたり，順番をつけて開発していくので，消化するテンポもよくなり，気持ちよく開発できる環境になるのではないでしょうか．どことなくTiDDを彷彿とさせます．ペアプロでは，はじめにお題をTodoにおとしてから作業を行うのでまさしくTiDDでした．
1回目のお題ではこのTodoがうまくまとめることができなかったので，なかなか黄金の回転を回すことはできませんでした．そもそもペアプロ(Objective-C組はトリプロでしたが)自体が初めてで，どう進めればいいのかが手探り状態でいっぱいいっぱい．
2回目のお題ではペアの方やTAの方にたくさんサポートしていただきながら，Todoをまとめ黄金の回転を踏まえてコーディングすることができました．
どうしてTodoがまとまらないのかというと，お題から設計を組み立てることができないからだそうです．どうやって実現するかがみえていないと，もちろん不安を解消する適当なテストを書くこともできず，不安がつもる悪循環……．これまで大規模な開発は経験したことがなく(小さな規模のアプリばかり作ってます)，設計を軽視してしまっていたのですが，今回のペアプロで設計の大切さを痛く実感しました．UMLの基礎をせっかく勉強したので，もう少し深く勉強してみようかな．
また，プログラムを書いてからテストを書くとき，いつも書きにくいと思っていたのですが，それはつまり実装したプログラムが使いづらいことだと気付いて，とてもぐらぐらしてます．テストを先に書くと，使う側の気持ちになるので，設計ができるできないに関わらずいい心がけになる気がします．
そんなわけで，TDDをぺーぺーの技術者が行いますと，設計の大切さが痛く実感できますので，むしろいいのじゃないかと思います．テストが書けるところはテストを先に，書けそうにないところはテストを後に，と臨機応変に開発へ取り入れ振り返ることで，徐々にテストファーストの比率をあげていこうと思いました．
まとめますと，TDDの前にもっと技術をみがけ！写経をしろ！ というひとことに尽きてしまいますが，もっともなので意義なしです．写経頑張ります．
最後になりましたが，主催者の春山さん，講演してくださった和田さん，TAの方々、参加者の皆さん，AIPさん，ありがとうございました．
コードレビューの振り返り その1
研究室内でコードレビューが始まった．研究室にとっても私にとっても初めての取り組みだ．
去年2012年，私が学部4年であった年は実際の開発に重きを置いていたが，中々品質というところまで手が届くことはなかった．そのおかげで，成果物のコードはずいぶんとからまっていた．ということで，今年2013年は，内部品質の向上もしくは，研究室内プログラマーの腕を磨こう，ということでコードレビューを開始した．
ちなみに，研究室内のコードレビューにおいて，私個人の目標としては「自分の書いたコードについて，全て説明できるようになる」としている．
すでに1.5h×3回ほどコードレビューを行って，今更気がついたのだが，せっかくコードレビューを行っているので，ブログに備忘録として公開しておく．
今回の対象は，現学部4年生が1月に書いたiPhone向けアプリ内のコードの一部，あるビューを読み込んだときに呼ばれるviewDidLoadに注目した．
- (void)viewDidLoad
{
[super viewDidLoad];
// Do any additional setup after loading the view, typically from a nib.
self.battingButton.hidden = YES;
self.changeButton.hidden = YES;
self.pitcher.hidden=YES;
enemyscore = arc4random() % 11;
totalEScore=enemyscore;
[[self nanaomoteLabel] setText: [ NSString stringWithFormat : @"%d", enemyscore]];
[[self totalELabel] setText: [ NSString stringWithFormat : @"%.f", totalEScore]];
self.nanauraLabel.text = @"";
self.hachiomoteLabel.text = @"";
self.hachiuraLabel.text = @"";
self.kyuuomoteLabel.text = @"";
self.kyuuuraLabel.text = @"";
self.nameLabel.font = [UIFont boldSystemFontOfSize:20];
//球場
[self studium];
}
初期化は初期化用のメソッドを用意する
viewDidLoadはあるビューが読み込まれたときに実行されるので，ひと通りの初期設定がまとめられていた．今の状態ではどんな初期設定を行っているのかわかりにくいので，きちんと初期化用のメソッドにまとめた方がいいだろう．また，初期化用のメソッドにまとめることでビューを読み込む時以外に初期化を行うとき(リセットするとか)にメソッドを呼ぶだけでいいので，保守も簡単だ．
=の前後には半角スペースをいれる
=の前後には半角スペースをいれるのかself.battingButton.hidden = YES;=の前後には半角スペースをいれないのか
totalEScore=enemyscore;どちらか一方に統一するべきだ．この2つのうち，どちらかを選ばなければならないが，そこは個人の趣味になる．私たちの中では前者の半角スペースをいれるということで一致した．その理由はスキマが空いて読みやすくなるためだ．
メソッドや変数名は小文字始まり，以降頭文字は大文字
enemyscoreという変数が存在しているが，これはenemyScoreに変更するべきだ．大きな理由としてAppleのコーディングルールで決まっているからだ．ちなみにクラス名は大文字始り，定数は全て大文字で命名する．
個人的な落としどころとしては，その方がぱっとみた時にそのものが変数なのかメソッドなのかクラスなのかすぐわかるから，と思っている．
基本的に単語の省略をしない
totalEScoreという変数が存在しているが，totalとScoreの間にEが入っている．これはEnemyのEなのだが，その場合はtotalEnemyScoreとした方が，よく分かる．コードを描いているときはよくても，数ヶ月後には忘れてしまうのだから，誤解を招く原因や理解を阻む表現は避けるのが吉だ．基本的にローマ字は避ける
nanauraLabel，hachiomoteLabel，hachiuraLabel，kyuuomoteLabel，kyuuuraLabelといった変数があるが，これは野球の7回裏だとか8回表のことをいっている変数だ．ローマ字だと分かりづらいので，基本的には変数名は英語でつけるようにしよう．そもそも，似たような動きをする変数は，適度コードで生成する方が管理がしやすいのではないだろうか．同じ動作に対する記述は統一する
オブジェクトの属性に値をセットする方法として，[[self nanaomoteLabel] setText: [ NSString stringWithFormat : @"%d", enemyscore]];と
self.nanauraLabel.text = @"";の2通りが混在している．これは統一した方がすっきりする．nanaurLabelに注目すると，
[[self nanauraLabel] setText:@""];と
self.nanauraLabel.text = @"";の2通りになるのだが，研究室内では後者で統一することにした．その理由として，前者は後者より仰々しい感じがするため，コードが見づらくなるためだ．そもそもドット演算子はコードを見やすくするためにある(らしい．自分では未確認なので今度調べることにする)ので，後者で落ち着いた．
IBOutlet系の部品はhoge+部品名で統一する
IBOutlet系の部品はコード上でみると，どうしても何が何なのか分かりづらい．ということで，すぐにわかるようにUIButtonならhogeButtonなど，後ろに部品名を付けておくといい．パラメータな定数(マジックナンバー)はdefineしておく
enemyscore = arc4random() % 11;の11や，
self.nameLabel.font = [UIFont boldSystemFontOfSize:20];の20などの，パラメータな定数(マジックナンバー)を直書きするのはよくない．コードの文頭にdefineして定義しておこう．
理由として，直書きすることで修正や変更に対応するのが大変になるためだ．個人で把握できるような規模のコードならまだいいだろうが，それが数ヶ月前に書いたコード，または他人が書いたコードだったらどうだろうか．数字が何を意味しているのか，なぜその数字になったのかが全く分からない，という状態で修正や変更を加える，なんてことは考えただけで嫌になる．
コードレビューをしていて，面白い話が聞けた．アジャイルに関して，今までで1番すっきり飲み込めたのでついでに残しておく．
そもそもプログラムに修正，変更などが加わるのはなぜだろうか．プログラムは正しく作らなければならない．プログラムが正しいとは，正しい仕様にそっていることだ．正しい仕様というのは顧客が決めるもので，顧客は何らかのビジネスのためにソフトウェアを発注するために生まれる．正しいプログラムの大本，正しいビジネスとは何だろうか．様々な推測はできるだろうが，正解なんてものは常に変化するだろう．やってみなければ，世に出してみなければわからないのだ．以上から，プログラムというものはどうやったって変化してしまうものだ．だから，ソースをコピー&ペーストしてはならなくて，パラメータな定数を直書きしてはならない．
変化に対して文句を言う前に，変化に対応して柔軟なプログラムを書けるようにならなければならない．アジャイルの考えとはきっとビジネスを健全に実現するためにあるのではないだろうか．
ちなみに公開メモとってみた．
ファシリテーション・グラフィック―議論を「見える化」する技法
「ファシリテーション・グラフィック―議論を「見える化」する技法」
堀 公俊，加藤 彰（著者）
4時間を1回で読了．
読んでからかなり時間があいてしまった．
この本は，話し合いの見える化によって，ハッピーな話し合いを目指すファシリテーション・グラフィックの基礎から実践について，非常にわかりやすくまとめた本だ．
この本を読んでいると，小学生の頃の宿題だった，社会見学新聞を思い出す．
小学生の頃，消防署やテレビ局，工場など様々な場所へ社会見学に行った．その度に1人A4用紙1枚の新聞を発行するのだ．ずいぶんと昔の話なので，詳細は忘れてしまったのだが，非常に楽しい思い出がある．前もって調べたこと，見聞きしたこと，わかったこと，感想などを，見てくれる人がわかりやすいように，自分なりにまとめるこの作業はなかなか骨が折れるけれど，楽しかった．小学生の宿題といえど，単にまとめるだけじゃなく，表にまとめてみたり，アクセントにイラストをいれてみたり，囲いにこだわりをいれてみたり(テレビ局新聞だったらブラウン管テレビで区切ったり)と中々こだわりポイントは多い．鮮やかで分かりやすい新聞が発行できたときには，よく祖父母にまでお披露目したものだ．小さい頃にそんな経験をしたおかげなのか，ファシリテーション・グラフィックの技術的なことについてはすんなりと飲み込むことができた．
しかし，大きな問題を抱えてしまった，もとい気付いてしまった(ありがたい話なのだけれど)．
ファシリテーション・グラフィックはリアルタイムで社会見学新聞を作るようなものであるということだ．どんどん増えていく情報を取捨選択しながら，わかりやすくまとめ，話し合いを支えるのだ．つまり，ロジカルシンキングで情報をまとめなければならない．普段の会議を思い出すと頭がくらくらする．まるで得体の知れぬ生命体と戦うみたいだ．もとより私はロジカルシンキングが大の苦手で(おかげさまで卒業研究は苦労した)，いまだに筋の通ってない意見を主張してばかりな気がする．勉強しなければいけない，とはなんとなく思っていたけれど，今度こそ見て見ぬふりはできない．
ハッピーな議論のためにグラフィッカーになりたい！ と思ったので，グラフィッカーの経験をためながら，ついでにロジカルシンキングの練習もしてしまおうと思う．
それから，面白そうな本を紹介してもらったので，今度読んでみようと思う．
「4日で使える 実践! 超ビジュアルシンキング」
アプリ開発をしながら学ぶ，iOSのためのOpenCV 1
iOSのためのOpenCVについて適当なアプリを作りながら勉強したので，不明な点やわかったところについて以下にまとめておく．
付け焼き刃な情報だと思うので，何か間違いがあれば指摘をよろしくお願いします．
まず，OpenCVとは何なのか．
Wikipedia - OpenCV
Open Source Computer Vision Libraryの頭文字をとってOpenCV．C，C++，Java，Python用の画像処理を支援してくれるオープンソースなライブラリなので，先人の知恵がつまっているようだ．
ここに，Objective-Cは含まれてはいないのだけれど，Xcodeは様々な言語を扱うことができるので，ライブラリを使うことができる．
OpenCVの概要がわかったような気がしたので，ここからは先人の知恵をお借りし，簡単なiOS向けアプリを作っていくことにする．イメージはこんなものだ．
ちなみに開発環境はXcode 4.6.2を用い，OpenCVライブラリは2.4.5で，動作確認はiOSシミュレータ 6.0とiPhone5（iOS6.1.4）で行った．
さて，ひとまず適当なXcodeプロジェクトを作成する．
- Xcodeを起動して，Create a new Xcode projectをクリック．
- 今回はiOS向けのアプリを作成するので，iOSのApplicationを選択する(図中1)．
次にSingle View Applicationを選択する(図中2)．ちなみにここではプロジェクトのテンプレートを決めている．今回選んだのはSingle Viewとあるので，1画面だけのアプリを生成してくれる．
テンプレートを選択したらNext(図中3)．
- 次にプロジェクトの設定を行う．設定が終わったらNext．
Product Name：アプリの名前．
Organization Name：会社とか組織の名前．
Company Identifier："ドメイン.*"で記入．とりあえず触ってみるだけの人は，"com.自分の名前.*"と適当に記入しておく．
Class Prefix：今回はひとまず空で．
Devices：今回はiPhoneで．
Use Storyboards：ストーリーボードなるものを使用する．後で使用するのでひとまずチェック．
Use Automatic Reference Counting：自動でメモリを解放してくれるのでひとまずチェック．
Include Unit Tests：テストを走らせることができる．今回は触れないので，以下の画像ではチェックがあるが，チェックしなくてもいい．
私は上記の画像のように記入を行った．以下，プロジェクト名は「ImageEditor」とする． - プロジェクトの保存場所を決める．
Source Controlのチェックはとりあえずチェックをいれておくと，後々プロジェクトの管理が便利になる（ローカルリポジトリの有無の設定）が，今回はチェックなしでOK．
Createを選択するとプロジェクトの作成が始まるので，少し待つ． - 最後に，きちんとプロジェクトが生成できたか確認を行う．
ウィンドウの左上にあるRun，Stopでアプリを走らせることができるので，Runをクリックする．iOSシミュレータが起動するので，真っ白な画面が起動するまで環境によっては気長に待つ．確認できたらStopで停止させる．
次に，今作成した「ImageEditor」でOpenCVライブラリが使えるように環境を整える．
前の記事にも書いたけれど，秋山ブログ [Xcode4,Objective-C++] OpenCV2.4.1をiOSで使うを参考に行う．
次は，グレースケールに変換を行いたい画像を用意する．
前の記事にも書いたけれど，秋山ブログ [Xcode4,Objective-C++] OpenCV2.4.1をiOSで使うを参考に行う．
- 「OpenCVのコンパイル」を1〜6まで行う．
- 「Xcodeプロジェクトの設定」の1，2を行う．
- 「Xcodeプロジェクトの設定」の3では，今回必要な
「libopencv_core.a」
「libopencv_imgproc.a」
の2つを追加する．OpenCVのライブラリ全てを選択してもいいが，その分アプリの容量が増えてしまうため，必要なライブラリのみをいれるのがよい． - 「Xcodeプロジェクトの設定」の4，5を行う．
次は，グレースケールに変換を行いたい画像を用意する．
- 使用する画像を用意する．
モノクロに変換する予定なので，カラーな画像を適当に用意する．私は自分のアイコン画像を使用した． - 画像をプロジェクトに追加する．Finderからドラッグ&ドロップでOK．
- そうするとファイルを追加するときのオプションを決めるウィンドウが出てくる．
DestinationのCopy items into なんちゃらのチェックを入れることを忘れずに行う．これは元のファイルをコピーして追加するというものだ．プロジェクトで使用したファイルが散らばらなくて済むので，おすすめだ．元のファイルは登録が済んだら好きにしてもらってかまわない．
- ファイルがリストに追加されているか確認を行う．
- リストからMainSroryboard.storyboardを選択する．
ストーリーボードを使うことで，視覚的に部品を設置することができる．
- Object libraryのImage ViewをViewにドラッグ&ドロップ．
Image Viewとは部品の1つで，画像を表示することができる．
- Image Viewに先ほど追加した画像を表示する．Imageで画像の名前を選択する．
表示できた．
がサイズがおかしいかもしれない． - そこでImage Viewの調整を行う．
表示する位置や，大きさなどが修正できる．
私はアイコンだったのでこのくらいにした．
- Object libraryのRound Rect ButtonをViewにドラッグ&ドロップ．
Round Rect Buttonとは部品の1つだ．これを押したとき，押して離したときなどに処理を行うことができる．
- デフォルトだとButtonと表示され，なんだかそっけない．好きな表示名に変更する．
長過ぎると省略されてしまうので，好みに応じて調整する．
先ほど設置したボタンをクリックしてみるとわかるが，もちろん押しても何もおこらない．次はボタンを押したときに反応するようにしていく．
- 左上のEditorの真ん中，Assistant editorをクリックする．
すると画面が2つに分かれる．クリックで左の画面に表示，option+クリックで右の画面に表示することができるので，左にMainStoryboard.storyboardを，右にViewController.hを表示する．
- ViewController.hの@interface内を以下のように書き加える．
@interface ViewController : UIViewController{
}
@end - ImageViewとViewControllerを接続する．
MainStoryboard.storyboardに表示されているImageViewを選択しておく．
controlを押しながらImageViewをViewController.hの{}の中へドラッグ&ドロップする．
- 吹き出しが表示されるので，NameにImageViewの名前を設定し，Connect．
ここではimageViewにした． - 次はRound Rect ButtonとViewControllerを接続する．
MainStoryboard.storyboardに表示されているRound Rect Buttonを選択しておく．
controlを押しながらRound Rect ButtonをViewController.hの}から@endの間へドラッグ&ドロップする．
- 吹き出しが表示されるので，ConnectionをActionに，NameをpushButtonとする．入力が終わったらConnect．
これでImageViewとRound Rect Buttonの接続が終わった． - 左にViewController.h，右にViewController.mを表示してみると以下のようになっているはずだ．
ここで，ViewController.mのpushButton内を- (IBAction)pushButton:(id)sender {と記述し，RunしてRound Rect Buttonを押してみてほしい．下記のようにコンソールに文字列が表示されたはずだ．
NSLog(@"pushButton");
}
pushButtonはRound Rect Buttonを押したときに呼び出されるメソッドだということがわかるだろう．ここで画像処理を行うことにする．いよいよOpenCVライブラリを活用するときがきた．
cv::Matな画像に画像処理を行い，
cv::Matな画像をUIImageな画像に変換して，表示する．
他のライブラリを使えばモノクロ画像にするくらいの画像処理ならUIImageのままいけるが，OpenCVを使いこなせるようになると後々複雑な画像処理も行うことができる（らしい）ので，ここは1つ我慢だ．
- OpenCVライブラリでcv::Matを使うためには，メソッドファイルの拡張子を変更する必要がある．リストからViewController.mを選択し，returnを押すと，名前を変更することができる．ここで「ViewController.m」から「ViewController.mm」に変更する．
- UIImageクラスの画像をcv::Matに変換するメソッド「cvMatFromUIImage」を「ViewController.mm」のpushButtonから@endの間に追加する．
参考元：OpenCV for iOSの使い方 #Objective-C #iOS #OpenCV #AdventCalendar #iPhone #画像処理 - Qiita [キータ]- (cv::Mat)cvMatFromUIImage:(UIImage *)image
{
CGColorSpaceRef colorSpace = CGImageGetColorSpace(image.CGImage);
CGFloat cols = image.size.width;
CGFloat rows = image.size.height;
cv::Mat cvMat(rows, cols, CV_8UC4); // 8 bits per component, 4 channels
CGContextRef contextRef = CGBitmapContextCreate(cvMat.data, // Pointer to data
cols, // Width of bitmap
rows, // Height of bitmap
8, // Bits per component
cvMat.step[0], // Bytes per row
colorSpace, // Colorspace
kCGImageAlphaNoneSkipLast |
kCGBitmapByteOrderDefault); // Bitmap info flags
CGContextDrawImage(contextRef, CGRectMake(0, 0, cols, rows), image.CGImage);
CGContextRelease(contextRef);
CGColorSpaceRelease(colorSpace);
return cvMat;
} - cv::Matの画像をUIImageクラスに変換するメソッド「UIImageFromCVMat」を「ViewController.mm」のcvMatFromUIImageから@endの間に追加する．
参考元：OpenCV for iOSの使い方 #Objective-C #iOS #OpenCV #AdventCalendar #iPhone #画像処理 - Qiita [キータ]- (UIImage *)UIImageFromCVMat:(cv::Mat)cvMat
{
NSData *data = [NSData dataWithBytes:cvMat.data length:cvMat.elemSize()*cvMat.total()];
CGColorSpaceRef colorSpace;
if (cvMat.elemSize() == 1) {
colorSpace = CGColorSpaceCreateDeviceGray();
} else {
colorSpace = CGColorSpaceCreateDeviceRGB();
}
CGDataProviderRef provider = CGDataProviderCreateWithCFData((__bridge CFDataRef)data);
// Creating CGImage from cv::Mat
CGImageRef imageRef = CGImageCreate(cvMat.cols, //width
cvMat.rows, //height
8, //bits per component
8 * cvMat.elemSize(), //bits per pixel
cvMat.step[0], //bytesPerRow
colorSpace, //colorspace
kCGImageAlphaNone|kCGBitmapByteOrderDefault,// bitmap info
provider, //CGDataProviderRef
NULL, //decode
false, //should interpolate
kCGRenderingIntentDefault //intent
);
// Getting UIImage from CGImage
UIImage *finalImage = [UIImage imageWithCGImage:imageRef];
CGImageRelease(imageRef);
CGDataProviderRelease(provider);
CGColorSpaceRelease(colorSpace);
return finalImage;
} - UIImage型の画像をモノクロに画像処理し，UIImage型で返すメソッド「greyMatFromUIImage」を「ViewController.mm」のUIImageFromCVMatから@endの間に追加する．
参考元：OpenCV for iOSの使い方 #Objective-C #iOS #OpenCV #AdventCalendar #iPhone #画像処理 - Qiita [キータ]- (UIImage *)greyMatFromUIImage:(UIImage *)srcImage
{
cv::Mat srcMat = [self cvMatFromUIImage:srcImage];
cv::Mat greyMat;
cv::cvtColor(srcMat, greyMat, CV_BGR2GRAY);
return [self UIImageFromCVMat:greyMat];
} - ViewController.mmのpushButton内を
- (IBAction)pushButton:(id)sender {と記述する．
imageView.image = [self greyMatFromUIImage:imageView.image];
}
Buttonをタップして1回目はいいのだが，2回目以降はエラーをはいている．
コンソールには，ImageEditor[8970]とでている．CGBitmapContextCreate，CGContextDrawImageといっているから，これらを使用している「cvMatFromUIImage」に問題があるのだろう．この問題については，「cvMatFromUIImage」，「UIImageFromCVMat」，「greyMatFromUIImage」がそれぞれどのように動作しているかについて考えることで解決の糸口をつかもうと思う．: CGBitmapContextCreate: unsupported parameter combination: 8 integer bits/component; 16 bits/pixel; 1-component color space; kCGImageAlphaNoneSkipLast; 2048 bytes/row.
ImageEditor[8970]: CGContextDrawImage: invalid context 0x0
それにしても，記事がものすごく長くなった気がするので，続きはまた．
Xcode4でOpenCVフレームワークを使用したiOS向けアプリ開発の準備
OpenCVを使った，簡単な画像処理を行うiPhone向けアプリケーションを作成する機会があった（というか真っ最中）．前にCore Imageフレームワークを使って遊んだことがことがあったので，技術的にはそんなにつまずくことなくいけるなーとか思ったのだけども，環境構築に随分と手間取ってしまった．なんてこった．ということで忘れないように覚え書きを残しておく．
とてもわかりやすいサイト
秋山ブログ [Xcode4,Objective-C++] OpenCV2.4.1をiOSで使う
すべてはここの通りにすれば万事OK．プロジェクトごとにやらなきゃいけないので少し手間がかかるけども．
C++でコーディングをしなければならないので，Objective-CとC++が混じって変な気持ちになる．そのうち，どうにかする手段を探してみよう．
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック
「リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック」
Dustin Boswell，Trevor Foucher (著者)
角 征典 (翻訳)
須藤 功平 (解説)
今日書いたコードをいじる未来の自分に楽をさせたい人なら，人の感想なんて読んでいないで，本書をすぐにでも読むべきなんじゃないだろうか，とか思わないでもないけど，自分なりにまとめてみようと思う．
本書は最初から最後まで，様々なプログラム言語での例を交えながら，リーダブルコード（＝読みやすいコード）とはどんなものかをわかりやすく伝えてくれる．基本的には，まずリーダブルでないコード（＝読みにくいコード）の例をあげ，そこからどこが問題なのか，どう改善していくのか（時には何通りかの思考法がある），その結果リーダブルでないコードがどうリーダブルになったのか，が1セットになっている．
これのおかげで，リーダブルコードとはどんなコードなのか，どうしていいものなのがよくわかる．隣でプロのプログラマに指導してもらってるってこういうことなんだろうか，とか少し考えたりもした．
さて，本のレビューなんて積もるほどありそうだから，ここで学生チームの開発経験1年ちょっとの駆け出しの私が，特に注目した点に焦点を当てることにする．それは，14章の「テストと読みやすさ」の14.8節「テストに優しい開発」だ．
// 引用ここから学部3年の授業によくある電卓の開発を行う(使用言語はJava，環境はEclipseだった)授業があった．そのときにテスト駆動開発（TDD）というものに初めて出会った．しかし，それからずっとテストが苦手だ．テストがすごい！ありがたい！というのはわかるのだけれど，自分でテストコードを書こうとすると，ううんと頭を抱えて動かなくなってしまう．このプロジェクトは絶対にテストファーストで開発を進めるぞ，と心に決めても，駄目なのだ．結局諦めてテストコードを書かずに手でテストを行ってしまうのだ．
あとでテストを書くつもりでコードを書くと，おもしろいことが起きる．テストしやすいようにコードを設計するようになるのだ！ このようにコードを書いていけば，いいコードが書けるようになる！
テストに優しい設計をすれば，振る舞いごとにうまく分割されて，自然にコードが構成されていく．
// 引用ここまで
本書では，テストファーストはさておき，上記で引用したことに重きを置いていると思う．これまで私は，テストコードを書くことばかり考えていたが，本書のおかげで自分がテストしやすいようにコードを設計すればよいのだということに気付くことができた．
いわれてみれば当たり前のことなのだろうけれど，テストに対する苦手意識は軽減した気がする．明日からはぜひテストしやすいコードの設計に気を使ってみようと思う．
最後に，テストの話に注目をしたが，他にも言語にとらわれない技術を身につけるノウハウがたっぷり詰まっていた．駆け出しプログラマは第1部だけでいいから，必ず読むといい．幸せになれる．まあ，第1部を読み終わった頃には次が読みたくなっているだろうけど．
また，日本語版のみについてくる須藤 功平さんによる解説がリーダブルコードの解説にあるので，興味のある人はこっちもどうぞ．
はじめて本の感想らしきものを書いてみたけど，難しいもんだ．何かつっこみがありましたら，コメントから（優しく）よろしくお願いします．
SyntaxHighlighterをBloggerで使うときの覚え書き
ふと，これから先ソースコードをブログにのせる時がくるかもしれない，と思ったのでその環境を整えることにした．ソースコードの表示方法は色々あるんだろうけども，よくみるこれ，
#import "ViewController.h"Syntax Highlighterを使うことにした．
@interface ViewController ()
@end
@implementation ViewController
- (void)viewDidLoad
{
[super viewDidLoad];
}
- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
}
@end
といっても先人がその方法を残していらっしゃるので，だいたいは同じ．
アプリ開発の記録 SyntaxHighlighterでObjective-Cをきれいに表示
このサイトにそって進め，補足がある部分だけ少し残した．
- SyntaxHighlighterをダウンロード
そのまま． - 解凍してファイルをアップロード
Bloggerにはアップロードできる場所がない．風潮的にはGoogle サイトを使うのがいいらしいので，私はそこへアップロードした．なんだかイマイチ使い方がわからなかったのだけども，適当なサイトを1つ作成，Home直下にファイルキャビネットというテンプレートを用いたページを作成，そこへ1でダウンロードしたファイルをアップロードした． - テンプレートを修正
テンプレートを修正する時は，Bloggerではブログを選択＞テンプレート＞HTMLの編集と進むことで編集することができる．Bloggerはを使うと怒られるので，に修正する． - 記事にコードを埋め込む
そのまま． - Objective-C用brushファイルをダウンロード
そのまま． - 【おまけ】Brushファイルの中身を修正
そのまま．
これで随分コードが見やすくなったけれど，自分的には1行ごとに色を変えたい． クラスをいじればいいんだろうけど，そういえばXcodeの背景はしましまじゃないし，これはまた気になった時にしよう．
