レガシーコード改善勉強会でした。 #wewlc_jp
運営について
アークヒルズサウスタワーにある、Yahoo さんの会議室でした。
オープニング
発起人？の方から、オープニングとして次のような話をうかがいました。
- この集まりの目的は何？
- 改善について議論できる下地を作ること
- 今後どうしたいか
- ITの力の最大化
- レガシーコードを改善しなくてよくなる
- レガシーコードの改善が当たり前に
- 今回はウルシステムズさんと一緒にやらせていただいた、もっといろいろ広げたい
- それ以上は分からない
アンケート用紙が配られていて、その集計結果次第で第二回、第三回があるかもしれない、とのこと。
セッション1
演者の稲葉さんが都合が悪くなってしまったとのことで、代役で訳者である平澤さんが書籍の内容をざっくりと説明するセッションになりました。
平澤さんはドメイン特化言語、リファクタリングも訳されてる…大物感。
一番記憶に残ったのは、レガシーコード改善ガイドがすでに七刷にもなっていて、一定したペースで売れ続けているということでした。
息が長いっていいことですねぇ…
書籍の内容ですが、書かれているのはビルドできるコードのことが多い。
なので、よくわからない設定ファイルや、ビルドできないコードについても、同じような（場合によってはもっとヒドい）戦いの記録がありそうだなぁと思いました。
セッション2
kyon_mm による方法論の話。
何のために、どういうことをやればいいのか、積み上げていく感じで分かりやすいものでした。
- 変更するなら、そのものを知らなければならない
- 知るためには、役割、目的に応じて適切なツール（ものであったり技法であったり）を使うべき
- ツールの使い方なんてもはや教養なので学べ
1 bleis 月とか 1 kyon_mm 月とかの人に特化した規模感がなんとなく危ういなぁとか思ったので、懇親会で会話してみたのですけど、
いまいち伝えられなかったのが残念でした。
kyon_mm 曰く「PO と QA を兼任してるけど、やっぱりコードが書けてテストもできる人がやるべきだよ！」（意訳）って言ってて、
それ巷で話題のフルスタックエンジニアですよねー、とツッコんでおきました…
セッション3
goyoki による心構えや振る舞いについての話。
以前見かけたときより健康そうな雰囲気でした。
大枠として次のような分類で課題と目標、実際のアプローチを説明していました。
- 人
- 環境
- アプローチ
保守性の話で、リスク分析して優先度を付けて要件にして、そのトレーサビリティを保つようにしていく、という話を聞いていて、
「で、誰が何をどうするから、誰がどう嬉しいんだろう」というのが分からず隙間時間（という名の休憩時間）に聞いてみましたけど、やっぱりよく分かりませんでした。
今度機会があったら聞いてみよう。
セッション4
ソニックガーデンの西見さんでした。
今回も Point of Sales と Point of Use のグラフが紹介されていたんですが、個人的に何か腑に落ちていなかったんですけどその理由が分かりました。
それぞれで、縦軸の縮尺が違うはずなんですよ。
納品時点での利益？が最大、という場合、利用者が要求したものが10入っているとする。
一方、使い始めたときから利益？が最大、という場合は、最初の時点では要求したものが1か2しか無いはず。
なのに、それらを同じ縮尺であるかのように見せている…これがグラフの魔術！！
今回も、組織的に技術基盤を揃えて、その効率を高める戦略は素敵だなぁと思いました。
セッション6
Yahoo トップページ部隊としての佐藤さんでした。
組織内でコード改善をする機運を高めて、実際にやってきたという話。
namespace で関数名を隠蔽してスタブ関数を実行する、というトリッキーなテクニックとかを紹介されてました。
懇親会で、テストコードのサンプルを作りこんで「さあお前ら手を動かせ」的なアプローチを取らざるを得なかった、などの裏話をお聞きして、
見かけによらずパワーのある人だなぁと思いました。
セッション7
誤タイプを招く ID 体系を導入されている t_wada さん。
こちらも一番最近の記憶に比べて健康さが増しているように感じたのですが、実際はそうでもなかったっぽい。お大事に…
お話をまとめるとこんな感じでした。
- 状況を具体的にして
- 一番やばいところから
- できることを一つずつ
- 確実にやっていけ
- 高望みするな
早速やろうと思って、話を聞きながらどうにかこうにか自動ビルドを復活させたりしてました。
