読者です 読者をやめる 読者になる 読者になる

CureApp開発者ブログ

アプリで治療する未来を創造するCureApp, Inc. のエンジニアブログです

技術ブログ開設のご挨拶 | All JSな環境構築のために一番大事なこと

ご挨拶

はじめまして。株式会社CureAppのCTO、鈴木晋です。

弊社は、医師によるスタートアップで、疾患を治療するアプリを開発しています。 薬のように病気を治すアプリが、医師から処方される。そんな動きがアメリカでは実現されはじめています。 日本の医療にもCureAppはそのトップランナーでありたいと思っています。

CureAppの理念

JavaScriptについて

そんなCureAppのシステム開発は、すべてJavaScriptです。 そして、すべてJSである利点を最大限に活かした開発が行われています。 私が思うJSの特徴、そしてJSの最大の武器は

多くのプラットフォームで動作する

という点です。

JSは"英語"になった

ここ5年の間に、JSは実に様々なプラットフォームで利用できるようになりました。 Webブラウザはもちろんのこと、Node.jsRhinoSpiderMonkeyといったいわゆるサーバーサイドのJS、 またTitaniumReact Nativeのようにスマートフォン開発もすることができます。 electronなどの技術を使ってMac OS Xのアプリをつくることもできます。 Google Driveのマクロを書くためのGoogle App ScriptJavaScriptの拡張です。 細かいところではMac OS XWindowsのバッチスクリプトとしても利用できます。 Webブラウザの扱えるAPIも、HTML5の登場により格段に増えました。

このように、プラットフォームを問わずJavaScriptは利用できるようになってきており、 自然言語における英語のようになってきている、と思っています。

ビジネスロジックとプラットフォームAPIを分けよう

この取り柄を活かすために、最も大事なことは ビジネスロジックとプラットフォームAPIを分けることだと思っています。

ビジネスロジックとプラットフォームAPIは分離可能

確かに、プラットフォームのAPIを叩かないと、ほぼ何も始まらないといっていいでしょう。

プログラミングのほとんどでは、何らかのデータを扱うわけですが、 データはファイルから読み込むか、ネットワークを通じて取得するか、ブラウザのDOMやOSの資源そのものを データとして利用するか、といったものがほとんどです。

ではプラットフォームのAPIを叩かないコードは、何もできないのでしょうか? というと、そうではありません。

プラットフォームのAPIから得られるデータを受け取って、計算処理をする部分だけを分離すればよいのです。 例えば多くのテンプレートエンジンは、テンプレート文字列と、流し込むべきオブジェクトを受け取り、 生成された文字列を出力するわけですが、その処理自体はプラットフォームに依存しません。 扱う対象が複雑なデータ構造の場合も、データ定義自体を共有することで対応可能なことは、React.jsの隆盛の示すとおりです。 プラットフォーム依存のDOMを、プラットフォーム依存のないデータ構造であるVirtualDOMという概念で扱います。 ビジネスロジックとプラットフォームAPIを分離し成功した好例といってよいでしょう。

分離してよくなること

分離可能なことは分かりました。ではなぜ分離すべきなのか。それは以下の2点です。

多数のプラットフォームで再利用可能になる

プラットフォームを問わず利用でき、コードを共有できます。 実際、弊社のビジネスロジックはあらゆるプラットフォームで動くように工夫され、 異なるプラットフォームで似たようなモデル定義などをする必要はありません。

テストがしやすくなる

テストのしにくいJS実行環境は存在します。 ビジネスロジックのテストは、Node.jsで行うようにします。素早くアクセスできるだけでなく、 多くのCIに標準サポートされている環境です。

CureAppは技術をオープンにする会社です

CureAppの基礎となる汎用的な技術はCureAppのgithubに多数公開しています。 いずれも複数のプラットフォームで動くことを考慮して書かれています。

CureAppは一緒に働きたいエンジニアを募集しています。

今後ともよろしくお願いします。