Software engineering from east direction

六本木一丁目で働くソフトウェアエンジニアのブログ

Gopher道場#2を卒業しました

Gopher道場#2にお世話になりとても良かったので、実際どういうところが良かったのかなど伝えようということでエントリーを書きます。

Gopher道場#2とは

mercari.connpass.com

conpassのページでは、Gopher道場とは、メルペイが提供する実践的なGoを体系的に学べる場です。という内容で紹介されています。 実際、Gopher道場では週一回の講義&宿題という形で体系的にGoを学んでいきました。

Gopher道場に参加してよかったこと

体系的に学べる

Gopher道場では、@tenntennさんによるGo言語についての講義を受けて、体系的に学ばせていただきました。 個人的にずっとふわふわしていた、構造体やインタフェースなどの概念についてかなり腑に落ちる形で説明していただけました。

実務での経験が盛り込まれてる

書籍では得られない知見として、「業務では実際どうなのか」という話が随所にあったのがとてもありがたかったです。基本的なところでpanicはどういうときに使うのかといったところから、実際にtemplate/htmlを使うのか・Goのtestでライブラリを使うのかなど、実務レベルでどういうやり方をしてるのかについて話していただけて大変参考になりました。

参考URLの共有

講義中、メルペイエンジニアの方がslackで講義内容に関連する参考URLを都度シェアしていただいていました。派生情報として参照して理解を深めることができ大変助かりました。

他のGopher道場生のコード・それに対するレビュー

毎回の講義後の課題に対して他のGopher道場生のコードとそれに対するレビューが見られるのがとても参考になりました。interfaceを使ったうまい抽象化の仕方などをコードを読んで取り入れてみるなど、自分ひとりでやっていたときには得られない知見が得られたのがとても良かったです。

Gopher道場#2 LT大会

Gopher道場後に、道場生によるLT大会が行われました。

mercari.connpass.com

私は、「業務中にサクッと書いたGo製ツールの話」というタイトルで、Gopher道場で覚えたテストの書き方・http.Handlerの使い方なども取り入れつつ実務で活用した話をさせていただきました。

speakerdeck.com

Gopher道場で学んだ内容を、これからのGoコードに活かして実践していくのがとても楽しみです。

最後に

このような時間をいただけて、運営いただいたtenntennさんやosamingoさんを始めとしたメルペイエンジニアの方々には感謝しかありません。 今後、Goコミュニティの発展に寄与できるように頑張っていこうと思います💪

PHPカンファレンス福岡2018本編&前夜祭リジェクトコン参加レポート

福岡・博多にて2018年6月15日（金）に【非公式】PHPカンファレンス福岡2018前夜祭リジェクトコン、2018年6月16日（土）にPHPカンファレンス福岡2018、が開催され東京から遠征参加しました。参加する方が増えれば良いなと思い今回レポートブログを書かせていただきます。

【非公式】PHPカンファレンス福岡2018前夜祭リジェクトコン

今回PHPカンファレンス福岡2018のスピーカー応募率が例年の数倍あったらしく、非公式で本編のスピーカー応募で落選した方が発表する場を用意していただいていました。 connpass.com

会場の様子

前夜祭リジェクトコンは、LINE Fukuokaさんのイベントスペースで開催されました。

f:id:khigashigashi:20180616135827j:plain
LINEさん入り口

f:id:khigashigashi:20180616144305j:plain
LINEさんイベントスペース

セッション内容

「ユニットテストを書きやすくするためにテストスイートを拡張する」

@tenkomaさんより「ユニットテストを書きやすくするためにテストスイートを拡張する」という発表をされていました。assertSameによるdiffを見やすくするなどの拡張の工夫を話されています。

「Docker for Mac の volume mount はどれくらい改善されたのか？」

@kunitさんより、Vagrant・Dockerそれぞれマウント方式を変えた上でどれだけのスピードが出るかというデモ中心のトークでした。

感想

