【保守・運用のお勉強】レガシーコードからの脱却を読んだ感想

読んだので勢いのまま感想を書いていきます。

※この記事のまとめは「それって個人の感想ですよね」です。詳しくは書籍を読もう！

レガシーコードからの脱却

>>Amazonのリンク

読んでみてふんわり思った感想

• チーム全体の技術力を高めるメソッドが豊富！
• リーダブルコードを先に読まないとリファクタできないかな！
• 「コードを書くより読む時間のほうが圧倒的に多い」はすごい共感！
• テストコードをちゃんと書こう！ドメインは日々変化するので古いテストコードも見直そう！
• リファクタのタイミングは実はたくさんある！
• チームのスキルがあがればプロダクトのリファクタも捗る！

どういう人が読んだほうが良いか

どんな人も読んだほうが良いとは思いますが、

IT企業の組織作りに関わっている人や

アジャイル開発に関わっている人は

特に読んでみても損はないかなと思いました。

どういう組織が実践できそうか

テストファーストの内容が多々書かれているため

テストコードを書く文化のある組織が実践可能なります。

SIerとかでたまにいるおじさんたちの

「テストコード何のために書くの?いらなくない？」

などとテストコード不要論を唱えている組織では

たぶんこちらの本の知識は意味を成しません。

ただ、知識自体は非常に役立つ知識のため、

この知識を使うことができる組織に転職したほうが良いと思います。

レガシーコードからの脱却：1章のまとめ

「ウォーターフォール」よりも「アジャイルがいいね！」的なこと。

• ソフトウェアの作り方や保守の仕方を間違えている！特にウォーターフォール！
• 機能をまとめてリリースするのは非効率
• ウォーターフォールのプロセスはレガシーコード製造機
• ソフトウェアエンジニアリングはすべての開発者の原則やナレッジの体系ができていない

レガシーコードの定義とは？

この書籍曰く

“テストコードのないコードがレガシーコードと定義している“

とのこと。

フロントエンドは頻繁に変化しがちなので

テストコードを書くか悩むこともありますが

バックエンドは必ず書いておいたほうが良いでしょう。

ウォーターフォールは製造業向け

予め流れてくる完璧なパーツを

受け取り組み立てて次に流す。

次の人はそれを受け取り

一部分を作り、それを繰り返し

製品をつくる。


「コンベアシステム」であれば

ウォーターフォールは機能する。

ただし、プロダクトの開発の場合

作ってみてその場にならないと

分からないことのほうが多い。

ウォーターフォールは

変更がきかないので二次開発などに見送るか

リリースまでに機能追加をすることになる。

ただし、時間は待ってくれない結局

他の機能を慌てて作り

質が下がるか最悪の場合

リリースすらできなくなる。

ウォーターフォールモデルよりも

アーキテクトに力を入れる必要がある。

ウォーターフォールの欠点

ウォーターフォールは設計が終わったらその設計を変更したがらない。

テストは時間とお金がかかる。

そのためまとめて一気にやろうとする。

結局、哲学的には正しいのであるが、

テストを最後にやることは困難を避けているだけで

最後に会心の一撃などのカウンターをくらうリスクを

背負った一か八かのギャンブラーみたいなものだ。

先にテストをして痛みが分かればまだ時間はあっただろうに。

コメントは「何をしているか、ではなくなぜそうしたのか」を書く

「コメントと実際のロジックは同期がとれていますか？」

例えば、「ここでプラス1する」みたいなコメントは「何をしているかはわかるけれど、なぜそうしたの？」と日本語だけ見たら疑問に思うでしょう。

未知を見積もる

やったことのないことを見積もるのは難しい。

そして見積もりと実際の作業での時間の使い方や分析に重きを

おいてしまう、それはプロダクト開発の本質ではない。

ベクトルが間違っている。

レガシーコードからの脱却：2章のまとめ

「システム開発の市場のお話とコードの変更・失敗などのコストのお話」

• 非効率なやりかたはビジネスにおいて大きな損失をもたらしている
• CHAOSレポートは本質的な問題があるが、「解決する道のりは長い」は正しい
• アメリカは間違った開発プロセスを用いた場合、毎年100億ドルは損していると指摘した
• コードを書いて時間が経てばどれもレガシーになる。レガシーにさせている分、その責任は私たち自身でとろうね。

