Zenn
📘

マルチパラダイム実践のすゝめ

2020/10/03に公開
アーキテクチャ
プログラミング言語
パラダイム
idea

異なるパラダイムからきているプログラミング言語/フレームワーク/アーキテクチャを学ぶ/実践することで、エンジニアとしての引き出しが増えますよっていう記事です。

背景

私自身、1年ほど前までは仕事でRuby/Railsを使ってwebアプリケーションを開発し、AWS(EC2)上で運用していました。
現職に転職したことで色々なパラダイムの言語やアーキテクチャに触れて非常に沢山の学びを得たので、そのことをシェアしたいと思い、この記事を書きました。

前提

マルチパラダイム と書いているのですが、ザックリと以下のことを意味しています。

  • 異なる思想から来ているプログラミング言語
    • 例：OOP&動的言語としてRuby、関数型&静的言語としてScala
  • 異なる思想から来ているwebフレームワーク/アーキテクチャ
    • 例：MVC、Domain Driven Design、Clean Architecture、serverless

自分が経験したこと

私は元々Ruby/Rails/AWS(EC2, Aurora MySQL, Redis, Mecached, Elasticsearch)を中心に仕事をしていました。その前もRuby/Railsがメインだったので他言語やアーキテクチャに触れた経験は殆どありませんでした。

転職して8ヶ月ほどの間に以下の技術スタックを仕事で扱うようになりました。

  • プログラミング言語
    • Scala/TypeScript/Golang/node.js/Python
    • オブジェクト指向/関数型/構造型
  • アーキテクチャ
    • Domain Driven Design
    • serverless
  • クラウドインフラ
    • ECS/EC2/Lambda/AppSync/Amplify/DynamoDB/Global Accelerator/etc.

とまぁ、今まで全く知らなかったパラダイムの技術スタックにどっぷり浸かってきました。今まで短期間でここまでたくさんの技術スタックを使ったことは無かったので、非常に刺激的でした。

その甲斐あって「そのケースなら●●が効率的」という技術選定の引き出しが増えました。今までは一つの技術スタックでなんとか頑張っていたのですが、ある程度、適材適所使い分けられるようになりました。
特に私はスタートアップで働いていることもあり、新サービス/新機能の技術検証からやることがあるのでこの引き出しは非常に役立っています。

マルチパラダイムに触れることのメリット

簡潔に言うと 問題解決の引き出しが増える ことがメリットだと思っています。目的を達成する（機能開発/改修/リプレース/etc.）ためには様々な制約や問題が存在すると思います。問題解決のための引き出しをたくさん持っていることで、それらの前提条件を満たすためのより良い提案ができるようになると思います。

現代のPCスペックをフルに使えば、ぶっちゃけどんな言語でどんなアーキテクチャのアプリケーションでも一般的なwebアプリケーション程度なら作れてしまうと思います。ただし その方法が問題解決するにあたって効率的であるか？という点ではNOだと思います。限られたリソース（時間/人員/技術スキル/資金/etc.）の下で目的を達成するためには、その問題を解決してくれるものをある程度知っている必要がると思います。

またこれは 知っているかどうか の差で決まってしまうことも多々あります。例えばキャッシュを知らない人にとっては、リクエスト時に毎回DBへ問い合わせが必要になりますが、知っている人にとっては「ここは表示するデータがほとんど変わらないのでキャッシュを挟むと効率的になる」という具合です。

引き出しが多くて損することはないので、どんどん新しいパダライムに触れるのが良いと思います。

マルチパラダイムに効率的に触れるためのTIPS

1. 具体的な使い方よりもそのパラダイムが生まれた経緯を知る

既存の何らかの問題を解決するために新しいパラダイムは発生しますので、そこを理解することが何よりも重要だと思います。そのプログラミング言語/アーキテクチャがどんな問題にフォーカスしているものかを理解できれば、自分たちが直面している問題にマッチするかどうかの判断がよりつきやすくなるかと思います。

例えば関数型パラダイムでは副作用を閉じ込めることが関心事の中心になるかと思います。そこで、副作用とはなにか、副作用を閉じ込めるとどんな良いことが有るのか、関数型にマッチしたプログラミング言語はどんなものがあるのか、などを調べていくと良いと思います。

2. 手を動かす

1.で経緯を理解したら、あとは手を動かして小さなサンプルを作ってみましょう。本/記事を読んだだけでは実際の勘所は身につかないので、簡単なサンプルアプリケーションを作ると良いと思います。
またもし可能であれば、業務の中で小さく始めて見ましょう。私は新しい言語を使う際には、小さなLambdaロジックを新しい言語で書き換えるところから始めました。小さく始めて成功体験を積めれば自信にも繋がります。

ここで重要なのが 実装が完璧である必要はない という点です。というより最初から完璧なものなんてできないので、まずは始める事が重要だと思います。

3. アウトプットを意識する

1./2.を通して自分の中にそのパラダイムへのメンタルモデルが形成されていくと思います。その過程を技術ブログにまとめましょう。それはこれからそのパラダイムを学んでいく人の助けになるでしょうし、何よりもあなた自身のためになります。
技術的なアウトプットは自身の技術力の証明にもなるのでどんどんやりましょう。

自分の場合は、DDDを別パラダイムの言語で実装するとどんな感じになるのか知りたかったのでgithubにGolangとScalaでサンプルアプリケーションを実装し、Zennに比較をまとめました。
ScalaとGolangでDDDを実装比較してみた

4. 気負わず興味のままに

完璧を目指したり、xxできるようにならないといけないと気負う必要はありません。その気負いが「まずは始めてみる」という姿勢を挫いてしまします。
その分野で世界有数の人になるには確かに生半可な覚悟では達成できませんが、「業務を進めていく上で困らない程度に習得する」というレベルであれば慣れればだいたいいけます。なので、まずは「興味あるから」程度のノリで踏み出してみることが良いと思います。

まとめ

新しい分野に足を踏み入れるのはいささか不安もあると思います。ですが、中長期的に見て得られるものは多いと思うので、是非とも気軽に挑戦してみてください。

Discussion