Gitの用途はチーム開発だけではない
さて、前回のyum導入に続けて、第2回は、IBM iにおけるGitの活用についてお話します。
と言っても、IBM iに特化した活用方法というわけではなく、むしろふつうにGitを使ってみようという話です。
前回でも触れていますが、私自身GitをIBM iで使い始めたのは、5733-OPSのライセンスが出るよりもずっと前で、当時はPerzl.orgから導入し、大変お世話になっていました。
それ以前に使っていたSVN（Subversion）からGitに変えた時は、とにかく、.svn ディレクトリ地獄から解放された、という思いだったことをよく覚えています。SVNでは、管理下におかれるすべてのディレクトリ内に「.svn」という名前の、SVNが管理するためのフォルダが作成されます。それと比べてGitは、管理下のルート・ディレクトリに.gitディレクトリが1つ作成されるだけなので、とてもシンプルです。
Gitの管理から解放する場合も、その.gitディレクトリを削除してしまえば、即座に管理下から外すことができます。この.gitディレクトリだけでよいというシンプルさが、Gitの素晴らしさだと、その当時は思っていました。
VCS（Version Control System)は、チーム開発やプロジェクト開発に役立ちます。複数のメンバーで、ソース・ファイル、ドキュメント、APIマニュアル、テストコード、問題管理などを共有する際に、あらゆる局面で役立ちます。
Gitは、そんなチーム開発に使用するイメージが強くありますが、実際はそれだけではありません。むしろ、大昔の@ushidayは、チーム開発ではなく、自分のためにだけ使うほうが多かったほどです。
独りで使っても大活躍のGit
チーム全員の足並みを揃えて、Gitを開発やプロジェクトに採用したりすることは難しいと思っている方は、ぜひ大昔の@ushidayのように、自分のためだけにGitを使い始めてください。次回は、独りでも使う価値があるGitの話をしてみたいと思います。が、その前に…
IBM iのRPG／CL開発でよく見受ける、ソースコード管理のバッドノウハウを思い出してみましょう。以下のようなケースは、長年使用されてきたシステムほどよくある話です。システム開発の依頼を受けると、目の当たりにすることがよくあります。
バッドノウハウの例
1. ソースコードを改修した時に、バックアップソースを保存しておかないと心配になり、不要メンバーが増殖
QRPGSRC.AAA001R というメンバーを、QRPGSRC.AAA001R_1、QRPGSRC.AAA001R@1、QRPGSRC.AAA001R.B1などと増殖させていませんか？
・ソース検索やシステム改修する時にノイズだらけで困りませんか？
・不要なソースをオミットするために、無駄な工数が生じていませんか？
・ソース検索 → ワードがヒット → 不要なソース、とわかると、精神的にイライラしませんか？
2. 過去にいつでも戻れるように、SAVLIB,SAVOBJコマンドでまるごとSAVFに保存
・本番ソースを汚染しないので、(1)のパターンより、いくらかよいとは思います。それでも、保存したSAVFはいずれ忘れられ、ゴミとなっていませんか？
・そのゴミは、人や担当が変わると、必要か必要でないのかさえよくわからなくなっていませんか？ スナップショットをSAVEするタイミングが人任せになっていませんか？
・残骸のSAVFが、いつの間にかディスクを圧迫してはいないでしょうか？（このようなケースは、ソースよりもむしろデータベースで多いかもしれません）
3. 新規開発案件にもかかわらず、ソース変更の時は、ソースコード内に改変前のソースコピーをコメントとして残していませんか？
・これまた検索性が悪くなりませんか？
・特に、5250のSUEを使用している場合は、正規表現が使えないので、イライラしませんか？
・目視デバッグの際に、「そんな筈はないのに？」と散々時間を費やしたら、コメントの * を見落としていたことはありませんか？（特に、5250のSEUではカラーモディファイされないので見落とされがちです）
上記のようなケースは、弊社の新人研修でもよく遭遇します。消してしまうことへの不安はわからないではないですが、コード・レビューをする側にとっては、とても見づらく大変です。
みなさまのソースライブラリには、上記のような不要なソースコードや、忘れられたSAVFはありませんか？ それも、もしかしたら10年～18年モノの。ウィスキーなら喜ばれるかも知れませんが、ソースコードで古くなった不要なコピーは「百害あって一利なし」だと、個人的には思います。
クライアント様からシステム改修を依頼されると、影響度合いを調査するためにソースコードを分析しますが、整理整頓されていないためにソースコード自体がノイズとなり、ターゲット・ソースやロジックがぼやけてしまっていることがよくあります。
こうしたノイズは、社内で開発されている情報システム部門の方々や、特にそれらを前任者から引き継ぐ方々にとっては、本来やるべきこと以外の、すなわちシステム改修以外のことにコストがかかってしまうのです。そして、システム改修をベンダーに依頼した時は、ソースコードを整理しているユーザー様とそうでないユーザー様との間で、改修コストに大きな開きが出てきます。
Gitを使ってソースコードのノイズを減らそう！
ソースコードのノイズを極力減らすために、Gitを活用して、ソースコードを整理整頓してみましょう。前述の通り、ソースコードの整理整頓は、チームでなくとも、個人ユースでもスタート可能です。
最初に、Gitといっても5733-OPSで提供されているGitではなく、まずはyumからインストールしてみましょう。
まだ、yumを導入していない方は、第1回の導入編（https://www.imagazine.co.jp/ushidayhack/）をご覧ください。
ACSによるGit導入
［手順１］
IBM i Access Client Solutionsを起動し、[ツール]→[オープン・ソース・パッケージ管理]を選択します。
［手順２］
[システム:]、[ユーザー:]、[パスワード:]、必要であれば[SSH 鍵（オプション）]を適宜入力し、[OK]ボタンをクリックします。
［手順３］
[使用可能なパッケージ]の中からGitを選択し[インストール]ボタンをクリックします。
［手順４］
黒いプロンプト画面が立ち上がり、 Is this ok [y/N]: と y を入力し Enterキー を押すとインストールが開始されます
［手順５］
プロンプトに Complete! と表示されたら、インストール完了です。
以下のように [インストール済みパッケージ] にGitが表示されているはずです。
今回は、ここまでです。
次回予告
これでGitを利用する環境は、整いました。次回は、上記バッドノウハウをGitで解決していきましょう。
ushiday@Hackな日々
第1回 テーマはyum
第2回 yumでGitを使おう ～その１
第3回 yumでGitを使おう ～その２
第4回 yumでGitを使おう ～その３
第5回 ncdu ～ディスク使用量を調査する便利コマンド
