とある事業の脱レガシー

6,508 views

Published on

0 Comments
44 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,508
On SlideShare
0
From Embeds
0
Number of Embeds
1,082
Actions
Shares
0
Downloads
20
Comments
0
Likes
44
Embeds 0
No embeds

No notes for slide

とある事業の脱レガシー

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

×