ブログサービス JUGEM でサーバサイドエンジニアの川島慧です。社内では @barie という名前で活動しています。 JUGEMは13年間続いてきたブログサービスです。そのコードは長い時間の蓄積とともに老朽化していて、かつそれを見直すこともないまま続いてきました。そのため数多くの問題を抱えており、ちょっとした施策を実施するのにもかなりの工数がかかったり、リリースしてから大量のバグが発見されるような状況が慢性的に続いていました。 今回は私がそんな問題をどう捉え、どう考え、どう改善して行ったのか、その活動内容を整理して全3回の記事にまとめていきたいと思います。その中で同じような問題にぶつかっていらっしゃる方に少しでも参考になるようなものがあれば幸いです。 JUGEMというサービス 前述の通りJUGEMは2004年2月から13年間続いているブログサービスです。実現技術はほぼPHP（一部Perl

こちらは前回の記事からの続きとなっております。 前回「上と下から同時に攻める」という方針を掲げ、そのうち上から攻める（アプリケーション全体で保証される仕組みの整備）の部分の改善をこの記事でご紹介していきます。 上から攻める 1. Composerを導入する アプリケーション全体で保証される仕組み作りにおいて最重要項目がComposerを導入することだと考えています。Composer自体が昨今のPHP開発においてほぼ必須のものになりつつありますし、なにより外部から優れたコードを入手して既存のコードと置換することで既存の問題の多くを解消できるようになります。 Composerの導入はPHPバージョン数さえ満たせていればすぐ出来ますし、導入方法は散々世に溢れている情報なので特には触れません。 2. HTTPリクエスト/HTTPレスポンスのクラス化 WebアプリケーションとはHTTPリクエストをI

こちらは前回の記事からの続きとなっております。 第1回の記事で「上と下から同時に攻める」という方針を掲げ、そのうち下から攻める（既存のロジックの切り出し）の部分の改善をこの記事でご紹介していきます。 下から攻める 1. 外部ライブラリをComposer管理へ移行 JUGEMの既存のコードの問題として、ダウンロードしてきた外部ライブラリ（主にPEAR）があちこちに配置され、どこまでが自分たちのコードでどこまでがそうではないのか分からなくなっている問題がありました。まずは自分たちで管理すべきコードのみが残るように外部ライブラリを整理していきます。 こちらは全ての外部ライブラリを根こそぎ調査してバージョンの特定を行い、Composer管理へ移動できそうなら全て移動していきました。 こちらの内容はYAPC::Asia Hachioji 2016 mid in Shinagawaにて発表した資料があ