18章 ビルドシステムとビルド哲学
18.1 ビルドシステムの目的
速い
webpackの代替がいっぱい現れてるのがこの記述の裏付けになるなーと思った
webpack3の頃は設定が複雑すぎて大変だった
今はとりあえずViteにしておこう
戦国時代なのでツールの選定で手をこまねいている
自動的にビルドされ、テストされ、本番環境へプッシュされる
テストとプッシュが両方自動化されていることで、デプロイ前のビルドが省略できている
手動デプロイだとここが二度手間になることが多い
テスト用と本番用で設定を揃えるのも地味に難しい
18.2 ビルドシステムがないと何が起こるか
読めないmakeスクリプトを思い出した。
やばめのmakeスクリプト、変な共通化で依存関係がめちゃくちゃなことも、、
シェルスクリプトは救援となるか
「ビルドシステムの必要性」は意外と説明されることがないので、短くまとまっていて良い感じ
大学を出たばかりのジュニア開発者なら、その作業がそれまでの経験の全てだったかもしれない
実際、手元でちまちま動かしている学習フェーズと実際のアプリを触り始めるフェーズとで、ビルドの存在で隔絶を感じたので、ユーモアがあるのも込みで良い文書
この章の前半は教科書のような内容
CIがいかに必要かということの経験がつまった文章だった。いまだとこのへんが「とりあえずGitHub Actionsでこのツールを実行させておこう」ってなるのが本当にすごいとおもう。(10年前まではそんなことなかった)
18.3 現代的ビルドシステム
AntのXMLをみてめっちゃ懐かしく思った。これをGroovyで扱う方法とかあったなーとか。
2000年から2010年くらいってプログラミング言語で扱うっていうのがあまり発展していなくって、XMLとXSLTで解決すればプログラミング言語によらずに(特定プログラミング言語のランタイムなしに(それらは有料であることが多かったように思う))ある程度のデータを処理するための定義が揃うっていうことから持て囃されていたような気もする。
解説のドキュメントが増えやすい環境
ビルドシステムの問題とは、エンジニアに多くの権力を与えすぎて、ビルドシステムに十分な権力を与えていない状態に実態は陥っていることだ。 中略 ビルド実行の際にどのように(How)実行するかという部分は、システムに任されるだろう
ビルドシステムの歴史をわかりやすく書いてくれた
Gradleオタクだったので、このへんの話めっちゃ好き
アーティファクトベースのビルドシステム
DDD本の「宣言的な設計」の箇所に同じことが書いてあった
関数型プログラミングの利用も書いてある
DDD本には「副作用は表明しろ」と書かれているが、そのあたりに言及はなさそう
全自動を目指している以上、あったら困るから?
暗号学的ハッシュの列挙
決定性ビルドで一番重要な技術では?
ハッシュ関数って凄まじい発明だと思うのに、そうやって言及されることは少ない気がする
自分が知らないだけかも
信頼でき制御下にあるサーバーやサービス上にプロジェクトの全依存関係をミラーすること
このへんの思想がBazelやGoに生きているって聞くとエンジニアリング組織の強さを感じるなー
18.4 モジュールと依存関係を扱う
18.5 結論
エンジニアの権力と柔軟性を制限することで、エンジニアの生産性が向上する
CoC
アーティファクトベースやリモートキャッシュなどによってscale downすることも念頭におかれているのは本当によき
18.6 要約
バージョンロックするっていうのはここ四年くらいは普通になった気がする。いままでは比較的無造作にアップデートしていく風潮があったなー。
後方互換性を維持されるのが当たり前ではなくなった、ということかもとJSのお守りをしていると思う
それでもデカいところを下手に壊すとコミュニティの分断を起こすので(Python 2, 3とか)重要でなくなったと言うつもりはないです
みんなからのコメント
Googleにしかできないとしたら、それはなぜか?
ビルドシステムやコンパイラがアプリケーション開発とは違う知識やスキルがもとめられるので、アプリケーション開発エンジニアの延長上にあるボランタリティでは貢献しにくそう。
そもそも「ビルドツールを自作する」という発想がない。だいたいSDKなりフレームワークなりのデフォルトをそのまま使ったり、シェルスクリプトで十分だったりする
その結果発生するものも「待ち」なので、ボーッとしていたら過ぎていく。ここに着目して生産性を改善しようとするのはGoogleらしい
現場でどこまでできているか?
最近はあまりこういったツールチェイン周りをうまくあつかうのができていないかもなー。(一年後にはこういったことを比較的やっていそうな気配はある)
この本があるのになぜ実践する企業はすくないのか?
アプリケーション開発をしたいエンジニアと、売り上げに繋がりやすい気がする機能をつくりあげたいPOが合わさると、こういったツールチェインの改善による生産性向上に対してそもそも着目しないみたいなことはありそう。
ビルドが並列化必須なほど規模の大きいプロジェクトを持っている企業は少なく、仮にビルド時にマシンパワーが必要でもクラウドから調達するのが簡単になってしまっている
それの乗り越え方はなにか?
アプリケーションコードの技術的負債を指摘するツールは増えてきたので、ツールチェイン周りの技術的負債を指摘するツールが増えると実践しやすそうな気はする?ツールチェイン版SonarQubeみたいな。
ステップを小さくするとしたらどうできそうか?
ツールチェインの移行をするとか、プラグインを書いてみるとか
ツールチェインはeasyが求められがちで、simpleを組み合わせるモノは最近少ない気がするので選択の余地が少ないかも
ツールチェインが乱立してるのってJS/TSくらいでは?