ソフトウェア開発における設計は、エンジニアによる腕の見せ所であるとともに、本質的に難しい。限られた時間の中で、持ちうる手札から最適な手法を選択しないといけない。大抵の場合は手法間でトレードオフを孕んでおり、最適さはそのアプリケーションの性質に密接に依存する。出来る限り良い選択をするには、インプットを増やして手札の数を増やすこと、そしてアウトプットを増やして最適解を探り続けることが重要となってくる。
ではどのようにそのスキルを伸ばしていけばいいんだろう、という話。
手札をどう増やすか
習熟度に応じては手札の増やし方は変わる。サーバサイドだろうがモバイル開発だろうが、プログラミングを始めるきっかけは人次第だが、まずは自分の興味のある領域を開拓することから始めるはずだ。周辺のフレームワークやツールの思想や精神を理解しなくてもよい。とにかく使い方を徹底的に覚える。
そうすると、いつの間にか流れる思想や精神が勝手に身体に染み込むはずだ。おそらく初心者が最初に選ぶテクノロジは一度は界隈を席巻した過去があり、それらには何か１つは重要な示唆を富んでいるはずだ。なのでよほどレガシーでない限りは勉強する価値は心配する必要はない。とにかく身体に染みつかせよう。
完全に染み込みきったら、そのテクノロジの信者になるフェーズが誰しもあるように思う。しかし、井の中の蛙になるべきではない。他のパラダイムのテクノロジに触れてみよう。
例えば、構造化プログラミング、オブジェクト指向、関数型プログラミングなどの思想を学ぶ。多くの場合、後発だからといってベストとも限らず、特定のパラダイムが答えというわけではない。メリット、デメリットを見極めて訓練をすることは、より良い設計をするための指針を与えてくれる。
これは感覚的な話だが、大抵の場合の正しいとされている概念や原則は似通っている気がしている。それに至るまでのアプローチの違いでしかないことが大半だ。
そしてコンピュータサイエンスの知識も、初心者を脱すると必然的に求められるのではないだろうか。親子関係を持つデータの取り扱い方、上位n件を取得したい、など。一般的なアプリケーションでもよく求められる要件ではあるが、データ構造やアルゴリズムを知らなければ、効率化のアイデアすら浮かばないことがある。完全に理解しておくほうがベターではあるが、脳内にインデックスを作っておいて、問題に直面したときに引き出せる状態があれば十分であろう。
ここではデータ構造とアルゴリズムのような話しかしていないが、当然ながら携わる領域によってはコンピュータサイエンスの求められる範囲も深度も異なるので一概には言えないが、手札を増やすという意味では絶対に学ぶべきである。
手札をどう活用するか
手札から選択した設計が蓋を開けたらどうだったか、という話。もちろん答え合わせはできない。しかし後悔はできる。もがきながら経験値を高めていく他ないのではないだろうか。
とにかく何かを作って世の中に出す。リリースした何かを育てる。それをひたすら繰り返す。
一方で素振りを否定するつもりはない。インプットのためのアウトプットというのも大切だろう。自分もよくやる。しかし、素振りだけでは泥臭い部分が見えない可能性が高い。例えばだが、アプリケーションのセキュリティ面や可用性のような部分は、使われなければ意識しなくなってしまう。
そして、アウトプットにおいてはトレードオフの問題が必ずつきまとう。手札があればあるほど傾向が強くなる。
おわりに
そろそろ疲れて本題から逸れ始めたのでこの辺にしておく。よく見るとタイトルと内容があってなさすぎる。
偉そうなことを書いたが、非コンピュータサイエンス上がりのエンジニア3年目の雑魚なので、信憑性はないかもしれない。自分がソフトウェア設計するときに考えている土台は、いつ得られたのだろうとふと考えたらこの文章になった。今後も間違う機会の方が多いと思うが、当時の知識でどんな手札があったのか、なぜその選択をしたか 程度は記憶しておきたいものである。