このエントリーをはてなブックマークに追加

条件分岐禁止とは言ってもガード節は書きたい?

PHPerKaigi本編で 設計力を上げる!バリエーションの見極め術 を発表した直後、懇親会であるPHPer茶会で「条件分岐禁止について」という枠が急遽設けられて、駆けつけて話した際に「条件分岐禁止の趣旨はわかるがガード節は書きたい」という意見をもらいました。

ガード節とは

ガード節とは、引数がそのメソッド・関数の処理する対象として合っているかどうかをメソッド・関数の先頭でチェックするif文です。通常、マッチしない場合は例外を投げるか、early returnにより処理から抜けます。
ガード節は一般に良いプラクティスとされており(防御的プログラミング)、質問者の方もガード節を良いものという前提に立った時、私の言う条件分岐禁止はそれに反しないか気にされたのでしょう。

ガード節と条件分岐禁止

さて、PHPerKaigiの発表スライドではほぼ割愛しましたが、私が想定している条件分岐禁止を守って書いたコードは下記のような感じです。
※ スライド中では良い例としてappのコードのみ示し、詳細は 昨年の@hidenorigotoさんのスライド を見てください、と口頭で言いました。

appのコード

$targetDate = new \DateTimeImmutable('2019-05-02');
echo $wareki = $warekiProviderResolver->resolve($targetDate)->provide($targetDate); // 令和1年5月2日

Resolverのコード

<?php

class WarekiProviderResolver
{
    /**
     * @var WarekiProviderInterface[]
     */
    private $providers;
    
    // ...
    
    public function resolve(\DateTimeInterface $targetDate): WarekiProviderInterface
    {
        foreach ($this->providers as $provider) {
            if ($provider->supports($targetDate)) {
                return $provider;
            }
        }
        
        throw new \LogicException(sprintf('No matching WarekiProvider found for date %s', $targetDate->format('Y-m-d')));
    }
}

そして令和のためのWarekiProviderがこんな感じ。(平成、昭和、大正…それぞれの元号についてWarekiProviderInterfaceを実装したクラスを作ります)

<?php

class Reiwa implements WarekiProviderInterface
{
    public function supports(\DateTime $targetDate): bool
    {
        return $targetDate->format('Ymd') >= 20190501; 
    }
    
    public function provide(\DateTime $targetDate): string
    {
        // ★ここにガード節書きたい?★
    
        $year = (int)$targetDate->format('Y') - 2019;
        
        return sprintf('令和%d年%d月%d日', $year, $targetDate->format('n'), $targetDate->format('j'));
    }
}

先ほどのガード節は必要だと主張された質問者の方は、おそらく下記のような使い方がされることを危惧されているのでしょうね。

<?php
$targetDate = new \DateTimeImmutable('2018-04-30'); // 平成の年月日
$warekiProvider = new Reiwa();

echo $warekiProvider->provide($targetDate); // 令和-1年4月30日

質問された方には、「各クラスResolverでresolveする使い方を想定していると周辺のクラス構成からわかるときは、別にガード節を書いておかなくても誰も変な使い方をしないだろうから、ガード節は書かなくても問題ない」とお答えしました(契約による設計)。
少なくともカルテットでは文化としてこの書き方が浸透していますし、必ずコードレビューをするので、ここにガード節が必要とは考えたこともなかったです。
が、このような変な使い方をしてしまうメンバーがいて、それをレビューで止めることができない環境であれば、ガード節を書くこともやむを得ないのかもしれない、と考えていました。

nazonohito51/dependency-analyzer

PHPerKaigiのLTで @nazonohito51 さんが nazonohito51/dependency-analyzer というライブラリを発表されました。
dependency-analyzerは静的解析を用いてプロジェクト内のクラス間の依存グラフを出力したり、ルールに沿った依存のみが書かれているかバリデーションしたりすることを通じて、単方向依存を実現しやすくする・設計の意図をプロジェクト全体で共有することを目的としたツールです。(詳細は @nazonohito51さんのスライド をご覧ください)
LTを聞きながらこのライブラリを使えば前述の質問者の方が危惧されていた変な使い方はCIで検出できると思ったので、早速使ってみました。

使い方はとても簡単です。
composer require –devで追加して、使い方を限定したいクラス(今回の場合は Reiwa )に @canOnlyUsedBy をdocコメントとして書き込み、CIでdependency-analyzerのチェックコマンドを追加実行するよう設定するだけです。
設定済サンプルが下記にあります。

https://github.com/77web/DependencyAnalyzerUsage

dependency-analyzerで想定外の使われ方を防ぐ

CIにdependency-analyserを設定しておくと、Resolverで使うことを想定されたクラスが変な使い方をされてしまった場合には下記のようにCIが落ちます。

