技術的負債の支援とOSS技術選定
Mosh勉強会 #1
Jun 13th, 2024
Profile
- id: Songmu (ソンムー)
- Masayuki Matsuki / 松木雅幸
- Mosh株式会社 技術顧問
- 株式会社ヘンリー VP of Engineering
- おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/
- https://metacpan.org/author/SONGMU
- 好きな言語は、PerlとGoと中国語
- 3 Times ISUCON Winner Using Perl
- 入門監視 付録C 執筆
- 「みんなのGo言語」共著者
Profile
- id: Songmu (ソンムー)
- What I ♥
- Blog / Twitter
- OSS
- Agile
- Full Cycle Development
- Road Bike, Cycling
Agenda
- 技術的負債をどう考えるか
- 技術的負債返却の支援
- OSS文化圏と技術選定
技術的負債返却をどう考えるか
いくつかの観点
- 開発フロー整備
- コミュニケーション設計 (ドキュメンテーションやユビキタス言語)
- 技術選定
- コード設計 (クリーンアーキテクチャ)
- アーキテクチャ (コンウェイの法則)
色々小難しい話はあるが、足元の開発フローの課題を解決するのが効果が高い。基本的なことをしっかりやる。
技術的負債と言えば聞こえが良いが、掃除や整理整頓をちゃんとやりましょうくらいで済む話が多い。難しいけど。
腕の良い料理人は片付けながら料理をする
- 料理を始める前に厨房を片付ける
- 余裕がないと実現できない
- 専門技術
- 急かされると無理
- いわゆる「木こりのジレンマ」
- 研がれていない斧で木を切り倒そうとするのは時間の無駄
- 誰もがわかっているが、余裕がなくなるとやってしまう
包丁を研ぐ
- 専門技術を磨く
- 機能開発と並行してメンテナンスをする
例えばテストコード
- テストコード習得は自転車習得に似ている
- 習得すれば圧倒的に速くなるし、それ無しでは生きられなくなる
- 誰でもできるようになる
- 回り道や転ぶことも許容する
- ただし、ストライダーによって転ぶ人は減った
- そういう技術も積極的に取り入れるべき
- テストを書きやすくする仕組みやライブラリ
メンテナンスを放置して逃げ切るのは無理
- サービスは長生きしOSSエコシステムは活発になった
- 変化に適応しながら、サービスを継続する必要性
- 例えば、ライブラリをアップデートしながら開発するのはもう当たり前
- 部屋の掃除・整理整頓みたいなもの。めんどくさがらない
- 手入れをしながら料理を提供し続ける
- 散らかしたものを放置して料理が腐る前に売り抜けるのは無理筋
誰かが大掃除をしておしまいにしない
- 皆が「片付けながら料理ができる」ように
- チームとしての営みにする
- 誰かに任せると結局またひどくとっ散らかってしまう
課題は変化する
眼の前の課題を解決すると次の課題がやってくる。例えば以下のようなもの。
- コードの肥大化
- スローテスト問題
課題が推移するのは喜ばしいこと。類似の課題は他所にもあるものの、やってくる課題はチーム固有の課題なので、他人任せにせずチームで解決するのが基本。
技術的負債返却の支援
Moshの負債返却計画をどのように支援しているか。
計画のレビュー
経営・開発両面への説明責任を果たせるように
- Why: なんのためにやるのか
- What: 何をやるのか
- How: どのようにやるのか
スケジュールとマイルストーン
- スケジュールはずれるので、マイルストーンを設定して進捗を見える化する
- 後戻りできないポイントを明確にする
- 不可逆な変更点はなるべく作りたくないが、作る場合は慎重に
優先順序付け
- フロントエンド
- バックエンド
- デーアストア
欲張らないように。どの順番で倒していくかを決めてもらう。
背中を押す
- 使いたい技術を使って良い
- 大きくはずれていない限り
- フィードバックループを回せれば問題ない
協力者を作ってもらう
- 誰かが大掃除をしておしまいにしない
- 仲間を作る・組織的な営みとする
- どこに何を整頓するのかの共通認識を整える
- 継続的な負債返却体制
- 誰かのやり方を押し付けすぎない
ピープルウエア
一人が単独で行動しても、意味のある変化はほとんど起こらない。だが、何も一人で行動する必要はない。何かひどく具合の悪いことが起こったとき(作業スペースでのひどい騒音など)、それについてみんなの関心を集めるのは簡単だ。そうなれば、それはあなたのための問題ではなく、みんなの問題となる。
-- 『ピープルウエア』第39章 眠れる巨人よ、目を覚ませ ◆だが、なぜ私が？
LEADING QUALITY
変化をリードするためには、上司や同僚、またあなたに報告する部下といった人々の助けが必要だ。 (中略) - 誰を味方につけるかを知る、そして彼らのモチベーション・目標としているもの・恐れているものが何であるかを知ること - チーム同士・メンバー同士の共感を生み出して連携と相互理解を深めること
-- LEADING QUALITY 第3章 品質文化醸成
技術選定の誤り
- あるに決まっている
- センスの問題？
- それも生存者バイアスに過ぎないとも
- 選択の連続なので間違えることがあるのは当たり前
- 間違ったものを買ってしまうこともある
OSS文化圏と技術選定
- トレンドの踏襲
- エコシステムとの協調
フルスタック志向かコンポジット志向か
- フルスタック: 「全部入り」を目指すか
- easy志向と親和性が高い
- コンポジット: 小さな小回りの聞くソフトウェアを組みわせるか
- simple志向と親和性が高い
このあたりはエコシステムの文化によっても好みが左右される。
easyかsimpleか
Easy: 手数の少なさを重視（そのかわり覚えることが増え、特定の状況には強いが他には弱い設計になる）
— Takuto Wada (@t_wada) March 31, 2021
Simple: 覚えることの少なさを重視（そのかわり手数が増えたり、自分で組み合わせたりしなければならない）
この二つを混ぜると設計の軸がぶれるので、分けることが重要https://t.co/exlrQB2osz pic.twitter.com/iwQ3Eknfl3
めんつゆはeasy
"Simple is not easy" スライド52 https://speakerdeck.com/takeru0757/simple-is-not-easy?slide=52
JSONとYAML
- JSONはsimple
- YAMLはeasy
それぞれに良さがあり、それぞれの良さを他方に求めると、その価値を毀損する。
JSONはsimple
- 覚えることが少ない反面、表現力に乏しい
- 一つのことを上手くやる
- 人間が読めるシリアライゼーションフォーマットとして優れている
- 必ず一行にできる強み
- ログフォーマットとしても使いやすい
- 必ず一行にできる強み
- 人間が読めるシリアライゼーションフォーマットとして優れている
- 仕様が簡潔
- RFC 8259 / ECMA-404 で定義され、パーズもそこまで難しくない
- 融通の効かない仕様が、堅牢性や一貫性、相互運用性に寄与している
- キーのクオート必須、ケツカンマやコメントを許容しないこと等
- システムを跨いだAPI等で使いやすい
YAMLはeasy
- 覚えることが多いが表現力が豊かで読み書きしやすい(ように一見思える)
- 多くのシンタックスシュガー
- 設定ファイルなどで利用される
- 仕様が複雑で難解
- 実は完璧なYAMLパーザーはこの世におそらく存在しない
- 実用的には十分なケースが多いのだろうが
- 例えばYAMLは文字列以外もキーにできる
- 実は完璧なYAMLパーザーはこの世におそらく存在しない
Unix哲学
- Small is Beautiful
- 小さいことは良いことだ
- Make each program do one thing well
- 一つのことを上手くやる
- KISS
- Keep It Simple, Stupid
simpleでコンポジット志向であると言える。今のベテランのエンジニアはその志向の人が多い。
文化圏
- フルスタック文化圏では、小回りの聞くユーティリティが育ちづらい
- コンポジット文化圏では、フルスタックフレームワークが育ちづらい
その文化圏・エコシステムにそぐわないとなかなか使われない。どういうキラーソフトウェアが作られたかによっても左右されるので鶏卵ではある。
「なぜ、フルスタックフレームワーク / 小回りの聞くユーティリティがないのか」というのは、文化圏の違い。→ 郷に入りては郷に従え
具体例
Web開発の文脈において覇権を取ったWebフレームワークがあるかどうかで文化圏の色が変わる。
- Ruby, PHP はフルスタック志向
- Rails, Laravel
- Perl, Go はコンポジット志向
私はsimplel志向かつコンポジット志向寄り。
(正確には、僕がPerlを良く書いていた頃は、easyでマジカル(complicated)なコードを書くことへの反省が界隈的にあった気がする)
フルスタック志向のメリット
- セオリーが定まっており余計なことを考えずに済む
- ネット上のドキュメントで十分なことが多く、社内ドキュメントなどもそれほど書かなくて良い
- 開発思想を通底させることが簡単
- 迷いが少なく初速が出る
フルスタック志向のデメリット
- 融通が利かず、レールから外れると大変
- マイクロサービス分割など
- 一部差し替えるなどがやりづらい
- 差し替えられるものもあるが認知負荷が高くなることも (ex. k8s)
- 乗り換えが難しくロックインされるリスクも高め
- 一蓮托生
- 多くのユーティリティを内包することでメンテナンス難易度が高い
- 外部からのコントリビュートのハードルも高い
- 強力で超人的なリーダーシップへの依存
- 「優しい終身の独裁者」
- もしくはガバナンス
- 複雑度が高く結果として寿命が短め
batteries includedの良し悪し
- Pythonの大事なモットー
- 標準ライブラリのメンテナンスは大変
- 言語コアのバージョンアップ時にメンテナンスの足並みを揃えるのが大変
- お互い互換を壊しづらい
- Rustの場合
- https://blog.rust-lang.org/2017/05/05/libz-blitz.html#batteries-included
- bateries includedにしない
- Cargo(パッケージシステム)を上手く作ることでカバー
(余談) Goの場合
- 日付ライブラリ、TLSが標準ライブラリに含まれている
- 開発体制が信頼できる
コンポジット志向のメリット
- 差し替えや切り出すことが比較的容易
- コントローラブル
- OSSライブラリに変更を取り込んでもらいやすい
- 小さいものは長生きしやすい
コンポジット志向のデメリット
- 思想の通底が難しく、統制が難しい
- ドキュメント書かないとダメ
- 初速が出ない
- 結局グルーコードが肥大化する
- easyっぽいオレオレの仕組みを作り上げて、混乱を生む
- 組み合わせ方にセンスが問われる
ガラパゴスを避けることの大事さ
- トレンドに乗る・作る
- オレオレを社内に閉じ込めない
- 世の中に問う
- 敲かれた技術やプラクティスの方が良いものになる
- 良いモノよりも使われているモノの方が生き残る可能性が高い
OSSの開発速度と互換性問題
- 「自分たちが追随できるか」が大事
- 速すぎないか、適度に枯れているか、腐っていないか
- 後方互換をどれくらい大事にしているか
- semverに期待しすぎない
- ソフトウェアによって文化や風土、塩梅がある
- バージョンアップデート後にどれくらい気軽に更新できるか
- Goはパッチバージョンが0でも安心
- 様子見が必要なソフトウェアも
OSSの開発体制や作者の色
- 「開発体制が信頼できて、継続性があるか」が大事
- コントリビューター陣
- スポンサーや後ろ盾の存在
- 信頼・協調できるか
作者の色
- コンセプトメーカー(発明家)とメンテナ
- めちゃくちゃセンスの良いeasyなツールやライブラリをつくる人がいる
- ただ、そういう新しものに無闇に飛びつくことにはリスクも
- その後メンテされない可能性もある
ghqの場合
昔の go get の挙動にインスパイアされて作られた、リポジトリ管理ツール。
https://github.com/x-motemen/ghq
- 作者のmotemenさんと、メンテナのSongmuとの協調関係があって継続している
Ingy döt Net (本名)
- http://ingy.net/
- YAMLの作者
- 現在のYAML仕様のprimary maintainer / manager
- 戸籍上の本名として登録し直したらしい
- それくらいぶっ飛んだ人
- 界隈のおもしろおじさん枠
- もちろんすごいハッカーでもある
- コンセプトメーカー・発明家
- 面白いものを発明するが、長期にわたって実用に耐えるものを作れるかは別問題
- easyでマジカルなものが好きそう
- オレオレスタック傾向
- YAPC::Asiaで来日していたことも
- 壇上でマジックやるような人
YAMLのルーツ
2001年頃
- Data::Denter というPerlモジュールが大元 (Ingy döt Net)
- XMLの簡素化を目指すsml-devグループのClark EvansとOren Ben-Kikiとの合流
- → YAMLの誕生
「Ingyのコンセプトを真に受けてしまったのか…」みたいな。
YAMLScript
https://github.com/yaml/yamlscript
- 現在アクティブなプロジェクト
- GitHub冒頭の説明が "Program in YAML"
- 嫌な予感しますよね
- YAML and YAMLScript
- YAMLScript Spring Update