「Developers Summit 2020」に参加しました

2020/2/14(金) 「Developers Summit 2020」に参加してきました。

公式サイト
https://event.shoeisha.jp/devsumi/20200213/timetable#day02



1日目（2/13）は仕事の都合で参加できなかったけど、なんとか2日目（2/14）は参加することができました。
気になったセッションをメモ。

【14-C-1】 レガシーコードからの脱却

セッション： https://event.shoeisha.jp/devsumi/20200213/session/2399/

みんなでアジャイル、という本を翻訳した。
どうやって全員でアジャイルになるの？という本。

レガシーコードからの脱却

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

posted with amazlet at 20.02.25

David Scott Bernstein
オライリージャパン
売り上げランキング: 1,611

Amazon.co.jpで詳細を見る

「レガシコード」ってタイトルにつけると売れるらしい
レガシコードっていろんな定義がある
レガシーソフトウェア改善ガイドによる定義　→　保守または拡張が困難なコード
これはみなさんのイメージに近いかな

議論のときは、まず共通認識は何かを確認するとよい
このセッションでは、レガシーコードの定義を
「理由は問わず、修正、拡張、作業が難しいコード」とする。

ソフトウェアと変更の切り口で考えてみた

使われるソフトウェアは変更が必要になる
変更を先にすべて予測するのは無理
変えたくなったら変えられるように作ろう、という割り切り
その反対がレガシーコード
すぐ治せる技術スキルが必要
変更のコストを下げたい

時間の使い方に問題があるケースが多い
８０％のコストが障害対応に使ってる
強烈に無駄

理由
・急ぎすぎている
・たくさん作ろうとしすぎている
・etc


レガシコードを作ったら負け。最初から作らないようにする。
どうすればいいかというと、開発プロセスに着目する

開発のやりかただけに着目しがち
作り出す成果が何よりも大事
何によって決まるかと言うと、コードの綺麗さだけじゃ決まらない

問題設定力　・・・　その問題って本当にお客さんが抱えているんでしたっけ
×
開発力
×
チーム力

アジャイルで、スクラムだけで技術的には何もやらない、はない
XPやデザイン思考などと組み合わせる

レガシコードを作らない９つのプラクティス
１．やり方より先に目的、理由、誰のためかを伝える
２．小さなバッチで作る
３．継続的に統合する
　アジャイルマニフェストでもいってる
４．協力しあう
　心理的安全性のもとに
５．CLEANコードを作る
　それぞれの頭文字
６．まずテストを書く
７．テストでふるまいを例示する BDDみたいなの
８．設計は最後で行う
９．レガシーコードをリファクタリングする

人間が覚えられる個数は7プラスマイナス２くらい
スクラムとXPからプラクティスを抽出している。

１．やり方より先に目的、理由、誰のためかを伝える
役割の違い
　・POの責任
　・開発チームの責任
役割が違う
明確に分断をしている

whatとhowを分離している
POの領域は、何をほしいか、なぜほしいか(What)
やりかたは開発者の領域(How)
物事のやりかたは１つでないく、やり方ごとにトレードオフがある
howを指示されるとコードが手続型になる
オブジェクト指向にならなくなる
作るうえで重要なのはコンテキストを共有・理解すること

ユーザーストーリー
何が、なんのために、誰のために、存在するかを一文で表したもの
仕様書じゃなくて、機能について会話できるレベル
会話によってしか共通理解は成り立たない
ユーザーストーリーをベースにお互い会話する
知識はドキュメントでなくコード（テスト含む）にまとめるべき
ストーリーがシンプルで１つのことを語ってると、テスト可能になる
ハッピーパスを一本通せばよい
動くようになってから足していけばいい
最初から良い設計って見えない
やりながら見えてくる
すこしずつ積み重ねて設計を見直していく

２．小さなバッチで作る
どかんとウォーターフォールでやると、結合試験でいろんな問題でる
リリースしてから、こんなの頼んでない、となる

鉄の三角形
ウォーターフォールはQCDSを全部固定しようとする
同時に約束できるのは２つまで、と言われている
Qは通常変えないほうがいい
Qを調整すると、後から辛い目にあう
品質はいじれない
元の品質が低すぎると、リリーススプリントでテスト、で間に合わない。高リスク

