Dane Harriganさん「Finding True Love in Legacy Software」

HerokuのAPIチームで働くDane Harriganさんのセッションは，レガシーソフトウェアに関するものでした（スライド等はこちら⁠）⁠。当初は，実際にレガシーコードをレビューしながらポイントを解説しようとしていたようですが，レガシーコードのレビューは専門知識も必要で，あまりにもややこし過ぎるので取りやめにしたとのことです。

このセッションでは，Herokuで実際に行ったレガシーソフトウェアの改善を元に，どのようにソフトウェアを設計すれば幸せになるかを紹介しました。

レガシーソフトウェアとは？

Daneさんの定義によれば，レガシーソフトウェアとは，次のようなソフトウェアを指すとのことです。

• 誰か別の人から引き継いだ
• テストが行われていない
• 読んでも理解しにくい
• メンテナンスが行いにくい
• 誰も好まない

ソフトウェア開発を行っていれば，誰もが経験したことがあるのではないでしょうか？ このようなレガシーソフトウェアでも，改善していく中で「真実の愛」を見つけることができると言います。

名前が重要

もっとも重要なことは「名前」と言います。具体的にやってはいけないのは，「⁠Core」とか自社の名前をソフトウェアにつけることです。

Coreは万能です。なんでも追加可能です。どんどんと機能をCoreに追加していった結果，なんでもできるとんでもないソフトウェアとなります。

「Core」のような曖昧な名前はつけてはいけません。単一の目的をもった適切な名前をつけなければ，万能で曖昧なソフトウェアはコードのゴミ捨て場となってしまうとのことです。

1つの責務を持つアプリに分割する

残念なことに，HerokuではCoreというアプリケーションが万能なゴミ捨て場となっていたようです。この問題を解決するために，Coreから機能毎に新しいアプリケーションとして分割し，整理していきました。

例えば，サーバのインスタンスの作成や起動などを行う部分は，Coreから分離され「Server Instance Management」となりました。同様に，課金に関する部分は，「⁠Billing Payments」となりました。このように少しずつ，Coreから各機能を分離していった結果，「⁠Core」は「Public API」となりました。

このようなソフトウェアのモジュール構成はデータベースであっても同様とのことです。 すべての情報を保持する万能なデータベースを作成すると，「⁠Core」と同じような問題に直面します。「⁠CoreDB」を作らず「Billing DB」など各サブシステム毎にデータベースを作成し，他のサブシステムからはAPI経由で連携させるのがコツとのことです。

真実の愛

レガシーソフトウェアは望ましいものではないとしつつ，何ヶ月もかけて使いやすく改善していくと，愛しくなってくると言います。きれいなコードとなっていくことで，愛着もわいてくるようですね。

なお，セッション自体は，シンプルで短いものでしたが，質疑応答では活発にDane氏に改善したAPIについて質問をしていました。Coreの分離には，ひとつでも数ヶ月かかり，全体では数年もかかったとのことです。また，分離した場合でも，切り替えは慎重に行い，一部のユーザに段階的なリリースを行ったそうです。

他にも「そのCoreを作ったのは誰？」「⁠レガシーソフトを改善するgemはない？」など多くの質問が行われていましたが，そのほとんどは外国から参加された方である点が印象に残っています。

長永健介さん「30days Album の裏側 - レガシー Rails 編」

株式会社paperboy&co.にてWebサービスの開発に携わる長永さんの発表です（スライド等はこちら⁠）⁠。本セッションでは，長永さんがこれまでレガシーなRailsアプリケーションの運用と開発に携わる中で得られた知見やノウハウなどを紹介しました。

レガシーなコードにテストを書くこと

長永さんはRuby on Rails製で20万人以上の会員数を誇るオンライン写真共有サービス30days Albumの開発を担当してきて，本アプリケーションを「古いRailsの使用」「⁠不十分な自動テスト」という2つの側面で「レガシーなRails」アプリだとしました。

長永さんは健全にRailsアプリのコードベースを運営していくにはバージョンアップし続けていくことが必要だと話します。そこでRails2.0.2からRails2.1.2にバージョンアップしようとしたところ，実に4年もの月日がかかってしまいました。それは圧倒的にテストコードが足りなかったことが最大の理由でした。

