トーク

ソフトウェア開発において、不確実性にどのように立ち向かっていくかは大きな課題です。
PHPerとしては、開発中にいかにコード品質を上げるかといったことは大きな関心で、その一つの規律のとり方としてTDDを実践されてきた方は多いのではないでしょうか。

トークの表題であるATDDは、Acceptance Test Driven Developmentの略です。TDD Cycleよりももう一つ大きなスコープでのフィードバックループをテストによって駆動します。特にアジャイル開発の文脈で「Agile Testing」という一つのテーマ内で紹介されることが多い手法です。

ユニットテスト・コンポーネントテストをカバーするテストによって開発を駆動するTDDに対して、ATDDはよりビジネスフォーカスの強いテストによって開発を駆動します。ATDDの開発プロセスの実践によって、技術レイヤ横断的な製品全体の回帰テストの整備につながり、直接的な顧客価値となる外部品質の明確化・維持・向上が期待できます。

このトークでは次の内容について話します。

• ATDDとはなにか、Example-driven Developmentの考え方
• 前提となる「Agile Testing」の考え方
• ATDDを実践する開発プロセス
• テスト自動実行基盤の構築プロセス・構築例
• ATDDを実現するツール選定とツールを用いた「受け入れテスト自動化」
• エンドツーエンドなテスト構築（APIサービスとブラウザベースサービス）
• TDDからATDDへ、自動化テストピラミッドを登っていく

内容は特定技術の実装からインフラ・CI基盤、開発文化・プロセス自体と多岐にわたりますが、ソフトウェアテストという側面で開発を駆動させるあり方として参考にしていただければ幸いです。

2020年の10月に「Fukuoka.php Vol.32」という勉強会で Laravel Livewire のデモを発表する機会をいただきました。

概ね好評だったのですが、一部の方から
「キモい」
「ヤバイ」
「怖い」
「負荷で死にそう」
「次世代jQuery」

という感想もいただきました。これらの危惧を払拭すべく個人プロジェクトではありますがLaravel Livewireを使用したアプリケーションを作成しました。

作成したアプリケーションを例に Laravel Livewire の使い方、内部ではどのように動いているのか、作成時に気をつけたことなど説明します。

Laravel Livewire は決して怖くはありません！！！！

あるシステムを理解して開発を開始するとき、必要なのはInfrastructure as Codeを含むソースコードだけでは大抵の場合は不十分です。では挙動がわかるようなテストコードがあれば十分かというとそうでもありません。
いわゆる「オンボーディングの効果的な運用」「開発開始までのオーバヘッドの削減（PHPerKaigi2020で発表）」は継続的な生産性向上のためには考えなければならない要素です。
そして、上記を補完するためにしばしばドキュメントが書かれます。

私はドキュメント運用のアプローチとして「コードによる生成を含んだドキュメント運用」に興味を持っています。
私はこれを「Documentation as Code」と呼んでいます。そして、そのような概念はすでに世の中にあり、時として「Documentation as Code」と呼ばれているようです。
例えばPHPDocなどはソースコード自体の構造とアノテーションをトレースしてドキュメントの自動生成を実現しています。
OpenAPIのように構造化されたデータとして情報を記述することでドキュメントと同時にAPIクライアントやの自動生成が実現できている例もあります。 これらはコードによってドキュメントが管理されており、継続的なドキュメンテーションも実現可能です。
さて、ドキュメントと言っても「何を解決するためのドキュメント」なのかを考える必要があると思います。
本発表では、上記のような「Documentation as Code」を実現するツールを独自にモデル化してそれぞれの特性について考えます。
そして、どのような「Documentation as Code」が「開発開始までのオーバヘッドの削減」に繋がるのか、私が実際に取り組んだ（また取り組んでいる）事例を交えて考えていきたいと思います。

令和の世においても根強く利用されるデータフォーマット『CSV』
他サービスとのデータ連携やバルクデータ入出力などで使い勝手が良いため、未だに大活躍しています。

