はじめに
株式会社ラクス チャットディーラー開発課のエンジニアRakusMoritaです。
2021年3月26日（金）～3月28日（日）開催のPHPerKaigi2021に、ラクスエンジニア7名が参加してきました。
PHPer（ペチパー）によるPHPerのためのこの大規模イベントは、今年はオンラインでの開催でした。
オンラインでありながらも、豪華な登壇者、絶えず流れるコメント、主催者の勉強になるコントなどなど・・・
お祭り騒ぎのような雰囲気伝わってきて、ワイワイと非常に楽しい勉強会でした。
ラクスは当イベントのスポンサーとして参加させていただいている他、社内から2名が登壇しました。
この記事では、PHPerKaigi2021に参加した社内のエンジニアが、参加したセッションの内容をまとめましたので、ご紹介したいと思います。
各セッションのスライドも用意しておりますので、PHPerな人、これからPHPerになる人は新たな発見があること間違いなしです。
～目次～
3/27（土）
実践ATDD 〜TDDから更に歩みを進めたソフトウェア開発へ〜
report by id:radiocat
ATDDとはAcceptance test-driven developmentの略で、日本語にすると受け入れテスト駆動開発です。アジャイル開発では開発要件をユーザーストーリーとして表現し、それが実現できていることを開発の完了条件として受け入れテストを実施する手法がありますが、 それを駆動型で開発に取り入れるやり方がATDDです。登壇者の現場で考えられている、中心となる2本柱が次の内容です。
四象限におけるQ2を強化する
四象限とは技術面とビジネス面の2軸と、開発チーム支援と製品批評の2軸を組み合わせたもので、Q2はその中でビジネス面と開発チーム支援の領域です。顧客視点の高レベルテストで自動化と手動テストを組み合わせるところがポイントです。
テストピラミッドを登る
テストピラミッドとはユニットテストを土台として、サービステスト、UIテストと上位に階層化したテストレイヤーに分類してテストを概念化したもので、上位のUIテストのほうが重厚化してしまうアンチパターンに陥らないように必要に応じてテストピラミッドを登っていくことがポイントです。
知識的情報だけでもボリュームたっぷりでしたが、さらにPHPで作られたWebサービスを題材としたケーススタディでは、自動受け入れテストツールを使った実践例も紹介されています。ATDDの自動化領域と手動テストとの共存のさせ方、ユニットテストなどのTDDの手法との組み合わせ方などについても語られており、実践に向けた応用方法の示唆に富む内容でした。知識のインプットだけでなく実践に向けたインプットにも役立つボリュームたっぷりなセッションだったので、今後も資料を読み返して現場で実践活用したい内容です。
負荷試験の観点から見るGraphQLにおけるPHPのコードチューニング
report by id:Y-Kanoh
API で利用するクエリ言語である GraphQL は、REST と違い、複数のクエリを1度のリクエストで行うことができます。 そのため、複数のクエリ発行のために何度もレスポンスを待つ必要がなく、 レイテンシは REST と比べて速くなる特性があります。
しかしこの仕組み上、秒間のリクエスト数低下や、短時間に処理が集中してしまいCPU負荷が高くなること、 重いクエリが含まれると全体のレスポンスに影響を与えることなど、デメリットも存在します。 利用時には、取得するデータを絞る仕組みや、複雑すぎるクエリを制限する仕組み、 PHPの場合は処理向上のためのOPCache導入などを行なって、コードチューニングを行う必要があります。その詳しい勘所について説明されていました。
REST との比較を行いながらわかりやすく説明していただけたので、両者のメリットデメリットなども理解できました。 実際使ってみての勘所を説明いただけていたので、GraphQL の導入を考えるかたはぜひ確認していただければと思います。
目的に沿ったDocumentation as Codeをいかにして実現していくか
report by id:Y-Kanoh
開発者がチームに join し、開発を始められる状態になるまでのオーバヘッドを削減する方法が、システムの理解を助けるドキュメントです。
しかし、更新漏れによる誤った理解を防ぐために、ドキュメントはメンテナンスを継続的に行わなければなりません。一方、開発と切り離された運用でのメンテナンスは、システムとの乖離を修正するまでの時間も長くなってしまい、 継続的なメンテナンスも難しくなってしまいます。
そこで、この発表では、システムとドキュメントをそれぞれ情報の集合と考え、 各情報同士が紐づいていない状態が増えることを「システムとドキュメントの乖離が大きくなった」と位置付けることで、 この問題の解決策を探っています。
その方法として、PHPDocなどのように、”システムとドキュメントの間に構造化データを用意し、 その構造化データをもとにドキュメントを作成する方法”や、OpenAPIのように “構造化データを先に用意し、 そこからシステムとドキュメントを作成する” 方法などが紹介されていました。 また、具体的に対策を行うためのツールも紹介されており、 どのような仕組みで対策を行うことができるのか想像しやすい内容でした。
ドキュメントのメンテナンス問題は私自身も思い当たることが多く、 発表内容の前半は胸が痛い内容でした。エンジニアらしく問題の本質を分析し、 仕組みでそれをカバーすることを考えさせられる内容でした。
PHPでCSVを安心して扱うために
report by id:tsudachantan
他サービスとのデータ連携やバルクデータ入出力などで使い勝手が良く、根強く利用されているCSVファイル。
PHPでのCSV処理は癖が強く、一見安全に対応できたように見えて運用面で深刻な問題を抱えることがあります。
現状とその解決方法について丁寧にお話いただきました。
fw3/streams
OSに依存しない安定した入出力と、発生していた問題の根本解決としてライブラリfw3/streamsを紹介されていました。
以下が特徴です。
OSとPHPバージョンの組み合わせに影響されず動作する
安全かつ確実に入出力が可能である
mb_convert_encordingを使った文字セットの変更ができる
妥当な文字セット自動検出が行える
OSに影響されない改行コード出力を行える
変換できない文字があった場合の代替手段を設定できる
ライブラリの説明に沿って様々な環境やパターンを網羅してCSVの扱い方について発表されており、大変勉強になりました。
PHPで学ぶ、セッションの基本と応用
report by id:soachr
以下の章立てで発表されていました。
- 生い立ち
- 技術的な仕組み
- 最低限の周辺知識
PHP以前に、そもそもHTTPでセッションが使われるようになった背景から、現在どのようにセッションが使われているのかまでを紹介された上で、じゃあ実際にPHPはどのようにセッションを実現しているのか、という内容まで紹介されていました。
今までふわっとしていたPHPのセッションについて理解できました。
ログイン機構があるシステムに関わっている方はとりあえずこの発表を聞けば問題ないと思うくらい、わかりやすい＆すっと理解できる内容でした。
新卒時代のときにこの発表に出会っていればもっとスムーズに理解できたのでは...とこの発表で初めてセッションについて学んだ方が羨ましいと思うくらいです。新卒の育成担当をしている身としては、ぜひ学習カリキュラムに入れさせていただきたいと強く感じました。
PHP8になった今の時代に、PHPの「エラー」「例外」そして「Error」をおさらいしておこう
report by id:tsudachantan
PHPには「エラー」を知らせる仕組みがたくさん用意されていますが、それぞれの違いが答えられるでしょうか。
PHPのエラーの扱いはバージョンごとに進化しており、それが混乱する原因にもなりえます。
とにかく不用意に\Throwable、\Errorをキャッチすることは危ない！というメインの主張を。
では、そもそもエラーとは？という説明からお話しされており、納得しながら整理できました。
まだまだPHP歴が浅い自分や、わかっているけど人に説明するのは難しいといった方にも役に立つ内容だと思います。
「Throwable/Error/Exception」についての棲み分けについての認識がクリアになり、効果的な例外の使い方について考える機会になりました。
Discordのチャンネルでも様々な意見が交換されており、チーム開発での意識のすり合わせの大切さを感じました。
Laravel のメール認証の内部実装を掘り下げる
report by id:Y-Kanoh
PHPのフレームワークであるLaravelは、さまざまなロジックが既に用意されており、 メール認証の仕組みも、少しの実装を行うことで、簡単に利用することができます。
しかし、既存のロジックは手軽さのために、拡張性が犠牲になっている部分があり、 独自の仕組みを組み込みたい場合は、内部ロジックを理解した上での改修が必要です。
メール認証の場合、この拡張性を損なっている原因は、App User モデルの責務が多すぎることです。 App User の持っている責務を明確化して、それぞれの依存関係を理解した上で、 分離独立させることにより、拡張性の高いロジックに作り替える方法を紹介いただいていました。
近年、機能が多くなりすぎて批判されることもある Laravel ですが、内部の依存関係を理解し、 責務に沿って作り替えれば上手く付き合っていけることを学べた発表でした。
PHPWebアプリケーションパフォーマンスチューニング
report by id:soachr
パフォーマンスチューニングについて、体系的にかつ具体的に説明されていました。
パフォーマンスチューニングの大原則の考え方である「推測するな、計測せよ」を軸として、どのように再現・計測・原因仮説、からの対策を取るのかを、Webアプリケーションを実現するミドルウェアごとに紹介されていました。
自身もパフォーマンス・チューニングを業務で行っていたのですが、まだ知らない視点や、計測時のコマンド、対策を知れてとても勉強になりました。
パフォーマンス・チューニングをやったことがない人で「なにから初めて何をすればいいのかわからない」方にもおすすめです。
PHP でもアーキテクチャテストしたい！
report by id:radiocat
弊社のリードエンジニア川並がアーキテクチャテストについて発表しました。
コードレビューが機能している状況においても、アーキテクチャ観点でしっかりレビューするのは難しく、開発初期にしっかり検討していた設計方針がいつのまにか泥団子状態ということも起こりえます。
アーキテクチャを維持するために、クラスの依存関係や実装ルールをコード化して自動テストするのがアーキテクチャテストです。
発表ではPHPのフレームワークである deptrac と phpat を使ったアーキテクチャテストの実例がデモを交えて紹介されました。
デモで使われたサンプルコードが以下で公開されています。
アーキテクチャは一度決めたら終わりではなく、アーキテクチャテストがアーキテクチャを育て、進化させていく！という、希望に満ちたまとめで勇気をもらえるお話でした。
3/28（日）
そのコード、フレームワークの外でも動きますか？
report by id:Y-Kanoh
アプリケーションの長期運用には、ビジネスサイド要因による仕様変更の他にも、 フレームワークのバージョンアップ/メンテナンスの終了や、 時代の変化によって利用していたフレームワークが陳腐化してしまうなど、リプレースを求められることがあります。
そのような時に、フレームワークにガッツリ依存したコードになっていると、 大半のコードを書き直す必要が出てきてしまいます。
この発表では、リプレースやリニューアル時に飛型しないために、 チームで作成するコードをフレームワークから分離し、 環境の変化に強いコードを作成する例を紹介していただけました。
発表中には、実際にLaravelで実装されたコードを、 Symfonyに移植するサンプルコードを説明していただき、 具体的にどのような効果が得られるかを体験できました。
また、最後におっしゃっていた、違うフレームワークや、違う仕組み、違う言語など、 「バリエーション」に強いコードにすることで、結果的に保守性を向上させるという考えが、 とても共感できました。
資料の中にソースコードのリンクもあるので興味のある方は覗いてみてください。
無駄な物をなるべく作らないリプレイス戦略
report by id:MasaKu
レガシーソースのリライトについてのお話でした。
リプレイス戦略は以下の段階で難易度が上がっていきます。
- リファクタリング
- リプレイス
- リライト
リライトとは、既存機能を完全に一から書き直すという作業であり、この作業を実施するには、そもそも なぜリライトが必要なのか という課題を明確にして、どのように書き直すかの方針を新たに決定する必要があります。
リライトを始めるには基本的なこととして、現状の仕様を完全に理解する必要があります。 そのための方法は
- コードリーディング
- リファクタリング
- 設計の振り返り
- 実際にサービスを使ってみる
などの方法を行います。
また、実際のユーザと直接対話することも重要です。 サービスが提供している価値はどこにあるのかを再認識するためにも、ユーザストーリーを立てて、本当にリライトが完了するかを見ていく必要があります。
ご発表の中で リファクタリングを限界までしても現状の問題が解決しないと思ったらリプレイス という判断基準をご紹介いただき、とても理解しやすいご説明でした。
なるせ先生のPHP学～PHP8新機能スペシャル～
report by id:Y-Kanoh
PHP8の新機能であるmatch式、NullSafe演算子、Attributeを、某テレビ番組風に紹介していただけました。
- match式
- フォールスルー（brakeがないと次の処理を実行してしまう）がなくて事故が起きにくい
- マッチする条件がないとエラーになるから安全
- 再帰処理で使いやすい
- コードの見通しが良くなる
- NullSafe演算子
- Attribute
また、新機能を単に紹介するだけでなく、その機能の便利なところや、 ちょっとした裏話も共有していただけて、ドキュメントを読むだけでは得られない内容でした。
個人的には、エルヴィス プレスリー が初耳でした。
今こそ理解するDI（Dependency Injection）
report by id:MasaKu
DIについて詳しく再認識させていただけたご発表でした。
というのも、個人的にDIについていろいろと調べていたことがあったのですが、結局これがDIなのかな？
といったぼんやりとした理解だったので、今回のご発表を聞き、少し理解が進んだように感じました。
DIとは保守性の高いコードを書くことを目的とした設計原則とパターンのセットであり、疎結合を実現することを目的としたデザインパターンです。
概念としては、制御の逆転を行い、必要になった時だけ呼び出す、という流れで外部からオブジェクトを使用するようにします。
例えば、メールを送信するメソッドを例にすると、外部から該当のメール送信メソッドを呼び出す際、メソッド内でメール送信オブジェクトを生成してしまうと、そのメソッドはメソッド内で生成したオブジェクトを自由に付け替えることができなくなくなります。
検証のタイミングでは、検証用のメールサーバを利用して、本番ではAWSのメールサーバを利用する、など使い分けをしたい場合、そのメソッド内でオブジェクトを生成してしまうと、コードを修正しなければオブジェクトの付け替えができません。
こういった密結合の状態を回避するのがDIです。
なお、DIの説明がある際にDIコンテナの話も良く出てくるが（フレームワークの標準機能として搭載されている場合が多い）、DIを実現するためにDIコンテナが必要なわけでなく、DIを実現しやすくするための工夫として存在しているものなので、DIコンテナは必須ではないようです。
また、類似のデザインパターンとして、サービスロケーターの話もよく登場するが、目的はDIと同じだが実現する手段がが異なるデザインパターンとのことです。
プログラマ三大美徳を実現するデプロイフローを目指して
rebort by id:Jazuma
www.slideshare.net
株式会社M & A Cloud 所属 @yamotuki さんによるセッションです。
「ベンチャーにおけるプロダクトやチームの成長とデプロイフロー自動化」というサブテーマのもと話が進みました。
(デプロイフローにおける)プログラマの三大美徳
怠惰 ：同じ作業の繰り返しは面倒くさい →自動化したい
傲慢 ：デプロイ手順をミスってエラーになるのはダサい →自動化したい
短期 ：デプロイ作業に2時間もかけたくない →2秒で終われ！
デプロイフロー自動化の歴史
サービス開発当初はデプロイフローが自動化されていませんでした。
開発者の人数が少ないのでやっている時間がない
売上が立っていないので運用フロー効率化よりも機能追加優先
自動化のノウハウがない
自動化文化がない
ユーザーアクセスが少なく、障害発生リスクがない
しかし、サービスが軌道に乗ってくると自動化をする理由が出てきました。
売上が立った
開発者が増えて手動作業だとミスが起こる可能性が大きくなった
デプロイフローそのものが複雑になり手動作業がつらくなる
運用に時間を取られて機能追加もおろそかに
なによりめんどくさことはしたくない！
このような経緯でデプロイフロー自動化が段階的に進みました。
セッションの中で 「プロダクトとチームの成長は自動化と密接に関係している」 と述べられていたのが印象的でした。
エンジニアはつい自動化それ自体が目的になりがちですが、チームやプロダクトがどのようなフェーズにあり、どんな問題を解決するために自動化をするのかということが重要だと思いました。
PHPのDI、attributesとこれから
rebort by id:rakusMorita
DI(Dependency Injection・依存性の注入)とは、簡単に言うと
- Dependency：使われるオブジェクトを
- Injection：使う側のオブジェクトに渡す
ということです。DIについては詳しく説明しませんが、
具象クラス（具体的な実装をしているクラス）との処理の結合を避けて、抽象クラスと処理を結合させることで、変更に強くすることが基本的な考え方です。
注入とは、インスタンスを抽象クラスから作成して動かすというものです。まだ具体的な実装ができていなくてもダミーのインスタンスを作りやすい（モックの作成がしやすい）ので、その結果、実装もそうですが、単体テストなども非常にやりやすくもなります。
DIの歴史とポイント
- DIはJavaから始まった
- PHP5でクラスの機能が強化され、DIっぽいことができるようになった。
- 近年PHPでもDIが標準的な思想として認知されつつある（型指定が当たり前に/interfaceが使いやすくなった/autoloadでrequire不要に等々）
今までの型指定のないPHP的な書き方もできますし、いい意味でJavaっぽさも取り入れた実装もできるようになってきて、PHPは良いとこ取りな言語に進化してきましたね。
APCやOPchaceなどによるコードキャッシュにより、実行速度も向上し、ますますDIがやりやすくなりました。
今時なフレームワーク（Laravel、Symfony、CakePHPあたり）はDIコンテナを持っている（あるいは持とうとしている）ということは、特に意識しなくてもDIを使えるようになってきたと言えるでしょう。
PHPの動向
PSR-11というインターフェイスが普及
異なるフレームワークやライブラリのを使っていても同じように呼び出せるDI用のインターフェイスが使えるようになりました。@Inject（アノテーション）記法が廃止になって#[Inject]（アトリビュート）になった
アノテーションは結局のところPHPDocだったので、文字列の解析になるので重かったのが、 アトリビュートだと言語としてサポートされていて、動作が格段に速くなりました。Autowireという機能
明示的にInjectの必要がなくなり、設定ファイル書かなくても作れるようになりました。
DIがシームレスに使える=意識せずともDIのメリットを享受できるように開発できる
ということですね。素晴らしい。
DIコンテナは今後も自然に広く使われていくことになるでしょう。
DNSを制する者はインターネットを制す！DNSの世界/市川@cakephper
report by id:MasaKu
ドメイン名ハイジャックの恐ろしさについて改めて身に染みたご発表でした。
悪意あるユーザが名前解決先のIPを書き換えてしまうため、ユーザ側としては悪意あるWebページに遷移してしまっていることを認識できません（HTTPSにも対応させることができる）。
また、この問題に気づきにくくする厄介な方法として、常に悪意あるWebページに遷移させるのではなく、10人に1人だけ悪意あるページに遷移させるなどするとより気づきにくくなります。
過去の事象として、名前解決先のIPを返すレジストラの脆弱性を突かれて情報改ざんされ、MXレコードが書き換えられたせいでメールも乗っ取られた、という事件も発生したようです。
この問題はレジストラ側の問題になるため、対策のしようがないため、改ざんを検知したらいち早く対応するなどの運用が必要となります。
また、DNSの歴史についてもご説明がありました。詳しい仕様についてはこの場では割愛しますが、面白かったエピソードとして、お子さんのYouTube閲覧時間制限のために、DNSパケットの解析を行い、アクセス制限を追加したというお話がありました。
DNSのクエリはどのIPの利用者が何時にどのアドレスの名前解決をしたか、という情報が暗号化されずに送信されるため、プライバシー上の問題もあるようです。（お子さんのプライバシーにかかわるため、上記対策は中断したとのこと）
ODoHという仕組みを利用してDNSのメッセージを暗号化することも現在提案されているようです。
新社会人のコード品質カイゼン記録
rebort by id:rakusMorita
ラクスのエンジニアの発表でした。
指摘が多く、コード品質が良いとは言えない状態から、どのように品質をアップさせてきたのかの発表でした。
チェックリストも、コミット前のコードの見直しも色々やってみたところ・・・
目立った効果がありませんでした。しかし・・・！
ペアプロ / モブプロ
これで、大きく品質が向上したようです。
先輩エンジニアの視点や考え方がリアルタイムでわかるので、「どういうところに気を付ければいいのか」などがわかるようになったとのことです。
「ペアプロをしてもらえる環境が素晴らしい」
というコメントがたくさん流れていました。
もちろん、環境も大切だと思いますが、彼の「思い切って先輩エンジニアにペアプロをお願いした」こと。
その勇気が彼の品質向上に繋がった、とても前向きになれる発表でした。
きっとチームにとっても、長い目で見て開発コストを抑えることに繋がるはずなので、ペアプロ・モブプロは忙しい環境こそおすすめです！
あとがき
このPHPerKaigi2021に参加し、エンジニアの生の声を聞き、色々な考え方に直に触れることで視野が広がりました。
エンジニアの方なら、よくググったり、書籍を読んだりすると思うのですが、やはり現場の経験から出た使えるアイデアだったり、調べたこともない知識をインプットできるという点で、このような勉強会は貴重ですね。
皆様のより良いPHPerライフを応援しております。
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
forms.gleイベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！ rakus.connpass.com