レガシーなコードに対してテストを追加するというのはとても難しいことですが，Rubyにはその助けになるStubとMockというライブラリがあると長永さんは言います。これらを武器に長永さんはRailsのバージョンアップのためにテストを追加し続けました。

テストを追加していくうちに，長永さんはある悩みを抱いたそうです。「⁠既存コードは正しくうごいているのに，わざわざそれにパスするテストを書くことに意味がるのか？」

そんな悩みを抱えた中，長永さんは「レガシーコード改善ガイド」という本に出会いました。その中には「仕様化テスト」という考え方が載っており，それは現在の振る舞いを調べてパスするテストを書くことにより，将来コードの変更で壊れるかもしれない振る舞いをテストで守るという考え方でした。まさに長永さんがやっていたことで自分は正しかったんだと自信を持ったそうです。

技術的負債について

長永さんは「技術的負債」という言葉について説明しました。技術的負債には大きく2つのパターンがあると言います。

ひとつは「昔は良かったが今は時代遅れになってしまったもの⁠」⁠。例としてRailsで非同期処理を行う際のライブラリとしてよく使われてきたBackgrounDRbというプラグインを挙げ，現在はdelayed_jobを使うのが良いとされています。30days AlbumにおいてもBackgrounDRbが使われていたのでdelayed_jobへの移行を試みたところ，2.1.2のバージョンでは正しく動作しないという問題に遭遇しました。さらに新しいバージョンへRailsをアップすることで正しく動作するのはわかっていましたが，現状は困難なのでライブラリへのモンキーパッチを当てることでなんとか凌いだとのことです。

もうひとつは「最初からよくなかったもの⁠」⁠。例としてDBスキーマの設計を挙げ，少ないデータ数の場合は問題にならないが大量データだと著しい性能劣化を引き起こす実装があったそうです。しかし既に大量のデータが格納された既存のテーブルを変更するのは困難で，最終的にはより高性能なハードウェアを導入することで解決しました。もちろんソフトの対応も時間をかければ可能だったかもしれませんが，時としてこういったハードでの対処も選択肢のひとつとして間違いではないという事例でした。

レガシーなコードに対してどう立ち向かうか

私達は仕事でプログラマをやっているので，ソフトウェアに対し現実的に取り組まないといけない，と長永さんは話します。品質，コスト，期間に責任を持ち価値をリリースし続けるためには，必ずしもカッコいいチャレンジングなことばかりにこだわるのではなく，むしろ古いやり方で問題を解決していく選択肢もあり，両者を比べて正しくジャッジしていく必要があります。

一方，開発者として忘れたくないこだわりもあります。完璧なコードを書くために細部にこだわりを持ち続けること。長永さんは推薦本として「リーダブルコード」を紹介しました。技術的負債を未来に残さないという姿勢も大事だと言及しました。後輩達に自分と同じ辛い思いをさせることなく，来た時よりも美しくというボーイスカウトルールにならって少しでも技術的負債を減らしていきましょう。

まとめ

レガシーコードに対し技術的側面からのアプローチだけでなく，心構えや取り組む姿勢などの精神論についても長永さんの熱い気持ちが伝わってくる素晴らしいセッションでした。

質疑応答ではいくつか質問がありました。Railsの進化に追従するためにこれからも戦い続けるのか，という質問に対し「折角会社に灯ったRubyの火を絶やしたくない」という長永さんのRubyistらしい回答がとても印象的でした。

タシツキミハウさん「プログラミングのトレーニング」

ポーランドのApplicakeで"delicious"なソフトウェアを開発されているTaszycki Michalさんの発表です（スライド等はこちら⁠）⁠。corporate universeという会社を辞めた後，PS3やXBOX，PC用コンシューマゲーム開発を経て，MichalさんはRubyの世界に入りました。Applicakeでプロジェクトのマネジメントをしながら，Code Retreatsという活動を通して同僚のプログラマをトレーニングしています。

Programming Workoutについて