ですが、PHPでは扱うための癖が強く「微妙にダメなのは判っているけど諦めて使っている」「そもそも絶対におかしくなるので編集してから利用、または入れてから編集している」などのつらくきびしい現実がありました。
また、一般的には「変換不能文字があると行ごと無かったことにするiconvストリームフィルタ」や「メモリが枯渇しやすくなるmb_convert_encodingを用いた対応」など、一見安全に対応できたように見えて運用面で深刻な問題を抱える対策が蔓延っています。

このトークではそんな現実と対決し「ダメだと判っていたそれを解決」「そもそもおかしくならないのでゼロストップでデータ入出力」できる方法をご紹介します。

• とある企業でDBAを務めていますが、お手製の監視スクリプトをytkitというスクリプト群としてオープンソースで公開しています
  • https://github.com/yoku0825/ytkit
  • 一番使っているのが監視スクリプトである yt-healthcheck というやつです
• コイツはまあ、Perlで書かれてるんですが、これを見ながら「本職のDBAはこんなこと考えながらMySQLの監視してるんだな」という紹介です
  • いいじゃないですか、変数名の頭に$がつくPで始まるもの同士仲良くしましょう！
  • なお、私のPerlはへたっぴです。監視用のSQLだけは自信があります。

PHPerの皆さんは、日々Webアプリケーションを開発している中で、フレームワークのコードと自分たちのコードを区別できていますか？
自分たちのアプリケーションにとって重要な、業務知識をモデリングして書いたコードは、「いまのフレームワーク」と切り離して動かすことができるでしょうか？

フレームワークのバージョンアップ、あるいはフレームワークの開発終了によって自分たちのアプリケーションの命運が左右されることがないように、フレームワークへの依存を取り除き、大事なコードの可搬性を高めましょう。
ごく一般的な小さなWebアプリケーションを題材に大事なコードを守りつつLaravelからSymfonyにフレームワーク変更する様子を実演しながら、考え方とテクニックについてご紹介します。

人は言います——モジュールを疎結合にせよ、と。
人は言います——具象ではなく抽象に依存して実装せよ、と。

ソフトウェア設計におけるベストプラクティスは異口同音に関心の分離の重要性を説きます。SOLID原則の「D」ことThe Dependency Inversion Principle / 依存性逆転の原則を実装するための道具立てとしてDIコンテナ、あるいはIoCコンテナと呼ばれる仕組みが利用されることがあります。

「PHP DI」などで検索すると、さまざまな説明が読めることでしょう。……御託はわかった。しかし昔の私には問題意識も活用方法も理解できず時間は過ぎ去っていきました。フレームワーク嫌いの私も数年も経験を積み、いくつかのフレームワークに触れてそれぞれの長短がわかってくると「Laravelのこれだけ使いたい」とか「CakePHPのここだけ羨ましい」などと考えはじめるものです。

このトークではPHP-DIに触発された簡易的なDIコンテナの実装方法を紹介し、PSR-18のような外部と通信するインターフェイスを分離しオブジェクトの生成をDIコンテナのオートワイヤリングに任せることで、どのように実装を簡潔にできるかを説明します。発表内容は実装にフォーカスしており、設計原則やソフトウェアアーキテクチャについては言及しません。

今回の発表では以下のコードの実装時に得られた知見を含みます。

• 特定のフレームワークに依存せずPHP-DIを用いてオブジェクト生成とメソッドのディスパッチを行なったWebアプリケーション
  https://github.com/phppg/phperkaigi-golf
• リフレクションを用いてメソッドを動的ディスパッチするライブラリ
  https://github.com/bag2php/meta

トラブルの耐えない決済システムをPHP×Laravelフレームワークでリプレイスするにあたって、どのような課題に対して、どうやって改善したかをお話します。

前半20分は、リプレイス後の決済システムのしくみについて、後半20分は、20万レコード更新を同期処理で実現したことについて、弊社DBAのyoku0825さんと感想戦をします。