「レガシーコードと対峙する方法を考える」から半年

2014/03/25にあったDevLOVE関西「レガシーコードと対峙する方法を考える」で、話した時のスライドをシェアしてみました。

レガシーコードと対峙する方法を考える - DevLOVE関西 | Doorkeeper

発表の内容としては、現場のひどいコードにどうやって単体テストを入れているかみないな内容です。レガシーコード改善ガイドの実践編みたいな感じです。

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

はじめての社外での発表で、あまりに発表するのが怖く、最初にモザンビークネタで話を惹きつけようとかいろいろ小細工しています。今、考えるとレガシーコードに悪戦苦闘している者として普通に発表すればよかったなと思うのですが・・・。そんなこともいい経験だと思うので、資料は会社の情報に関係する部分だけ修正して、そのまま上げました。

あれから半年たって、状況は随分と好転した気がします。好転したと言っても、レガシーコードがなくなったわけではないです。

当時を振り返って、今、思うことは悪いのはレガシーコードではないということです。ソフトウェア作成のプロセスの問題、人のマネージメントの問題、コミュニケーション能力の問題、いろいろな問題の結果がひどいコードとして見えていただけで。冷静に考えると、コードに対する八つ当たり以外のなにものでもないなあと思います。混乱したプロセスからレガシーコードが生まれて当然です。これはソフトウェア開発に限った話ではないのかもしれませんが。

私の経験が誰かの役にお役にたてばいいなと思い、半年の振り返りを書いておこうかと思います。 

好転した理由

１．XDDPとの出会い
２．育児時間短縮勤務

この２つです。

今の取り組んでいることは、

PFD・USDMでTDDを安定させることです。

そして、社内のレガシーコードを制御可能なコードにすることを目標にしています。

１．XDDPとの出会い

勉強会に参加していただいた方から、

(感想)というかやってること、XDDPに近いな。ドキュメントがテストコードに変わってる感じ。

言うメッセージをいただき、XDDPを知りました。

レガシーコード改善ガイドに紹介されている『仕様化テスト』の実践例の発表に対する感想だと思います。

既存コードをテストで保護⇒テストに保護され安全に変更

たぶん、XDDPの既存資産を調査して仕様を抽出する「スペックアウト」という作業を指しているのかな？と思っています。

それでXDDPに興味を持って、XDDPを知るために『「派生開発」を成功させるプロセス改善の技術と極意』を読んでみました。 

「派生開発」を成功させるプロセス改善の技術と極意

 その流れでAFFORDD（派生開発推進協議会）に入会

派生開発推進協議会（AFFORDD）

いろいろしているうちに、AFFORDD関西部会に入会。
そこでいろいろ話をいろいろ聞けたので、職場にXDDPを取り入れてみました。

今、やっていることは、

・PFDで自分の業務を見える化
・自分の影響の及ぶ範囲の仕様書はUSDM形式の仕様書に切り替える

まだまた、使いこなせているというレベルには到達していませんが、今の自分の問題にはすごく会っているような気がしています。

何がよかったのか？
・絡まってしまった問題を解きほぐす方法と、再構築する方法

・目的別に整理して表現する方法

この２つが示されていたことです。 

・絡まってしまった問題を解きほぐす方法と、再構築する方法

PFD（プロセス・フロー・ダイアグラム）

これはソフトウェアの作成まのでプロセスの見える化する簡単な図です。今まで自分の仕事を誰かに引き継ごうと思うと、自分と同じ、経験・知識のある人でないと駄目だと思っていました。ここで言う経験・知識はコーディングやソフトウェアの知識ではなく自社製品・製造工程などです。

でも、入社10年のベテランに域になってくると、社内に自分以上の経験・知識のある人なんてほとんどいないです。それがPFDでプロセスを分解することによって、このプロセスは業務の知識、このプロセスはコーティング、このプロセスはテストと分解することが可能になります。結果的に、いろいろな人に仕事を割り振ることが可能になりました。

後、今まで時間がないと思っていた正体がこれで分かった気がします。
ソフトウェアの作成ってコーディングだけじゃなんですよね。当たり前のことですが、エラーの修正するにしても不具合の再現、関係者に話を聞く、社内の処理、などなどコーディング以外の作業が意外といっぱいあります。今までもコーディングの工数は結構正確に見積もれていたのですが、その他の工数を考慮出来ていなかった。そして見積りに失敗して、結果的にどんどん時間がなくなっていることに気が付きました。

一度、PFDに書き出してみると、自分のやっていることがよく分かります。まだ、ここまでは出来ていないのですが、自分のプロセスを振り返って自分の作業プロセスの再構築が可能かな？と思ています。

・目的別に整理して表現する方法

USDM形式の仕様書です。

USDMは、

①要求仕様書⇒（Why、What）：何を変えることが求められているか？それはなぜ？
②トレーサビリティマトリックス⇒（Where）：どこを変えればいいか？影響の確認
③変更設計書⇒（How）：実際にどのように変更するか？

の３点セットで構成されます。 

書類を書くことに対していろいろな意見はあると思います。でも、要求を正しく理解しているか？確認するには、何らかのアウトプットをするしかありません。今までは、コーディングでアウトプットしテストで間違っていることが分かるという感じでした。

