【書評】「レガシーコードからの脱却」の9つのプラクティスは圧倒的に正しい（経験者談）

はじめに

株式会社アトラクタの原田騎郎さん（@haradakiro）から、書籍「レガシーコードからの脱却」をご恵贈いただきました。（どうもありがとうございます！）

せっかくいただいた本なので、本書を読んだ僕の感想を書いてみようと思います。

どんな本なの？

端的に言うと、「初めからレガシーコードを作りださないための9つのプラクティスを説明した本」となります。

最初にタイトルを見たときの印象は「今そこにあるレガシーコードを、どうやってイケてるコードに書き直していくのか？」を説明した本なのかなと思ったんですが、本書が主眼としているのは「そもそもレガシーコードを作らないこと」でした。

ですので、「レガシーコード改善ガイド」とは毛色が違う本だと考えた方が良さそうです。
（「レガシーコード改善ガイド」は、「今そこにあるレガシーコードを改善する方法」を解説した本です）

レガシーコード改善ガイド (Object Oriented SELECTION)

ちなみに、原著のタイトルは "Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software"です。

Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software

本書におけるレガシーコードの定義

「レガシーコードって何？」という人のために簡単に説明しておくと、本書におけるレガシーコードとは「修正や拡張、作業が難しいコード」（訳者まえがきより抜粋）のことです。

ポジティブかネガティブかでいうと、明らかにネガティブな意味です。
「弊社にはレガシーコードがたくさんあります」とのたまう人がいたら、その会社はちょっと大変な状況であることが疑われるので注意しましょう。

本書が提示する9つのプラクティス

本書は「ソフトウェアの寿命を延ばし価値を高める9つのプラクティス」として、以下のプラクティスを掲げています。

1. やり方より先に目的、理由、誰のためかを伝える
2. 小さなバッチで作る
3. 継続的に統合する
4. 協力しあう
5. 「CLEAN」コードを作る
6. まずテストを書く
7. テストでふるまいを明示する
8. 設計は最後に行う
9. レガシーコードをリファクタリングする

それぞれの具体的な内容についてはここには書きません。
本書を購入してご自身でチェックしてみてください😉

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

正直に言うと、あまり目新しい内容はなかった・・・が！

さて、ここから下は僕の感想です。

本書をひと通り読んだあとの感想は、「うーん、あまり目新しい内容はなかったな🤔」でした。

ネガティブですよね？disってるように聞こえますよね？？

いや、でも違うんです！

なんで目新しい内容がなかったのかというと、この本に書かれているほぼすべてのプラクティスが今僕が勤めているソニックガーデンで実践できていたからです。
そして、ソニックガーデンにはレガシーコードがありません。
かれこれソニックガーデンで7〜8年働いてきましたが、「うわー、これはないわー。まさにレガシーコードだわー」と思ったことは一度もないのです。

反対に、僕が以前勤めていた前職や前々職の会社では「勘弁してくれよ〜、まったく！」とうんざりするようなレガシーコードを何度も見てきました。
そうした職場では本書に書かれているプラクティスがほとんど実践されていませんでした。

このことから何が言えるのか？

これはつまり、「本書に書かれている内容は圧倒的に正しい」ということです。

本書で紹介されている9つのプラクティスを実践していけば、確実にレガシーコードから脱却できます。
これは僕自身の経験と照らし合わせて断言することができます。

では、どうやって実践するのか？（要検討）

本書に書かれている内容が正しいことはわかりました。
でも、もしこのブログを読んでいるみなさんが、「今の職場では全然実践できていない！なんとかしたい！」と思ったときはどうすればいいのでしょうか？

残念ながら、その答えは本書には載っていません。（もし僕が見落としているだけだったらすいません💧）

僕もSIerで働いていた経験があるので予想が付くのですが、「ウォーターフォール型かつ、多重下請けかつ、納品型の受託開発」をやっていたりすると、ビジネスモデル上の制約や会社の力関係等があるために、こうしたプラクティスを一（いち）開発者の意見で導入するのはほぼ不可能だと思います。

また、そうした開発スタイルではなくても、同僚にあまり向上心がなかったり、上司がまったく理解してくれなかったりすると、自分のやる気だけが空回りして疲弊することもよくあります。（こちらも経験あり）

