githubを会社で導入してみて感じたこと

会社で利用するソースコードのバージョン管理システムをgithubに移行しつつあります。

gitは以前から個人で利用していたのでブランチ管理のメリットや気の利いたマージなどはもう知っていたのですが
githubで同時に複数人で開発をする、という状況は初めてだったので感じたことを残しておきます。

導入

まず当然なのですが開発スピードは上がってます。
これはgithubというよりgitの分散リポジトリの仕組みが大きいです。svnでsvk使うと効率が良いのと同じことです。

そこで問題になるのが各開発者のリポジトリ間をどうやってマージさせていくのか、って所なんですが
masterからリリース用のブランチを切ってそこにpull requestを投げて他の開発者に確認してもらってからマージする、という流れで今は運用しています。
投げられた側が確認してマージをコミットするので責任は一蓮托生としてます。
人数増えるとこの運用だと回らないと思いますが、席から全員顔が見える範囲くらいの人数規模だったら大丈夫だと思ってます。

発見

この運用フローを導入することで今まで見えてなかったものが色々見えてきました。
pull requestで運用する、ということは強制的に他の人の開発コードを読む機会が増える訳です。
そうしているうちに気づいたのが実装コードの意識の低さ。とりあえず動いてるレベルでコミットされてるのが多数。

愕然としました。
今までちゃんと見てなかった自分もアレなんですがこのレベルでプロダクトって言われると正直辛い。
コピペで意味を理解せずに済ませているところが多かったり、メンテナンス性を考えてなかったり、コードの重複を余裕でやってたり、とかです。

鍛錬

おそらく「ソースコードを読む」という習慣がないんだと思ってます。
Rails、jQuery、Symfony2、Djangoなどの凄腕の技術者たち、いわゆる天才達が作った
フレームワークのソースコードがネットを介してすぐ読める時代に住んでるのに正直もったいないです。
今挙げたフレームワークのコードを1つでもちゃんと追ってたら恥ずかしくてあんなコード書けなくなると思います。

あと今までの経験上「あとからやる」は基本やらないです。
とりあえず動くもの、で適当に書いたコードは大抵の場合適当なままで終わります。
だから、とりあえず動くものでも全力で取り組むべきだと考えてます。

それと本読もう。いろんな言語のベストプラクティス本とかね。
Google先生に興味ある単語を入れると、もっともらしい答えをリストアップしてくれるせいで、
知識のインスタント化が進んでしまって、身につけるところまで至ってないことが多い気がします。
あとGoogle先生を盲目的に信用しすぎるのはアレです、いわゆるステマです。（言いたいだけ）
様々な媒体から知識を高めていって利用できる情報なのかそうでないのかを分別できる大人になりましょう。

これらを持続できれば、35歳プログラマ限界説とか関係ないんじゃないかと思います。

最後に昔のマンガになりますが「シュート！」で奇跡の11人抜きをやってみせた久保嘉晴の言葉を借りて駄文を締めさせていただきたいと思います。

ソースをコミットしたら観客すべてが自分を見ていると思え。