リポジトリの運用保守性とコードの可読性・メンテナンス性のバランスについて

2019年11月1日2022年7月24日

こんにちは。
今日は、自分の周りではあまり聞かないのですが自分の中にはある、リポジトリの運用保守性について少し考えてみます。

ここで言う運用保守性とは、リポジトリの操作とそれに伴う本番環境への反映などを対象とし、その運用保守性を上げていく対応のことを指しています。

マスターブランチへのマージはrevert出来る状態にしていくブランチ運用で、
処理系変更は影響が出るのは当然なのでそこは除外し、処理系変更以外の、リファクタリング等によるrevert時のコンフリクトを極力なくす事を重視します。
そこをなくすことによって、不具合発生時のrevertがし易くなります。

一方、コードの可読性・メンテナンス性を上げる対応ですが、
こちらは機能変更によってメソッド名の意味合いが変わる事による名称変更をする等のリファクタリングを織り込んで行くスタイルになります。

この両方の主張はどちらもエンジニアなら考える内容だとは思いますが、両立出来ていないのが現実ではないでしょうか。

実際は両立は可能ですが
コードの可読性・メンテナンス性の側に機能変更とリファクタリングの分離と言う負担が発生します。

機能改修にリファクタリングを織り込むことが良くない例

master

コードの内容（例）

def onClick()
end

ブランチA

要件

画面要素の変更

コミット

画面要素の変更とメソッド名変更をコミット

def onClick()
end

から

def onButtonClick()
end

に変更

ブランチB

要件

サイドバーにもボタン追加

コミット

ボタン追加

処理は

onButtonClick()

あるから使おう

と言う二つのブランチがマージされた後、ブランチAでの改修が不具合があり、
修正ブランチ作るよりは運用の観点から見ると修正を待つより一度revertして修正の後に再度マージしたい。

と言った場合にブランチBも戻さなければいけなくなってしまいます。

これが、

ブランチA0

要件

メソッド名変更

コミット

def onClick()
end

から

def onButtonClick()
end

に変更

ブランチA

要件

画面要素の変更

コミット

画面要素の変更をコミット

ブランチB

要件

サイドバーにもボタン追加

コミット

ボタン追加

処理は

onButtonClick()

あるから使おう

となっていれば

ブランチAはrevert出来そうです。

このような事象は毎回発生するものでも無いため、おろそかにしがちではありますが、
普段から意識していないといざという時に痛い目を見る事になりかねません。

ただ、厳密に分離を原則とすると、リファクタリングが進まなくなる可能性が発生します。

そこで、この両者のバランスを取れる落としどころはどこなのか、少し考えてみたいと思います。

明らかに今回このブランチでしか参照しないな～と思われる部分（ソースの全検索も必要であればする）であれば
許容。
メソッド名、クラス名、その他スタイル名など他所でも再利用が考えられている物に関しては
極力改修とリファクタリングを分離。
処理の最適化
極力改修とリファクタリングを分離。
変更する事でコミット対象ファイルが5個超える場合は
改修とリファクタリングを分離。
ファイル名変更は必ず
改修とリファクタリングを分離。
※gitのコミットではファイルの削除と追加が裏で行われているだけなので
中身の変更の履歴ががここで途切れるため。
ファイル分割は必ず
改修とリファクタリングを分離。
※これもファイル名変更とほぼ同じ理由により。
メソッドの順番入れ替えも必ず
改修とリファクタリングを分離。
※これもファイル名変更とほぼ同じ理由により。