じゃあ、僕自身はどうしたのかというと、今の職場を変えることは諦めて転職しました。
その転職先が今僕が働いているソニックガーデンです。
前述の通り、ソニックガーデンに入ってからは本書に書かれているような理想的な環境を手に入れることができたので、僕にとっては「転職する」という選択肢は正解だったと思います。

では、みなさんだったらどうしますか？
これはみなさん自身の宿題なので、自分の頭でよ〜く考えてみてください。

「9つのプラクティス」は転職活動するときにも役立つかもしれない

もしあなたがよりよい環境を求めて転職しようと思った場合は、本書の「9つのプラクティス」が役に立つかもしれません。
なぜなら、面接官から「何か質問はありませんか？」と聞かれたときに、9つのプラクティスで書かれていることをベースに「◯◯はどうされていますか？」とか「◯◯は実践されていますか？」と尋ねれば、その現場のレガシーコード具合が予測できそうだからです。

これから転職しようとしている方は、本書を読んで質問リストをあらかじめ作っておきましょう👍

その他の感想：翻訳が非常に読みやすい！（重要）

本書の内容とは直接関係がありませんが、本書を読んでいる最中、僕は翻訳が非常に読みやすいところに密かに感銘を受けていました。

訳書ってたまに翻訳がめちゃくちゃ読みづらいことがあるんですよね。
過去に読んだ訳書の中には、いくら翻訳を読んでも内容が頭に入ってこないので、「もはや原著を買って英語で読んだ方が良いのでは？」と思ったものもあります。

その一方で、僕自身が英語の技術書を日本語訳したことがあります。
（「Everyday Rails - RSpecによるRailsテスト入門」という電子書籍です ↓ ）
leanpub.com

実際に翻訳をやってみると、これがめちゃくちゃ難しいんですよね〜。
英文の構造や言い回しって、日本語と大きく異なる部分が多々あるので、素直に翻訳すればするほど「読みにくい日本語」が量産されていくんです。
Everyday Railsの翻訳をするときも「翻訳臭」を消すのにすごく苦労しました。

そういった「読む側」と「翻訳する側」の両方の経験がある僕からすると、本書「レガシーコードからの脱却」の翻訳は非常に高レベルだと思います。
訳書臭がまったくしないので、すらすら読むことができました。

なので、本書を読むときはそういった翻訳の自然さ、滑らかさにも注目して読んでみてください！

まとめ

というわけで、このエントリでは書籍「レガシーコードからの脱却」の書評を書いてみました。
本書の感想は次のように大きく２つに分かれると思います。

まず、僕のように、本書を読んで「あまり新しいことが載ってないなー」と思ったそこのあなた！
あなたはきっと幸せな環境で開発ができている人です。（良かったですね😄）

反対に「へー、こんなやり方があるのか」とか「これは実践できてないな」と思ったそこのあなた！
あなたは今から何かアクションを起こすときなのかもしれません。

自分が置かれている状況を判定する「リトマス紙」として、ぜひ「レガシーコードからの脱却」を読んでみてください。

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

あわせて読みたい

我田引水になってしまいますが、弊社ソニックガーデンの働き方を紹介した本がいくつか発売されています。
ソニックガーデンは受託開発をやっているのに、なぜレガシーコードが生まれないのか？
その答えを知りたい方はこちらの書籍も読んでみてください。

ザッソウ 結果を出すチームの習慣 ホウレンソウに代わる「雑談+相談」

管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう

リモートチームでうまくいく

「納品」をなくせばうまくいく

Rubyプログラマが何を考え、どうやってコードを書くのか、その過程を動画にしてみました

はじめに：銀座Rails #12で登壇させてもらいました

去る2019年8月29日、銀座Rails #12で「プログラマがコードを書きながら考えること 」という発表をさせてもらいました。

ginza-rails.connpass.com

この発表では「プログラマが書き上げたコード（＝完成形）」ではなく、「そのコードをどうやって書いたのか？（＝何を考え、どんなツールやテクニックを使って、どれくらいのスピードで書いたのかという点、すなわち、コードを書く過程）」をテーマにしました。

そして、その過程をわかりやすく伝えるために、スライドだけでなく、僕がガチンコでコードを書いていく様子を動画コンテンツとして会場のみなさんにお見せしました。
これまでいろんな勉強会やイベントで発表してきましたが、動画を事前に用意して発表で使ったのはこれが初めてです。

