はじめに
私はJavaエンジニアで、参画するプロジェクトもほぼJavaです。
そんな私ですが、プロジェクトに参画したら、最初に以下を確認するようにしてます。
- プロジェクトの共通処理
- エンド企業やベンダー独自のライブラリ
- Apache CommonsやGoogle Guavaなどのオープンソースライブラリ
コーディングにこれらを利用することで、より効率的かつそのプロジェクトに即した成果物ができると考えるからです。
では、なぜこんなことをするようになったか、今回はその契機をお話しできればと思います。
きっかけはハードコーディング
前所属していた会社のときの話です。
受託開発後、保守・運用まで担っていたシステムを、私が引き継ぐことになりました。
システムに対する解像度を上げてから引き継ぎに臨むため、私は事前に環境を構築し、ソースコードや資料を確認していました。
そんなときのことです。
DBとの接続を担う処理にハードコーディングを発見しました。
それも、DBの接続先となるURL・ユーザ・パスワードなど、いわゆる環境依存値です。
このシステムには本番環境の他に、検証環境と開発のためのローカル環境がありました。
仮に、ハードコード部分がユーザとパスワードのみで、全環境のユーザとパスワードが同じなら、百歩譲って納得はできます。
しかし、接続先のURLは環境によって異って当然ですし、ソースを見るとユーザとパスワードも各環境で異なっているようです。
引き継ぎ時に確認したところ、「デプロイ前にソースコードを、反映予定の環境のものに修正している」とのことでした。想定どおりですね。
私が担当になってから、ハードコーディングは撤廃しました。
環境に依存する値は設定ファイルからの取得が可能となり、デプロイ事故の危険性も無くなりました。
しかし、私が改善できたのは、技術力があったからではありません。ただの偶然です。
改善内容について
実はこのシステムは、DBの環境依存値を外出しで定義する設定ファイルも、そこから値を読み込むライブラリも最初から持っていました。
つまり、最初からハードコーディングなんてする必要なかったのです。
私がやったことといえば、これらを利用するように修正しただけで、
今回のために新しくコーディングした処理なんて全くありません。
背景
このシステムは、他社が開発したシステム(以降、仮にAシステムとします)をベースにしています。
我々はAシステムのソースコードの提供を受け、それを基礎に開発されたのが、今回私が担当になったシステムです。
そしてAシステム自体も、その会社が開発した別システム(以降、仮にBシステムとします)の一部を抜粋し、共通処理のライブラリとして流用していました。
DB用の設定ファイルおよびライブラリは、このBシステム時代のものでした。
私は偶然、これらの設定ファイルとライブラリを発見できたので、容易に改善できたのです。
どうしてこうなった?
Aシステムでは、設定ファイルとライブラリは使用されず、別の方法で外部から環境依存値を取得していたようです。
なので、設定ファイルとライブラリの存在に気付けなかったのでしょう。
そして開発過程でどういうわけか、DBとの接続処理がハードコーディングになり、そのまま本番運用までいってしまい、設定ファイルとライブラリはあるのに、わざわざハードコーディングで運用するという、奇妙な状況が生まれたのではないでしょうか。
まとめ
AIを利用した開発がスタンダードになりつつある昨今、よりドメイン知識の重要性が主張され、エンジニアはよりその知識量を問われることになります。
独自の共通処理やライブラリは、ドメイン知識とコーディングの両方に跨り、その知見は今後も重要視されていくと思います。
また、今回のシステムのエンド企業は、優れた独自ライブラリを多く保有していました。
しかし、それらに関する知識や資料が共有される機会は少なく、知識量はベンダーやメンバーごとに大きく差がありました。
これらの知識へのアクセシビリティ確保は、エンド企業やベンダー側の今後の課題になっていくのではないでしょうか。
ここまでお読みいただきありがとうございました。