「がんばりすぎない設計判断を支えるリファクタリングとリアーキテクティング（仮）」

2021.06.18

オファーレター

お題ですが、「Railsエンジニアのためのソフトウェア設計入門」的なものをと考えておりまして、

Railsしか触ったことがないエンジニアが、設計に対して視野を広げるために、

何を学んでいったら良いかの指針を得られる内容だと嬉しいなぁ思っております。

お願いしようと思ったきっかけは、

最近現場の若手のエンジニアの方が、Railsを触りつつも、

設計というものについて意識が高まっていることを感じておりまして、

ぜひ和田さんにお話頂けたらなと思った次第です。

講演録

生煮えの新作講演

依頼内容

若手のエンジニアに発想のヒントとなるような、抽象度高めの、色々なところにポインタを張ったような話を

前提

ITは事業のコアになった

ソフトウェアがハードウェアのおまけだった時代の終わり

ところてん(@tokoroten)

なんとなく、DXという言葉に対しての引っかかりが理解できてきた気がする

「デジタル」という言葉に「アジリティ」という意味が含まれていないので、

「変更容易性の高いソフトウェアによるアジリティの獲得」というDXの本質がソフトウェアエンジニア以外には伝わってない感じなんだな

パスが遠いので、つなぐための材料を提供する

この本を題材に過去に公演したことがある

仕様の変更や、既存の仕様のより深い理解、また新たな技術、よりよいアイデア、環境の変化などに適応してシステムを変化させるプロセスである

Code Qualities →？→Emergent Design

組み上げたピラミッド

ソフトウェア業界は様々なピラミッドを生み出している

https://gyazo.com/525b0d880b2c6d29a5460182842651ac

コードの質

テスト容易性

理解容易性

変更容易性

保守性の低さがもたらすもの

ひとつひとつの変更に余計な時間がかかる

内部品質への投資の損益分岐点は一か月以内に現れる

病理学

悪かった部分の振り返り

気づき方

名前をつけるのが難しい

長いテストコード

長いプロダクトコード/メソッド

もやっとしたものに名前をつけて整理する

叡智

単なる知識ではなく、知恵とか英知と言われる領域

I should think that you Jedi would have more respect for the difference between knowledge and... heh heh heh... wisdom

Wisdom

先人の知恵

巨人の肩

原則

プラクティス

スタイル、名前、道具

Testability

Observability

Controllability：テスト対象の動かしやすさ

Isolability

Deployability

Smallness：対象が十分に小さいこと

Singularity

Level of abstraction

Efficiency

Reuse

実行円滑性

観測用意性

制御

リファクタリング（名）

外部から見たときの振る舞いを保ちつつ、理解や修正が簡単になるように、ソフトウェアの内部構造を変更させること

保守性を上げていくこと

後からでも保守性をじわじわと上げていくというアプローチを可能にする

安全にリファクタリングをする仕組みが必要

リファクタリング（動）

一連のリファクタリングを行って、外部から見た振る舞いの変更なしに、ソフトウェアを再構築すること

語彙、形式、共有

共通した形に名前をつけて、カタログ化して、学べるようにしていく

カタログ化して暗記するだけだと知識止まりで、叡智にならない

他にも

かつては、設計の最初から導入するものだった

現在では、パターンはリファクタリングのターゲットになった

状況に応じて、その時々の保守性を最善にするための手段を提供してくれるもの

パターンとリファクタリングはつながる

https://www.youtube.com/watch?v=Q-FJ3XmFlT8

ユニットテストとリファクタリングを組み合わせて、繰り返し、回転させるもの

プログラミングから連続したところにアーキテクティングがある

TDDをYAGNI原則に則って厳格に行うならば、3イテレーション目でアーキテクチャが破綻するであろう

いつどれだけやるのがいいのか？：スイートスポット

ソフトウェアの規模

変更の頻度

技法の列挙は、始まりにすぎません。それは、通り抜けなければならない関門です。技法なしには、実際に動くプログラムの設計を行えません。技法があってもできないことには変わりませんが、少なくとも出発はできます。

こうしたすべてのすばらしい技法が、なぜ始まりにすぎないのでしょうか。その理由は、これらを使うべきとき、使うべきでないとき、始めるべきとき、やめるべきとき、進むべきとき、待つべきときを、皆さんはまだご存知ないからです。リファクタリングに寄与するのはリズムであって、個々の音符ではないのです。

それを実際に体得したと実感するのはどんなときでしょうか。それは、皆さんが諦観 (calm down)を身につけ始めたときでしょう。それは、誰かの書いたコードがどんなにぐちゃぐちゃでも、それを改善し、進化し続けるようにできるという、絶対的な自信を感じるようになるときです。

20年の時を経て

アジリティーというものは、現実の世界やソフトウェア開発の世界の双方において、変化に対応する、すなわち何らかの行動に出た後で遭遇する未知なる物事に対処するということなのです。

（p.334）

リエンジニアリングの3つの選択肢

20年で一周するように作り替える

全体のシステム（系）を破壊せずに新たに作り直すか？という観点

（引用転記間に合わず）

アジリティの本質

優れた設計によって変更が容易になる..（引用転記間に合わず）.p.336

変更容易性の高いソフトウェア→アジリティ

ようやく繋がった

TDDは、設計のひらめきが正しい瞬間に訪れることを保証するものではない。しかし、自信を与えてくれるテストときちんと手入れされたコードは、ひらめきへの備えであり、いざひらめいたときに、それを具現化するための備えでもある。（p.83）

本人の言及

Takuto Wada(@t_wada)