初めての試みなので、どうなるかちょっと不安でしたが、意外と好評だったようでほっとしました。

伊藤さん(@jnchito)のコーディング実演中 (動画)

作りたい機能をこれだけサクサクコーディングできたら面白そう！というイメージが湧いてモチベーション爆上がりです😆#ginzarails

— こうだい＠Ruby on Rails勉強中 (@kodai_0122) August 29, 2019

流石、Rubymine 使いこなしてるな〜。terminalが一回も出てこん。 #ginzarails

— Yuki Minamiya(南谷 祐貴) (@yuki3738) August 29, 2019

手で確認は面倒くさいからテストコードを書く
これは習慣化していきたい。よく最後にテストコード書くので
#ginzarails

— okabeeeat (@okabeeeat) August 29, 2019

みなさんのツイートのまとめはこちらにあります。
togetter.com

また、当日使ったスライドはこちらに置いています。

動画はBOOTHで販売してみることにしました

しかし、今回の発表のメインは動画だったので、スライドだけ見てもあまり役に立ちません。
じゃあどうやって動画を公開しようかな〜？と、いろいろ検討した結果、今回はBOOTHを使って有料販売してみることにしました。

当日使用した動画は以下のページにて490円で販売しています。

jnito.booth.pm

無料のお試し版動画もあります

とはいえ、どんなものかよくわからないものにお金を払うのもみなさん不安だと思うので、無料のお試し動画も作りました。
以下のYouTube動画はBOOTHで販売している動画の前半部分を無料で公開したものです。

【お試し版】プログラマがコードを書きながら考えること 〜動画でわかるWebクローラー開発〜

このお試し動画を見て「続きを見たい！」と思った方は、ぜひBOOTHの購入ページに進んでやってください🙏

なんで有料販売にしたの？

動画を有料販売にした理由はいくつかあります。

編集作業が思っていた以上に大変だったから

動画を撮る前は「スライドを作るより、動画をぱっと撮ってぱっと見せる方がラクなのでは？」と想像していました。
ですが、実際にやってみると、発表時間内に収めるために動画を切り貼りしたり、わかりやすく伝えるためにキャプションを付けたり、なんだかんだでめちゃくちゃ時間がかかってしまいました。

iMovieでがんばって編集してました

なので、「これだけ手間ひまかけて作ったものを無料で公開するのはちょっともったいないな」と思ったのが理由のひとつです。

YouTubeの広告は質が悪い（と僕は思う）から

制作コストを回収するのであれば、広告付きのYouTube動画として公開する（＝再生回数上げて収益を得る）、という手も考えられます。
ですが、YouTubeの広告を見ていると、なんか詐欺まがいの怪しい広告をときどき見かけます。

もし、僕の動画を見た人がそういう広告に引っかかって「脳のドーピング剤」みたいなよくわからない商品を買ってしまったら僕は悲しいです。
いや、そんなものに実際に手を出す人は滅多にいないと思います。
ですが、そういう可能性がゼロではない、というのが僕の中ですごく気持ち悪いんです。

それに、そもそもYouTube広告の99.9%が自分にとって興味がない、邪魔なモノでしかない、というのもYouTube広告を避けたい理由のひとつです。
たぶん、ほとんどの人がYouTubeの広告はなくせるものならなくしたいと思っているのではないでしょうか？（なので、僕はYouTube Premiumに入って広告を出さないようにしました）

こうした理由から、YouTubeで間接的にお金をもらうよりも、僕の動画を見たいと思っている人から直接お金をいただく方が健全ではないかと考えました。
（注：これはあくまで僕自身の考え、ポリシーであって、YouTubeでお金を稼いでいる世の人々を否定するものではないので、念のため）

単純に試してみたかったから

あとは単純に、有料販売したらどれくらいの人が購入してくれるのか試してみたかったから、という理由もあります。

世間には書籍やWeb記事、YouTube動画など、プログラミングを学習するための情報がたくさんあります。
ですが、今回のように「他の誰かがガチンコでコードを書く様子を収めたコンテンツ」はほとんど見かけません。

こういったコンテンツは珍しいですし、他のプログラマの方（特に初心者さん）にとって非常に参考になるはず、と僕は信じています。
そこに対価を払ってくれる人がどれくらいいるのか見てみたい、というのも理由のひとつです。

カッコいいところだけでなく、カッコ悪いところも見せる勇気