プログラミングは複雑なスキルです。野球やマーシャルアーツも複雑なスキルです。しかし，野球ができることと野球のプロであることは違います。プロであるために必要なのは才能でしょうか。いいえ，必要なのは努力です。自分がスキルを手に入れるためには，たゆまぬ鍛錬が必要なのです。

Programming Workoutはとてもシンプルなアイデアです。多くの面白いプロジェクトを経験する中で，仕事以外にもプログラミングの練習が必要だと感じました。そこでProgramming Workoutです。

達人を目指すのにはモチベーションが重要です（Matzも言っていましたね⁠）⁠。達人を目指し続けるには多くの障害がありますが，どのようなやり方をすればよいでしょうか。単純にまっすぐ進むことが正しい道とは限りません。

Programming Workoutは基本的な2つの側面があります。肉体的なトレーニングをプログラミングにも適用すること。もうひとつはコミュニティをつくり，一緒にWorkoutに取り組むこと。PROGRAMMINGWORKOUT.comには500人も登録しました。

マスターになるための4つのステップ

Programming Workoutのやり方を技術レベルごとに紹介します。

まずは初心者（Beginer）のやり方です。何の技術を習得したいのかゴールを設定するのではなく，願いをかけるといいでしょう。毎日トレーニングすることがとても大事です。VimGolfやRubyQuiz，ProjectEulerなどを活用してシンプルなトレーニングを選ぶとよいでしょう。次のレベルに進むために，トレーニングを習慣づけましょう。毎日歯をみがくという習慣があると思いますが，既にある習慣の前後にトレーニングの習慣をつけるとよいでしょう。また，失敗を恐れてはいけません。

次に未熟者（Novice）のやり方を説明します。SMARTという指標に従って目標を決めましょう。

• Specific:具体的で
• Measurable:測定できる
• Acievable:チャレンジングだけど無理ではない
• Relevant:関連性がある
• Time-bound:期限がある

目標は人それぞれです。自分にあったゴールを決めるのが重要です。師匠を探すということも大事です。師匠は目標にすべき人でも，RailsCastsなどのサイトでも構いません。Noviceのスケジュールは，毎日一つのことにFocusすべきです。他のことに気を取られないようにしましょう。"keep working hard"熱心に取り組み続けてください。

名人（Adept）のやり方を説明します。Adeptな人は，できることを把握しています。Adeptなレベルに達したら，運動の強度を変えるとよいでしょう。トレーニングを増やすとか，トレーニングをより複雑なものにするとか，実験するなどトレーニングを工夫することができます。

進捗を計測することはとても大事です。タイピングの練習をしているならばWPM（一分あたりの単語入力数）を改善することや，自分で進捗を計測してみること，どれだけ速くリファクタリングできるかを計測してみるといった例を挙げました。

Adeptなレベルに達したら，弱点を探すことも重要です。弱点というのは，改善できるところだからです。CodeKataは複雑な問題をとりそろえているのでとてもすばらしいです。Adeptのスケジュールはちょっと複雑です。肉体をトレーニングしている方は知っていると思いますが，激しいトレーニングの後には超回復のために，一日二日休むことも大事です。自分の経験やプラクティスを共有することでお互いのモチベーションを高めあうことができます。

最後は達人（Master）のやり方を説明します。自分がMasterと自覚するのではなく，Masterだと周りから言われるものです。Masterは何をすべきでしょうか。それは，いい仕事を続けることです。Masterのスケジュールを見てみましょう。一見Beginerのスケジュールと同じですが，Masterは自分の鍛錬に何が必要なのかを考えてスケジュールを組む必要があります。また，一番下手なプレイヤーでいることも大事です。新しく他のスキルを習得するために，初心を忘れないということが大事です。教える立場になってみるということも大事です。Rails GirlsやCode Retreatなどでコーチをしてみるといいかもしれません。これはとても素晴らしいトレーニングになるでしょう。

まとめ

札幌Ruby会議2012のテーマ「WE CODE」にかけて，Michalさんは「WE CAN CODE BETTER, IF YOU WORKOUT.」と締めくくりました。私たちもプログラミングのトレーニングを通じて，コードをよくしていきましょう。