会社でプログラムを書いて測定をしたり、ソフトウェアを扱ってデータ分析をしたりしています。仕事で数年前に開発された製品と新しく開発しているプログラムの修正をすることに苦労しています。
最新の製品では新しいコンセプトで開発が行われ、新しい回路に応じてプログラムの変更できるようにして共通化して使いまわせるようにソフトウェアアーキテクチャが変更されています。その反面、古い製品は、以前のままなので、新しい製品との差が大きく、郷に行っては郷に従うようにプログラムを変更しています。また、使っていたソフトウェアが対応しなくなり、別のソフトウェアを見つけて対処しています。運用する面では、エンジニアに負荷がかかってしまう状況になっています。
そういった状況を少しでも軽くしたく、プログラムを俯瞰的に見ていくことで切り替えができるのではないかという仮説を立て、ソフトウェアアーキテクチャについて書籍を買って読んでいます。プログラム同士の関係性がざっくりとでも把握できれば、気を付けることを見つけやすくなり、対処しやくなるのではないかと考えているからです。下記は、今自分が考えていることです。

ソフトウェアは、実態のないものに名前をつけて構成されているため、作っていけば行くほど、その人だけの理解している範囲というのが生じます。ある程度は、ライブラリを扱ってデータを処理していくので、どういった処理をしているかということが推測することができます。その状況がコミュニケーションやバグの修正などによって整理され、決まりができていくことで共通化され、ソフトウェアの品質がよくなっていきます。その状態を示したのが、ソフトウェアアーキテクチャと捉えています。

ソフトウェアアーキテクチャを考えいていくとき、Unstructured monolith -> Modular monolith -> Micro serviceという流れの変化の中にいるのだと考えてみました。

新規のコードを追加するとなったとき、想定できることが限られています。最初の想定より評価をすることが増えていくにつれ、コードがどんどんと複雑になります。それは、担当した人だけが秩序をもった状態になります。別の人がそのコードを読み直すと、不要なのか、必要なのか、理解できない状況が生まれます。コードを見渡すと、複雑に関係を持っている状態になっています。複雑にコードが絡み合っているUnstructured monolithになっています。
　そこから、計算を行うモジュール、logを出力する方法を記述したモジュール、全体の流れを管理するモジュールとして分割したり、作っているプログラムの構成に合わせたりすることで、複数人でプログラムを扱っても、共通する前提が共有できるようになっていきます。それによって、コミュニケーションによるズレを減らすことができます。モジュールとして分割されたModular monolithとして扱いやすくなります。リファクタリングする活動も全体の流れを理解し、扱いやすいように構成をまとめることに貢献しています。
私がプログラムに主に携わっているのはC++でコンパイルして動作させる範囲で、monolithとして扱われるアプリケーションの範囲ですが、データを解析する部分でさらに別のアプリケーションを扱い、素早くデータを処理する仕組みがあります。効率的にデータを分析するためにアプリケーション範囲で境界線を引くよりも、お互いが調整した上でのデータ配置をする方が最適な処理ができるために形式を合わせて処理が簡単に進むようにしていきます。独立したMicro serviseがあり、その中には結合するための仕組みがあるという括りでみることができます。ただ、このサービスは、ハード側の進化に伴ってより素早く処理できることが増えています。最適なMicro serviceが存在しているというよりもその時の最善なサービスを選択している状態になっています。

ソフトウェアアーキテクチャという視点を持ち、プログラムをいくつかのまとまりとして括っていくことが、大きなシステムを見ていくときの理解の手助けになりそうです。。