本編に全く引けを取らない密度の濃いトークにでした。前乗りで福岡に来ていてよかったなという内容でした！

PHPカンファレンス福岡2018本編

2018年6月16日（土）にPHPカンファレンス福岡の本編の会場の様子やセッション内容を一部抜粋です。 phpcon.fukuoka.jp

会場の様子

博多駅が最寄りのFFB ホール（福岡ファッションビル）で開催されました

f:id:khigashigashi:20180616144334j:plain
FFB（福岡ファッションビル）

今年はセッション会場が2トラック用意されていました。

f:id:khigashigashi:20180616144408j:plain
セッションホール

スポンサーブースや配布物なども充実していてとても盛り上がっていました。

f:id:khigashigashi:20180616144352j:plain
スポンサー企業の旗

f:id:khigashigashi:20180616144451j:plain
配布物

セッション内容

今回はスピーカー応募が例年の数倍の倍率だったらしく、かなり厳選されたセッションになっていました。実際に聞いたセッションを一部抜粋します。

「何故PHPなんですか？」

Golangを使って見えてきたPHPの良さについての発表でした。Golangを使ってみて、強い静的型付けや標準機能の充実によるメリットを感じつつも、try/catchや継承などPHPで当たり前に使っていた機能がないことなどのデメリットも同時に感じたとのこと。 結果、開発の速さやWeb開発に適しているといったPHPの良さをGolangによって気がついたという発表でした。

個人的には、バージョンアップすることによって得られる新機能の恩恵についても紹介いただいていて、PHP7.3での新機能のキャッチアップがてきていなかったのでありがたい機会でした。 その際に個人的にqiitaで見た記事を関連話題としてシェアさせていただきます。

qiita.com

「ログの設計してますか？PSR3とログ設計の話」

speakerdeck.com

若手エンジニア・中堅エンジニアに向けたログ設計やログ出力のリスクについての話をされていました。ログについて考える上でのPSR-3: Logger Interface - PHP-FIGやRFC 5424 - The Syslog Protocolを参照した上で解説いただいています。 ログ設計について知りたい人がいたときに最初に教えたいと思ったセッションでした。

「SOLIDの原則ってどんなふうに使うの？オープン・クローズドの原則編 拡大版」

speakerdeck.com

phperkaigi2018で発表されたものの拡大版でした。先輩・後輩の掛け合いの形で進めていくトークで、SOLID原則の１つ、「オープン・クローズドの原則」をコードレベルで解説いただいています。

【プラチナスポンサーセッション】ロリポップ！マネージドクラウドを支えるコンテナ技術のすべて

