属人駆動開発

少々面倒なことが起きた。
今年からあるプロジェクトに週３程度で参加していたが、リードエンジニア、というかその人がずっと一人で開発してたんだけど、急遽退職することになり現状のシステムの保守+iOS/Androidの開発が宙に浮いてる。

でさっきこんなものを読んだんだけど、まじで属人性をなくす必要性を感じてる。
http://blog.qiita.com/post/74997115585/increments-dev-team-culture?utm_source=qiita&utm_medium=header

railsでできたアプリは確かに設計は綺麗だし、ruby/railsに深い理解があるんだなーというのがわかるのだけど、逆によくわからないメソッド拡張やDSLが多く、当然それらのドキュメントはないので黒魔術コードを読む必要がある。

それに無駄にsolrとか非同期処理が多いので、よくわからないエラーが出てもマジで対処法がよくわからない。
ビジネス上の仕様もまだちゃんとわかってないので、これでエラーが解決してるのかとか、そもそもデバッグどうすればいいのとかが多い。

そしてスペックは存在しない。。。

その人が一切辞める気がないならテストなくてフィーチャーの開発に注力するのはいいんだろうけど、マジでテストないとこういうとき辛い。僕は日頃からテスト不要開発を推奨してるけど、それはかなり個人的な最速を求めたときの話であって、会社でやるプロジェクトでは書いてほしい。テスト不要開発とか言って前にやったプロジェクトは1000exampleくらい書いたし。。。

で、今のプロジェクトは僕はずっと続ける気はないしフリーランスなので、なるべくエンジニアの交換可能性が高いまま維持できて、かつアジャイルでいうベロシティが高水準に維持できるような、そういうワークフロー的な俯瞰が可能なプロジェクトにできればと思う。

すごい矮小化した言い方をするとテストを書いてドキュメントを整備しましょうということなのだけど、もう少しいうとプロジェクトのステージに見合ったコードを書きたい。

というのは、例えば検索ならsolr, 非同期ならsidekiqみたいな発想はスケールした時には正しいアーキテクチャ構成だろうけど、実際問題月間PVが1000万くらいまでなら余裕でどっちも要らないと思う。あるいはmoduleがすごく深いnamespaceにあったり、middlewareレベルの拡張、このへんは設計として正しいかどうかと、あとから入る人が読みやすいかが全く別物であることを意識していないと危険だと思う。

この件をある知り合いのエンジニアに話したら、「ライブラリ開発者とアプリケーション開発者の違い」的なことを言っていて、なるほどなーと思った。