phpdoc in Quartetcom\TryDependencyAnalyzer\Wareki\Min
+------------------------------------------------+-----------+----+---------------------------------------------+-----------+
| depender                                       | component |    | dependee                                    | component |
+------------------------------------------------+-----------+----+---------------------------------------------+-----------+
| Quartetcom\TryDependencyAnalyzer\WrongUsageApp | other     | -> | Quartetcom\TryDependencyAnalyzer\Wareki\Min | phpdoc    |
+------------------------------------------------+-----------+----+---------------------------------------------+-----------+
The command "./vendor/bin/analyze-deps verify ./src" exited with 1.

https://travis-ci.org/77web/DependencyAnalyzerUsage/jobs/522931490

CIが落ちたらマージしない、という簡単な判定で想定外の使われ方を確実に防ぐことができるようになりました。

まとめ

カルテットは世界一効率的な広告代理店を目指しており、開発部のみならず社内全体で人の注意力より道具・仕組みの力でミスを防ごうとする雰囲気があります。
新しい道具も積極的に使って、よりメンテしやすいコードを書いていきたいですね。


このエントリーをはてなブックマークに追加

はじめに

こんにちは、@ttskch です。今日はちょっとした小ネタで、以下のツイートの焼き直し記事です :hand:

伝えたい内容はこのツイートでほぼすべて言い終わっているのでこの記事を書く意義はかなり謎ですが(笑)、一応細かいところを軽く補足しつつ記事の体裁にしてみようと思いますので、よろしければ最後までお付き合いください :joy:

※ GitHubを使っていることを前提とした内容になっていますのでご了承ください :pray:

WIP-PR駆動開発とは

WIP-PR駆動開発とは、開発の最初にWIP(Work In Progress:進行中)な状態からPull Requestを作ってしまって、そこにどんどんコミットを追加しながら開発を進めていく開発スタイルのことです。

開発の途中経過がGitHub上で可視化されるため、チームで開発している場合の情報の透明化に一役買ってくれます。もちろん一人での開発にも使えます。

WIP-PR駆動開発のやり方

基本的には以下のような流れで行います。

  1. ローカルでmasterから開発用のトピックブランチを切る
  2. そのブランチに git commit -m "[ci skip] wip" --allow-empty などのようにして空のコミットを追加
  3. とりあえずこの空のコミットをGitHubにpush
  4. GitHub上でmasterへのPull Requestを作成
  5. ローカルで開発を開始(最初のコミットは git commit --amend で空コミットと結合する)

「まだ何も開発してない状態でPRを作って、それから開発を始める」というのがポイントですね。

