私も初めはそうだった.
だから、未来の私のような人へのメモ. または会社の後輩に説明するのが疲れる人も使ってもらえたらうれしい.
動けばいいと学生のときは思っていたし、早く書いて素晴らしいアルゴリズムを動かすことがソフトウェアエンジニアとして一番大事なことだと思っていた。
その時にソフトの設計なんかにみじんも興味がわかなかった。
そのときの感覚としては、”XX原則”といった類は全て幻覚にも等しいものだと思っていた. 単にそういった新しい概念を出しているように見せるだけで、誰かが名声を得体がために作った造語なだけの何かと考えていた.
原則の中身はふわふわしているし、考えたらわかりそうなことという印象も強い. 新しいアルゴリズムを学んだときの様な高揚感もない.
通常、初学者が学ぶときに一人で実装を行い、様々なものを作り出しているだろう.何か変更しようと思ったって全部自分の頭の中で考えられるし、どんなところに気をつければいいかもなんとなく当てはつく. もし不具合が出ても致命的なものは出ないだろうし、数時間触れば全部の不具合を潰せる自身もある. そんななかで、クラスの依存がとか、凝集度が、とか言われていてもまずピントこない. ソフトが大きくなったらどうなるかなんて、何とかなりそうな気がしてならない.
でも、ならないんだ.
実際どんなに優秀なエンジニアがいたとしても、最後はどうにもならなくなる.
何年も何十人もの人月をかけて開発してきた数十万行のソースコードは、どこか一箇所でも変更を入れるのが怖くなる. もし金融系や医療系、FA系、自動車系で不具合なんてでてきたら、とんでもない.
新しいメンバーが入ってくることもあるだろう. すでにある数十万行のコードを前にして、なんの危険もなくコードを修正できるだろうか. たった一行でもシステムが止まる様な変更をしてしまえば、会社の経営すら危うくなる.
怖すぎて完全に任せることはできない. レビューも必要になるが、レビューで本当に不安を払拭できるかといえば、そんなことは微塵もない.
なのにもかかわらず、仕様変更はどんどんやってくる.
想定していない変更が山ほど現れる.
時間が立つにつれ、テスト項目として確認することが増えていって、一箇所変更を入れると不具合が10個ぐらいでる. その不具合を修正するとそれに伴って5,6個出る. それをさらに修正して…
かなり根本的な修正を入れることになったとしたら、数ヶ月単位の変更で終わるとは思えない. もっと年月がかかってしまう.
この感覚を持つには、実体験を持つのが一番早い.
想像できる人は幸せな方で、私は体験するまでそれを真に理解できた感じがしなかった.
経験しないにこしたことがないが…
じゃ、少しでもコードを安心して変更するにはどうすればいいか.
これから入れる変更を最小限の影響しかないように設計しておく.
根本を買えるような仕様変更でない限り、ほとんど一部のみにしか影響しないし、その先は大丈夫ってなっていれば、本当にやりやすくなる.
安心して眠れる.
上記の影響が小さくなる様にするために、
世の中には「様々な原則」「様々なパターン」「様々な設計」がある.
だから、どうか原則や設計を意識して、プログラミングをして欲しい.
プログラミングの一番大事なのは、文法や便利なCSSを覚えることでも最新のフレームワークを使いこなすことなどでは全くなく、設計であることをいつか痛感できるはずだから.
