DBを軸にして周辺技術を活かす soudai1025(PHPの現場14)

こんにちは。「PHPの現場」というポッドキャストについての話題です。最新回の「PHPの現場 14. データベースにかける(soudai1025)」を聞きました。

php-genba.shin1x1.com

私の中では、そーだい(@soudai1025)氏と言えば、Software Design(雑誌)のRDBアンチパターンです。毎月読んでおります。

がっつりRDBの話になるのかと思いきや、思いのほかアプリケーションやコードレイヤーの話も多く、多様性のある話で面白かったです。感想を綴っていきます。

お互いのコミュニティには、それぞれ良いところがある

最初の話は、LaravelコミュニティとSymfonyコミュニティの話です。

frasco.io

私も軽く読んでみたのですが、そもそもLaravelとSymfonyは全く別のフレームワークであり、設計思想も違います。相容れようがありません。

コミュニティというのは、相手の良いところを参考にしながら、お互いに進化していくものです。もちろん、様々なコミュニティを知ること自体は、とても良いことです。

いつも同じメンバーで固まるだけでなく、アウェイのコミュニティに参加したほうが新たな発見が得られるという話が、ポッドキャストの中盤エピソードであります。

また、ポッドキャストの後半では、ランチタイムを活用して営業や総務などの違う職種の方と話すことによって、視野が広がって新たな発見が得られるという話があります。

私は、どちらかと言うとアプリケーションレイヤーのエンジニアです。例えば、私がDBエンジニアやインフラエンジニアと会話をした場合、私がアプリケーションレイヤーの知識を提供する代わりに、DBやインフラの知識を貰うことが出来ますよね。

スキルの多様性は、こうやって磨かれていくものなんです。そーだい氏の場合は、それがDBでした。DBを軸とし、さらに周辺技術を吸収した結果、エンジニアとして成長を成し遂げたわけです。

f:id:konosumi:20171217162130j:plain

DBで解決するのか、コードで解決するのか

データには、NULLを許容してはならないとか、文字数は何文字までとすると言った、様々な仕様があります。問題は、その仕様をどのレイヤーで担保するのかという話です。

NULLを許容しないためには、データベースにNOT NULL制約を付与する方法もあれば、コードの入力チェックで弾いてしまうという方法もあります。

データベースに制約を付けた方が、データはより確実になります。しかし、一方でデータベースは身動きが取りづらいという欠点もあります。データベースに一度付けた制約は、変えるのにとても労力が必要なのです(特に、データ量が増えるほど顕著になります)。

つまり、データの品質をアプリケーション側で担保するほうが、身動きがとりやすくなります。しかし、一方でアプリケーションはバグに弱いという欠点があります。

この見極めが非常に重要で、エピソード内では「NOT NULL制約は貼った方が良い」「DB特有の機能を使いたくなったら、不吉な匂いと思え」と言った話があります。

なかなかに濃くて面白い話ですよ。

強みを武器にして、周辺技術を広げる

そーだい氏と言えば、RDB(PostgreSQL)で有名です。そーだい氏の描く技術力の幅の広げ方は、かなり参考になると思います。具体的には、RDBを軸にしてNoSQLや分散データベースにも知識の幅を広げていくという話です。

私は、技術力の広げ方には縦と横があると思っております。縦の広げ方は、例えばアプリケーションエンジニアが、DB・サーバ・インフラなどの技術力を身につけることによって、フルスタック寄りを目指す方法です。

横の広げ方は、iOSエンジニアだけどAndroidやReactNativeもやりますと言った、同じレイヤーでのスペシャリストを目指す方向性です。

もちろん、縦にも横にも広げることが出来たらベストですが、まったく関係のない技術を吸収するよりも、周辺技術から吸収していったほうが、効率性が良いことは間違いありません。

エンジニアは年齢も性別も関係のない、実力主義の世界です。エンジニアとして、自分の技術力の幅をどう広げていくのか?これはとても重要な課題なのです。

さいごに

がっつりDBの話になるのかと思いきや、様々なトークテーマの回でした。

  • コミュニティと勉強会
  • DB設計とORM
  • アプリケーションとDBの関係性
  • エンジニアの生存戦略

など。かなり面白い回でしたので、おすすめです。