去年の2015年2月くらいから、新しいプロジェクトに参加した。
そのプロジェクトは、新規のシステム開発だった。
そのプロジェクトのために、私は他のチームから異動してきた。
その中で、私はWebサービスを担当した。幸か不幸か、その開発を一人でやることになった。
そこで私は、ちょいちょい学習していたデザインパターン等を試してみることにした。
複数人の開発では、デザインパターンなどの知識を持っている人が他にいないため、適用することはなかった。
あったとしても「それとなく、さりげなく」を徹底していた。
知らない人がいるのにパターンを適用すると、混乱を招くからだ。最悪、怒られる。
一人プロジェクトであれば、この点は無視できる。チャンスだと思った。
厳しいことをいえば、保守等を考えてやめるべきかもしれない。
デザインパターン等の知識を持たない人が手を出せなくなる恐れがある。
しかし、ソフトウェアアーキテクチャを適用しないのであれば、いいものができるかと言われればそうではない。
設計が存在しないため重複したコードが大量にあふれ、賢い画面が大量にできあがり、インフラストラクチャーに依存していく。
どんなに私が設計能力が劣っていても、それよりかはマシになるだろうと考えていた。
それから、私はドメイン、インフラ、ＵＩ、アプリケーションを分離し、単体テストを作っていった。
開発期間に余裕があったわけではないが、動かすだけなら一見無駄に見える作業を、ひたすらにこなしていった。
中規模以上の開発において、ソフトウェアアーキテクチャをしっかり考えて一から設計、コーディングしていくのは初めてだった。
書籍などで知っていることでも、いざ実践すると、うまくいかないことの連続だった。
それでもなんとかやっていき、半年後にリリースできた。
まだバグなどの問題は起きていない。
そして一年後の今日、そのWebサービスを修正している。機能追加の案件があったからだ。
改めて見ると粗が目立つ。依存関係がおかしい所がいくつかある。
構造に迷ったりした苦心の跡も随所に見てとれる。
とりあえずひどいところ、修正に影響が出そうなところをリファクタリングしている。
テストがあるので、問題なく構造を変更できる。
そして、インフラストラクチャー層とドメイン層の依存について、もっとよい方法があることに気付いた。
新しいインタフェースを作り、依存関係を逆転させた。
この知識は、このプロジェクトのリリース後に得たものだ。
私のような設計初心者でも、このような気付きを得るくらいにはなった。
やはり、実践に勝るものはない。
私はこのプロジェクトに非常に感謝している。
おそらく、次はもっとうまくできるだろう。
その次は、それよりもっともっとうまくできる。
デザインパターン等の設計における知識を「よくわからない」という理由で避ける人がいる。
それはもったいないことだ。わからないからこそ、やってみるべきだ。コードを書くべきだ。
なんだかんだいって、ほとんどのプログラマーは知識からではなく、プログラムを動かしながら学び始めた人が多いだろう。
設計も同じようにしたほうがいいと思う。
私はこの経験から、そう学んだ。
設計を意識し始めて一年経った。
設計を大事だと思うのは日増しに強くなっている。
一年前に始めたプロジェクトへの機能追加が、あっという間に終わりそうになりながら、そう考えている。
