とある事業の脱レガシー
TRANSCRIPT
とある事業の脱レガシー～技術的負債を取り戻すプロジェクトの物語～
時は201x年、数年に渡る大規模リニューアルプロジェクトを経て立ち上がった新サービス。
しかしその正体はなんと、10年前のPHP入門書を読んだプログラマーと、20年間SQL以外書いたことがないDBエンジニアの手による、MVCもバージョン履歴もない動的ページの山だったのです。
そこに偶然現れたある平凡な助っ人PHPエンジニア...
やがて彼は、データセンターにはWebとDBの2サーバーしか存在しないのに何故かテスト環境があるという、次なる衝撃の事実を知るのでした...
…って導入を考えてたんですが、トリを務めるとか予想外! ちゃんとしなきゃ…
なんかいろいろ中途半端ですみません
たなかひさてる @tanakahisateru
Pinoco developerPHPTAL contributorFirebug translation contributorYii framework userPhpStorm user
フルスタックエンジニア(笑)
レガシーとは
単に下手なだけのプログラム ≠ レガシー
レガシー (Legacy) 1. 遺産，遺贈(財産)
2. 受け継いだもの，遺物
• なぜか置き換えできずに古いまま残されたもの
• まったく役に立たなければ単に捨てられるだけ。何らかの恩恵があるから存在する
古いとわかっているのになぜ置き換えられないのか
• より良い代替物を開発できない
• どうして動いているのかわからない
• 既存の設計が無駄に複雑すぎて、全ての知識を吸い上げきれない
• 作りなおして失敗するよりはそのまま使うほうが安全だ
魔術的 ブラックボックス
どうやったら 置き換えられるのか
• 再現性のある設計/プロセスに変換する
• 属人化せず、論理的な推論の連続で仕組みを成り立たせる
• 絡み合うレガシー部分に引きずられず、一気通貫に進める
科学的 多くのエネルギーが必要
•レガシー = 魔術
•リプレース = 科学
レガシーシステムの デメリットを明確にする
魔術的なものの多くは次の2つに分類できます:
• 科学で置き換え可能なもの …(a)
• 科学的に考えると実は無駄 …(b)
(a) は本質的に必要(b) が保守工数を圧迫すること = デメリット
例
この変数 $hoge は200行前に if でこれが入るかもしれないし、そうでなければその前の行の初期値で…
ってものすごい検索とスクロールですよね、心折れますね
$hoge = 0; if ($fuga > 100) { $hoge = 1; }
// この間200行
echo $hoge;
例この変数 $hoge は200行前に if でこれが入るかもしれないし、そうでなければその前の行の初期値で…
ってものすごい検索とスクロールですよね、心折れますね
$hoge = $conditionalContext->getHoge();
• なんで200行もステップ解析しなきゃなんないの?
• 目視で見落としない?
• これどう考えても無駄だよね
• 手続きを宣言(AはBである)に変換する!
$hoge = $conditionalContext->getHoge();
「保守プログラマーは複雑な手続きを解析するのが仕事だ」という思い込みの蔓延 = 魔術的概念しかなかった時代の信仰形態、あるいは、これまで信仰を集めてきたものは変えられないという諦め
脱レガシーとは、この組織的な思い込みモードから脱却することである
(注: フィクションです)
うっかり「私の経験では」とか言っちゃうかもしれませんが、これはフィクションです。いいですか、フィクションですからね。
全4編•第一話 プログラミング
•第二話 開発プロセス
•第三話 インフラ
•最終回 人事
• A社 = 開発/サーバー設備を提供、委託先
• B社 = 事業会社、発注元
• P氏 = とあるPHPer
B社にP氏がジョインしました。
第一話 プログラミング
B社「このまえ依頼したフォームの改修どう?」
P氏「この2000行でいちどもfunctionを見かけてませんね」
B社「あー、全機能だいたいこの調子で組んであるよ、これ」
index.php
画像はイメージです
P氏「ああああーっもう今回改修する機能、実装はぜんぶ作り直します」
B社「え、すごく手間かかるんじゃない?」
P氏「自分、まだ正社員じゃないですよね。てことは工数オーバーしても個人事業主の未請求扱いですよね。B社的には、動作保証さえしてれば、工数リスク関係ないですよね」
<?php reruire __DIR__ . ’/../src/bootstrap.php’; MyApplication::create()->run(MyController::class);
index.php
MyController
MyService
index.phtml
models*
create
access
use
render
<?php require __DIR__ . ’/../src/bootstrap.php’; MyApplication::create()->run( MyController::class, );index.php
view.php
edit.php
<?php require __DIR__ . ’/../src/bootstrap.php’; MyApplication::create()->run( MyController::class, ‘view’ );
<?php require __DIR__ . ’/../src/bootstrap.php’; MyApplication::create()->run( MyController::class, ‘edit’ );
※.htaccessとか書けませんからね
• 今やっておかないと将来の自分にとって都合が悪い
• だからやる
• この判断が、物語のはじまりとなった…
事業会社と受託開発は 違うという読み
売上 → 予算 → 成果 → 売上…
• 運用スタッフが売上を出すITは直接売上を出さない
• ITスタッフに分配される予算は限られる
• 予算と成果のサイクルに「魔術的無駄」があるとすぐに負のスパイラルになる
その後P氏の実装を原型として、徐々に他のフロント機能もB社自身が作るようになりました。
P氏の設計を真似して、他の機能が個別に改修されていきます。
最終的に、その手法はサイト全体でひとつに統一され、フレームワークとなりました。
その頃には、P氏もすっかりB社の社員です。
社内フレームワーク社内フレームワークがすべて悪というわけではない
社内フレームワーク = たしかに技術的負債ではある
重要なことは、その技術的負債が:
• より多くを返済するための借り入れなのか
• 返済よりも利子が高くつく種類のものでないか
を見極めること
レガシーシステムを含んで どうやってテストするのか
• クラスをクラスでテストするPHPUnitでは、そもそもクラスが存在しない…
• アプリケーションサーバーの外から生スクリプトの振る舞いをテストしたい
• Behatもいいんだけど….
• PHP 文法で BDD 風テストできる Codeception がオススメ
Behat
Codeception
レガシーコードを どうやって解析したか
• PhpStorm には Find by usage (変数/関数使用箇所検索) がある
• PhpStormを開発スタッフ全員分買ってもらいました
お買い求めは こちらのサイトへ
第二話 開発プロセス
B社内で開発する部分が増えてきたので、バージョン管理にGitを採用しました。
最初にサーバーがなくても、手元で使い始められるので導入しやすかったためです。
[重要] かならずGitかMercurialを使って下さい。
未経験者にはSubversionのほうが簡単だろうというのは、あまり使っていない人がいいかげんなことを言ってるだけです。だまされないで。
B社「でも枝分かれいっぱいあって難しそう」
P氏「じゃあ枝を作らなければいいんですよ」
しばらく master と pshi と yamada ブランチ(仮名)固定で運用。
それでも、ありとなしでは雲泥の差。
P氏「コード書けましたテストもOKです」
B社「よーし更新しよう」
P氏「え、それ何やってるんですか」
B社「え、いや、タイムスタンプ見て、FFFTPで変更したファイルだけを...」
うひゃぁ!
git diff [prev tag] --name-status
M config/main.phpM src/hoge/index.phpM src/hoge/js/fuga.jsA web/css/new-style.cssD web/img/tmp.png
それGitでできるよ
git diff [prev tag] --name-only | git checkout-index --prefix=./FTPするやつ/ --stdin
それGitでできるよ
タイムスタンプが
いかに信用出来ないか
P氏「あれ? こっちで変更してないファイル、タイムスタンプ上がってますね」
B社「もしもしA社? 昨日そっちで何かやった?」
A社「あれとこれと... そういえば /inc あたりに...」
B社・P氏「ちょっとまって、それこっちでも使ってる!」
カオス
P氏「テストサーバの index_2tmp.php って何ですか」
B社「知らないなぁ、使ってないやつじゃない?」
P氏「じゃあこの index3.php も要らないですね」
B社「それは本番にもあるから使ってるやつ」
とめどなくカオス
B社「もしもしA社? ひとつお願いしたいことが...」
A社「はい、追加費用のかからないことなら」
B社「たのむからGit使ってください」
form ユーザー企業 to エンジニア
作業するときはかならずチケット(課題)管理するようにしました。
Gitでは、チケットごとに異なるブランチを切ることにしました。
緊急でないかぎり、本番の更新は随時ではなくまとめてやるようにしました。
• 事業会社は自分のことなので真剣です
• Gitの操作はプログラミング能力とは関係ありません
• チケット管理システムは意味がわかればWebのフォームに文字を書けるだけでOKです
• 問題意識、情報の運用、ソフトウェアの開発プロセスには、本質的な情報の力が出ます
受託開発の会社は、顧客をITの素人だと思ってはいけません。実は自分たちが長けているのは、PHPの文法とかだけだった、なんてことないように!
• 特権的な分野で過去のやり方を守るだけ = 魔術
• 新しいやり方から次のやり方を生み出せるもの = 科学
第三話 インフラ
P氏「あれ? testとprodにnslookupしたら同じIPになるんですけど...」
B社「そりゃそうさ同じマシンだもん」
P氏「え」
B社「たしか同じのにWordPressも入ってるよ」
期待したもの
App
DB
本番
App
DB
テスト
Blog
開発
得られたもの
App
DB
本番 /var/wwwテスト /var/www_test
本番 dbテスト db_test
cron (本番のみ)
WordPress wp_db
WordPress /var/www/blogphpMyAdmin FTP
やばい
テスト環境だけ AWS に移動しました。
いつでも自由に停止/再起動できるようになりました。
テストが本番に影響する心配もなくなりました。
テストメールが送信されないよう Mailcatcherを利用しました
B社「うーんうーん」
P氏「どうしましたか」
B社「XAMPPでは動かないのになんでtestで動くの?」
C:¥XAMPP
• Vagrantに移行
• Maicatcherのお手軽版としてFakeSMTPを利用
• 手元でテストしたものの信頼性が格段に向上。
• テストサーバーの取り合いもなくなりました。
ここでVagrant環境とテストサーバーを、随時本番サーバーに似るようメンテし続けたことが後で効いてきます。
ある日、メディア掲載に大成功し...
アクセス殺到
サーバーが… 死んだ…
23:10 夜運用スタッフ大慌て
帰宅後の社員を巻き込んで飛び交う深夜の社内チャット
自宅のP氏「SSHが息してないです」
P氏「こうなったらA社のデータセンターに...!」
B社「翌日出勤時間の9:00まで、あそこリスタートできる人誰もいないよ」
翌日9:00まで
リスタートできる人誰もいないよ
ほどなくして、B社内でAWSへの完全移行が決定されるのであった…
B社「自分たちのビジネスのタイミングでサーバ運用したい!」
サーバ環境を変えてもちゃんと動きそうな期待は、テストサーバーとVagrantで十分に積んできました。というわけです
ELB
EC2 (App) RDS
Nginx Apache
EC2 (WordPress)ApacheMySQL
PHP MySQL
SES
これからはこいつらのEBS スナップショットからテスト環境を生成可能
• ハードウェア設備は利権化しやすいポイントです。
• 変える理由に実利がともなわないと、出資者は動きません。経営で重要なのは移行費用を回収できるかです。
• 脱レガシーには、移行コストと先の損得の見積もりを、わかりやすく比較することが重要です。
最終回
人事
ここまでのエピソードでもっとも重要だったこと = 人事
HOW?
WHY?
どのようにして P氏を採用したか
• カンファレンス
• 勉強会
• コワーキングスペース
適切な情報が流れているコミュニティに接点を持つこと
なぜP氏を採用できたか
• ITによる成長力を信じる社風があること
• ITに頼らずに今の事業を支えている人がいること
• タイミング (←重要)
• 手が空いた優秀な人材は、それを放っておかない会社が数多くある
• 良い人材がいたとき、すぐに採用できる余裕を経営に織り込むこと
• 現場から「この人を採用したい」という声が挙げられるようにすること
その後人事はどうなったかITの会社ではないのに、多くの良いエンジニアを多く採用/契約できた。
• 悪いエンジニアは優秀なエンジニアを歓迎しない
• 良いエンジニアは優秀なエンジニアをひと目で見分けられる
• むしろ良いエンジニアは自分よりも優秀なエンジニアがいたらどんどん呼びこむ
え、なにこの経営者向けのオチ?
自分が所属してる会社でどうやって脱レガシーするか聞きたかった?
→ 自分の会社を、人事/社風のレイヤーで動かすことを考えて下さい
• レガシーの正体は非科学です
• 非科学とは社会的/組織的な迷信です
• 人のメンタルを変えないかぎり、それは表面的な対応でしかありません
• 道具や教本だけに頼ると、脱レガシーだと思って採用した最新手法が、やがて時間とともに、次のレガシー(先代の残した魔術)となります
• たとえば、Jenkinsのタスク、Chefのレシピ...
• 秘伝のタレに再現性を与える行為 = 脱レガシー
• 学びましょう!
• 学んだことを仕事に持ち帰りましょう!
• そして人に伝え、迷信に頼らないチームにしましょう!
• 大変かもしれませんが「やりたい」という気持ちをエネルギーの源泉として!
ありがとうございました