はい、どうも、こんにちは、七堂です。
今日はめっちゃマルチタスクで仕事をしていました。A案件の保守をやり、B案件の保守開発をやり、B案件の開発をやり……。
すごく受託請負のソフト開発屋さんみたいでした。
マルチタスクをしていると、なんかそれっぽいよね。
さて、そんな中、めちゃくちゃハマりました。何にハマったのかって、プロジェクトのビルドだよね……。（※ビルド プログラムを実行可能な状態にすること）
どうしてハマったのか、どういう仕組が理想なのかを、未来のためにメモを残して起きます。
プロジェクトのビルドでハマった理由
ハマった理由は以下の３つ
- リソースがメンテされなくなったため
- テストコードがメンテされなくなったため
- 手順が複雑になっていたため
リソースのメンテがされていないプロジェクト
１つの案件はビルドは、ビルドに必要なリソースをサーバー上に上げておいて、みんなが共通のリソースを使えるようにした仕組みでした。
開発中はみんなが同じソースを使えるので、それぞれが部品の開発に集中できるため、効率は上がります。
なのですが……、安定して運用をするようになると、そのリソースのメンテナンスがされなくなるのですよね。
今回はどうしても入ってこないプログラムがあって、頭を悩ませた結果、そのサーバー上のリソースがメンテナンスされていないことに気が付きました。
なぜメンテしなくなったし！！
普通なら、ソースを修正したら、リソースもメンテするのが基本です。そういったことが運用手順として記録されています。
テストコードがメンテされなくなったプロジェクト
２つ目はテストコードがメンテされていないために起こっていました。テストコードを通過するとビルドが通る仕組みでしたが（意図的にスキップもできる）、メンテがされていないため、エラーとなり、永遠にビルドされていなかったです……。
テストコードを書くことは、こういった弊害があるから、あまり好きではないです。
プログラミング初心者がいる場合には、テストコードはかなり有効でしょう。汚いコードはテストコードがかけなくなるためです。
例えば、引数が１つのメソッドでしたら、引数１つのバリエーションを作れば良いです。
これが、無意味に２つになった場合は？ 全件を網羅するために引数１のバリエーション×引数２のバリエーションになってしまいます。
コードの綺麗さを担保するためにはテストコードは有効なのです。ですが、運用フェーズに入ってくると、話は変わってきます。テストコードをメンテしなくなり、ビルドが通らないなどの弊害が生じてくるのです。
プログラム修正をするときに、テストコードまで面倒を見るって話は、何故かどこかのタイミングで形骸化してしまうのですよね……。
手順が複雑になったプロジェクト
３つ目は手順の複雑さによって引き起こされるものです。
WEBアプリの場合、フロント（画面）、バック（サーバーサイド）、データベース、バッチのようにソースが分かれるのが基本です。
こうなってくると、フロントをビルドして、デプロイして、バックをビルドして、デプロイして、データベースの値を変更して、バッチを更新して、と手順が複雑化してくるのですよね。
切り分けられていることは、メリットは大きいです。フロントでバグが生じたら、そこだけの修正ですみますし、画面だけをバージョンアップさせたいとなったら、フロントだけ回収すれば良い。
でも、そうなってくると、本番環境へリリースするだけで、４，５時間かかる鬼のようなシステムが出来上がってしまいます。
すべてのモジュールを一括でビルドするようなプログラムを用意できればよいのですが、これもなかなか時間を持っていかれるわけで、改善はされにくいです。
サバクラ分離はメリットが大きいように見えて、そうでもないのでは？ って思うわけです。
プロジェクトのビルドを平和におこなえるために
まとめることが大事
今日の仕事で思ったことは、リソースの管理を１つのGitで管理できるようにすることが大事なのかなと思いました。
WEB系案件の場合は、プログラムからDBが作成される仕組みを持つフレームワークが多々あります（マイグレーション）。あの形が一つの理想形何じゃないかなと。そうすれば、サーバーとDBを１つにまとめることができます。
バッチすら内包するフレームワークもありますしね。SpringBootなどなら、サーバーも内包できます。サーバーのプロパティ管理が減るわけです。
プロパティといえば、開発環境、製品環境の設定ファイルもうまいこと、１つのGitもしくはセキュリティが硬い共有エリアにまとめておけることが大切ですかね。
環境ごとのファイルが本番サーバーにしかない状態になるので……。
仕組みで回すことが大事
共通のリソースは、サーバーのスケジュール機能を用いて、常に最新化をするってのも手です。
仕組みで自動化してしまえば、今回のようなトラップは少なくなります。
テストコードも自動ビルドの仕組みを上手く使えば、エラーにならないようにしないと、社内環境が壊れるってふうにすると良いと思います。
まぁ、書かなくてもきれいなコードを書ける人選をするのが一番だとは思いますが……………
ただ、仕組みで動かすのには、初期投資の時間が必要になってきます。こちらはなかなか承認が通りませんので、初動でリソースをまとめることに勢力を注いだほうが良いかなと思いました。
まとめ
お仕事で久しぶりにハマりました。まさかのプロジェクトのビルドでね。
原因はリソース管理の甘さと、手順の複雑さです。IT業界なのにこういったのを簡単にできないのはどうにかしているかなと。
改善策としては、ソースを一つにまとめることが大事だと思いました。これだけで、管理の工数は大幅に削減できます。
あとは、仕組み化ですね。ただ、こちらは、初期投資が大きい分、なかなか組織では許されない行動になるかと。
まずはリソースをまとめることを第一にです！