リファクタリングが自分を成長させてくれる
前回の記事では、どんな初心者でも「投票システム（フロント）」を実装できるっていうことを紹介したんだけど、当然ググってコピペ、そのコードをひたすらコピペで量産では、ごみコード（またの名をウンコード）になるのはいうまでもない。なので前回の状態からレビューをしてくれる架空の先輩エンジニ …
この記事は初心者プログラマ、上達できない人向けの記事だ。なのでGitやDockerについて詳しい人は読む必要がない。できる限り小難しいことは書かずにその特徴を書きたい。
プログラマをやっていく上で絶対に避けて通れないのが、GitとDockerだ。なぜこの２つをまとめて紹介しているのかは後述するが、プログラミングをするための前段階のツールって感じ？そしてあなたがエンジニアとしてどこかで働いている場合、フリーランスで働いている場合、趣味でやっている場合、どの場合でもこの２つは絶対に遭遇する超大前提ツールと言える。
Gitインストール
全然関係ないけど、「ターミナルを開いて」とか「PowerShellを開いて」と言われて、2秒以内に開くことができない人は、以下の記事を読んでね。その時点で悪いけどあなたはプログラマの土台にすら立てていない。
初心者プログラマは基本動作だけで年間66時間以上も損しているかも？
Gitとは何かを知らない人はググってね。ざっくり言うと、Gitはソースの分散型バージョン管理システムだ。うん。とりあえずググってみて。
GitやDockerを使う理由が説明できる？
Git、Dockerは前述の通り非常にベーシックなツールであり、どこに行ってもこの２つから逃れられないと言えるほどスタンダードなツールだ。そこで質問したいんだけど、世の中のプログラマがこの２つを好んで使う理由を説明できる？ 「会社で使っているから」「みんなが使っているから」という思考停止な理由でしか理解していないそこのあなた！まぁ、それでもいいんだけこんな便利なツールは意味がわかって使った方がいいと思うわけ。
だけどGitやDockerの利便性やその理由は、ものすごいたくさんあるし非常に多角的になる。そこで今回は"Gitがなかった時代の不便さから再認識するそのメリット“をほんの一部紹介したい。当然この記事以外の利便性や別の視点からの考えもあるだろうが、あくまで私が実際に体験したGitの利便性の一部を書きたい。（Dockerは次回）
Gitが使われていなかった時代のバカども
2010年より前。Gitという技術は存在していたようだが、日本ではまだ全くスタンダードではなかったと記憶している。意識の高い企業は他のバージョン管理システムを使用していたらしいが、多くの中小企業はバージョン管理すらしていなかった。当時私はまだまだ新米で周りが見えていなかっただけかもしれないけど、実際の案件でGitやそれ以外のバージョン管理システムに触れるなんてことはほとんどなかった。
で、当時の私は、Windowsサーバーで動くASP（classic）を使ったWebシステム開発を行っていた。VBAのようなコードでWEBシステムを作れるやつだ。そしてチームは4人ほどで、あの当時ローカルPCにWindowsサーバー環境を構築できるわけもなく、4人全員が共有でファイルを更新して動作確認するための検証サーバーが用意されていた。この時点でヤバさが伝わるかな？それぞれの修正がコンフリクトしないように、それぞれの担当ディレクトリが割り当てられていた。
1. アホみたいにコメントで名前と目的を書く
そのプロジェクトのソースコードには以下のようなコメントがいたるところに書かれていた。
''# 2008/12/12 山田 ●●のため追加
If str = "" Then
End If
''# 2002/03/25 小山田 ●●のため追加
If str2 = "" Then
End If
まじで笑っちゃうくらいこのようなコメントが至る所にびっしり書かれているんだよ。そして私もこのように書くようにと指示されていた。当然このプロジェクトには上記の例のようにもっともっと古い日付のコメントで、誰かも知らない人の名前が書かれていることなんてざらだった。「いや小山田、誰よ！」っていう何年も前に退職された人が登場したりする。
これさ、当然嫌いな奴の名前にこっそり変更することもできるし日付もウソつけるわけ。サーバーの操作履歴を見れば、誰がいつ修正したか割れるかもしれないけど、場合によっては特定が難しいこともある。また、以下のように同じ処理を代々受け継いで修正したようなコメントもよく存在していた。
''# 2002/12/12 小山田 Sessionをチェックして処理を分岐する
''# 2008/12/12 山田 Session管理はDBで行うように変更
~処理~
小山田さんの修正後6年も立って山田さんがその処理を修正したパターン。もし、2008年のコメントアウトだけが書かれなかったり、後に誰かに削除されたらどう？ 処理とコメントがちぐはぐになって未来のエンジニアを混乱させてしまうことになる。
そして何よりウザくて汚いんだよ。日付と名前を馬鹿みたいにびっしり書いてよ。
当然Gitが登場してからは、それぞれのコミットにより「いつ、だれが、どのように」変更したかすぐにわかるようになった。
2. バカな先輩にファイルを上書きされる（コンフリクト）
これはあるあるなんだけど、開発が動いていくと、どうしても同一のファイルを複数人が修正することがある。当時のファイル修正ルールとしてはどんなファイルをいじる場合も以下の手順をふまされていた。
- サーバーからファイルをDL
- ローカルでファイルを修正
- サーバーにファイルをUL
ところが**先輩（バカ）**が、Redmineでチケットを完了しているにも関わらず修正ファイルをサーバーにアップしていなかったというケースがあった。当然私はサーバー上のファイルが最新になっていると思って、DLして修正してULするわけ。そのあと、アップロードを忘れていた先輩が自身の修正したファイルを上げた。。私の修正はすべて消えてしまったわけだ。もちろんローカルに自分の修正後のファイルは存在しているので、復元するのはそれほど難しくないのだが、以下のようなアホみたいなやり取りが生まれてしまう。
リーダー：「おい！実装全然出来てねーじゃん！」
私：「いや、やったはずっすけど。動確もしましたし。。」
リーダー：「でも出来てないんだって！もう一回確認しろっ！ﾊﾞｶﾔﾛｰ！」
私：「あれ？俺の修正消えてる・・なんで？」
こういうケースは100回以上あった気がする。ところがGitが登場してからブランチをマージするときに明示的にコンフリクトが発生してそれを解決しなければソースを反映できなくなったことで上記のようなコントは起きなくなった。今回のケースでいうと、私が先に検証ブランチにマージを完了しているはずなので、"先輩（バカ）“が検証ブランチにマージするときにコンフリエラーになり、それを解決するのも”先輩（バカ）“ということになる。
バックアップのためにファイル名+日付のゴミを生み出し続ける
今となってはよくわからないんだけど、なぜかサーバー上でファイルをリネームしたバックアップがたくさん存在していた。例えば、“app.asp"に対して"app_20081010.asp"みたいな複製ファイルだ。おそらく元の状態に戻すのが困難になるため、前もってファイルのバックアップをとっているんだろう。
ファイルのバックアップを取るのは百歩譲っていいとして、そのバックアップを消し忘れることがしばしば合ったんだよね。想像してみてよ、大量に日付が付いた複製ファイルが存在しているんだよ？そして時間がたてばたつほど、本当にそれらを消していいかどうか誰もわからなくなってしまうわけだ。
Gitでは、こんなことをする必要は一切ない。例えば、ローカルで修正していてコミットする前にやっぱり全ての修正を戻したいってなると、
# rootDIRで
git checkout .
って全部元に戻せるし、すでにコミット済みでもそのコミット取り消したりすることも可能だ。
パ二くって本番サーバーを直接いじるアホ
これはGit関係ないっちゃないんだけど、FTPなどでサーバーのファイルを修正することが常態化している場合、本番サーバーも随時いじっちゃうわけ。とりわけ重大なバグがそのまま本番にアップされていることに気付いたとき、チームはパニックになり、素早く修正を反映したいから、直接本番に上げることがよくあった（緊急対応）。チームの全員が本番サーバーをいじれるアカウントを付与されることも往々にしてあった。
チームの誰でも本番サーバーをいじれるってこと自体が問題なんだけど、それよりも問題なのが、検証サーバーへの反映を行わずに本番サーバーへ反映が行えてしまうってことだ。後日、この緊急対応したファイルに対して他の修正を行い、検証サーバーから本番サーバーにアップしたらどうなる？本番では緊急対応によりバグが修正されているので、検証でもそのバグは消えていると思いこんでしまって、またバグが内在したファイルを本番に上書きしてしまうわけだ。
Gitが存在しないからこのような不手際が発生するってことではないんだけど、Git（Githubなど）によって手続き的にこのような事故を防ぐことができる。
例えば、masterブランチを本番、stagingブランチを検証として、さらにmasterブランチには誰もpushできないように、権限を持つ上長がstagingからmasterにのみマージ可能という風にルールで縛ることで解決できる。まぁこの例は、“Git"というよりはGithubやGitlabなどのツールによる利便性と言えるが。
当たり前すぎてありがたみを忘れかけていたGit
ざっとGitがなかった時代の事故をほんの一部紹介したが、リアルにこのようなことが頻発していたんだよ。当時の意識高い企業がどうしていたかとか、それ以前（2000年以前）の人たちはどうしていたのかなどは不明だが、確かにバカバカしいコントが繰り広げられていた。おそらく当時から働いている人には共感してもらえると思う。なお、SVNというGitに似たツールもあったけど、それもそこまで浸透していなかったはずだ。
Gitを使うメリットは？って聞かれても当たり前すぎてもはや答えるのが難しかったりするけど、Gitがなかった時代の話をするとそのありがたみが伝わりやすくなると思ったわけだ。
もしあなたが現在でもGitを使いこなせずここで紹介したような事故が頻発しているようなシステム会社に勤めているとしたら、すぐにその会社辞めた方がいいよ！ たまーにあるんだよ。未だにFTPで複数人開発しているような残念な会社が。
次回も同じようにDockerについて書きたいが、Dockerの利便性はGitによっても支えられている面があるので、先にGitのことを書いた。
