デブサミ2020 Day 2 - 書かれる予定のないブログ

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

大事なことが多すぎて長めですm(_ _)m

「レガシーコード」の定義は様々。ここでは「修正、拡張、作業が難しいコード」とする。
「使われるソフトウェア」は変更が必要になる→変更できるように書いておく。
品質は検査では上がらない。出来上がってから確認しても、品質の改善には繋がらない。
What と How を分離する。 How を指定してしまうと、選択や交渉の余地がなくなって創造性が発揮されなくなる。
ユーザーストーリーをベースとして会話する。知識はコード(テストコード)に落とし込む。
QCDS: Quality, Cost, Delivery, Scope の関係性。
Quality を下げると、後で埋め合わせが必要になる。リスクが高い。
Cost を調整するとは、人数を増やすこと。人月の神話からも分かる通り、上手くいかない。
Delivery を遅らせることは、普通はビジネスが許容しない。フィードバックも遅くなる。
Scope を調整することが合理的。短いスパンで少ないタスクをこなす。
↑によって仕掛りが減らせる。完成したものにのみビジネス的な価値がある。
↑によって素早く、多くのフィードバックが得られる。
「良くないコード」は多すぎるので、「良いコード」について押さえる。
名前が重要。汎用的な名前がついているものは疑わしい。
CLEAN Code を書く。 Cohesive, Loosely coupled, Encapsulated, Assertive, Non redundant の頭文字。凝集性、疎結合、カプセル化、断定的、非冗長。
CLEAN とテストで、バグ発見の時期を開発の終わりからもっと早い段階にもってくる。
テストのしやすさが品質を測る基準になる。
素早く働くということは、綺麗に働くということ。5S は開発におけるコードや物理的な環境についても適用される。

ひたすらに同意しか無いお話でした。

レガシーコードからの脱却 | Ryuzee.com

デブサミ2020【14-C-1】レガシーコードからの脱却 #devsumiC #devsumi - Togetter

プロダクトを10年運用するチームをつくる

はてなさんで実践している内容ですね。

「動いているシステムはさわるな」は現代では通用しない。現代のシステムは常に自動で更新され続ける。
システムを更新し続けるためには「CI/CD」「監視」「DevOps」の整備が必要。
人も入れ替わり続ける。この業界は学生の部活よりも入れ替わりが頻繁かも。
人の入れ替わりに対応するために、はてなでは「スキルマップ」「障害対応演習」「式年遷宮」を利用している。
スキルマップの効果。チームのスキルバランス可視化、リスクの察知、チームから失われたスキルの気付き、学習目標の指針。
スキルマップを維持するコツ。評価に使わない、他チームと比べない、粒度を気にしない、定期的にメンテする(振り返りでメンテする。振り返りやってないならやった方が良い)。
障害対応は属人化しやすい。新規メンバーは入っていきづらいし、緊急事態なので教育の余裕がない。
ステージング環境をわざと壊して、慣れていないメンバー中心で復旧させる。避難訓練。
半期に一回ぐらい、スキルマップで弱いところを壊す。また、実際の障害直後に当日対応しなかった人を対象として行う。
一定のタイミングでシステムの根幹(アーキテクチャ、FW、データストア等)に手を入れる。式年遷宮。
↑技術的負債の返済、モダンな環境への適応、エンジニアの技術継承(人の入れ替わりへの対処)が目的。
現実の式年遷宮とは違って、フルスクラッチはしない。しないためのエンジニアリング。