これは、チーム開発における「連携の大切さ」と「プルリクの重要性」を強く実感した体験談です。
今となっては懐かしい思い出ですが、当時は正直かなり大変でした。
コードはほぼ出さず、体験談と考察中心で書きます。
ある日、コードが静かに壊れ始めた
チーム開発をしていると、
- コーディングスタイルの違い
- ライブラリの使い方の違い
- 実装順の違い
といったズレはよくあります。
最初は「まあチーム開発だし、こんなものか」というレベルの話でした。
問題の核心：勝手な変更とライブラリアップデート
徐々に問題になってきたのが、次の行動です。
- 自分のコードのエラーを消すために
ライブラリを勝手にアップデート - 他人のコードを
自分の実装に合わせて直接変更
しかも、
- 事前相談なし
- 変更共有なし
- プルリクなし
完全に 個人判断だけで変更が入る状態 でした。
本人に悪意はなかった
ここは補足しておくと、
本人に悪意はなかったと思います。
- 「エラーが出ていたから直した」
- 「動くようにした」
ただそれだけ。
ですが、チーム開発ではそれが一番危険 でした。
最初は柔軟に対応していた
当初はこちらも、
- 修正に合わせる
- 影響範囲を吸収する
- 「まあ仕方ないか」で済ませる
と、かなり柔軟に対応していました。
チーム開発では調整が必要だと思っていたからです。
対応範囲がどんどん広がっていく
しかし問題は収まりません。
- ライブラリのバージョン差分が広がる
- API仕様が変わる
- 他モジュールにも影響が出る
結果として、「どこまで合わせればいいのか分からない」 状態になっていきました。
本人のコードとも整合性が取れなくなる
さらに皮肉なことに、
- 他人のコードを自分基準で変更
- その変更が別の場所に波及
- 最終的に本人のコードとも噛み合わなくなる
という状況に。
最終的には、大幅な書き直しが必要になりました。
なぜこうなったのか
今振り返ると、原因はとてもシンプルです。
- 変更内容の共有がなかった
- 影響範囲の把握が不十分
- 「自分の問題を先に解決する」思考
- チーム全体視点の不足
そして何より、プルリクを使っていなかったというのが一番の問題でした。
プルリクがあれば防げたこと
もしプルリクを使っていれば、
- ライブラリ更新を事前に共有できた
- レビューで影響範囲を確認できた
- 「この変更大丈夫？」と止められた
- 変更履歴が明確に残った
つまり、問題が起きる前にブレーキを踏めた はずです。
チーム開発で大事だと感じたこと
この経験から強く感じたのは以下です。
- ライブラリ更新はチーム合意が必須
- 他人のコード変更はプルリク前提
- 「直した」ではなく「何を変えたか」を共有
- 動く ≠ 正しい
- ローカル最適 ≠ チーム最適
ルールがないと善意は破壊になる
本人は善意でも、
- ルールがない
- プルリクがない
- 共有がない
この状態では、その善意は
簡単にコード破壊に変わります。
まとめ
- チーム開発でコードは簡単に壊れる
- 勝手なライブラリアップデートは危険
- 他人のコード変更は必ずプルリクを使う
- 技術より連携が重要
- ルール・共有・レビューは必須
チームプログラミングでは、
コードを書く前に人と話すこと、
そして
プルリクを通すこと が何より大事だと学びました。