プロジェクトの失敗要因

要因を分析すると以下の3つがキーワードになる。

• コードの変更
• バグの修正
• 複雑さの扱い

コードの変更

保守運用の場合

「コードを書くよりも読むことに多くの時間を使う」

変更できないコードを書いてしまった場合

小さい機能追加でも場合によってはシステムの根幹部分だったりする。

その場合はすべて再テストが必要となる。

「機能を追加する前に、いまの設計を理解しよう。とりあえず機能を追加しましたは、危険。」

「ただし、設計があかん場合、拡張はむずかしいよね。」

バグはなぜ発生するのか？

開発のプロセスに欠陥があるかららしい。

バグを見つけるのもそもそも難しいらしい。

HSPの私はよく見つけているけれども。。

一生懸命作った機能も実は・・・

使われていない機能も存在する。

設計のミスかな。

ちょっと良くなるかも！と

そんなに時間をかけずにちょっと付け足した小さな機能追加も

お客様の要件にないし、誰も使っていない。無駄になってしまうので

そしてその保守運用コストだけがかかる。

無駄なものになってしまったということになる。

レガシーコードからの脱却：3章のまとめ

「アジャイル入門のお話」

• 現状の課題は多いが新しい考えによりソフトウェア業界は正しい方向に動き始めている
• アジャイル開発手法はウォーターフォールに代わる選択肢、開発コストを削減する
• ソフトウェアを作る開発技能と開発の独自要求める芸術バランスを学ぶ必要がある
• アジャイルが漸く浸透してきた、浸透するまでに15年かかった
• 開発者もマネージャーも技術を学び、意図的に質の高いソフトウェアを作るべき

アジャイルのプロセスの中心にあるもの

「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供」するという約束

テスト駆動やペアプロの技術プラクティスを取り入れることによって

デプロイ、運用、拡張がしやすい変更可能なソフトウェアを作ることができる。

スモールゴールの設定

ソフトウェア開発は、最初はゴールが全く見えない。

見えていても「目的」だけで、どんなルートかもわからない。

ウォーターフォールは「だいたいこんな感じのルートがあって・・・」と

想定だけが先にいく。

アジャイルはとりあえずそのルートに進んでから考える。

そのとりあえずがスモールゴールとなる。

アジャイルの実践に必要なスキルとは

「仕様」に関しては「目的や理由」の話ができるようなコミュニケーションをとるようにする。

コードの品質に焦点を当て、保守可能なソフトウェアを作るのに役立つようなプラクティスの採用。

例えばリーダブルコードやエクストリームプログラミングの知識は必須。

あと実は左脳をつかって論理的思考や数値分析をおこなっているが、

右脳で想像や芸術などの観点も必要となる。

ユーザーがどういう想定で使うかな？というお客様目線で物事を考えるのは

もろ右脳だからかな。

レガシーコードからの脱却：4章のまとめ

「人間は健康寿命を延ばそう、自社サービスも寿命を延ばしながら価値を高めよう」

• 使われるソフトウェアは変更が必要となるのではじめから変更しやすいコードを書く
• 正確なものを作るには「理解」が必須
• すごいエンジニアになるには必要なスキルは全て学習しよう
• 必要な変更をすべて予測するよりも、変更となったときに対応できるプラクティスやレジリエンスを身に着けよう
• 課題を発見したときは背景から理解するように心掛ける

4.9「9つのプラクティス」

ここの9つのプラクティスが

レガシーコードへの脱却の本質かなと思いました。

ぱっと思い出すと6個ぐらい思い出せました。

• 理由・目的・誰のためにを意識する
• ほかのチームと協力する
• CI/CDを回す
• CLEANを意識する
• テストコードを書く
• 積極的にリファクタリングする

残りは本で確認してくださいませ←

レガシーコードからの脱却：5章のまとめ

書籍にタイポを見つけた気がする