speakerdeck.com ロリポップのマネージドクラウドを支えているコンテナ技術についてのセッションでした。内製されている、haconiwa(https://github.com/haconiwa/haconiwa)や、コンテナ技術について論文として公開されているとのことでした。

rand.pepabo.com

「Testing Live!!!」

www.slideshare.net

VAddy クラウド型Web脆弱性検査ツール - 株式会社ビットフォレスト を題材にしたテスティングライブでした。表記揺れなど整合性が5分間でバンバン指摘されておそらくほぼ全員が自分の携わっているサービスどうだったっけと震えるライブになりました。動画が公開されたら社内に展開したい内容でした！

「ランサーズバージョンアップ報告」

speakerdeck.com

ランサーズさんによるPHP5.3・CakePHP1.3のバージョンアップの結果についてのご報告でした。昨年のPHPカンファレンス福岡2017でバージョンアップを始めるご報告をされていたものの続編になります。

engineer.blog.lancers.jp

感想

明日からやってみようと思える内容が多く、きっかけとしてきてよかったなと思いました。今回は、スピーカー応募落選してしまいましたが、次回は発表する側で参加できるようにしようとモチベーションがあがった2日間になりました！

BEAR.Sunday Meetup #6 に参加・発表内容まとめ

2018/4/28(Sat)に開催されたBEAR.Sunday Meetup #6に参加してきました。

bearsunday.connpass.com

今回は、実際にproduction環境でBEAR.Sundayを採用している実例を中心とした発表でした。発表いただいた内容を個人的にまとめたものを整理したので、気になっていたけど参加できなかったといった方に少しでも雰囲気が伝わればと思います。

そもそもBEAR.Sundayとは

f:id:khigashigashi:20180429133429p:plain BEAR.Sunday

BEAR.Sunday is a framework for creating elegant, truly RESTful API centric web applications in PHP.

https://bearsunday.github.io/manuals/1.0/en/index.html

Tutorialがわかりやすいので、触ってみるのは簡単にできます。

Many web frameworks give you lots of components, modules and features. BEAR.Sunday however gives you just 3 consistent framework patterns into which you can then wire up to your favourite libraries and custom gizmos.

https://bearsunday.github.io/manuals/1.0/en/index.html

RestfulやDI・AOPなどのProgramming paradigmを書いている中でかなり意識するので、既存のMVCを当たり前のように使っている人は一度触ってみるとフレームワークの見方が変わってとてもおもしろいと思います👏

発表内容

実際に登壇された方の発表内容のメモです。 （以下、発表内容と文章の表現が異なる場合はご指摘いただけると・・・。）

Opening Session

BEAR.Sundayの作者である、@koriymさんによる発表でした。

BEARについて

評価について

  • 各人がどういう背景・視点を持っているかが重要、そこがずれると話はずれていく。
  • 分類例
    • RAD(Rapid Application Development):
      • ex, laravel / cakephp / FuelPHP ...etc
      • Downside
        • performance / maintainability
    • Enterprise:
    • Component:
      • micro ...etc
      • micro (framework):
        • エンドユーザーコードに制約を課していないのでframeworkではないという批判もある
        • micro (framework)の作者にもマーケティング用語としての「framework」を使っているという声がある

大きな泥団子

大きな泥だんご (おおきなどろだんご、英: Big ball of mud) は理解可能なアーキテクチャが欠けている ソフトウェアシステム のことを指す。 ソフトウェア工学の視点から望ましくない状態にも関わらず、このようなシステムは事業の圧力、開発者の 刷新 や コードエントロピー などの理由によって当たり前に発生している、アンチパターン の1つである。

PHPの変遷

  • ~4.4: web自体に価値、紙をwebにしただけで価値がある時代
  • 5.2: 早く簡単に（web2.0）、何がいいかわからない時代、早く世にだして受け入れられるかを検証
  • 5.3+: 創造を継続すること：変更可能・品質担保

Developerの成長について

  • OSI参照モデル等と同様にDeveloperにもレイヤーがある。
  • Developer
    • Practice
    • Skill
    • Idea
    • Mindeset
    • Health
  • 「ツールの使い方」などのPracticeよりIdeaやMindsetを重要視すべき
  • そして今回のMeetupはIdeaの話をしたい

その他

Lightning Talk

アドテクの新規事業をBEAR.Sundayで作る実例について

スタートアップを経営されている林さんという方より、新規事業をBEAR.Sundayで作る実例について話していただきました。

  • アドテクの広告効果測定
    • 膨大なデータ量になるが、BigTable等は費用面で現状使わない。しかし、今後シームレスに移行したいと思っている。
    • それもあって、各アプリケーションをPKGにして差し替え容易なアーキテクチャをBEAR.Sundayで実現したいという狙い。
    • 核となるCorePKGが各アプリケーションを呼ぶ構成
      • CorePKGではrouterを書いている、URIをみてどのアプリケーションを呼ぶかをマッピングする
      • 各アプリケーションは全てCorePKGのcompoer.jsonでバージョン管理するためCorePKGをデプロイするだけでデプロイが完了する
  • BEAR.Sundayの特徴としてMicoro Service化するには過剰だが疎結合なアーキテクチャにしたいというシーンで機能しやすい -Micoro Service化する場合はデプロイ等のコストが高いので、6人くらい専任のDevOpsの人員が必要くらいの意気込みがいる

OTOBANKでのBEAR.Sunday実例

@kalibora さんより、株式会社オトバンクにて運営されているaudiobook.jpにてBEAR.Sundayを活用した事例について話していただきました。

  • 選定理由
    • PHPでRestful APIを作る = BEAR.Sunday という社内エンジニアの雰囲気があった
    • くまが可愛い
  • 使ってよかったこと
  • AOP
    • OAUTHの認証処理で使っている
    • @OAuth2\Validate() アノテーションを作り、メソッドインジェクションする
  • swagger-php
    • 実装のために書いたアノテーションなり設定なりコードがそのままドキュメンテーションやSDKクライアントの元になる swagger.json になる
    • bodyにあるオブジェクトを配列にするinterceptorを用意する
      • bodyの興味ではないので、rendererに機能を用意してrendererをinjectするという方法が良い
      • BEAR.Sundayはリソースがrendererを持っている、MVCであればglobalはView classがもっているが
    • swaggerを普通に使うと面倒しているので、改良しちゃってる
      • ただし、メリットがちゃんと出ているかは微妙
      • phpDoc同様、使い続けることが難しい
      • 実際にswaggerが負債になってる事例が会場内で紹介された。

BEAR.Sundayに権限ライブラリを作成(?)して適用してみた

エキサイト株式会社の@poemn_caoさんより、BEAR.AclResourceを作った際の話をされました。

www.slideshare.net

@madapajaさんによる発表

GitHub - madapaja/Madapaja.TwigModule: BEAR.Sunday ModuleというBEAR.Sundayのmoduleを作られている@madapajaによる新規事業をBEAR.Sundayで作るお話でした。

  • 新規事業
    • 複数のサービス間連携を想定。
    • サービス層によってフレームワークは分けている
      • presentation層：Laravel/React
      • API: BEAR.Sunday
      • DB等
  • 構成の自由度、アプリケーションの合成という観点でBEAR.Sundayは魅力的。
  • 使った結果感じた問題

Symfony Configコンポーネント統合例の紹介

エキサイト株式会社のkuma_nanaによる「Symfony Configコンポーネント統合例の紹介」という話でした。

www.slideshare.net

The Birth of FormalBears

@iteman (Atsuhiko Kubo)さんによるこれから作るフレームワークについての話をしていただきました。

www.slideshare.net

Varnishの利用

https://spur.hpplus.jp/にてVarnishを活用する実例についてでした。

  • cacheの制御
    • ttl cache
    • cache無効化
    • rankingやrecommend・動的に異なるものをどう扱うか
  • varnishの活用
    • vmod_key
      • pageの構成要素をキーとして渡す
  • BEAR.SundayでVarnish用にxkeyヘッダを追加するモジュール

Web Page = GLUE + SPEC

@koriymさんに実装のアイデアの発表でした。

Skyの@mackstarさんによるリモートLT

Skyにいらっしゃる@mackstarさんによるリモートでの発表でした

感想

BEAR.Sundayはチュートリアルやって一度@koriymさんに教えていただいたものの、実際にアプリケーションを作ってはいなかったのですが、それでも普段MVCフレームワークを使っていて意識しにくいアーキテクチャについての実例や議論はとても勉強になりました。（と同時に、アーキテクチャレベルの議論に参加できない自分のレベルに落ち込みつつ😓） また、個人的には会場での議論の際にでた「フレームワークを作る側」の捉え方についての話がとても参考になったので、引き続きのOSS活動に活かそうと思います。

Go Conference 2018 Spring に参加してきた

2018年4月15日に開催されたGo Conference 2018 Spring に参加してきました。

gocon.connpass.com

会場は、日本橋にあるCybozuさんのイベントスペースで行われていました。

セッション内容

セッション内容と登壇者の一覧は、@cia_rana さんという方がまとめてくださった、Go Conference 2018 Spring セッション一覧 · GitHubもがとても見やすいので引用させていただきます。

また、セッション内容に関連するリンク集を、@pei0804 さんがまとめてくださってます🙏 tikasan.hatenablog.com

以下、自分が聞かせていただいたセッションの感想を一部、簡単にまとめます。

Testing with microservices in merpay

メルカリの中でもメルペイという決済サービスをgo+gRPCで実装した際のテストの話をされていました。

所属している会社にてECの決済部分を主に担当しているため、「どうやって決済をgoで実装しマイクローサービスで安全に出すか」という関心事に引っかかってとても参考になりました。
「決済をやることの難しさ」・「人類が正しく実装するのは難しい」という話とともにそれをどうテストしていったかという話でした。
なので、「ミスできない」環境でマイクローサービス化に一歩進まないという状況にいる方には手がかりになる内容だなと思いました。

How to write Go code

eurekaのCTOの@kaneshin さんによる「どういう考え方でgolangを書いていけばいいか」というテーマで、主にどのように公式ドキュメントを活用していくかという話でした。
走り書きのメモを以下に載せておきます。

持ち帰りたい大テーマ

  • 言語思想：「愚者は経験に学び、賢者は歴史に学ぶ。」
    • 作った人たちの思想を公式ドキュメントから学んでいく
  • リソースの最大活用：公式ドキュメントを最大限活用する

golang公式ドキュメントの読み方

GoらしいAPIを求める旅路

@lestrratさんによる、「GoっぽいAPIをどう書くか」という話でした。

www.slideshare.net

具体例として、https://github.com/cenkalti/backoff をどうGoっぽいAPIに変えていくかという話で、変えた結果をhttps://github.com/lestrrat-go/backoffに上げていただいています。

コードジェネレートとの付き合い方

@pei0804 さんが作成されているコードジェネレータについての話でした。twitterでやり取りさせていただいた方を初めて生で見たという感動が個人的に有りました。

www.slideshare.net

力強くOSSを自分で作っていった課題と解決の話がとても面白いです。

さいごに

Goの実践の場を増やして発表側になれるように改めて頑張ろうと思います。

PHPerKaigi 2018で「レビューをもらいやすい細かいプルリクの切り分け方」というLT登壇して得られたこと

今回のPHPerKaigi 2018では、「レビューをもらいやすい細かいプルリクの切り分け方」というタイトルでLTに登壇してきました。

本記事では、今回登壇して得られた知見・良かったことを共有します。読んでいただいた方に次のPHP ConferenceでLT登壇してみようかなと思っていただければいいなと思っています。

PHPerKaigi 2018とは

phperkaigi.jp  PHPerKaigi 2018は今年初開催のPHPエンジニアのカンファレンスです。 TrackA・Bの2つレーンがあり、TrackAがトーク、TrackBはコミュニケーション中心の企画が行われていました。

f:id:khigashigashi:20180311162427j:plain
TrackAの様子
  トークが1レーンだったこともあり、みなさんレベルの高い厳選されたトーク内容でした！また、TrackBで行われた「Interactive Round Table」というコミュニケーションの場等もとても盛り上がっていました。

LT内容

今回LTで発表した内容は、「レビューをもらいやすい細かいプルリクの切り分け方」という内容でした。

普段、やっている人は無意識のうちにやっているけどそれに対するノウハウが無いなと感じていたので、改めて整理したという内容です。 発表中は、皆さんアルコールが入っていたこともありとてもあたたかい空気の中の発表になりました。

f:id:khigashigashi:20180311181830j:plain
LT登壇中

得られた知見

大した内容じゃないと思っていてもネタになる

特に今回のような大きなカンファレンスでは技術的難易度の高い内容を話さないといけないと思いがちだと思うのですが、そうでもないということを改めて感じました。 実は整理しきれていない領域であったり、抱えている悩みを解消する話は、自分にとっては大したことがないと思っていても他の人にとっては良い知見になる可能性があるなと思います。

最初の30秒

プレゼンテーションの話になりますが、今回のLT登壇者に共通していたことは最初の30秒で会場の空気を作っていたことかなと思います。
自分ができていたかはわかりませんが、もし次のPHP ConferenceでLTをしてみようと思う方は、最初の30秒を場の雰囲気に合わせてみたり一個前のトークの内容を引用してみる等をしてみるといいかもしれません。

良かったこと

知見が整理される

発表資料を作る過程で、自分の頭のなかにあることを整理してアウトプットする必要があります。 その過程で、自分自身の知見・方法論として整理されます。

twitterで一方的に知っていた方と話す勇気になった

twitterで一方的に知っていた有名人の方に話かけれない自分を、スピーカーTシャツが押してくれました（笑） おかげで、話してみたかった方と話す事ができて、PHPerKaigiのテーマである、コミュニケーションが出来たなと思います。

話しかけていただけるとっかかりになる

そもそも普段人見知りな私は、知らない人に話しかけるということ自体の難易度が毎回高くてイベント出不精です。 ただ、登壇して発表すると大変ありがたいことに参加者の方から話しかけていただけるので、人見知りな方におすすめです。

最後に

金・土と開催されたConferenceでしたが、これまで参加したカンファレンスの中で一番主体的に楽しめた魅力的な内容でした。 PHPerKaigi 2019も楽しみにしています！

レビューをもらいやすい細かいプルリクの切り分け方

はじめに

コードレビューにおいて、新規機能開発をしているとどうしてもプルリクが大きくなってレビューコストが高くなると思います。 「小さくプルリクを出せ。」と言われても具体的な考え方が整理された知見は少ない気がしています。 小さいプルリクに切り出す考え方について、私自身が先輩エンジニアにレビューしてもらう際に意識していることをこちらにまとめます。

また、PHPerKaigi 2018のLTでの発表内容の詳細になります。 phperkaigi.jp

プルリクに関する前提

本記事は、Gitホスティングサービス(GitHub、BitBucket等)における、「Pull Request」や「Merge Request」をプルリクという言葉で表現しています。

PHPerKaigi 2018の発表資料

目次

  • 「大きい」プルリクとは
  • 大きいプルリクがなぜ悪いのか
  • なぜ大きいプルリクが生まれるのか
  • どうやってプルリクを小さくするか
  • 小さくしきれないプルリクはどうすればいいか

大きいプルリクとは

大きいプルリクの実例

githubのPull Requestを用いて2つ例をあげます。差分が何千行もあったり変更ファイルが大きいものがざっくり、大きいプルリクだと呼ばれたりします。

f:id:khigashigashi:20180305200224p:plain

Files Changed: 39 Diff: +4,571 -1,676

f:id:khigashigashi:20180305200234p:plain

Files Changed: 3,448 Diff: +3,94 -748,338

上記のプルリクを分解してみると、下の図のように様々な要素が含まれているケースが多いです。

f:id:khigashigashi:20180305201035p:plain

この図をベースに大きいプルリクがどういう特徴があるか見ていきます。

「大きい」プルリクの3つの特徴

  1. 複数機能が含まれている
  2. ついでの実装が混ざってる
  3. 一機能の実装コードが膨大

f:id:khigashigashi:20180305201212p:plain

f:id:khigashigashi:20180305201328p:plain

f:id:khigashigashi:20180305201420p:plain

大きいプルリクがなぜ悪いのか

影響範囲が大きくなる

大きいプルリクには、複数機能・複数観点が含まれます。そのため、プルリクが通ったとしても複数機能の影響範囲を一回のリリースで見ることになります。 また、一機能だけだとしても既存メソッドの修正が複数あればそのメソッド使っている箇所全てが影響範囲として動作保証しないといけません。 結果として、大きければ大きいほどあなたのプルリクをリリースした際に問題が発生する可能性が高まります。

レビュワーの負担がかかる

レビュワーは、あなたが書いたコードをリリースしても良いのか・問題は起きないか・もっと良い書き方ができる箇所はないかという視点でチェックしてくれます。 大きいプルリクの場合は、影響範囲が大きくなるのでそれだけレビュワーの使う労力・時間が肥大化します。

問題がないことを説明する難易度が高くなる

大きいプルリクだと、影響範囲が大きいためそれに対してどのように動作保証をするのかという説明はかなり難しいです。それを、一回のプルリクで説明してレビュワーに理解してもらうのは現実的ではありません。

なぜ大きいプルリクが生まれるのか

結論から、たくさんの要素を一気にやろうとすることが理由です。上の「大きい」プルリクの3つの特徴で見たとおり、複数の要素を一つのプルリクに詰め込んでいくことでサイズが大きくなっています。

どうやってプルリクを小さくするか

小さい要素に切って細かくリリースする 大きいプルリクの特徴が生まれる理由は、一回のリリースで一気にやろうとすることにあります。小さい様子に切って細かくリリースしていきましょう。

小さい要素に切っていくために以下の4つのSTEPを踏んでいきます。

  • 1: スコープを定義する
  • 2: スコープ外を切り出す
  • 3: スコープ内を細分化する
  • 4: スコープ内から切り出す

STEP1: スコープを定義する

f:id:khigashigashi:20180305202952p:plain 機能開発・改修するにあたってゴールが無いことは基本的にはないですよね。ここのをしっかり抑えることで、何がゴールに必要で何がついでかを明確に区分することが出来ます。

例）「新規決済手段をリリースする」というゴールの場合、新規決済の注文処理=必要、既存決済部分のリファクタリング=ついで、と区分できますよね。

STEP2: スコープ外を切り出す

f:id:khigashigashi:20180305203017p:plain 「ついでに」やったことはリリースゴールに関係ないので、今回の「プルリク」に必要はありません。 プルリクを分けて事前リリースの対象になります。 ただし、リファクタリングした後のコードに対して、リリースゴールに必要な実装を施す場合は「やっぱりセットじゃないと」という思いもあるかもしれません。 その場合は、リファクタリングのプルリクを別に切り出しておいて、リファクタリングをしたブランチをリリースゴールのブランチにマージして下さい。 一瞬だけプルリクは大きくなりますが、リファクタリングのプルリクが事前にリリースされることによって本流ブランチの差分からは外れるので結果としてプルリクは小さくなります。

STEP3: スコープ内を細分化する

スコープ内を細分化するには、スコープ内にも先に出しておける機能がないかを見極めることが大事です。 切り出せる対象は、既存の振る舞いを変えないものです。 例えば、新規モジュールを作って利用するのであれば最後のプルリクでやらなくても事前にリリースできますよね。

以下、切り出せる単位の例を記します。

例1: 新規クラスの場合

新機能を実装するにあたり、新規クラス・メソッドの実装、既存クラス・メソッドの修正のどちらかになるかと思います。 新規クラス・メソッドの実装であれば、呼び出しが行われないので事前にリリースしても大丈夫なケースが多いですよね。

例2: 既存クラス・メソッドの修正

既存クラス・メソッドの修正の場合は、 - 既存処理の振る舞い（特にI/F）を変える場合：呼び出し元の修正とともにセット - 既存処理の振る舞いは変えない：単体でリリース可能

STEP4: スコープ内から切り出す

依存関係の整理にて、切り分けた単位がそのままプルリクになります。事前リリース可能対象をどんどんdevelopmentにマージしていきましょう。 その際に、ただし機能ごとではなくクラスごとのリリースになるので、テストコードがセットになっていることが理想です。 また、レビュー済みの事前リリースが住んでいるのであれば、参照元のメソッドがレビュー済みな状態で次のコードのレビューを開始できます。

小さくしきれないプルリクはどうすればいいか

上記の方法でやっても、どうしても小さく出来ないことはあります。例えば、「新規決済の実装」という場合は、注文・キャンセル・配送・与信延長等、決済フローが1セットで1機能です。さすがに注文だけリリースするけど配送は後でということは出来ませんね。 その場合は、コードの差分を「どん！」と渡してもレビュワーは正確にあなたのコードを見きれません。レビュワーに伝える努力が必要です。

トピックブランチの活用して要素ごとにレビューを出す

トピックブランチは、案件専用ブランチです。実装している機能に対してトピックブランチを用意します。 このトピックブランチに対して、要素ごとに派生ブランチを切ってプルリクを出すことが有効です。 f:id:khigashigashi:20180309020709p:plain 例えば、「新規決済の実装」であれば、注文部分を実装したプルリク・キャンセル部分を実装したプルリク・配送部分を実装したプルリク・与信延長部分を実装したプルリクをトピックブランチに出してそれぞれレビューしてもらいます。 そうすることで、レビュワーは要素ごとにレビューをすることができるため、細かい点までレビューする事が可能になります。

コミット単位で要素を分ける方法もありますが、レビューコメントがもらいにくいため、機能実装のレビュー記録・進捗が見えにくい点があります。 やっておいたほうがいいことは、派生ブランチはマージ後に削除しておいたほうがブランチがきれいに保たれるので良いです。

自分の書いたコード以外で発生する差分はそれだけで一コミットにする

不要なライブラリの削除やライブラリのgit管理下に置く場合は、それだけでかなりの差分になります。この差分に対して自分が書いたコードを混ぜた暁には埋もれます。 あなたの書いたコードを探すこと自体でレビュワーはゲンナリです。自分の書いたコード以外で発生する差分は明確にコミットを分けるようにすることが有用です。

例、git管理下のライブラリを削除してcomposer installする

また、余計な変更が混ざっていないことを可視化するためにプルリクエストの説明内に下記のようにgit statusの出力をgrepした結果を載せることも有効です。

$ rm -rf app/Vendor/aws
$ git status | grep -v app/Vendor/aws
On branch development
Your branch is up-to-date with 'origin/development'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)


