コードを綺麗にする誘惑に君は耐えられるか

tech

try! Swiftのセッションの翻訳を読んで、ちょうど今考えていたことと関連したので、記事にしようと思いました。 https://realm.io/jp/news/tryswift-daniel-steinberg-blending-cultures/realm.io

まだObjective-Cでメンテナンスが続いているアプリもたくさんあるわけですが、せっかくSwiftにしたんだったら、新しいパラダイムも取り入れていきたいですよね。 でも実装スピードを優先するのであれば、それぞれのメンバーが慣れている方法でとりあえず突き進んで仕舞う方がいいと思います。

フェーズ1はとりあえず動く事を優先して、コードはあえてぐちゃぐちゃのまま残す。 そうすればとりあえず期限内に完成して余裕が生まれるはずなので、その隙にガンガンリファクタを入れてスタイルを統一するなり新しい技術を試すなりすればいいと思います。

Swiftは頑張れば頑張るほど綺麗なコードが書けるので、誘惑に負けてしまう人も多いと思います。私がその例です。 SwiftLintを入れてチームのコードスタイルを統一する人もいると思います。私がその例です。 もっと綺麗に書ける！と思ってRxSwiftを導入するチームもあると思います。私がその例です。 しかしあまり綺麗なコードにこだわっていると、一歩一歩が重たくなってしまいます。コードの再利用を考えるのはほどほどにして、とにかくその機能なり画面を完成させましょう。

ただあまりぐちゃぐちゃすぎるとあとでリファクタできなくなるので、開発の早い段階でコードレビューなり勉強会なり開いて意識の統一を図るべきだと思います。 そうすればメンバーの開発スピードが上がってきた頃には、コードレビューが要らなくなると思います。実際いまは、速度を最大限優先してコードレビューはなしにしています。気になったら勝手に見てね、という感じです。不具合や仕様変更があればその人が責任持って直せばいいので。

特に画面遷移の処理を共通化するのは、簡単そうに思えて、そして実装するとなんとなく動くのですが、全体のバランスを取るのが実は大変だったりします。こっちの画面からだと開かないんだけど。。とか、こっちの画面から遷移して閉じたら余計なものまで閉じちゃう！といった問題が起こります。後回しにした方がいいかもしれません。

開発中のプロジェクトは今ちょうど佳境に入っていまして、少し反省も兼ねて今の気持ちを綴ってみました。

ネットには綺麗なコードが溢れていますが、現実のプロジェクトでそれを最初から実現しようとするのは、もしかしたら無理があるかもしれません。現実の状況をよく見極めましょう。 自分のチームに最適な進め方を見つけて、その価値観を早いうちにチームで共有できると、ベストだと思います。

みなさんのご武運をお祈りいたします。