第1回実践iOSアプリ開発モブプログラミング会についてまとめ

春もたけなわで行楽の好季節となりました。@yimajo です。
2018.4.14にiOSアプリ開発をモブプログラミングをする会を開きまして、その報告を書いておこうと思っております。
上の写真は会場のSansan株式会社横にある国際連合大学前です。週末はファーマーズマーケットというのをやってました。

第1回 実践 iOS アプリ開発モブプログラミング会
https://mobproios.connpass.com/event/83871/

この文章は、第2回目を開催した際に、参加を迷う人がこの記事を読むことを想定しています。もしくはモブプログラミング会を開催してみたい人のために何かしら参考になるように心がけています。

モブプログラミング会の概要

iOSアプリとしてTodoアプリをMVP（Model View Presenter）パターンでつくる過程をモブプログラミングしようというのがやりたいことでした。
画面や機能としては

• Todoの登録
• 登録したTodoの一覧
• 登録したTodoの編集
• できればTodoの検索

というのだけを決めていました。なぜMVPにしたかっていうと、RxSwiftなどのライブラリを使ってMVVMにすると慣れてない人はツッコミ入れづらいので避けたほうがいいのではないかと思ったからです。初回なのでベースとなるものでやりたかったというそれです。

会場は表参道のSansan株式会社さんの13Fスペースをお借りしました。土曜日のお昼から大変感謝です。

参加人数

参加人数は次のとおりです

• 応募

• ドライバー枠2人

• ナビゲータ枠5人

• 当選

• ドライバー2人

• ナビゲータ枠5人（3人は補欠）

• 当日実際に参加した人数

• ドライバー1人

• ナビゲータ3人

• イベントの共同管理者1人

もともと少ない募集しかしてませんでしたが、私ともう一人だけでもいれば良いというスタンスだったのでキャンセルは全然問題はないです。ただし、少ないがゆえに connpass 上でちゃんとキャンセルしてもらえないと補欠の人が参加に繰り上がらないのでそこだけは気になるところです。

ドライバーは一人となっていましたが、ナビゲータの2人が順次ドライバーになってもらい、コードを書き進めてくれるのを交代しました。

時間の配分としては

• 14:30にドライバー1がコーディング開始（Todo登録と表示を作る）
• 16:00にナビゲータがドライバーに交代（Todoをdoneにできるようにする）
• 17:30にナビゲータがドライバーに交代（Todoを編集したりリファクタリングする）
• 19:00に終了。懇親会として近場に肉を食いに行きました

昼から夜にかけて時間があったので、およそ1.5時間くらいでドライバー交代していきました。

振り返り

やってて気づいたこと

例えば下記のようなコードの isDone = done ではselfをつけろと言われてコンパイルエラーになります。

class Todo {
    private var isDone = false
    func changeState() {
        action() { done in
            isDone = done // `@nonescaping`でもクロージャがOptionalならここがself.が必須となる
        }
    }
}

// デフォルトでescapingしない。つまり`@nonescaping`
func action(foo: ((_ done: Bool) -> ())?) {
    // このコード自体はサンプルとして無理やりクロージャを使ってtrueにしています
    foo?(true)
}

let todo = Todo()
todo.changeState()

もちろんSwift4.1ではデフォルト @nonescaping なため self が要らないはずなのになぜ?というところがお楽しみポイントでした（現在のSwift 5.5でも検証したら同じ）。

理由としては、((_ done: Bool) -> ())?のようにOptionalにしているからで、それによってクロージャが@nonescapingにも関わらずselfが必要というコンパイルエラーになります。これに気づくまでに問題の切り分けをして試行錯誤していったのが良い体験でした。

おそらく日々コードを書いているとクロージャの引数はOptionalにはせず、カラのクロージャをデフォルトの引数として渡すことが多いので、人がコードを書いているのを眺めてないとこの状況には遭遇しなかったかもしれないです。もしくは日頃の仕事中だとコンパイラの言うとおりにselfを付けてスルーしてたかもしれないですね。

仕事でモブプログラミングをする場合はハマったりすると辛いところだと思いますが、休日に楽しむモブプログラミングではハマって試行錯誤するほうが問題解決を楽しめますので、エラーになることが良いきっかけだったりします。

テストコードで気づくこと

ドライバーが交代して機能追加したりリファクタリングするのですが、ユニットテストが威力を発揮しました。こういうのをちゃんと出来ることも時間があったからだと思います。

• Realmでデータを保存したり読み込んだりするユニットテスト
  • 参加者がRealm知らなかったりする場合などに意味があるので最初にサクッと書きます
• Presenter経由でデータを保存したり読み込んだりするユニットテスト
  • 利用用途に合わせたコードをユニットテストで確認していきました

