arclamp.jp アークランプ

システム再構築のために新機能提案の作業を行っている。そのためには、まず既存機能を解析する必要性がある。が、仕様書は存在しないので、画面や業務の動きを知るだけではなく、コードを追わなくてはいけない。
コードを追うというのは、緻密にやろうと思えば誰でも出来る。しかし、スパゲッティ状になったプログラムは、ロジックがあちこちに散らばっているため、分析するとなるとかなりの時間がかかる。新機能への提案というフェーズでは、詳細に把握するというよりも、アーキテクチャの概要を理解し、問題点を指摘することが目的だ。となると、いかに短い時間で全体をつかむのかが重要になる。

そこで大事なるのが思想だ。エンジニアというのは合理的な生き物だ。どんな変なアーキテクチャやコードであっても、思想とアーキテクチャの間には、それなりに合理的な理由があるものだ。だから、思想が理解できれば、アーキテクチャの理解も早くできるわけだ。

重要なのは、初期思想と、そこからの変遷をつかむことだろう。だいたい再構築というのは、既存コードに修正を加え続けたプログラムが崩壊しかかっておきる。だから、初期のアーキテクチャに引きづられて新規機能がついている。新規機能が初期思想の先にあればよいのだが、不幸にして思想の転換があると、思想とアーキテクチャに不整合がおきてしまう。だから、再構築段階でコードを読むと「なぜこんな非効率なことを！」ということになる。

しかし、現在の思想とアーキテクチャの不整合を指摘するだけではだめだ。初期のアーキテクチャがどのような思想で開発され、それがどのように変化したことで非効率になったのかまで理解しないといけない。そこまでできれば、ユーザーに対して、「初期の思想はこうであってものが、こう変わってきたために再構築にいたった。だから、新アーキテクチャは、この方向でいくべきである」という提案が出来る。ヒントになるのは、当時の業務フローや仕様書だろうか。

副次的な効果も見逃せない。初期思想を知れば「この機能であれば、こうなっているはず」というあたりがつきやすい。現在の思想から想像しようとしても、そもそもアーキテクチャに不整合があるわけだからあたりがつきにくい。そして、そうした不整合部分にバグが潜んでいる可能性も高い。

手書きのソースコードは、まさに思想そのものである。相手をシステムと見ないで、人間だと思って付き合ったほうが、より理解が進むのではないだろうか。