no changes added to commit (use "git add" and/or "git commit -a")

その他参考になる資料

techracho.bpsinc.jp qiita.com

PHPerKaigi 2018にて「レビューをもらいやすい細かいプルリクの切り分け方」というタイトルでLT登壇します。

PHPerKaigi 2018という3/9(金）・3/10(土)に行われるカンファレンスでLT応募し採択いただいたので登壇いたします。

PHPerKaigi 2018

phperkaigi.jp

PHP界隈で有名な方々が登壇されたり、「Interactive Round Table」というトピックごとの相談会も用意されていてとても中身の濃いカンファレンスになりそうな予感で楽しみです。

 

LT内容

  • タイトル：

レビューをもらいやすい細かいプルリクの切り分け方 | PHPerKaigi 2018

  • 内容：

コードレビューにおいて、新規機能開発をしているとどうしてもプルリクが大きくなってレビューコストが高くなると思います。「小さくプルリクを出せ。」と言われても具体的な考え方が整理された知見は少ない気がしています。
アーキテクチャ（MVC）・改修/新規/バグ等の軸で小さいプルリクに切り出す考え方について、私自身が先輩エンジニアにレビューしてもらう際に意識していることを話せればと思っています。

 

公式twitterの方にもご紹介いただきました。

 

私はそんなにハートが強いエンジニアではないので、自分よりPHP歴やサービスを触る歴が長い人に見てもらって、見逃している影響範囲がないかチームでチェックしてもらいたいと思ってます。

また、リリース単位となるプルリクエストが大きければ大きいほど、リリースの影響範囲が広範囲に渡って怖い。

なるべく自分の目と説明能力が届く範囲の影響範囲にプルリクエストのサイズを保ちたい。

そういった背景の元、色々試行錯誤した結果「こうした方がいいのでは」という話をさせていただこうと思います。

最後に

まだ、絶賛チケット販売中なので、ぜひ皆さん参加いたしましょう、、、！

passmarket.yahoo.co.jp