backstage

合唱音源の新着情報の舞台裏

トップ > IT > PHPカンファレンス2017でレガシーシステム対応の話を聞いてきた

PHPカンファレンス2017でレガシーシステム対応の話を聞いてきた

IT

※1週間経って資料が多数追加されたので、記事を半分くらい加筆修正しました

f:id:s2terminal:20171008122237j:plain:w300

PHPカンファレンス2017に行ってきました。

phpcon.php.gr.jp

聞いてきたセッション

今回は レガシーなシステムといかに向き合うか をテーマにセッションを選んできました。 なので、選んだのはすべて事例発表セッションです。

似たような題材のセッションを6つも選んだ都合上、近い話が多かったので、どんな話があったのか以下に簡単にまとめてみます。

レガシーなシステムがあると何が悪いのか？

  • セキュリティ が担保されない
  • アプリケーションの パフォーマンス の向上に限界
  • 新しい機能が使えず 生産性 が上がらない
  • 開発に関する 情報収集 が困難になる
  • 技術者が集まらず 採用不利

などなど、数あるデメリットを差し引いても、レガシーコードは残り続けます。 直接的に利益や価値を生み続けているからです。

ならば私たちにできるのは、「レガシーシステムをメンテナンスし続ける」か、それとも「新しい環境に移管する」かの2択になります。

VOYAGEさんのセッションのフレーズを借りると 「コードを自分たちの手に取り戻す」 事です。

コードを自分たちの手に取り戻す

レガシーなコードとは、何を足したら壊れるか分からない、何を引いても壊れるか分からない、 ジェンガ のようなものだと、VOYAGEさんのセッションでは喩えられていました。

  • ソースコードの全体像を誰も把握しておらず、読みづらい
  • 使われていないと思う箇所があるが、消す勇気が無い
  • エラーログがたくさん出ているが、だれも見ていない
  • 開発環境構築方法が確立されていない。たとえば、ひとつの大きなサーバにみんなでsshして開発している
  • KPI改善・機能追加のタスクが常に最優先で依頼されるため、リファクタリングなど品質担保に割く工数が無い
  • テストコードは無いか、メンテされていない
  • 前任者は退職しておりコードの意図は分からない
  • 不具合があるまま長らく放置され、それが仕様になってしまっており修正できない
  • そんなよく分からないシステムだが 動いており、利益を生み出し続けている

弁護士ドットコムさんのセッションの言葉を借りると カウボーイスタイルの開発 です。

プロジェクトのステージによって、考えるべきものは異なってきます。 明日には撤退するかもしれないようなシード期であれば、いかにサービスを良くするか？だけに注力するべきです。

そこから事業が成長するにつれて、後回しにしてきたソースコードの品質、サービスのスケーラビリティ、タスクの優先順位のようなプロジェクトマネジメントの重要性が上がっていきます。 こうなっていくと、 レガシーコードの対処 も必要なフェーズになってくるわけです。

https://image.slidesharecdn.com/20160901awsstartupsecuritytalkshkiriyam-160912001259/95/aws-startup-security-talks-aws-7-638.jpg?cb=1481444401

レガシーコードと付き合っていくために必要な事の例としては

  • レガシーコードを減らす
    • 適切な処理共通化や、地道なgrep等で、不要なコードをできるだけ削除していく
    • Vagrant,Chef,Ansible,Docker等で、開発環境構築を容易にし、ローカル開発可能にする
    • チーム全員にPhpStormを導入して静的コード分析することで、内容の把握できないレガシーコードを極力減らす
    • Redashを入れることで、不要になった管理機能をどんどん削除していく
  • これ以上レガシーコードが増えないようにする
    • git運用フローを決め、コードレビューをルール化する
    • コーディングガイドラインを制定し、ペアプロで浸透させ、チームで生産するコードの品質を向上する
    • スクラムを導入し、適切な優先度判断ができる開発スタイルを確立する

などが挙げられていました。

新しいシステムに移行する

一方で、PHP5系→7系のように、新しいシステムに移行した話も多く聞いてきました。

  • 継続的テスト環境を用意する
    • 簡易でもいいのでE2Eテストを
    • fluentd等でエラーログを収集しリアルタイムで通知できるように
  • リソース(人員、工数)を確保する
    • アプリ担当とインフラ担当の数名で、数か月以上かけて、というチームが多かった印象
    • QAチームがいない場合はチーム全員で検証するための時間を確保しよう、という話も
    • アーリーな事業フェーズではKPI改善や機能追加優先。サービスが成熟して安定黒字を出すようになったら移管の話を
    • パフォーマンス改善などユーザーメリットや、サーバー費用削減のような、具体的なメリットを打ち出す
  • 諦める事を決める
    • レスポンス改善は目指さない、デザインは変えない、deprecated警告は対応しない、など
    • これをしないと、やることが増え続けて何年経っても終わらなくなってしまう
  • 移行する順番を決める
    • HTTPエンドポイント単位やマイクロサービス単位などに分割して、少しずつ移行する。システムすべてを一気に移行することは難しい。
    • 簡単なもの、影響度の少ない部分、行数の少ない箇所から順番に進める
    • パスによってサーバごと切り分ける等で、新旧の両バージョンを同居させる

また、New Relicでアプリケーションをモニタリング するとか、後方互換性を維持し、新旧両方のPHPバージョンで動くようにして同じテストを通す とかは複数の事例で言及されていたので、鉄板の手法のようです。

こういったPHPバージョンアップやレガシーコードとの付き合い方のようなセッションが多く、どのセッションもとても人が集まっていました。 会議室にとても入りきらないので急遽サテライト会場が用意されたり、話を聞いている人たちの反応が「あるある～」といった感じだったりして、「レガシーシステム対応」を課題に思っている人はとても多いのを実感しました。

その他のセッションの資料等については、TECH PLAYやレバテックさんのブログにまとまっています。

聞くことができなかったセッションの中では Docker 系の話が多かった印象です。「レガシーなシステムと向き合うために、開発環境を整えよう」という文脈でも、Dockerが話題に上がったセッションもありました。

その他雑記

PHPカンファレンスはネットが快適でいつも助かっています。

あと、昨年と違って今年はお弁当の販売は無かったようで、昼休憩でちょっと路頭に迷いました。

s2terminal.hatenablog.com

今年は懇親会には行かなかったのですが、懇親会LTには当日申し込み枠が設けられており、すべて埋まっているようでした。

参考文献