レガシーコードについて考えてみた #wewlc_jp
レガシーコード改善勉強会 in東京 - パスマーケット に参加しています、なう。
勉強会出ててくる内容（キーワード）や雰囲気はハッシュタグから追えると思いますのでぜひ！
参加レポートではなく、せっかくなので勉強会のテーマの “レガシーコード” について個人的な想いをつらつら書いてみます。
レガシーコードってなあに？
- レガシーコードとはテストのないコードである
というわかりやすい定義もありますが、
- 仕様がわからないコード
- 意図がわからないコード
- 読めないコード
といった主観的なイメージもよく聞きます。
定義としてレガシーコードとはなんなのかはともかく、上記に書いたようなコードはどれも無いほうがうれしいし、あったとしたら減らしていきたいものです。
【余談】このあたり読むと面白い！
レガシーコードとの遭遇
今までの自分の経験では、コードが存在するところには（程度の違いはあるけど）必ずレガシーコードが存在していました。
仮にレガシーコードが存在しないステキな環境があったとしても、半年後に自分の書いたコードを覚えてなかったりするので明日レガシーコードが存在している可能性はあるでしょう。
ってことは、スタートアップだろうと保守運用だろうと自社開発だろうと受託開発だろうと、レガシーコードとどう向き合っていくかはエンジニアやっている限り切っても切り離せないものなのかなーと思うようになりました。
よくあるレガシーコード
今までレガシーだなーと思ったコードを思い出してみました。
- メソッドでやりたいことがわからない
- インデントや条件が複雑すぎてどうやったらそこを通るかがイメージしにくい
- メソッドが大きすぎてテストコード書こうにも複雑すぎる
- AメソッドとBメソッドそれぞれでは問題なさそうだけど、設計に統一性がない
- 変更部分にしか注意がまわっていない書き方をしている
- 歴史を感じるくらい人によって書き方がバラバラ
- そもそもシステムやテストの設計方針がない
- とにかくわけがわからない
思い返してみるとこれらの共通点は、
- テストコードが存在しない
でした。
もちろんテストコードがあればいいってわけじゃないけれど統計的に！
レガシーコードができそうなにおい
今度はコードレビューしていてレガシーコードになりそうだなーと感じた瞬間を思い出してみます。
これらを見つけた時に聞いてること。
- メソッドが長い
→「このメソッドの目的ってなに？」
→「このメソッドテスト書いててつらくなかった？」 - インデントが深い
→「ここ通るときの条件を教えて！」 - 条件文が複雑
→「この条件文を文章で説明してほしいなー」 - メソッドからreturnするパターンが多い
→「このメソッドのreturnのパターンを教えて！」
コードを書かない時にもレガシーなにおいを感じるタイミングはあります。
- 説明が不安そう
- 仕様理解があいまい
- タスク自体のDoneの定義があいまい
- （項目・コード問わず）テストが書けてない
- 本人がぱつってる
こんなときはあやしいですよね。
レガシーコードとどう向き合ってきたか
もちろんこれまでにレガシーコードを見てイラッ☆としたことはたくさんあります。
でも前任者だけでなく自分自身もレガシーコードを生む可能性があることに気づいてからは、それほどネガティブな感情を持たなくなりました。
でも、そこでネガティブな感情をもって立ち止まったら、自分自身も同じようにレガシーコードを生んでしまいます。それはレガシーコードに負けた気がするし、自分自身もまた加害者になってしまいます。
だから、
状況次第でなかなかリファクタリングできない・進まないことはあるかもしれないけど、少なくとも増やさないようにして少しずつ減らしていこう
ってことを考えるようになりました。
今後レガシーコードとどう向き合っていくか
今後以下の2つのアプローチを考えてます。
- やってきたことをアウトプットする
- 知識をインプットする
1. やってきたことをアウトプットする
レガシーコードと向き合うようになって、いろんな失敗を経ながらもどうにかレガシーコードを減らしてきました。
自分は本能で動くタイプなので、やってみたあとから、
「あのときやったことに名前・方法論があったんだ」
と知識がついてくることが多いです。
それはそれでいいと思うんですが、やってきたことを形式知としてアウトプットして知識に転換していくことがそろそろ必要だと思っています。
2. 知識をインプットする
アウトプットをする一方で、今なら効率よく知識をインプットできる気がするし、頭でっかちにならずに知識を経験に転換していくサイクルをまわすこともできるので、引き出しを増やせばもっとはやくもっと多くの改善ができるんじゃないかなーとわくわくしています。
考えるきっかけを下さった登壇者の皆様、運営の皆様ありがとうございました。
おわり！！
リリース手順書について本気出して考えてみた #CleanReleaseManual
社内でエンジニア向けのプレゼンをする機会があったので、リリース手順書について本気出して考えてみました。
手順書書くくらいなら自動化すればいいじゃん
もちろんそうです。
でも、まともなリリース手順書をつくれなければ、自動化されたリリース作業を行うことはできても自ら自動化することはできません。
自動化やContinuous Deliveryはもちろん大事ですが、自分と一緒にはたらくエンジニアには自動の前に考えてほしいことがあったのでプレゼンにまとめてみました。
新人の頃の教訓
この内容は、すべて自分が新人の頃にリーダーから伝えてもらったことです。
- 「変化前の確認⇒変化⇒変化後の確認」さぼらない
- 上から下までコピペでリリースできることが最低限
- リリース手順書には相手がいる
- 相手の事を思いやって書く
- 意図を持って書く
最初はなかなかうまく書くことができませんでしたが、新人の頃に癖づけることができて本当によかったです。
いろんな人のリリース手順書を見てきましたが、震えるような手順書には出会っていません。
たかがリリース手順書、されどリリース手順書！
リリース手順書に限らないコツ
このプレゼンのメインはリリース手順書ですが、そのコツは手順書に限るものではありません。仕事と作業を分けることを意識して大事な事に集中したいものです。
いろいろと賛否両論はあるかもしれませんが、すべて受け止めます。
ご意見ご感想はご自由にどうぞ。
ホウレンソウ、○○管理って本当に必要!?
とある先輩がメルマガと称して率直な意見をぶつけ合うメールを配信しているのを見ていいなーと思い、チームメンバーに同じことをしはじめました。
せっかくなので当たり障りない範囲でブログにも残してみます。
ホウレンソウ…
タスク管理…
スケジュール管理…
いろんな本・記事・プレゼンで語られているし、誰もが新人の頃に上司や先輩からうるさく言われた経験があります。
ひょっとしたら無条件で『必要だ！』と教えこまれてきたかもしれません。
でも、本当に必要なんでしょうか？
私はなくてもうまくいくならばいらないんじゃないかと思います。
コミュニケーションコストだってかかるし、
管理コストだってかかるし、
時間だってかかるし、
かったるいし、
もし無くせるなら無くしたい！
その時間使って新しい機能つくってお金もうけたい！
その時間の分早く帰って合コンに行きたい！
って心から思います。
とはいえ現実的に考えると、やっぱりホウレンソウやなんとか管理は必要になってしまうことが多いです。それはなぜかというと他人とコミュニケーション無しで同じ方向へ進むのは難しいから。
「あそこに向かうぞー」（ホウレンソウ）って認識合わせたり、
「ちょちょ、そっちじゃない！こっちだよー」（なんとか管理）ってチェックしたり、
やっぱり必要になってしまう。
しかし、
（今必要である）＝（だから必ずやった方がいい）
（今必要である）＝（どこの誰にとっても必要である・なくすことはできない）
と考えてしまうのは思考停止です。
無条件で「必要だ！」「当たり前だ！」と思っていたホウレンソウやなんとか管理は、なくすことはなかなかできないかもしれないけど少なくとも減らすことはできます。
もし減らすことができたらもっと大事なことに時間が使えることでしょう。
普段やってる仕事の進め方を思い返してみて、
今やってる朝礼がなくなった時、
今やってるかんばんがなくなった時、
今やってるスクラムの儀式がなくなった時、
どうすればいいのか想像できないのだとしたら、それは何かに頼って思考停止してしまっているのかもしれません。
うまくいっている時ほど“当たり前”や“成功”の中身を疑ってみると見えてくるものがあるものです。
「がんばった！」の向こうへ
「がんばった！」は麻薬だ。
僕らの仕事であるサービス開発・ソフトウェア開発を例に挙げると、プロジェクトが炎上したり大トラブルに巻き込まれてどれだけ大変な想いをしても、どうにかリリースまでたどりついて乾杯のビールを飲んでしまえば「よかった！」「がんばった！」となってしまう。
もちろんみんながんばったし、がんばっていると思う。
でも「がんばった！」だけでお給料がもらえるほど世の中は甘くない。
極端な話、がんばらなくても成果を出せば給料がもらえるだろう。
そして、チームメンバーはもとより、競合サービスのメンバーだってみんながんばってる。おそらくがんばってない人はそんなにいない。
であれば、「がんばった！」はあくまでお酒の肴に止めたい。
自分は大丈夫だと思っていても、何かを達成したあとはやはり気が緩んでしまうもの。
勝って兜の緒を引き締めるとはよく言ったものでリリース後のふりかえりにこそ本気でバチバチするように意識しようという自戒を込めて。
「がんばった！」の先に行きたい。
2013年をふりかえってみました
（DevLOVE現場甲子園打ち上げより）
2013年も残すところわずかとなりました。
毎年恒例の個人年間ふりかえりを行ったところ、2013年も多くの出会い・学びがありました。簡単ではありますが今年にふりかえりのほんの一部を公開させていただきます。
数値でふりかえり
- カンファレンス・勉強会参加 : 47
- 発表（社外） : 10
- スライド公開数 : 5
- ブログ投稿数 : 10
- KPT総ファシリテート数 : 73
- 読んだ本 : 30
- クリアしたゲーム : 12 ※神々のトライフォース2含む
- 回収したアニメ : 20
- 握手会参加数 : 1
KPTT
Keep
- 新しいチームも自他共認めるいいチームに変われた
- サービス（楽天レシピ）が大好きになった
- 年初に立てたチーム年間計画をクリアすることができた
- 2012年から2013年の1年にかけて個人的4大ドームツアー講演達成した
（Scrum Gathering、XP祭り、デブサミ、アジャイルジャパン）
Problem
- 業務内でエンジニアリングに携わる時間が減ってきた
- いろいろ計測してみたけど仮説の設定があまくあんまりいい指標ではなかった
- 大きなイベントが重なって継続的でなかった
- Agile2013のセッション通らなかった
- 出世払いが増えてきた
Try
- 業務外でエンジニアリングする（内容は決めてあるけど濁します）
- 1年を通してのKPIを設定する
- ブログを月1以上書く
- 発表を依頼されるようになる
Thanks
To チーム・部署
新しい環境でも遠慮なくやらせていただきました。一緒にやってる仲間から「仕事が楽しくなった」「自慢できるチーム」といってもらえたのがなによりでした。もしかしたら賛否両論ある方もいらっしゃると思いますが、変化が起こっているということなのでそれもまた嬉しいフィードバックです。
サービスとしてもチームとしても今年は準備の期間と計画していたので計画以上に進めることができたので2013年としては優かもしれませんが、サービスとしての価値がうまれないとなんの意味もなさないと思います。遠慮したり安定させるのは大人に任せて、来年以降もこれまで以上に空気を読んで空気を壊して行こうと思いますので引き続きよろしくお願いいたします。
To 会社
ありがとうございました。
会社を変えてやりましょう！
To 勉強会・コミュニティ
たくさんの出会いと学びをありがとうございました。
現場を変えてやりましょう！
変わる現場をつくる #devlove
このエントリーは『DevLOVE Advent Calendar 2013 「現場」』の2日目の記事です。
自己紹介
2番バッターを務めさせていただきます@TAKAKING22です。2番というと、送りバント・進塁打・ヒッティングなど状況にあわせたバッティングを求められます。
私は、楽天株式会社という会社でエンジニアをしています。
楽天には野球団と楽天市場と英語以外にもたくさんのサービスが存在し、私は後者の小さなサービス達を開発・運用する部署に所属しています。肩書きはエンジニアですが、チームビルディング・プロジェクトマネジメント・プロダクトマネジメントなど必要であらば現場を変えるために役割の壁をぶっ壊して日々奮闘しています。
そんな現場での実体験を勉強会やカンファレンスなどで発表させていただいているのですが、はじめての発表は2011年の12月のDevLOVE HangarFlight - Snow Barrageでした。私のエンジニア人生にとって大きなきっかけになり、そこからの約2年間でたくさん成長ができたと思います。
現場と変化
私たちの業界では、ビジネスも技術もプロセスも凄まじいスピードで変化していきます。それに合わせて現場も変化していかないと取り残されてしまいます。
なんていうマクロな視点だけでなく、ミクロな視点（自分たちの現場）でも変化はつきものです。言語のバージョンは数年でサポートが終了するし、メンバーが１人変わればチームの雰囲気はがらっと変わるし、そうした変化に対応する形で現場もまた変化を求められます。
ところが、現場で活動をしていると変化を拒む見えない壁にぶちあたることがあります。そんな時に私たちには3つの選択肢があるそうです。
私の現場の変化のストーリー
「●●だからできるんでしょ？」
という声をよく聞きますが、どの現場もはじめからそうであったわけでなく必ず誰かが変化をおこしたストーリーがあります。
私は2012年末に今のチームに異動することが決まった際に、まずメンバーへの個別のヒアリングをしました。その結果をチェンジインセプションデッキにまとめ、面談の際に上司との合意をとりました。
- 何やってるかが見えない
- テストがない
- トラブルが多い
- リリースに時間がかかる
という状態だったチーム。
それから約10ヶ月。
今では、カンバンの前で毎朝朝礼をし、毎週ふりかえりをし、テストコードを書き、トラブルも起きず、リリースは毎回成功しています。
言葉で書くと簡単ですが、一朝一夕に変化したのではなく、小さな成功や失敗を積み重ねた変化の結果が今のチームです。
私がチームに入るという大きな変化にも対応してくれたメンバーに感謝しています。
私にとっての現場
先ほどうまくいかないときに3つの選択肢があるといいました。私は常に３つ目の「変える」を選ぶようにしています。
自分の現場が必ずしもいい現場だとは限りません。仮に今いい現場だとしても明日にはどうなるかわかりません。
そんなときに我慢するのもいいでしょう。辞めるのもいいでしょう。しかし、変えることから逃げてそれらを選択をすることは絶対にしたくないです。
いい現場は自分たちでつくらなければいけません。
私がやっていることは、自分では名前を使わずとも、アジャイル・リーンなどさまざまな呼び方で呼ばれます。
しかし現場の最前線で戦う私たちからすると、
『なんだっていい！やってやる！！』
という思いでしかありません。
明日起こせる変化は小さいかもしれませんが、その１歩を積み重ねない限り行きたい目的地にはたどりつくことができません。
私は、その思いのもと、明日からも現場のために現場にあわせた変化（１歩）を起こし続けていこうと思っています。
そして変化を起こせなくなったとき、第一線から退こうと決めています。
ネクストバッター
次のバッターはOppyさんです。
DevLOVEの裏方をされていて、DevLOVE現場甲子園2013でもたくさん助けていただきました。
ランナー1・2塁。
3番、Oppyさんのバッターボックスにご期待ください!!
Change Hackersで「つくる現場 - 変化を支える3つの現場アーキテクト -」について発表します #changehackers
11月6日(水)に開催される変化の担い手チェンジエージェントの実践を追え！ - Change Hackersというイベントで「つくる現場 - 変化を支える3つの現場アーキテクト -」という発表をさせていただきます。私自身の現場で起こした “変化” の事例発表です。
セッション概要は以下の通りです。
教科書を読んだり成功した現場の事例を聞いていると、「いい環境だ」「うちではできない」と壁を感じることがあるかもしれません。しかし、どの現場も最初からうまくいっていたわけではなく、壁を壊した誰かのストーリーが存在します。今回は私の現場のストーリーを通じて、現場で感じたチェンジに必要な3つの現場アーキテクトについてお話しさせていただきます。どこにでもいる1エンジニアの私でも壁は壊せました。 “ヒーローでなくても壁は壊せる”
このイベントはChange Hackerというコミュニティが主催しています。
私は自分自身のことをチェンジハッカー／チェンジエージェントだと意識したことはないですが、常に現場をチェンジさせることを考えて活動をしてきました。
チェンジはただ起こせばいいものではありません。
私はたくさんの経験（失敗）の中から、現場に合わせたチェンジを計画的に起こすことを意識するようになりました。
私自身がおこしてきたチェンジとそれによって現場／チームがどう変わったのかというチェンジの事例と、その中で見つけたチェンジに必要な土台、3つの現場アーキテクトについてお話しさせていただきます。
当日はもう１人のチェンジハッカー、私の先輩でありヒーローでもある伊藤さんのご講演もあります。まだ空席があるようなので、ぜひお時間がある方はこちらからご登録ください！空席残りわずかなのでおはやめに！！
みなさんにお会いできることを楽しみにしております。
