はじめに
てくみー、てくみー、てっくっみー♪ nikkieです。
12/21(水)に「技術的負債の返済から改善する開発者体験 - Techmee vol.5」がオンライン開催されました。
mtx2sさんのゲスト講演が気になりそこだけ参加し、以下にレポートをまとめました。
今回はこの講演を聞いて考えたことをアウトプットします。
目次をご覧ください！大きく3つあります。
目次
1️⃣『Clean Architecture』は構造の価値を説く！
第2章と第15章が参照された『Clean Architecture』。
ソフトウェアには「振る舞い」と「構造」という2つの価値があると指摘されます。
ソフトウェア開発者には、この2つの価値を維持する責任がある。残念ながら、片方だけにフォーカスすることが多く、もう片方が無視されてしまっている。 (Kindle の位置No.488-489「第2章 2つの価値のお話」)
Uncle Bobの主張は、この2つのうち価値が高いのは「構造」、なぜなら構造がソフトウェアをソフト（振る舞いを変えられる）にするから。
しかし、開発者は「振る舞い」にフォーカスすることが多く、「構造」の価値を無視している。
我が身を振り返っても、ぶっ刺さりますね。
「振る舞い」にフォーカスした結果、「この振る舞い、変えにくすぎじゃない？」と私の関心は「構造」に向かったわけなのですが…
話を戻すと、「構造」、すなわち、ソフトウェアをソフトたらしめる要素に注目を集めたく、『Clean Architecture』が書かれたんだなあ、と気付きました。
タイトルのArchitectureは「構造」と近い単語1だと思いますし、（通読してはいないですが）この本では「振る舞い」の話はあまり出てこないように思います。
第2章は、振る舞いだけにフォーカスするのではなく、開発者は構造の重要性を主張する（＝闘う）必要があると説かれます。
そして、「第15章 アーキテクチャとは？」では、優れたアーキテクトが行うこと2つが説かれます。
それを語る上で、「形状」という言葉が使われます。
ソフトウェアシステムのアーキテクチャは、それを構築した人がシステムに与えた「形状」である。(Kindle の位置No.2193-2194)
これは、ソフトウェアのアーキテクチャの選択肢の内、選び取られ具体化した1つといったような意味合いなのかなと思われます。
形状は目の前にある（開発者には知覚できる）のです。
第15章を読み進めると、優れたアーキテクトのやることの1つはこちら2
アーキテクトの目的は、方針とは無関係に詳細を決めながら、方針をシステムの最も重要な要素と認識するシステムの形状を作ること (Kindle の位置No.2271-2272)
方針は「ビジネスルールや手順」、詳細はIOやデータベースやフレームワークなど。
『Clean Architecture』で説かれることの1つには、雑に言えば「ビジネスルールをフレームワークに依存させないようにしよう」というのがあると思いますが、その根拠がこのあたりなのですね。
第2章・第15章を改めて読み直して
Uncle Bobはこう言っているという私の理解です
- 「振る舞い」より「構造」の価値が大きい
- 構造については、方針を最も重要と認識できるようにシステムの形状を作る
- 具体的には、方針が詳細に依存しない
2️⃣ウォード・カニンガムが言った意味の「技術的負債」
イベントレポートでも触れたトピックですね。
「もしも自分たちが書いているプログラム（WyCash）を、金融の世界に関する正しい捉え方だと自分たちが理解した姿と一致させることができなくなれば、自分たちは絶えずその不一致につまずき続けることになり、開発スピードは遅くなっていくでしょう。それはまるで借金の利子を払い続けるかのようです」と説明したのです。
ウォード・カニンガムが使った意味では、開発者の理解とソフトウェアが一致していない状態が負債です。
私は、ソフトウェアを急いで世に出して学びを得たにもかかわらず、その学びをプログラムに反映しない、つまり借金で言えば全く返済をしないケースが多々あると考えています。
技術的負債を返済しない（学んで更新された開発者の理解とソフトウェアの間の不一致を解消しない）状態への言及ですね。
ところが、「技術的負債」は原義から離れていきます。
カニンガムもこの点に言及しています。
多くのブロガーが負債のメタファーのことを、後できれいに書き直すつもりなら雑なコードを書いてもいいという考え方と混同し、かつその考え方こそが負債の原因であると説明しています。
私は雑なコードを書くことには全く賛成しませんが、たとえ理解が不完全だとしても、目の前の問題に対する現時点での理解を反映するコードを書くことには賛成です。
「後できれいに書き直すつもりなら雑なコードを書いてもいいという考え方」、こちらのほうが一般的という感覚が私にもあります。
この考え方を実行するタイミングは来ないよということは、例えばt-wadaさんの「質とスピード」でも説かれますね（市場に出した後は次の開発に進まざるを得なくなる）
我が身を振り返っても、カニンガムの主張に賛成です。
しかし、この意味は多数派ではないので「技術的負債」という言葉を使った意思疎通がやりにくい感覚です（バベルの塔！）。
勉強会中のツイートから興味深いものを見つけました。
最近読んだ『技術的負債じゃなく、もはや技術的不良債権』に出てきた内容で良かった。https://t.co/3QUrIjIAOr#Techmee
— nwiizo (@nwiizo) 2022年12月21日
ウォード・カニンガム自身による説明を読み直して
- 開発者の理解とソフトウェアが一致していない状態が技術的負債
- 返済しよう（開発者の学びをソフトウェアに反映しよう）
- 一般的な理解は「後できれいに書き直すつもりなら雑なコードを書いてもいい」
- カニンガム「私は雑なコードを書くことには全く賛成しません」
3️⃣クイック&ダーティ
技術的負債の4象限3で、「意図的・無謀」と説明される象限の呼び名としてmtx2sさんから紹介されました。
関連して思い出したことが2つあります
Readable vs Hacky
思い出したのが『読みやすいコードのガイドライン』の第1章「可読性の高いコードを書くために」。
コードを書く戦略を
- Readable：「時間をかけて読みやすいコードを書く」
- Hacky：「その場しのぎのコードを短時間で書く」
とすると、評価の仕方によっては4、合理的な選択としてチーム全員がHackyを選んでしまうと指摘されます（Readableなコードを書く戦略が活きるには評価の仕方もポイントなんだなあという学び）
錯覚の進捗
ケント・ベックの『エクストリームプログラミング』（第2版）の計画に関する章（12章）では「錯覚の進捗」という語が出てきます。
例として、速度、品質、価格の3変数で管理するプロジェクトがあります（※これはうまくいかない例として登場します）。
スポンサーは「速度」と「価格」を固定しようとし、開発チームが操作できるのは「品質」です。
品質を下げても、作業がなくなるわけではない。(略)
錯覚の進捗を生み出すことはできるかもしれない。
だが、満足度の低下と人間関係の崩壊という代償を支払うことになる。(Kindle の位置No.2035-2037)
「雑なコード」を書く、これがワークする状況も一定程度はあるのかもしれませんが、私の文脈においては「錯覚の進捗」につながることが多いなという経験をしてきています。
私はどうしても雑に書きたくないのですが、それは未来の自分に「（伸びしろはいくつもあるのは承知しているけど、でも）ここはこういう意図を込めて当時の全力でやったんだぜ！」と胸を張りたい（満足度を下げたくない）からかなと思うのです。
「錯覚の進捗は満足度の低下を引き起こす」、これを『エクストリームプログラミング』から学んだわけですが、自分が関わっているコードベースに「これ、錯覚の進捗じゃない？」という箇所を見つけたときどう動くべきなのかは、答えを持っていない領域です。
このあたりは書籍にはない話だと思いますし、今はまだ指針もわからないなあという感じですね。
mtx2sさんの講演に戻ると、(2)クイック&ダーティの象限をどう脱するのか、このあたりの具体的な話（事例）はめっちゃ聞きたいですね。
Hackyの話もあるので、評価システムといったところまで関わるかもしれません。
終わりに
「技術的負債が開発者体験を悪化させる」を聞いて考えたことをアウトプットしました。
このエントリは、いまのnikkieはこう考えているというバックアップの意味合いがメインですね。
最近これを言う人はあんまりいない気がするけど、古の言葉に「ブログを書くまでが勉強会です」というのがあります。自分の思考の整理になったり後々読み返せる記録になったりするので、SNSに書くだけじゃなく、ちょっとした文章でもいいのでブログに書くのをお勧めします。#pyconjp
— Ryuji Tsutsui (@ryu22e) 2022年10月15日
積ん読を部分的に崩し、自分の中でも知識が繋がって楽しい時間でした。
発表、ありがとうございました！
アーカイブはこちらから。
- 『Clean Architecture』では「振る舞い」と近い単語が「機能」、「構造」と近い単語が「アーキテクチャ」かなと思います↩
- もう1つは「詳細の決定をできるだけ後回しにできるようにする」ことです。こちらはPyCon JP 2021座長で参考にしました。https://ftnext.github.io/2021_slides/stapy_Dec/pyconjp2021_secrets.html#/↩
- TechnicalDebtQuadrant↩
- 書籍の例では、機能の開発速度をそのまま個人の評価とします。たしかに短時間で書く方向に進みそうですね↩
