Upgrade to Pro — share decks privately, control downloads, hide ads and more …

プログラミング言語に依存しない、質の高いコードを書く技術

 プログラミング言語に依存しない、質の高いコードを書く技術

PHPカンファレンス沖縄 2021で登壇した内容。

Arakaki Yuji

May 29, 2021
Tweet

More Decks by Arakaki Yuji

Other Decks in Programming

Transcript

  1. 自己紹介 • 新垣 雄志 ( あらかき ゆうじ ) • Twitter:

    @arakaji • 職歴 ◦ 琉球インタラクティブ株式会社 ◦ 株式会社 Payke ◦ CBcloud 株式会社 ← NOW • PHP 歴 ◦ 前職、前前職ともにサーバーサイドで PHP を使っていた ▪ CakePHP ▪ FuelPHP ◦ 現職ではサーバーサイドは Ruby を使っている
  2. なぜこのテーマを選んだか? • PHP は前職まではがっつり使っていたが、現職は主に Ruby で開発をしている • そのため、個人的にいま「 PHP 」特有のテーマがみつからなかった

    • プログラミング言語に依存しないテーマを探した • 現職ではスタートアップあるあるのスピードと成長優先で書かれたプロダクトを引き継 ぎ、コードの保守性なども改善しながらもプロダクトの成長をさらに加速させるための 開発をしている最中 • 「コードの品質」と「プロダクトの成長速度」をどう両立させていくかがテーマ • そこで出会った名作
  3. 質とスピード • 和田 卓人 (@t_wada) 先生の登壇資料 • ソフトウェア開発においてよく言われる「コードの品質を一旦犠牲にしてスピード優先 で開発する」という言葉に対する誤解を解く内容 •

    コードの品質と開発スピードはトレードオフではない • 品質の高いコードを書くことにより、開発速度が上がる • 質を上げながら開発速度も上げるにはどうすればいいか?ではない • 質を上げることによって開発速度を上げる
  4. SQuaREのソフトウェア品質モデル • システム及びソフトウェアの多岐にわたるステークホルダ ( 利用者、発注者、開発者 など ) が持つ多様な品質要求を定義し評価するための基準として定義された国際規 格 SQuaRE

    シリーズ • 品質モデルでは、品質を構成する上位の要素「品質特性」とこの品質特性をささえ る詳細化した下位の要素「品質副特性」を定義している
  5. SOLID原則 • S: 単一責任の原則 (SRP: Sigle Responsibility Principle) ← 着目

    • O: オープン・クローズドの原則 (OCP: Open-Closed Principle) • L: リスコフの置換原則 (LSP: Liskov Substitution Principle) • I: インターフェイス分離の原則 (ISP: Interface Segregation Principle) • D: 依存関係逆転の原則 (DIP: Dependency Inversion Principle)
  6. ボトムアッププログラミング • プログラミング言語を自分たちの開発しているアプリケーションの適する形に変えて いくこと • フレームワークやライブラリを使うのはそれと同じ ◦ Laravel や CakePHP

    を導入することで PHP が Web アプリケーションの開発により適した形に拡張され る ◦ aws-sdk のライブラリを導入することで、 AWS を操作するのに適した形に拡張される • これをもっと小さい単位で、自分たちのアプリケーションコードを書くときにも行う
  7. Driverクラスのtype判別メソッドの定義 • 配送ドライバーには複数種類ある ◦ 軽貨物ドライバー (kei_car) ◦ 一般貨物ドライバー (ippan_car) •

    Driver インスタンスがどのタイプかを判別するた めの is_hogehoge() というメソッドを定義 • 問題点 ◦ DRIVER_TYPE が増えるたびに同じようなメソッドを再 定義しないといけない
  8. NewRelic • NewRelic の APM 、クランド連携、 agent 、ログ収集を行うと問題発生時に以下のよう なことがワンストップできるようになる。 ◦

    エラーレートの可視化 ◦ 発生したエラーのスタックトレースを表示 ▪ どの API( パス ) を叩かれたのかもわかる ◦ そのエラーが発生したときのトランザクション中のログを一覧で表示 • これによって問題発生箇所、影響範囲、原因が非常に素早く把握することができる
  9. 適切なログ出力 • NewRelic で調査しやすくなったとはいえ、適切なログが出力されていないとそこで息 詰まる。 • なにか問題が起きたときに原因調査するための情報があるか?という視点でログ出 力を行う ◦ 本来発生しない例外をキャッチした場合、その内容をエラーログに出力する

    ◦ 外部連携 (SaaS 含む ) をする場合、その Request/Response を INFO ログとして出力する ◦ Web アプリケーション場合 Request のログを出力する (API であれば Response もログ出力する ) ▪ 秘匿情報はマスクするのは前提 ◦ 大きいバッチ処理をする場合経過状況を INFO ログに出力する
  10. テストカバレッジ • ソフトウェアコードのうちテストがなされている比率 ( 網羅率 ) • テストカバレッジが 100 %であれば良いかというとそういう訳ではない。

    コードカバレッジは、コードのテストされていない部分を発見するための有用なツールである。ただテ スト自体がどれだけ良いかという指標としては、テストカバレッジはほとんど役に立たない。 カバレッジの数値がほしい理由はわかる。テストが十分かを知りたいのだ。カバレッジの数値が低い 場合、たとえば 50% 以下の場合は、おそらく問題があるだろう。けれど高いカバレッジの数値にはあま り意味はない。ダッシュボードの数字に意味がなくなる助けをするだけだ。 from: https://bliki-ja.github.io/TestCoverage/
  11. 質の良いテストコードを書く技術 • 3 角測量 ◦ 一つのメソッドをテストするとき、 2 つ以上の実例を持ってテストをする ▪ それによってメソッドの実装の一般化が抽出される

    ▪ ただテストコードの重複によるテスト実行速度の悪化にもつながるので、テストコードを書くとき のフローの中で行うが、実装・テストともに完了したら重複を除去することもある • 欠陥挿入 ◦ プロダクトコードの任意の行の意味合いを変えて、テストが失敗するかどうかを検証する ◦ もし失敗しない場合は適切にテストが書かれていないこと ( 漏れがある ) を示しているのでテストの追 加・修正が必要だとわかる
  12. 参考資料 • 質とスピード〜ソフトウェア開発の典型的な誤解を解く〜 (2020 秋バージョン ) ◦ https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition • つながる世界のソフトウェア品質ガイド

    ◦ https://www.ipa.go.jp/files/000044964.pdf • X 25010 : 2013 (ISO / IEC 25020 : 2011 ) ◦ http://kikakurui.com/x25/X25010-2013-01.html • 開発者が知っておくべき SOLID の原則 ◦ https://postd.cc/solid-principles-every-developer-should-know/ • 単一責任の原則 (Sigle responsibility principle) について、もう一度考える ◦ https://www.ogis-ri.co.jp/otc/hiroba/others/OOcolumn/single-responsibility-principle.html • メタプログラミング ◦ https://ja.wikipedia.org/wiki/%E3%83%A1%E3%82%BF%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A 9%E3%83%9F%E3%83%B3%E3%82%B0