テストコードはかなり雑に、Xcode初期設定で同梱されるテンプレートのテストコードにメソッドを増やして書くだけで充分だと感じました。

環境をXcode9.3にしたこと

現在はXcode9.3が最新なので、それで進めていたのですが、Xcode9.2ではXcode9.3のワークスペースを開いても認識されなかったようです。別にTodoアプリを作るのに最新じゃなくても良かったかもしれません。多数の人とやるとなると環境を合わせるのが難しいです。あらかじめXcodeをDLしておいて、会場でUSB経由で配布してもよいかもしれません。

一般的なモブプログラミングでは環境を変えずに道具を使いまわすかもしれないのですが、せっかくiOSアプリ開発のモブプログラミングという限定した環境の縛りがあるのでノートのmacを持ってくれば出来るというのを目指しています。

参加率について

やはりどうしても申し込みだけしてキャンセル処理せず来ない人は発生します。そうなると、補欠になってしまって参加したくても来られなかった人がいたら申し訳ないと思います。
対策としては枠を広げるのが良かったかもしれないですが、安易に枠を広げるのは最後の手段なので、参加に対する温度差を分けられたらなという考えがあります。

具体的には

• 「モブ枠3人（積極参加したい勢。もちろんキャンセルするときはキャンセル処理する枠）」
• 「勢いで申し込む枠（もしかしたら行ける勢）2人」

などに参加を分割したほうがいいかなと思います。防ぎたいのは、勢いで申し込みしてそれ以降まったくノータッチにされることなんですが、勢いを否定したいわけではないので参加枠に濃淡を付けておくと良いかもなと思ってます。

事前の自己紹介はしない

よくあるもくもく会とか、事前に自己紹介すると思うんですが今回はしませんでした。

一つ目の理由は時間が勿体無いということ、もう一つの理由は、例えば「いつもは仕事でSwift触ってないんですが...」とかそういう事を発言してしまうと、その場での議論の発言力が弱まってしまわないかというのが気がかりだったためです。発言についてはポジションを気にせず、誰が言ったかよりも、何をどのように言ったかを重視したかったためです。

HRT を最大限に活かした発言をできる人が目立つほうが良いと考えました。否定ではなく提案をする、具体的には「☓そのコードないわー より ◯提案あるんだけど」 っていうのが理想ですね。プログラミングを楽しむための会なので、楽しめるように発言できる人が参加しやすいことがより良いと思っています。

懇親会

終了後に店に行きましたが、Uber Eatsでも良かったかもしれないです。
モブプログラミングした画面を表示しながらご飯を食べるほうが議論の続きがやりやすかったかもしれないですね。

第二回以降のお題

同じようなTodoアプリをRxSwiftを使ったMVVMで作っていくのもいいかもしれないかなと思ってます。
一人でも知っていればどうとでもなるし、前提としてライブラリを使うということを書いておけば、知らなかったらググってから参加するかなと思ってます。
もしくはMVPのままPromise系のライブラリを使うのもいいかもしれないです。async/awaitが使えるHydraが最近気になっています。

その他、通信したほうがより実践的で良いというのも理解していて、GitHub APIで取得したリポジトリをお気に入りに登録していくのもいいかもしれません。

そもそも何故やろうと思ったか

iOSアプリ開発の仕事をしてる中で、自分のやり方がまともなのか、極端な話老害になっちゃってないかというのがあるんですね。老害は自分が老害だと簡単に気づけるものじゃなさそうです。

例えば一人で仕事をしていたり、自分のチームだけで仕事をしてると次第にやり方が楽な方向に流れてしまいがちです。忙しいからとか、技術的負債などの理由によって今までのコードの書き方を考え直す機会を失ってしまって、「自分たちの考えが正しい（他は間違っている）」というような硬直した考えになってしまうのを防ぐほうが良いと思ってます。

インターネットにはいろいろなソースコードもあるし、そこに至る過程や考えが書いてないこともあるけれど、それは前提が違う場合がほとんどです。他には、書いてある事と違うことを自分の都合の良いように解釈したり、逆に悪いように解釈してしまうこともあるんじゃないでしょうか（いわゆる勉強会というものに参加しても同じようなもんだと感じてます）。

アウトプットしている方も全ての前提を明らかに出来ないし、受け取る側が賢く取捨選択するしかないわけで、特に技術的な事に関して、ネットがあろうとなかろうと自分で考えて試していかないと自分自身の能力自体が衰えたり、そのように感じてしまう可能性があるというのを危惧しています。

そういうことの解決として、よそのチームや人とコードを書いていく場を共有するというのがコストが低くて良いのではないかと思ってます。ですので、もし第二回以降があればご参加の検討をよろしくお願いします。