【イベント参加レポート】Builders Box ON AIR #1 レガシーコードからの脱却
Builders Boxとは
今年6月に本格始動した、SansanのCTO藤倉さんが主導するエンジニアのための情報サブスクリプション。
記念すべき始めてのイベントは、このご時世なのでオンライン開催。「レガシーコードからの脱却」の著者David Bernstein氏、そして翻訳者のキロさんの話が聞けるとなれば、参加しない理由はない。
なぜBuilders Boxを始めたか
オープニングで藤倉さんが登場。Builders Box初のイベントということもあり、なぜBuilders Boxを始めたかについて話してくれた。
我々は、日々ITのサービスを利用している。Amazon, Uber Eats...
日本発のものは、まだまだ世界に浸透していない
日本発のものを世界に広げていきたい、そういう思いから立ち上げた
日本CTO協会もだが、ここ最近「日本発のエンジニアリングを世界に届けよう」という機運が高まっているのはとてもよいことだと感じている。
アジャイル開発に不可欠な5つのプラクティス
David氏はワシントンの自宅から発信。みんながオンラインだというのを逆手にとって、グローバルにつながる勉強会が開催される昨今の機運はありがたい。
なお、英語での講演だったため、内容について間違えて理解している箇所があるかもしれない。講演を聞いていた方は、誤っている箇所があればご指摘いただけると幸いである。
↑David氏のWebサイト
「Integrate Continuouslyこそがアジャイルのコアだ」
継続的なインテグレーションは鼓動のようなもので、作ったものが素早く統合されるからこそ作り上げたときの感覚がフレッシュなままにフィードバックを受けることができる。もちろんエラーもすぐに捕まえられる。
Done, Done-Done, Done-Done-Done
コラボレーション
コラボレーションするにはスキルがいる
エンタープライズのソフトウェア開発は社会的活動
ソフトウェア開発者は「Excellent Communicator」
家具の組み立てを例に、ペアで知的作業を行うことのベネフィットについて解説。ずっとSwarmingしているのがMobbing、というのはなるほどだ。
こういった概念の整理がマシンガンのように頭に叩き込まれる。非常に刺激的だ。
クリーンなコードを書く
凝集されている
疎結合である
カプセル化されている
断定的である
冗長さをなくす
コード品質が我々を導く
いい言葉だ。
Microsoft,Amazon,Yahoo...大きな会社たちはコードのリファクタリングに多大な時間を費やしている。
最初にテストを書け
DavidさんはTDDがお好き
TDDはQAの代わりになるものではない
開発者の活動はQAの活動とイコールにはならない
良いテストを書く
書いたコードがムダなコードにならないためには、良い単体テストを本体より先に書く。
TDDは素早いフィードバックをくれる。
これ、本当に同意するんだけどなかなか現場での実践が進まない。テストの効果や意義を頭ではなく心で理解する必要があるのだろう。とりあえずこのDavidさんの話を聞いてもらう、というのがよいかもしれない。
TDDで得られるのは、20分ごとにフィードバックをくれるエンジニアがそばにいる体験。このたとえはしっくりくるし、GitHubの台頭でプルリク文化が浸透した今のエンジニア界隈では受け止めやすいのでは。
TDDはリファクタリングをサポートする
というか、テストがないコードをリファクタリングするのって辛いんだよなぁ。地雷探知機なしに地雷除去をするようなもの。でも、リファクタリングしなきゃいけないものってテストがない場合が多い。つらい。
テストできるコードを書こう
テストできるコードは、高品質なコード
そうだそうだ！
レガシーコードをリファクタする
朝おきて今までにやったことを覚えているか?忘れていることがすでにあるはず。
これはレガシーコードと向き合うことの難しさが端的に表された問いだな…。
技術的負債のリボ払いなど、不穏なキーワードが飛び交う。
コードの変更が必要なとき
レガシーコードは地雷であり、時限爆弾。リファクタリングしよう。
最初から正しいものが何なのかわかる、ということはそうそうないので2回目に正しくしよう。
The True Spirit of Agile
アジャイルの真の価値はテクニカルなもの。変更可能なコードを書くこと。
Q&A
「100%のカバレッジは100%のよいコードであることを示すわけではない」
ついついカバレッジを上げることに心血を注いでしまうけど、これはそのとおり。
良い質問。この問いへの答えが、「レガシーコードからの脱却」を書いた理由。
質疑からも伝わってくる、Davidさんの素敵な人柄。最高の一言だった。
レガシーコードからの脱却
お次は原田騎郎さん。
Davidは、テクニカルこそがアジャイルのコアだ、と言っていた。
ビジネスのやり方もアジャイルで、というやり方が増えてきている。
アトラクターではそのあたりも含めてお手伝いしている。
Davidの本にはすごく共感するが、翻訳しながら説教されているような感覚に陥る笑
日本の現場で、できていない理由は?
リファクタリングだけやりたい、といっても無理。
Davidの本が、話がよかったのは、一連の要素が塊になっているから。
よりよいライフサイクルを入れていくという話なら経営者も興味を持つ
ワンセット入れるというのはかなりタフだが
タフです。
なぜカイゼンするかというと、楽になりたいから。
リファクタリングをやることに許可を求めるからいけないのであって、通常のコーディングの一環としてやってしまえばいい。技術的負債はリボ払い。
勝手にリファクタリングをして影響がでてしまったら
アメリカの医療機器は、少しでもコードを変えると再認証が必要だった。それに数千万かかるのでおいそれとコードを変えようとならなかった。
ただ、結果に変更がないというエビデンスが示せるならばいいよね、という方向になってきた。
要するにCI/CD。そういうのがないと生き残れなくなってきているのでは
なぜ日本の会社は上手じゃないのか
たとえばGoogleは、わりと簡単にサービスを止める。エンジニアのリソースは限られているので何かを止めないと新しいことを始められない。
日本はサービスを止めるのが下手くそ、というか止めたがらない。いかにサービスを止めるか、コードから取り除けるか。
「止めるよー」と連絡するとだいたい連絡がこない、そういうものから消していけばよいのでは
ちょっと足りないくらいの状態で移行することで、移行先の肥大化を防ぐ
これは耳が痛いな～…。サービスを、コードを残すならテスト保護など必要になってくるし、メンテナンスコストがかかってくる。止める決断は難しいが、それがないとフィーチャー自体がレガシー化・負債化していく。
「アジャイルやりたい」問題
アジャイルやりたい、ってきたお客さんはだいたい断っちゃう。
何かの課題があって、それを解決する手段としてアジャイルがあるのが本来の姿。ただアジャイルやりたい、だと向かう先がない
アジャイルうまくいかなかった、次はデザイン思考だーみたいになっちゃう
本の翻訳で周りの環境は変わったか
これ見といてね、と本を渡せるのはすごく便利。
「みんなでアジャイル」と「レガシーコードからの脱却」をペアで渡すと、だいたい課題感を認識してもらえる
原田さんの伴走の仕方
だいたい一緒にやる。内側に入る。
こわいことをいうときにニコニコしているのは大事。今日のDavidみたいに。
エンジニアへのメッセージ
子供が高専生。高専ではなんでも使える。
昔はそれぞれの領域で分かれてエンジニアリングしていたが、今は敷居がすごく下がっている。いろいろやってみやすくなっている。
もっといろいろやってみたらいい。
20%時間をあけてスキル向上にあてるといい。
Uber Eatsなどは、物理的な世界とソフトウェアエンジニアリングの見事な融合
クロージング
原田さんからのメッセージ。
いろいろなところでプロダクトをつくり、コードを書いていると思う。
全部がうまくいってはいないだろう。
まずは自分の仕事をどれだけ安全にできるか、うまくやれるかというところに時間を使ってみよう。
いきなり全部を出来るようにはならない。全部を覚えるのは大変。
自分でいかに時間をつくり、仕事を楽にするか。
Davidさんの話も、騎郎さんと藤倉さんの対話も刺激的かつプラクティカルなもので、日曜の朝からやる気を駆り立てられるものだった。
ぜひともアーカイブ公開してほしい。
この記事が気に入ったらサポートをしてみませんか？