ところで、今回の動画はべつに「俺様のプログラミング能力のスゴさを見よ！！」と自慢するために作ったわけではありません。
気持ちとしてはむしろ逆で、こんな動画を作って見せたら、みんなから「なーんだ、伊藤さんっていつもネットで偉そうなこと書いてるけど、全然大したことないやーん🤣」とバカにされるかもしれない、と心配していました。

それでも「動画にして見せる価値があるかも」と思ったのは、以下の2つの記事を読んだからです。

• 2018年の段階で私が知らないこと — Overreacted
• プログラマーの方に質問です。正直、1日8時間も集中力続かなくないですか？ - Quora

前者はReact界の有名エンジニアであるDan Abramov氏が「私はこんなこと（＝技術関連の知識）を知らない」と、「自分の知らないことリスト」を公表した記事です。

また、後者の記事ではRubyのパパことMatz氏がご自身の集中力について「私は普段だと集中力は１５分くらいしか持ちません」と公言しています。

これらの記事を読んで僕は非常に救われたというか、「すごい人はどこを切り取っても全部すごいわけじゃないんだな。まあ、そうだよな」と安堵しました。
そして、自分のすごくないところを堂々と言えるところが逆にすごいと思いました。

Matzさんのようなスーパープログラマと僕を同列に並べるのはおこがましいですが、それでも「自分のすごくないところもおおっぴらにできる勇気」みたいなところは僕も見習いたいなと思いました。

こうした思いもあって、自分がハマったり迷ったり間違ったりするところも全部動画に撮って公開してみようと考えたのでした。

まとめ

というわけで、このエントリでは銀座Railsで僕が発表した内容と、そのときに使った動画の販売ページをお知らせしました。

「伊藤さんは普段どんなことを考えて、どんなふうにコードを書いているのかなー？」と興味を持っている方がいたら、ぜひこの動画を購入して見てやってください！

【動画】プログラマがコードを書きながら考えること 〜動画でわかるWebクローラー開発〜 - 伊藤淳一 @ BOOTH - BOOTH

おまけ

ちなみに、BOOTHには「ブースト」という機能があって、これを使うと購入金額を上乗せすることができます。

BOOST↑（ブースト）機能とは何ですか？ – BOOTHヘルプセンター｜よくある質問

画像の引用元: https://booth.pixiv.help/hc/ja/articles/230690927

この機能を使って金額を上乗せしてもらえると僕が非常に喜びますので、もしよかったらよろしくお願いします😆（もちろん強制ではありません！）

あわせて読みたい：銀座Rails #12の参加レポート

銀座Rails #12に参加したみなさんが書かれた参加レポート（または開催レポート）です。（みなさん、どうもありがとうございます！）
僕の発表に関する感想もあるので、動画の内容が気になる方はこちらも参考にどうぞ。

• 銀座Rails#12@DeNA行ってきました。 - Qiita
• 銀座Railsに参加した - tanaken’s blog
• 銀座Rails#12@DeNA に参加しました。 - yrinda
• #ginzarails 「プログラマがコードを書きながら考えること 」by jnchitoさんの観察ログ - 渡り鳥の旅路
• 【イベントレポート】銀座Rails#12@DeNA - bagelee（ベーグリー）
• 銀座Rails#12@DeNAに参加しました - よしにゃんのお部屋
• 銀座Rails#12を開催しました - とにかく何か書く

声をかけてくださった銀座Railsの河野さん、スポンサーのDeNAさま、リンクアンドモチベーションさま、どうもありがとうございました！

【DIY】妻のリクエストに応えてホールソーでキッチン棚の区切り板に穴を空けた話

はじめに

先日、妻が「トースターの位置が高くて使いにくいので、左のキッチン棚に移動させたい」と言い出しました。
ですが、左の棚にはコンセントがないため、そのままだと左の棚にはトースターが置けません。

・・・と言っても、何を言ってるのかわからないと思うので、写真で説明します。

はい、そういうことです。
（上の写真では左の棚は扉で隠れていますが、扉をスライドさせるとふつうに棚があります）

最初は「業者を呼んで左の棚にコンセントを追加してもらおうか」と妻と話してたんですが、「これ、そんなことしなくても、区切り板に電源コードを通す穴を空けたら解決するんじゃない？」というアイデアがひらめきました。
つまり、こういうことです。