※ 空コミットのコミットメッセージに書いた [ci skip] はCircleCIやTravis CIなどのCIサービスでビルドをスキップさせるためのキーワードです(参考: CircleCI / Travis CI

めんどくさい

やってみると分かりますが、ブランチを切る度に空コミットを作ってpushしてGitHubのWeb UIでPull Requestを作って、という作業はまあまあめんどくさいです :dash:

そこで、一連の作業をシェルスクリプトで自動化してしまいましょうというのがこの記事の主旨です :muscle:

hubコマンド

シェルスクリプトを書く前に、お使いのマシンに hub というコマンドをインストールしておいてください。これは、GitHubの操作をコマンドラインで行うためのGitHub公式のCLIツールです。

https://hub.github.com/

このコマンドを使ってシェルスクリプトからPRを作成します。

hubコマンドには色々な機能がありますが、hub browse で今いるプロジェクトのGitHubリポジトリをブラウザで開いてくれる機能だけでもめちゃ便利なので、WIP-PRしない人もとりあえずhubコマンドは入れておくことをお勧めします。

hubコマンドの利用にはGitHubの認証が必要

hubコマンドを使うためには、当然ながらGitHubの認証が必要です。

ユーザー名とパスワードでも認証できますが、2FAを設定している場合は毎回2FAトークンの入力が必要になってしまうので、GitHub上でPersonal Access Tokenを発行して設定ファイルに記入しておくのがお勧めです。

https://github.com/settings/tokensGenerate new token というボタンからトークンを作成できます。スコープは repo だけでOKです。

作ったAccess Tokenを ~/.config/hub というテキストファイルに以下のようにユーザー名と合わせてセットしておけば、それ以降特に意識せずに認証ができます :ok_hand:

github.com:
- user: user_name
  oauth_token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

gitのサブコマンドは自作できる

ところで、gitコマンドのサブコマンドは簡単に自作できるということをご存知でしたでしょうか。

やり方はとても簡単で、 git-hoge といったファイル名の実行ファイル(シェルスクリプトなど)をパスの通ったディレクトリに置いておくだけです。こうしておくと、 git hoge のようにハイフンなしでそのコマンドを実行できます。

というわけで、今回はシェルスクリプトを git wippr というgitのサブコマンドとして実行できるようにしてみます。

実際のシェルスクリプトの内容と使い方

では、いよいよ実際のシェルスクリプトの中身です。(最初のツイートでネタバレしてますが笑)

#!/bin/sh

# 第1引数の文字列をブランチ名としてブランチを切る
git checkout -b $1

# 空コミット
git commit -m "[ci skip] wip" --allow-empty

# push
git push -u origin $1

# hubコマンドを使って、第2引数の文字列をタイトルとしてPRを作り、作られたPRをGoogle Chromeで開く
# ※ macOSでGoogle Chromeがインストールされている場合の例です
hub pull-request -m $2 | xargs open -a "Google Chrome"

これを /usr/local/bin/git-wippr に保存して、以下のようにして実行可能なパーミッションを設定すれば完了です :ok_hand:

$ chmod u+x /usr/local/bin/git-wippr

使い方も見たまんまで、masterブランチにいる状態で

$ git wippr branch-name "PRのタイトル"

という感じで実行すれば、 branch-name という名前でブランチが切られて、そのブランチからmasterへのPRが PRのタイトル というタイトルで作成され、Google Chromeで自動的にPRの画面が開かれます。

なんて便利なんでしょう :tada:

番外編

シェルスクリプトの中に

# hubコマンドを使って、第2引数の文字列をタイトルとしてPRを作り、作られたPRをGoogle Chromeで開く
# ※ macOSでGoogle Chromeがインストールされている場合の例です
hub pull-request -m $2 | xargs open -a "Google Chrome"

という箇所がありましたが、この方法だとリポジトリに PRのテンプレート がセットされている場合にもそれは適用されずにdescriptionが空のPRが作成されてしまいます。

これを回避する代替案として、上記の箇所を以下のように書き換えることもできます。

# hubコマンドを使って、標準のブラウザでGitHubのPR作成画面を開く
hub compare

この場合、git wippr コマンド実行時にPRのタイトルまで決めてしまうことはできなくなりますが、その代わりに、PRテンプレートが反映されたdescriptionが入力された状態のPR作成画面が開かれます。(PRのタイトルも、作成画面であとから入力することになります)

個人的には最近は個人開発でしかWIP-PRを使っておらずPRテンプレートとかほとんど使ってないので先述の方法をご紹介しましたが、チーム開発メインでPRテンプレートを多用する方は、こちらの方法のほうが便利かもしれません。

コマンド名を変えて2つとも作っておいて使い分けるという手もありますね。

おわりに

というわけで、140文字で書けることを長々と記事にしてお送りしました(笑)

ご自身の好みに合わせてカスタマイズしたりしつつ、ご活用いただければ幸いです :raised_hands:


このエントリーをはてなブックマークに追加

こんにちは。下田です。

Symfonyで開発していると必ず触ることになる、services.ymlについて。
最近ですが、このservices.ymlに記述するだけで実現できてしまう機能が意外とたくさんあることを知りました。
今回はそれらの機能について、どんなものがあるのか調べてみました。

(以下、Symfony4.2での記述です)

services.ymlでできること

インジェクションいろいろ

まずは基本、 あるオブジェクトを他のオブジェクトに注入したい時に書く方法です。

コンストラクタインジェクション

基本形の argumentsです。
コンストラクタ引数の変数名をkey、実際に渡すオブジェクトをvalueに書きます。

services:
    App\Service\MessageGenerator:
        arguments:
            $logger: '@monolog.logger.request'

セッターインジェクション

コンストラクタではなく、setterメソッドを使ってオブジェクトを注入する時のyamlの書き方です。
callsを使うと任意のsetterを呼ぶことができます。
(※実際、setterではなくとも任意の関数をcallできるようです。用途がぱっと思いつきませんが:thinking:

services:
    App\Service\MessageGenerator:
        calls:
            - method: setLogger
              arguments:
                  - '@logger'

省略形で以下のようにも書くことができます。

services:
    App\Service\MessageGenerator:
        calls:
            - [setLogger, ['@logger']]

参考:https://symfony.com/doc/current/service_container/calls.html

また引数に@?を使うと、 注入したいオブジェクトがcontainerにない場合は無視する という書き方もできます。

services:
    App\Service\MessageGenerator:
        calls:
            - [setLogger, ['@?logger']]

上記の例では、 @loggerのインスタンスが存在しない場合はそもそも setLogger()がcallされません。

参考:https://symfony.com/doc/current/service_container/optional_dependencies.html#ignoring-missing-dependencies

@?でオプショナルにできる機能はついさっき先輩に教えてもらいました。多謝:pray:

タグによる自動注入

symfonyの開発を進めていると tags: ['twig.extension'] とか tags: [{name: form.type }] などなど、tags:を書くことがあるかと思います。

あれは特定タグのつけられたオブジェクトたちを、まとめて別のオブジェクトに注入する働きがあります。

(例えば、tags:['form.type']を付けられたものは、ここらへんでまとめて注入処理をしているようです)
参考:https://symfony.com/doc/current/service_container/tags.html

また、symfonyに最初から用意されているタグ以外にも、オリジナルのタグを作って好きなオブジェクトにまとめて注入することもできます!

services:
  app_sample.foo:
    class: App\Sample\SampleFoo

  app_sample.bar:
    class: App\Sample\SampleBar

  # ...

  App\SampleResolver:
    class: App\SampleResolver
    calls:
      - ["addSample", ["@app_sample.foo"]]
      - ["addSample", ["@app_sample.bar"]]
      - ["addSample", ["@app_sample.baz"]]
      - ["addSample", ["@app_sample.foo2"]]
      - ["addSample", ["@app_sample.foo3"]]
      # ...
      - ["addSample", ["@app_sample.foo100"]]

これが

# config/services.yaml
services:
  app_sample.foo:
    class: App\Sample\SampleFoo
    tags:
      - "myapp.sample"

  app_sample.bar:
    class: App\Sample\SampleBar
    tags:
      - "myapp.sample"

  # ...

  App\SampleResolver:
    class: App\SampleResolver
    # 大量のcallsが減ってスッキリ!

こう書けます。

具体的な方法は弊社記事に詳しい説明があります。
前述のcalls:をたくさん書かなければいけない場面に遭遇したときなどにオススメです :smiley:

遅延読み込み

実際にはめったに使われないのに、他のインスタンスの初期化に必要なため毎回インスタンス化しなければならず、しかもインスタンス化すると重くて困るようなオブジェクトやサービス(例えば、処理失敗の時だけ必要なloggerや、外部APIクライアント等)に遭遇したことはありませんか?

そういったオブジェクトには lazy: trueを付けることで、そのオブジェクトが実際に必要になるまでインスタンス化を遅らせることができます。

依存関係が複雑になってくるとインスタンスの生成順序なども問題になってきますが、そんな時でもlazy:オプションで実際のインスタンス生成を後回しにすることで解決できるかも知れません。
参考:https://symfony.com/doc/current/service_container/lazy_services.html

Factoryパターン

あるクラスを直接インスタンス化せず、ファクトリを利用してオブジェクトを生成したいときがあります。(同種のインスタンスがたくさん必要なときや、インスタンス生成手順に複雑な処理が必要なときなど)

そんなときはファクトリクラスを作ると思うのですが、services.ymlでもファクトリクラス名とメソッド名を記述することで、ファクトリを使ったインスタンス生成を利用できます。 factory: を使います。

例えばこんな感じでファクトリクラスを作った場合、

class NewsletterManagerStaticFactory
{
    public static function createNewsletterManager()
    {
        $newsletterManager = new NewsletterManager();
        // ...
        return $newsletterManager;
    }
}

services.ymlの記述はこんな形になります。 keyに生成したいクラス名を書き、生成に使うファクトリクラス名とメソッド名を factory:に記述します。

services:
    App\Email\NewsletterManager:
        factory: 'App\Email\NewsletterManagerFactory:createNewsletterManager'
        # 配列でも書けるが、古い書き方
        # factory: ['App\Email\NewsletterManagerStaticFactory', createNewsletterManager]

上記はファクトリメソッドがstaticの場合ですが、そうでない場合でもファクトリクラス自体を先にインスタンス化しておけば普通に使えます。

services:
    # 先にファクトリをインスタンス化して、サービス登録しておく
    App\Email\NewsletterManagerFactory: ~

    App\Email\NewsletterManager:
        factory: 'App\Email\NewsletterManagerFactory:createNewsletterManager'

参考:https://symfony.com/doc/current/service_container/factories.html

まとめ

以上、個人的に便利でスゴい!と思ったものや、実際に使っているものを羅列してみました。
services.ymlの記述を工夫するだけで実現できてしまうことが思いの外多くて驚きでした。

また今回、それらの機能について調べることで、背後にある有用な設計パターンについてもたくさん知ることができました。
設計の引き出しをたくさん増やしておけば、「何だかうまくいかないな…」と思った時でも、ひらめきが生まれるかもしれません :bulb:

今回紹介した機能は公式のサービスコンテナのドキュメントにまとまっていますので、皆様も是非services.ymlについて調べてみて下さい!
https://symfony.com/doc/current/service_container.html#learn-more