私の感覚ですが、プログラムは1回目より2回目、2回目より3回目の方がよく書けます。そう意味では、一回目に変更設計書として頭の中を出力するのはいいのではないかと思います。ただ、プログラムする人と変更設計書が違う場合はあまり意味がないと思いますが。

今までお願いする場合、ほとんと作業の丸投げしか手段を知りませんでした。USDMによって要所、要所で確認が可能になり丸投げしてテストでNGでなく、要所、要所で確認してサポート出来るようになったのは大きいと思います。

２．育児時間短縮勤務

今年の４月から、１６時半に子供を保育園に迎えに行くために、８:３０～１５：１５の６時間勤務をしています。もちろん残業はしていません。

今までのやり方で６時間で仕事が終えるのは不可能で、仕事のやり方を１８０度変える必要がありました。

今まではどんどん仕事を抱え込んでいくタイプでした。「出来ない」と言うのが苦手で、人に仕事をお願いするのが苦手でした。それで、どんどん自分で仕事を抱えて、そのイライラの矛先がレガシーコードに向かっていた気もします。

それが、まったく自分では作業できない状況になり人に仕事を他人にお願いするしか手段がなくなりました。結局、それが良い結果につながったと思います。仕事を溜め込んでボトルネックになっていたのが、仕事を吐き出して、どんどん身軽なりました。

USDM・PFDの技法がなければ、仕事を吐き出すことは不可能だったと思います。他人に丸投げして、そこで新しいトラブルが発生し、相当面倒なことになって、また仕事が増えて、の悪循環だったことは想像できます。

後、月一回行っている勉強会、LLCチーム経営「これからのリーダーシップ勉強会」も、人と働くためのいろいろなヒントを与えてくれました。人に仕事をお願いする技術が少しずつついてきたことも好転した理由かなあと思います。

育児時間短縮勤務の強みですが、出来ない理由を簡単に説明できるところです。他の会社は知らないのですが、私の会社は時間がないと言うと、残業でカバー、休日出勤でカバーと言う風習がまだまだあります。確かに残業すればどうにかなりますが・・・。それが、「時短勤務中で残業できませんが、人を入れてもらえれば、それは出来ますよ」と、人を入れてもらう交渉が格段にしやすくなりました。

もちろん、XDDPがなければ、人の増員による問題解決という選択肢がとれませんでした。時短勤務とXDDPにより、人が増えて状況は改善の方向に向かっています。

結局、育児時間短縮勤務をすると決めて、全てを変えようと決心したことが良かった気がします。

 今の課題

今の自分の課題は、TDDをPFD・USDMで安定させチームに根付かせることです。

・PFDに単体テストを書くといプロセスを明示して、単体テストがないコードに、単体テストを入れることを改造のプロセスの一部にする

・USDMに、要求としてコードの掃除を入れて、コメントの整理、単体テストを入れるためのコードの変更を、本来したい変更と分けて管理する

PFD・USDMによりTDDを根付かせる仕組みを取り入れることが可能ではないかなあと思っています。僕の印象ですが、USDMとTDDは相性がいい気がしています。

TDDの印象として、なんか感覚の部分が多い。テストの粒度とか何をテストするとか。デベロッパーテストなのでそんなものかもしれないのですが、個人の感覚しだいて結構結果が変わってしまう気がしています。USDMを使うとその辺りがある程度チェックできるのではないか？結果が安定するのではないかと思っています。

今取り組んでいるのは、

１．「試行リファクタリング」⇒USDM

混乱したコードから、いきなり正しい変更を見極めるのは難しい。それで、今はレガシーコード改善ガイドで紹介されている、「試行リファクタリング」を試しています。とりあえず変更による影響は無視して、スピード重視で大胆にソースを変更してもらい、変更のイメージを掴んでもらう。そしてその変更コードは破棄。

その学習学んだことをUSDMで書いてもらって、本番みたいな感じです。

２．スペックアウトとして「仕様化テスト」

スペックアウトしてメッソドの仕様を紙に書きだすのは、どうなんだろうという思いがあります。メンテナンス大変そうだし、面倒。結局、メソッドの入力が何で出力がどうなるか？それだけが重要なのではないかと思っています。

それで、同じ手間をかけるのなら「仕様化テスト」の方がいいのではないかと考えています。ただ、問題はテストのフレームワークに入れるためにソースの変更が必要だということ。レガシー度が高いほど変更箇所は多くなり、これをどう安全に作業してもらえばいいのかが難しいです。後、この作業をUSDMにどう書いてもらうか？それも書かないか？その辺り手探り状態です。

もともと「レガシーコードと対峙する方法を考える」は、和田卓人さんのスライドを見たことから始まりました。

テストを書く文化を育てる戦略と戦術 from Takuto Wada

結局、テストを書く文化を育てる戦略と戦術の自分なりの解が、「PFD・USDMを使ってTDDを現場に根付かせる」かなあと思ています。

「レガシーコードと対峙する方法を考える」で、irofさんが、

「確かな技術がある技術者集団にとっては、レガシーコードは問題にならない」

といった趣旨の発言をされていて、妙に納得しました。

"レガシーコード"再考 from irof N

レガシーコードがあってもそれが制御可能なら問題にならない、問題になっているのはこちらの技術力の問題なんだなあと。

とりあえず、今は社内のレガシーコードを制御下に置くべく日々やっています。

最後まで読んでくださった方、ありがとうございます。