こんにちわ。てぃろです。
今回はコラムです。
simple is best
”simple is best”は、私の座右の銘といってもいいものです。
シンプル/単純というのは非常にわかりやすくてよいものだと思います。デザインにおいてはシンプルな見た目は洗練された印象を与え、見ていて落ち着きます。機能としてシンプルなものはその使い方がわかりやすく構造的にも壊れにくいものが多いのではないかと思います。
対して、複雑なものはわかりにくいものです。一歩間違えれば複雑な見た目やデザインというものはゴチャゴチャとした印象を与えます。機能や構造が複雑なものは、構造上壊れやすく直しにくいということがよくあります。
全部が全部そうではないと思いますし、複雑で美しく頑健で使いやすいものも中にはあるでしょう。ですが、作り手になって考えてみたらどうかという話です。複雑なものは設計そのものでミスも入りやすく、また作りづらいため時間もかかります。
これはソフトウェアにとっても同じ事です。
昔からソフトウェアのデザインパターンはいくつも作られてきました。最近ではクリーンアーキテクチャがよく叫ばれるなど、シンプルかつメンテナンス性の高いコードの作り方というのがいつも研究されてきていましたし、エンジニアならだれもがそれらを学んで開発に取り入れたいと考えていると思います。
現場はシンプルとほど遠い？
開発現場でそんな理想的な設計がいつもできているかというとそんなことはないというのが現実ではないでしょうか。私自身そこまで多くの開発現場を直接見てきたわけではないですが、様々な人の話を聞くにつけ、そんな理想的な開発現場は存在しないということがなんとなく思います。
なぜそんなふうに理想は実現できないのか？という真の原因はわかりません。
私の直感では、シンプルな設計というものの共通認識がとれていないことが原因のように思っています。
もう少し具体的に言うと、ソフトウェアアーキテクチャの考え方が抽象的なものであるがゆえに、具体的な設計における共通認識がとれないのではないか？ということです。クリーンアーキテクチャについて実装を試みた現場をいくつか見て思いましたが、その実装難易度が高いと言われる所以は、解釈の幅が広すぎるからなのではないかと思います。誰もがシンプルにしたいと願うけれども、その抽象的な議論の中でシンプルで具体的な設計やコーディング規約を導き出せていないのではないかと思います。
そもそも抽象を具体に落とすという知的活動はなかなかに高度で工数のかかる活動ですので、クリーンアーキテクチャをはじめとした抽象的な設計概念をもとにして具体的な設計に落とし込んでいくことがほとんどの現場では現実的ではないのではないか？とすら感じます。
ここまでクリーンアーキテクチャを引き合いに出しましたが、それを悪いとは言いません。昔からシンプルな設計が考えられてきていることを思えば、そもそもシンプルな設計とは何か？という共通認識を取ることがソフトウェアアーキテクチャにおいては難しいのではないかと思うのです。クリーンアーキテクチャもそういったシンプルでわかりやすくメンテナンスしやすいコードを目指した考え方であると思う一方、現場に目を向けると、エンジニア同士の解釈の違いが大きくより複雑性を助長する面があるのではないか？ということを少し疑っていたりします。
とにかくシンプルにしたい、できないならコメントを残したい
私は複雑なものを理解するのがすごく苦手です。
複雑な設計も複雑なコードも理解するのにものすごく時間がかかりますし、障害調査などもすごく苦手だと思っています。何よりすごく疲れる。
なので、クリーンアーキテクチャなどの抽象的な設計概念にとらわれずに原点に立ち戻ってもっとシンプルにできないかな？と常々思うのです。
シンプルとは素直と言い換えてもいいと思います。工夫を極力しない。こう考えるとこうだよね？と言う、論理的に正しい書き方を追求するだけでいい。ベンダーが提供しているAPIなら、その作り手が想定している通りの使い方をする。そこに工夫は極力入れない。そうすればコードを読むだけで意図が伝わります。
そんな私でもリポジトリパターンくらいは使います。それはDB操作のコードは複雑なのである程度抽象化したほうが全体から見てシンプルになりやすいと考えるからです。
ですが、それ以外に責務としてレイヤーを分けていく意味をあまり感じません。変更容易性を追求し過ぎれば変更に時間がかかる冗長性の高いコードになりかねません。特に今はマイクロサービス化やFaaSを使ったインフラレベルでの責務の分離が可能なので、コード上での変更容易性はそこまで重要視されない場合があると思っています。
もちろんそうはいかない場合もあると思います。マイクロサービス化できなかったり、オンプレミスの現場はそうでしょう。それならばちゃんとコメントとドキュメントを残すことこそが、工夫だと思います。ロジックやレイヤーの分け方だけを頑張るのではなく、なぜその工夫に至ったか背景やその工夫がどんなものかもしっかりと書き残すことを頑張るべきです。
これは、開発現場は人が入れ替わるものだからです。
労働市場におけるエンジニアの流動性はどんどん高まり、属人化が開発現場の中長期的な目線で見た生産性を落とすことは誰の目で見ても明白です。
だからこそ、誰にでもわかるシンプルなコードを書いたり、工夫したならそれをきちんとコメントで書き残して誰でもわかるようにしておくというのが、エンジニアとして身に着けるべき所作なのではないかと考えています。
結局いいたことは…
何よりも読んでて疲れないコードっていいよねって、そんな話をしたかっただけなんですけどね。