• ソフトウェアがどう作られるよりも何をすべきかに注目することによって開発者は最良の実装を発見できる
• 品質の高いソフトウェアを作るために、周りの人達との接し方を知る必要がある
• 目的、理由、誰のためかを表現するために、実装の詳細を説明することを捨て、機能を定義するためのきわめて重要な会話に代えていくことで開発が発見のプロセスになる
• 敏腕プロダクトオーナーは受け入れ基準が明確に定義された良いストーリーを書く
• もっと効果的に機能を作って、開発にあてる時間を全体の1/3にまで回復しよう。要求の記述を減らし、プロダクトオーナーと開発チームで協調性を生み出していこう

ユーザーストーリーの組み立て方の重要性

何が、何のため、誰の為に存在して、その年齢層は、それをすることによってどうなるのか

メリットは、デメリットは、などいろいろと私も考えて実装することが多いです。

そんなことが書かれていました。

プロダクトオーナーの役割

目的の共有、ユビキタス言語などで伝える。

質問に対しては素早くこたえる。

積極的にリファクタを後押しする。

他にも役割はありますが、そのぐらいできれば

割と素敵なオーナーなんじゃないかな。

テストはどうするべきか

受け入れ基準やそのテストは何すればクリアなのか、

自動化できる部分はないかなど

ゴールを明確にして、効率化できる部分は

していきましょって感じ。

レガシーコードからの脱却：6章のまとめ

ホリエモンさんの「ゼロ」みたいなことが書いてある。小さくても良い。前に進もう。

• 納期がソフトウェア開発プロセスを決定すること
• 自分の時間がもっとコントロールするにはどうしたらよいか
• 小さなタスクほど、見積もテストも簡単で、扱いやすいこと
• 機能を観察可能なふるまいに分割する方法
• タイムボックスで進められるようになったら、スコープボックスを習得すること。スコープボックスとは、タスクを小さくして扱いやすいものに分割すること

洋服ダンスよりも小さな収納ボックスのほうが確かに扱いやすいね。捨てたり引っ越しするときにコスト削減できるし。

小さく作り数値を出して分析して効率化

小さく作り、依存関係もなるべく減らして

小さく作るまでの時間や

テストをする時間、

ビルドにかかる時間、

これらを計測して最適可能なものは

どんどん改善していこう。

小さいからシンプルにできるはず。

レガシーコードからの脱却：7章のまとめ

• コードを書くたびに統合テストをすることでソフトウェア開発に伴うリスクを削減できる
• 統合テストが苦痛になるため、ウォーターフォールでは統合テストを延期し、リスクと変更のコストが増大する
• フィードバックサイクルを短くすることで、開発者の行動の結果がすぐに把握できるようになる
• 継続的にデプロイできることの重要性を理解すれば、タスクの自動化方法を探し、機能の相互採用について即座にフィードバックを得るために継続的インテグレーションを活用することができる

完了しました！はまだ未完了です

本当の完了のゴールは

「保守可能なクリーンなコードでビルドが落ちない状態」です。

つまり、「自分のマシンで動いた！」だけが

完了ではありません。


アジャイルインフラストラクチャーの

お話がここではメインです。

リスク分散のための戦略なども。

まぁよくあるWeb系自社サービスを持っている会社なら

たいていのことはやっていそうだなと思いました。

レガシーコードからの脱却：8章のまとめ

「この章が保守運用チームには一番重要なのでは？」

• 質の高いコミュニケーションとチームへの知識拡散のために適切なテクニックをすぐに使う
• ペアリング、スパイク、スウォーミング、モブなどのさまざまな協働スキルを使う
• 未知の探求、学習の増幅、知識の伝搬に、協働スキルは役に立つ
• コードレビューとレトロスペクティブからフィードバックを受け、フィードバックを活かして行動しよう
• 常にメンターであり、メンティーであれ。自分とチームのスキルを上げていこう

協力してお仕事をするとは

ペアプロ、モブプロ、スウォーミング、勉強会など

チームのスキルアップを全体的に上げる方法が

書いてある。成長する企業はみんなここらへんを

やっているのではないかなと思いました。

エクストリームプログラミングを

再読したくなりました。

レガシーコードからの脱却：9章のまとめ

• 凝集性のあるコードは副作用を減らす
• 疎結合なコードはテストが容易である
• カプセル化されたコードは簡単に拡張できる
• 断定的なコードによってソフトウェアがモジュール化される
• 非冗長なコードは保守の問題を減らす

CLEANなコードを書こう！

エクストリームプログラミングと

ドメイン駆動設計とリーダブルコード、

