リファクタリング について 考えてみて もらいたいスライド

https://bliki-ja.github.io/CodeOwnership/

https://bliki-ja.github.io/CodeOwnership/ コードの所有には、私が 今まで見てきたものだけ でも、いくつかの形があ る。ここでは大きく3つの カテゴリに分けてみた。

https://bliki-ja.github.io/CodeOwnership/ 強いコードの所有では、コードはモ ジュール（クラス、関数、ファイ ル）などに分かれており、それぞれ が一人の開発者に割り当てられてい る。開発者は自分のモジュールだけ を変更することができる。他の開発 者のモジュールを変更したい場合は、 モジュールの所有者に頼んで変更し てもらうことになる。または、パッ チを書いて送りつける方法もある。

https://bliki-ja.github.io/CodeOwnership/ 弱いコードの所有では、上記と同様、 モジュールが各開発者に割り当てら れているが、他の人のモジュールも 変更してもよいという点で異なる。 モジュールの所有者は割り当てられ たモジュールに責任を持ち、他の人 によって変更が加えられることに気 を配る必要がある。他の人のモ ジュールに大幅な変更を加える場合 は、きちんとそのモジュール所有者 に断りを入れるのがよいだろう。

https://bliki-ja.github.io/CodeOwnership/ コードの共同所有では、モジュール の割り当てそのものを行わない。 コードはチームの所有物であり、誰 もがどのコードにも変更を加えるこ とができる。コードの所有という考 えがが無いと考えてよい。ただ、 コードの共同所有を提唱する者たち は、個人ではなく「チームに」所有 されていることを強調している （チームによる共同所有は、エクス トリーム・プログラミングからきて いる。2版では「Shared Code」と呼 ばれている。）。

https://www.ketancho.net/entry/2018/02/22/080000 デイブは僕のチームにいる重要 な知識の塔だった。他の誰も追 いつけない、深い技術知識を 持っている人物だ。 (中略) デイブが2週間の休暇でいなく なるたび、僕が不眠になったの も仕方がない。

https://bliki-ja.github.io/

https://bliki-ja.github.io/CodeOwnership/ :リファクタリング（名詞）:外 部から見たときの振る舞いを保 ちつつ、理解や修正が簡単にな るように、ソフトウェアの内部 構造を変更させること。 :リファクタリング（動詞）:一 連のリファクタリングを行って、 外部から見た振る舞いの変更な しに、ソフトウェアを再構築す ること。

https://bliki-ja.github.io/CodeOwnership/ :リファクタリング（名詞）:外 部から見たときの振る舞いを保 ちつつ、理解や修正が簡単にな るように、ソフトウェアの内部 構造を変更させること。 :リファクタリング（動詞）:一 連のリファクタリングを行って、 外部から見た振る舞いの変更な しに、ソフトウェアを再構築す ること。 プロダクトバックログの観点 =内容(要件)が変わらないこと インターフェースの観点 ＝提供するふるまい(Behavior)が 変わらないこと

https://bliki- ja.github.io/IsHighQualitySoftwareWorthTheCost/

https://bliki- ja.github.io/IsHighQualitySoftwareWorthTheCost/ 顧客はこのソースコードを見る ことはなく、アプリの動作に影 響を与えないので、レベッカの ソフトウェアに余分な4ドルを支 払う人はいるのでしょうか？ もっと一般的に言えば、より高 い内部品質のためにもっとお金 を払う価値がないことを意味し ているはずです。

https://bliki- ja.github.io/IsHighQualitySoftwareWorthTheCost/ 内部品質の主な特徴の1つは、ア プリケーションがどのように動 作するかを簡単に把握できるよ うにして、どのように機能を追 加するかを容易に確認できるよ うにすることです。

https://bliki- ja.github.io/IsHighQualitySoftwareWorthTheCost/ ここでなぜ内部品質がユーザー や顧客にとって重要なのか、そ のヒントが見えてきます。内部 品質が良ければ、新機能の追加 が容易になり、その結果より速 くより安価になります。

https://bliki- ja.github.io/IsHighQualitySoftwareWorthTheCost/ • 内部品質を疎かにすると急速にクラ フトが蓄積されていく • このクラフトが機能開発を遅らせる • 優れたチームであってもクラフトを 発生させるが、内部の品質を高く保 つことによってそれを制御すること ができる • 内部品質が高いとクラフトが最小限 に抑えられ、チームはより少ない労 力、時間、コストで機能を追加する ことができる

内部品質が高いソフトウェアとは？？ • 読みやすい(適切な名前、役割の分割) • 開発者に理解されている(コードの共同所有) • 変更しやすい • テストされている、テストしやすい • 変更の影響が限定的である • 変更しなくても変化に対応できる

たとえば？ 1. まずは最低限動くコードを書く 2. 変数やメソッドの名前を気にする 3. 変数のスコープを気にする 4. If文をクラスで実現して減らしていく (デザインパターン) 5. 単一責任の原則を気にする 6. DI(依存性注入)を考える 7. データはデータベースに入れてコードの変更 を不要にする

https://bliki-ja.github.io/RollerSkateImplementation/ アジャイル開発の重要な特性として、 小さな機能サブセットに分割してシ ステムを稼動させる方法をあれこれ 考える、というものがある。 我々 は、ソフトウェアがもたらすビジネ ス価値のためにソフトウェアを構築 するのである。 システムの稼動が 早ければ、それだけそのビジネス価 値（の少なくとも幾分か）を早く手 に入れることができる。

https://bliki-ja.github.io/ContinuousDelivery/ 重要なポイントは、顧客から 今開発中のそのバージョンを、 すぐに本番環境にデプロイし ろ と言われたときに対応でき るかどうか、そして誰もパ ニックに陥らずに済むかどう かということだ。