コードは増えるよどこまでも - 脳に収まるコードの書き方⑥ - ReadLog

2024年9月11日 22:26

概要

タイトル：脳に収まるコードの書き方
ジャンル：技術書（情報系）, ソフトウェア開発, プログラミング技法
備考：ここから第2部、後半戦！

ここは本の紹介と記録を目的としたマガジンです。
時間がない人や面白い本を探している人向けです。
本の一部を引用しながら、少しでも興味を持ってもらうことを目指してます。

10章から第2部に入って、コードを作る話から管理の話に移っていきます。
だんだん過激?な主張は抑え気味になりますが、最後まで駆け抜けていきましょう！

（前略）フィーチャーブランチを使いたくなるかもしれませんが、使ってはいけません。その道はマージ地獄へ続いています。

p.172 10章コードの拡大

何年か前に、とある会社のインターンシップに1週間参加したことがあります。そこで習ったことの1つが、Gitリポジトリのコード管理手法の一つ、Git-flowについてでした。

誤解を恐れずに簡単に説明すると、Git-flowは主に3種類のブランチを使用します。

開発作業はfeatureブランチにコミットしていきます。
featureブランチでの作業が完了すればdevelopブランチへのプルリクエストを作成します。それが承認されればdevelopブランチにマージされます。
区切りまでの開発が終わればmainブランチにマージして公開！という流れです。

これはいいことを知れた、と思って、同じくインターンシップを受けた友人とGit-flowに則ったリポジトリ構造でチャットボットを作るなどしました。（楽しかったな）

そんな私の思い出をすり潰す発言です。これはいただけませんね。

ちょっと著者の言説を整理していきましょう。
前回の話になりますが、この本の主張においてコミットされるコードは常に、テストコードをパスするビルド可能なコードです。

ただしこの10章では、すぐには完成しない機能が対象になっています。具体的に言うと、4時間では実装できない機能です。（※1日8時間勤務の中で2回完全なコードをコミットするという前提もあるため。）

対象の機能が完成していなくても、定期的なコミットは必要です。
不完全な状態ではテストはパスしませんが、ここで導入されるのがフィーチャーフラグです。

フィーチャーフラグ
開発途中のコードが動作しないように分岐させるためのフラグ変数

製品リリース向けのテストコードを実行するときには開発中の機能が動作しないようにした状態にします。これでリリースはできる、という話です。

少し気になるのが、コードレビューの単位をどうするのかという話。
普通はプルリクエストのタイミングだと思うんですが…
確かにこの本の方針に従っていれば、脳に収まらないコードはビルドに失敗します。ただ、実装者以外のレビューも当然必要です。

コミットは乱立されるし、複数の人が同じブランチにコミットすればコミット数は増殖していきます。どのコミットをレビューすればいいのか分かりにくくはならないのか…いったい？

作成・更新されたファイルの情報を共有してレビューすればひとまずは済みそうですが、なんにしろこの辺りはチーム内で運用を決めないといけなさそうです。
なぜか書いてないし…この辺りはまた個人的に調べておきます。

補足：Git-flowがあんまりよくないという主張は他にも見たことあります。

この名前は絞め殺しイチジクからとられています。「宿主」の気に巻き付いて育つツル性の植物で、長い時間をかけて水と日光を奪い、宿主を絞め殺します。その時点では、自分を支えられるくらい強固なツルに育っています。あとに残るのは、死んだ元の木と同じサイズに育った内部が空洞のイチジクです。

p.164 10章コードの増大

何でいきなり植物の話なんだと思うかもしれません。
10章の後半は、大規模なリファクタリングをするときの話です。

改修対象のクラスが大きすぎるとき、いきなり新しいクラスに置き換えるとコンパイルエラー出まくって時間がかかりまくった。
という著者の体験談からこの話は始まります。

ではどうすればよかったかというと、絞め殺しイチジクのやり方に倣うべきだ。ということになります。

メソッドを少しづつ新しいクラスと入れ替えて、絞めていき、ゆっくりと、確実に古いクラスを葬ってあげましょう。それがシステムにとっての救いです。

次：

この記事が気に入ったらサポートをしてみませんか？