![[重要] かならずGitかMercurialを使って下さい。
未経験者にはSubversionのほうが簡単だろうという
のは、あまり使っていない人がいいかげんなことを
言ってるだけです。だまされないで。](https://image.slidesharecdn.com/escape-from-legacy-150703052135-lva1-app6891/85/-42-320.jpg)
![git diff [prev tag] --name-status
M config/main.php
M src/hoge/index.php
M src/hoge/js/fuga.js
A web/css/new-style.css
D web/img/tmp.png
それGitでできるよ](https://image.slidesharecdn.com/escape-from-legacy-150703052135-lva1-app6891/85/-47-320.jpg)
![git diff [prev tag] --name-only | git checkout-index
--prefix=./FTPするやつ/ --stdin
それGitでできるよ](https://image.slidesharecdn.com/escape-from-legacy-150703052135-lva1-app6891/85/-48-320.jpg)
とある事業の脱レガシー
- 3. そこに偶然現れたある平凡な助っ人PHPエンジニア... やがて彼は、データセンターにはWebとDBの2サー バーしか存在しないのに何故かテスト環境があるとい う、次なる衝撃の事実を知るのでした...
- 5. たなかひさてる @tanakahisateru Pinoco developer PHPTAL contributor Firebug translation contributor Yii framework user PhpStorm user フルスタックエンジニア(笑)
- 6. レガシーとは
- 8. レガシー (Legacy) 1. 遺産，遺贈(財産) 2. 受け継いだもの，遺物
- 10. 古いとわかっているのになぜ 置き換えられないのか • より良い代替物を開発できない • どうして動いているのかわからない • 既存の設計が無駄に複雑すぎて、全ての知識を吸い 上げきれない • 作りなおして失敗するよりはそのまま使うほうが安 全だ
- 11. 魔術的 ブラックボックス
- 13. どうやったら 置き換えられるのか • 再現性のある設計/プロセスに変換する • 属人化せず、論理的な推論の連続で仕 組みを成り立たせる • 絡み合うレガシー部分に引きずられず、 一気通貫に進める
- 14. 科学的 多くのエネルギーが必要
- 16. •レガシー = 魔術 •リプレース = 科学
- 17. レガシーシステムの デメリットを明確にする 魔術的なものの多くは次の2つに分類できます: • 科学で置き換え可能なもの …(a) • 科学的に考えると実は無駄 …(b) (a) は本質的に必要 (b) が保守工数を圧迫すること = デメリット
- 18. 例 この変数 $hoge は200行 前に if でこれが入るかも しれないし、そうでなけれ ばその前の行の初期値で… ってものすごい検索とスクロールですよ ね、心折れますね $hoge = 0; if ($fuga > 100) { $hoge = 1; } // この間200行 echo $hoge;
- 19. 例 この変数 $hoge は200行前に if でこれが入るかも しれないし、そうでなければその前の行の初期値で… ってものすごい検索とスクロールですよね、心折れますね $hoge = $conditionalContext->getHoge();
- 20. • なんで200行もステップ解析しなきゃなんないの? • 目視で見落としない? • これどう考えても無駄だよね • 手続きを宣言(AはBである)に変換する! $hoge = $conditionalContext->getHoge();
- 22. (注: フィクションです)
- 24. 全4編 • 第一話 プログラミング • 第二話 開発プロセス • 第三話 インフラ • 最終回 人事
- 25. • A社 = 開発/サーバー設備を提供、委託先 • B社 = 事業会社、発注元 • P氏 = とあるPHPer B社にP氏がジョインしました。
- 26. 第一話 プログラミング
- 30. <?php reruire __DIR__ . /../src/bootstrap.php ; MyApplication::create()->run(MyController::class); index.php MyController MyService index.phtml models* create access use render
- 31. <?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とか書けませんからね
- 32. • 今やっておかないと将来の自分にとって都合が悪い • だからやる • この判断が、物語のはじまりとなった…
- 33. 事業会社と受託開発は 違うという読み 売上 → 予算 → 成果 → 売上… • 運用スタッフが売上を出す ITは直接売上を出さない • ITスタッフに分配される予算は限られる • 予算と成果のサイクルに「魔術的無駄」があるとす ぐに負のスパイラルになる
- 35. 社内フレームワーク 社内フレームワークがすべて悪というわけではない 社内フレームワーク = たしかに技術的負債ではある 重要なことは、その技術的負債が: • より多くを返済するための借り入れなのか • 返済よりも利子が高くつく種類のものでないか を見極めること
- 36. レガシーシステムを含んで どうやってテストするのか • クラスをクラスでテストするPHPUnitでは、そ もそもクラスが存在しない… • アプリケーションサーバーの外から生スクリプ トの振る舞いをテストしたい • Behatもいいんだけど…. • PHP 文法で BDD 風テストできる Codeception がオススメ
- 38. レガシーコードを どうやって解析したか • PhpStorm には Find by usage (変数 /関数使用箇所検索) がある • PhpStormを開発スタッフ全員分買っ てもらいました
- 39. お買い求めは こちらのサイトへ
- 40. 第二話 開発プロセス
- 44. しばらく master と pshi と yamada ブランチ(仮名) 固定で運用。 それでも、ありとなしでは雲泥の差。
- 46. うひゃぁ!
- 47. git diff [prev tag] --name-status M config/main.php M src/hoge/index.php M src/hoge/js/fuga.js A web/css/new-style.css D web/img/tmp.png それGitでできるよ
- 48. git diff [prev tag] --name-only | git checkout-index --prefix=./FTPするやつ/ --stdin それGitでできるよ
- 50. P氏「あれ? こっちで変更してないファイル、タイム スタンプ上がってますね」 B社「もしもしA社? 昨日そっちで何かやった?」 A社「あれとこれと... そういえば /inc あたりに...」 B社・P氏「ちょっとまって、それこっちでも使って る!」
- 51. カオス
- 52. P氏「テストサーバの index_2tmp.php って何です か」 B社「知らないなぁ、使ってないやつじゃない?」 P氏「じゃあこの index3.php も要らないですね」 B社「それは本番にもあるから使ってるやつ」
- 53. とめどなくカオス
- 57. • 事業会社は自分のことなので真剣です • Gitの操作はプログラミング能力とは関係ありません • チケット管理システムは意味がわかればWebのフォーム に文字を書けるだけでOKです • 問題意識、情報の運用、ソフトウェアの開発プロセスに は、本質的な情報の力が出ます 受託開発の会社は、顧客をITの素人だと思ってはいけません。 実は自分たちが長けているのは、PHPの文法とかだけだった、なんてこ とないように!
- 58. • 特権的な分野で過去のやり方を守るだけ = 魔術 • 新しいやり方から次のやり方を生み出せるもの = 科学
- 59. 第三話 インフラ
- 60. P氏「あれ? testとprodにnslookupしたら同じIPに なるんですけど...」 B社「そりゃそうさ同じマシンだもん」 P氏「え」 B社「たしか同じのにWordPressも入ってるよ」
- 62. 得られたもの App DB 本番 /var/www テスト /var/www_test 本番 db テスト db_test cron (本番のみ) WordPress wp_db WordPress /var/www/blog phpMyAdmin FTP
- 63. やばい
- 67. C:¥XAMPP
- 68. • Vagrantに移行 • Maicatcherのお手軽版としてFakeSMTPを利用 • 手元でテストしたものの信頼性が格段に向上。 • テストサーバーの取り合いもなくなりました。 ここでVagrant環境とテストサーバーを、随時本番サー バーに似るようメンテし続けたことが後で効いてきます。
- 70. サーバーが… 死んだ…
- 75. ELB EC2 (App) RDS Nginx Apache EC2 (WordPress) Apache MySQL PHP MySQL SES これからはこいつらのEBS スナップショットからテスト環境を生成可能
- 76. • ハードウェア設備は利権化しやすいポイントです。 • 変える理由に実利がともなわないと、出資者は動き ません。経営で重要なのは移行費用を回収できるか です。 • 脱レガシーには、移行コストと先の損得の見積もり を、わかりやすく比較することが重要です。
- 77. 最終回 人事
- 79. どのようにして P氏を採用したか • カンファレンス • 勉強会 • コワーキングスペース 適切な情報が流れているコミュニティに 接点を持つこと
- 80. なぜP氏を 採用できたか • ITによる成長力を信じる社風があること • ITに頼らずに今の事業を支えている人がいること • タイミング (←重要)
- 81. • 手が空いた優秀な人材は、それを放っておかない会 社が数多くある • 良い人材がいたとき、すぐに採用できる余裕を経営 に織り込むこと • 現場から「この人を採用したい」という声が挙げら れるようにすること
- 82. その後人事はどうなったか ITの会社ではないのに、多くの良いエンジニアを多く 採用/契約できた。 • 悪いエンジニアは優秀なエンジニアを歓迎しない • 良いエンジニアは優秀なエンジニアをひと目で見分 けられる • むしろ良いエンジニアは自分よりも優秀なエンジニ アがいたらどんどん呼びこむ
- 85. • レガシーの正体は非科学です • 非科学とは社会的/組織的な迷信です • 人のメンタルを変えないかぎり、それは表面的な対 応でしかありません • 道具や教本だけに頼ると、脱レガシーだと思って採 用した最新手法が、やがて時間とともに、次のレガ シー(先代の残した魔術)となります
- 86. • たとえば、Jenkinsのタスク、Chefのレシピ... • 秘伝のタレに再現性を与える行為 = 脱レガシー
- 87. • 学びましょう! • 学んだことを仕事に持ち帰りましょう! • そして人に伝え、迷信に頼らないチームにしましょ う! • 大変かもしれませんが「やりたい」という気持ちを エネルギーの源泉として!
- 88. ありがとうございました