コストを調整する、というのは人を増やすこと
人を増やしてもコミュニケーションコストが増える
オーバーヘッドになりリニアに生産性は増えない
「遅れているプロジェクトに人を足すとさらに遅れる」


時間を調整してもよいが、多くのビジネスでは時間が重要
一番調整すべきなのはスコープ
およそ半分の時間はほとんど使われない
使われないものを作るのをやめよう、というのが一番合理的
大事なものから順番にやっていこう

スコープ調整しながらするとき、タイムボックスによるアプローチをする
同じ時間区切って、延々と繰り返す
固定のリズムの中で仕事する
1週間でやるのがお気に入り
小さくやるので設計量も開発量もすくない、バグもすくない
ウォーターフォールだと、最初の計画は大嘘になる
アジャイルは、短いイテレーションで小さな嘘をつく
軌道修正しやすい

同じリズムを刻むことで負担を少なくして、異常に気付く
ペースメーカーがあると、すごい気づく

1サイクルを長くするほど、リソース効率を目指しやすい
同時に手を付けるものが増える
タスクの切り替えが増えて集中力が落ちる
分担したほうが効率的、という幻想のもと、分担してしまう

サイクルを短くすると、プロセス効率があがる
1個ずつやっていくしかない


モブプログラミング＝究極の1個流し
進捗９０％ばかり複数ならんで、どれも終わってない、となりがちだが、
1個流しだと、完成したものが1個ずつ確実にでてくる
多少おそくなっても、1個ずつ出してお金を稼げたほうがビジネスにとっては幸せ

ソフトウェアの評価は、顧客にとって価値あるものにもとづいて評価すべき
完成して初めて価値になる
価値実現までの時間が短すぎるのもだめ
全体として出荷できるものを作る
効率より効果★
効果が出てから効率を求める

フィードバックをたくさんうけたほうが当たる確率が当たる
小さなバッチでフィードバック回数を上げる
継続的にお客さんやPOに見てもらう
フィードバックを受け入れないと意味が無い

５．CLEANコードを作る
品質は最初から作りこむしかない
検査で品質は上がらない

良くないコードの例はたくさんあるので、全部避けるのは難しい
→　模範になるパターンを覚える
→　CLEANコード

Cohesive （凝集性）
１つの部品は１つの責任に集中する
１つのことをやってればはっきりした名前を付けられる
データってついたクラスや、チェックってついたメソッドは怪しい

Loosely Coupled （疎結合）
オブジェクト間の関係を明確な意図をもった状態に保つ
あとで差し替え可能にする。サービスを直接呼ばない

Encapsulated （カプセル化）
中を隠す
呼び出し側の観点で機能を作る

Assertive （断定的）
フィールドを持つなら、それを管理する挙動も持つ

Non Redundant （非冗長）
dry原則

テストのしやすさと設計のよさは相関関係がある
テストコードが書きにくいなら設計がよくない

早くテストしてバグを直さないと、後から見つけて直すとと６４０倍のコストがかかる
バグを作りこんでからの経過時間が長いほど、修正コストはかかる

明日のベロシティのために今日品質を上げる
速度って焦ってやっても早くならない
日々の積み重ねによってしか実現できない

素早く働く＝綺麗に働く
散らかしながら進むのではない
繁盛しているお店ほど綺麗

これって5Sだった
整理、整頓、清掃、清潔、躾

テクニカルいくらがんばっても5Sができないと上手くいかない

まとめ
コーはド変更できるように書くべき
目的、理由、誰のため、を伝える。
小さく分けて意味のあるものからやる
小さなバッチでみんなで協力
テストコードも含めてCLEANを維持
継続して見直し。最初から完璧は無理。

【14-D-2】 エンプラアジャイル導入の守破離

セッション： https://event.shoeisha.jp/devsumi/20200213/session/2408/

【14-E-4】 アジャイル開発の原則を守りつつ、マルチサイト開発を行なう！ ～ベトナムのメンバーとともにつくる～

セッション： https://event.shoeisha.jp/devsumi/20200213/session/2418/

アジャイル開発の原則を守りつつ、マルチサイト開発を行なう！ from Arata Fujimura