Pull Request を見なおして開発をスピードアップする試み ~レビューをしないという選択肢~

こんにちは。 コベリンの @numa08 です。

コベリンには3人のエンジニア (@numa08, @mironal, @ryohey) がいて、動いているプロジェクトがいくつかあり、うち複数人で回しているものが4つあります。

内訳は

  • iOS/Android版feather
  • 新期開発中の自社サービス
  • 新規開発中の受託サービス

となっています。

それぞれのプロジェクトでは Pull Request を通してコードや進捗の共有、品質の向上を目指しています。

しかし、多くのプロジェクトがそうであるように、 Pull Request を軸にした開発フローでしかも人数が少ないとなると「待ち時間の発生」というボトルネックが生まれます。

「待ち時間の発生」に対するアプローチはチーム毎に様々な方法があると思います。「様々な方法がある」ことを認めた上で「ケース・バイ・ケース」で判断するという方向に舵を切ってしまうと、どうするべきかの判断の基準が人によって異なったり、また決断をすることによってメンバーにストレスがかかることが懸念されます。

そこで、プロジェクト毎にどう言った方法が適切なのか、どうするのがベストなのかを調査し、話し合い、「Pull Request のレビューを行うのか」あるいは「行わないのか」を定めたルールを試験導入することにしました。

今回は、試験導入することになった方式を紹介します。

レビューをやるのか/やらないのか

iOS版/Android版 feather の場合

  • コードレビューをやるもの
    • 全てのソースコードの変更
  • コードレビューをやらないもの
    • 依存ライブラリのアップデート
    • typo の修正

twitter 非公式クライアントの feather は Android版はリリースをしてからそろそろ1年、 iOS版は2年以上経ちます。いずれもソースコードの量も多く、変更が及ぼす影響はどうしても大きい物になってしまう可能性を秘めています。

そのため、コードの変更を行った場合は Pull Request の作成とレビューの実施を絶対に行う物としました。ただし、依存しているライブラリのバージョンを上げるだけの変更や typo を修正するだけの場合は Pull Request を作るものの、コードレビューの依頼はせず、変更者本人によるマージの後、 slack などを利用して変更を行った事をメンバーに通知します。

また、 Clashlytics を利用しているので、依存ライブラリのバージョン変更による見た目や挙動の変更確認はコードを見なくてもベータ版を誰かにインストールしてもらうことで確認可能です。

そういった理由から「基本的にコードレビューは行うものの、小規模な修正と考えられるライブラリのアップデートや typo の修正はレビューは行わず、マージ後に周知をする」としました。

新規開発中の自社サービス

  • コードレビューをやるもの
    • 変更者の主観で「不安だ」と感じた物
  • コードレビューをやらないもの
    • 全部

現段階でリリースをされていない新期開発中サービスについては、レビューを実施することよりも速く開発をしてリリースをすることを優先したいと考えています。ただし、その前提として、 Issue を利用して設計をいつも以上に詰めることや、他のサービスと連携をする I/O 部分について変更が必要となった場合はメンバー全員に周知をすることとします。

そのため、「基本的にコードレビューは行わないが、設計については細かく共有し変更の通知をすぐに行い、早期のリリースを目指す」としました。

新規開発中の受託サービス

  • コードレビューをやるもの
    • 不安なもの
  • コードレビューをやらないもの
    • 全部

こちらも未だリリースされていないサービスのゼロからの開発のため、自社サービスと同じ仕組を導入します。また、実は開発がスタートしてから1ヶ月近く経ちますがこの方式で問題は出ていません。 Issue を利用した情報共有や設計の共有が行われているからだと考えられます。

まとめ

コベリン社内でコードレビューの実施を行うかどうかのルールを決定し、試験導入することにしました。こういった大切なルールはやはり昔ながらの「紙に印刷して眼につくところへ貼り付ける」が有効だと思うので、早速印刷をして貼り付けました。

f:id:numanuma08:20160808230133j:plain

今後、この試みがうまく言っているかどうかを検証する必要があります。開発効率の向上を検証することは難しいといえますが、幸いにもコベリンではイテレーションを作ってベロシティを計測する手法が確立しているため、それによる計測が行えるはずです。

「Pull Request を作ってコードレビューを行いマージをする」という、 開発フローは一見メリットが多いようにも思えますが必ずしも全てのプロジェクトについて万能であるとは言えません。我々は常に今までの当たり前を見直すことが求められていると言えますね。

なお、この試みを行った結果についてもブログで紹介をする予定ですので、しばらくお待ち下さい。

引越ししました

こんにちわ。 コベリンの山口です。

先日の記事でもお知らせしましたが、池袋に引っ越しをしましたヽ(•̀ω•́ )ゝ✧

2016/7/16(土)はコベリンが池袋に引っ越した日として何処かに永遠に刻まれることでしょう。