手描きの完成予想図

が、問題は「どうやって穴を空けるか」ということです。
というわけで、この記事ではDIYで区切り板に穴を空ける方法を紹介します。

板をくり抜くならホールソーが便利（らしいのだが・・・）

ネットをいろいろ調べていると、世の中にはホールソーという便利道具があることを知りました。
ホールソーというのは電動ドリルに輪っか状の刃を取り付けて、それを回転させながら板に穴を空ける工具です。

makit.jp

「ほうほう、なるほど。これを使えば一発で穴が空けられるじゃないか！」と思い、近くのホームセンターで電動ドリルとホールソーを買ってきました。

リョービ(RYOBI) ドライバードリル CDD-1020 645801A

E-Value 木工用7枚刃ホールソー 20mm

さっそく電動ドリルにホールソーを装着して、「よーし、穴を空けるぞー！」と作業に取りかかったのですが・・・

ホールソーで穴を空ける準備万端の伊藤さん

まったく刃が立たない！！😂😂😂

本来であれば下の写真のように、先端のドリルが板に入っていくはずなんですが、どれだけ力を入れて押し込んでも刃先が板の表面でツルツル滑って先へ進みません。

本当ならこうなるはず！（画像の引用元: https://makit.jp/01968/ ）

これは困った！！せっかく電動ドリルまで買ったのに〜😣

先に下穴を空けておけば大丈夫？

そこで、弊社ソニックガーデンのメンバーに雑談ネタとして「かくかくしかじかで穴を空けられなくて困ってるんだけど、誰かいい方法を知らない？」と尋ねてみました。

すると、あるメンバーから「化粧板のように硬い板の場合は、先に細い下穴を空けてからやればいけるかも」という意見が挙がりました。

その意見を聞いて「なるほど、その発想はなかった。やってみよう！」と思い、もう一度ホームセンターに行って、下穴を空ける細めのドリルをいくつか買ってきました。

トップ(TOP) 六角シャンク テーパー下穴錐 ミニタイプ 電動ドリル用 ETK-2.5S

リリーフ(RELIFE) チタンコーティング六角軸ドリルセット鉄工用 6本組 21901

最初は一番細い2.5ミリの下穴錐を使って穴開けに挑戦してみました。
すると・・・おお、入った！
これだと結構すんなり穴を空けることができました。素晴らしい！

それから、3ミリと4ミリのドリルを使って少しずつ穴を広げていきました。
こちらも先ほどと同様、問題なく板を貫通していきました。

下穴は空けることができた。じゃあ、ホールソーは？

それではいよいよ、この記事の主役であるホールソーの出番です。
はたしてリベンジできるのか・・・！？

4ミリの下穴を空けてから、もう一度ホールソーを使おうとする図

では、やってみましょう。スイッチオン！

チュイ〜〜〜〜〜ン・・・・おお、いけた！！

下穴を空けてからホールソーを使うと、しっかり先端のドリルが板の中に入っていきました！
これならホールソーがホールソーとしてちゃんと機能しそうです。

ホールソーで穴を空ける途中経過です。これならいけそう！

そして、ついに・・・！！

それからホールソーでガリガリやること数分間。
ついに穴を空けることができました！ばんざーい！！🙌

逆サイドから見てもきれいに穴が空いてます。

これでトースターの電源コードもこのとおり！！

もともとイメージしていたアイデアスケッチのとおりに仕上がりました。

まとめ

というわけで、工事完了後のキッチンの全景がこちらです。
これまでは完全にデッドスペースになっていた左の棚を有効活用することができました。

今はこんな感じです（キッチン棚の扉は邪魔なので処分しました）

「業者を呼ばなくても自分でできた！」と、妻も喜んでいました😄

今回のDIYで得た知見は「板が硬ければ先に下穴を空けてからホールソーを使え」ということです。
みなさんもキッチン棚の区切り板に穴を空けたくなったときは、この記事を参考にしてみてください！

おまけ：妻が使っているトースター（小型オーブン）はこちら

ちなみに妻が使っているトースターはこちらです。

アイリスオーヤマ コンベクションオーブン 15L PFC-D15A-W

厳密にはトースター専用機ではなく、トースターとしても使える小型オーブンです。
妻はときどきこのオーブンを使ってパンやケーキを焼いています。

先日妻が焼いてくれたシフォンケーキです