これらの知識が必要となる章。

あれです、ミニマリズムやシンプリズムを

コードに取り入れている感じですね。

責務を大きくしないように。

レガシーコードからの脱却：10章のまとめ

• テストファースト開発の方法とそれをする理由
• あまりにも多くのテストを書いたり、実装依存のテストコードをかいたりするとテストファースト開発は失敗する
• テストはコードのリファクタリングをサポートする必要がありふるまいを表すテストだけを記述する
• テストファーストはQAに役立つが、QAに代わるものではない
• テストファースト開発は失敗するテストを作成し、合格するのに十分なコードを書くことで機能を作る。そのあと、必要に応じてリファクタリングし、失敗する別のテストを書くことを繰り返す

出ましたテスト駆動

参考書に

問題は書いてあるけれど

回答が付いていない状態が

テストコードがない状態。

参考書に

問題が書いてあり、

当たり前のように回答と解説が書いてある状態

これがテストコードのあるサービス。

テストコードがあれば

自分のロジックに素早くフィードバックがくるので

ありがたいね。

レガシーコードからの脱却：11章のまとめ

「テストコードは仕様書だからしっかり書いてほしいよね」

• テストスイートを使用して、ふるまいを記述し確認する方法
• テストを活用することで、目的を明確に説明できるようになるとともに、それらが生きた仕様になること
• テストは「セーフティネット」を提供してくれる。それによって、リファクタリングが可能になり、間違いがすぐにわかるようになること
• ふるまいのテストを書くことで、書くべきテストの種類と数を常時把握できること

テストコードの効率的な手法が書かれております。

この通りなのですが、さくっとテストコードの効率的な手法が書かれております。

この書籍で足りない知識はテスト駆動設計の本やスライドを読み漁り

とにかく手を動かすことが大事だなと思いました。

レガシーコードからの脱却：12章のまとめ

「テストコードが仕様書です(2回目)」

• 品質は保証できない。品質は作り出すものだ。品質を検証するのではなく、作りこむことに集中しよう。
• 読みやすく理解しやすいコードが、柔軟で変更しやすい(ゆえにコストパフォーマンスも高い)
• 意図を示すプログラミングは観点の凝集につながる。抽象のレベルがそろい読みやすく理解もしやすい
• オブジェクトの生成と利用を分離することでテスト容易性を改善し、依存性を下げよう
• 創発設計は初心者向きではない。品質とテスト容易性に不断の注意を払う必要がある

設計を最後に？なんで？

テストコードが仕様書となるため、

テストコードを書いてロジックを書いて

全てパスしてビルドもうまくいった。

そこから設計を書いたほうが

良い場合もある。

設計してコード書いて

バグが見つかって設計を直して

コードを書いてまたバグが見つかっての

ループになってしまうよりも効率的。

設計書を修正する時間を減らすことができるから。


あと、コードを書く時間よりもコードを読む時間のほうが

多いという言葉は保守運用をやっていると

本当にその通り！と納得した。

レガシーコードからの脱却：13章のまとめ

• 技術的負債を返済するためにコードをクリーンアップする効果的な方法
• 機能追加の前準備と、実際の機能の追加を切り離すことで、作業が大幅に単純化されバグ発生リスクが減ること
• コードを効果的にクリーンアップする方法と、ソフトウェアをつくるときに設計を改善することが重要な理由
• リファクタがうまくなれば、クリーンなコードを自然に書き始めるようになる

リファクタのタイミングとか勉強になった

リファクタのタイミングは以下、割と引用

• 重要なコードがうまく保守運用されていないとき
• コードを理解している人がいなくなったとき
• 新しい情報によって良い方法がみつかったとき
• バグを修正するとき
• 新機能を追加するとき
• docを書くとき

大きくリファクタするよりも

小さい単位でリファクタしていこう！

レガシーコードからの脱却：14章のまとめ

エクストリームプログラミングと似たようなことが書いてある。

関連記事

• 保守運用フェーズのときは迷わずこれを読もう！オススメの読んで良かった書籍3選。
• 【読書のアウトプット】XPエクストリーム・プログラミング実践記から得た学び
• 【保守・運用のお勉強】リーダブルコードを読んだ感想。メンテナビリティを向上させよう！