以前のオフィスとは違って広いのでこんなことや

こんなことをして楽しめます。

f:id:mironal:20160719152530j:plain:w480

まだダンボールが散らばっている状態ですが、これからおしゃれな感じに内装をアレコレする予定です(早速ディアウォールを買いました)。

こちらが例のリストです。

引越しします

どうもこんにちは。 暑さも厳しい季節になってまいりました。 亀山です。

弊社は今度池袋西口に引越します!立教大学の近くです。 またマンションの一室ですが、今より少し広くなるので業務が捗りそうです。 おしゃれな内装を目指して、色々想像中です。

ところでブログをWordpressからはてなブログに引越しました。 Wordpressは自由度も高く慣れていて良かったのですが、使い方に合わせてプラグインをいっぱい入れたりテーマを自分で作ったりした分、管理も面倒になって古いままになり、更新頻度も落ちていったのが問題でした。 はてなブログにはWordpressのインポート機能もあり、有料プランで独自ドメインも使えるのと、株式会社ネクストさんもはてなブログだったなぁと思って引越してみました。

引越しが終わったらまた写真でも載せます! それではまた。

Android 版 feather 進捗20 #feather_android

スクリーンショット 2016-02-29 11.36.03

Android 版 feather 開発担当の @numa08 です。

皆様こんにちは😎

コベリンでは先日、名刺のデザインを刷新しました。実はメンバー毎の背景のデザインが違うので、もし交換をする機会があれば、見比べて貰えると楽しいです。

さて、Android 版 feather の進捗ですが、 esa にまとめていますのでご確認ください。

イテレーションまとめ

ここでは上記のまとめをふまえて、メンバーの所感を書いていきます。

numa08

ギャップに関する実装を始めたのだが、調査の部分が多いのでリリースに結びつかないのがちょっと歯がゆい。仕方ないので、空いた時間を使って fastlane でビルドとかリリースをする仕組みを作った。以前より CI 環境の管理が手軽になった感じがして良い。

mironal

タブ編集画面のissueに手をつけ始めたが、 issue の粒度が荒かったためバーンダウンチャートに作業の進捗が反映されなかった。もっと細かい粒度で issue を作り進捗が反映されるようにしたい。

ryohey

見た目の修正に慣れてきてできることが増えて楽しいです。今回あまり時間がとれなかったので、次回からそろそろ機能の実装にも加わっていきたいと思います。

Android 版 feather 進捗19 #feather_android

IMG_0428

Android 版 feather 開発担当の @numa08 です。

皆様こんにちは☺

休日を1日挟んでの金曜日ですので、なんとなく体がダルかったりしますね。

そんなこんなで19回目のイテレーションが終了しましたので、その成果を報告します。

前回から、バーンダウンチャートや toggl のレポートは esa.io にまとめるようになったので、そちらを確認してみてください。

イテレーションまとめ

ここは、上記のまとめをふまえてのメンバーの感想を書いていきます。

numa08

いい感じに Realm に慣れてなかった頃の負の遺産を消し去ることができつつあります。この調子で、内部のデータをより使いやすい物に切り替えていって、開発のスピードを上げていきたいですね。

今回は、 @ryohey がUI周りの機能追加を行ってくれたので、ベータのバージョンアップとかを見ているのが楽しかったです。

mironal

iOS 版が忙しくて Android 版の作業は特に何もしなかったけどレビューは優先した。

ryohey

前回のイテレーションの振り返りで作った、自分にアサインされている issue の一覧のページを開くコマンド yarukoto で毎朝やることを確認しながら作業していました。 今回は Android 版に注力したので、UI 的に気になっていた部分をどんどん直せました。 内部の実装も分かってきたので、今後は開発を加速してバリバリカッコイイアプリにしていこうと思います。

Android 版 feather 進捗18 #feather_android

IMG_0465

Android 版 feather 開発チームの @numa08です。

皆様、あけましておめでとうございます。なんて、もう2月ですが・・・。

年が明けてコベリンでは書き初め会を行ったり、初詣に行ったりしました。今年も良い1年にしたいですね。

さて、2016年最初のイテレーションが終了しましたので、その成果の報告を行います。ただ、今回からバーンダウンチャートの結果や toggl のレポートは、弊社で最近使い始めたドキュメント管理サービスのesaにまとめていますので、そちらを参照してください。

続きを読む

エンジニアのためのオープンな slack チームを作りました

feather 開発チームの @numa08 です。

コベリンは以前より開発体制や内部組織をオープンにする活動を行ってきました。この度、その一環として、 slack のチームを作りました。

slackのアカウント作成フォーム

チャットでは、 feather の開発に関することや開発環境のこと、あるいは全く関係ないコベリンで流行っていることについて適当に会話をしています。

興味のある方は、軽い気持ちで参加をしてみてください。