CureApp開発者ブログ

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

無料でピザを食べられる濃密な座談会を開催しました。

なりゆき

ご好評いただいたMedTechConf01。 医療ITベンチャー3社、それぞれの特色を活かした発表ができました。

この様子はCodeIQ magazineにも取り上げていただきました。

codeiq.jp

上記のイベント、とても反響ありまして、その後何人の方とお会いすることができました。 「イベントいけるやん!」と味をしめたCureApp人事部隊は、

「弊社の技術セットにくわしく興味のある方に、より濃密に話をしたい」と思うに至りました。

MedTechConf02

そこで2/24(水)、限定10人で青山スタートアップアクセラレーションセンターにて開催しました。 トーマツさん場所の提供ありがとうございます。

雰囲気: 座談会ですねこれ

f:id:cureapp-dev:20160226114935j:plain

無断キャンセルの波に揉まれて、参加者は少なかったのですが、

  • 「JSというゆるい言語で大規模開発やるとはどうなってるんだ?」
  • 「JS好きだけどDDDをJSでやるなんて!」

という疑問がおありなコアな方々がいらっしゃいまして、 エンジニア座談会のような感じで進んでいきました。 途中でピザも登場して、皆さん大満足でお帰りいただきました!

内容

マルチプラットフォームJSについて

  • ビジネスロジックってプラットフォーム固有のAPI使わないけど、データ層へのアクセスだけちょっと問題。
  • データ層へのアクセスをHTTPレイヤにするのはいいよ。
  • superagentはまだ有能
  • fetchはこれからの技術
  • parse.comが終わるなか、JS製のOSSLoopBackは期待大。

DDD(ドメイン駆動設計)について

  • DDDのfactoryって、JSONから復元するところってただの単調作業で辛い。
  • DDDのrepositoryのCRUDも、割と処理が定型化している。
  • base-domainはそういったDDDの定型処理をしてくれるフレームワークで、ビジネスロジックの記述のみに集中できた。
  • Railsライクなフレームワークの「モデル」だと、DDDのサービスのような 複雑な振る舞いを記述する場所がなくて、コントローラが肥大していたよね。
  • メソッドの行数は少なく!ただドメインエキスパートが考える概念と粒度を揃えることも大事。
  • ドメインに各アプリケーションが依存する設計だと、ドメインのバージョン更新とか、異なるバージョン間の併存に対応するのが辛くなってくるのでは? -> 正直辛い。open/close原則などで運用するべきだが...。

その他

  • 保守性は、型で縛るか、テストや自動ドキュメントで縛るか、は好みもあるが、CureAppはテストと自動ドキュメントで、今のところ規模大きくても大丈夫。
  • 結局DDDっていうよりテスト書くことが大事なのかも。自動ドキュメントも。
  • IE対応どうなのよ: 弊社はSauceLabsを利用して自動e2eテスト。
  • callback地獄は追いにくいから保守性にも悪。Promise使おう。
  • CoffeeScriptが負債になる時は来る、が、そのときは変換後のコードから伸ばしていけばよい。
  • 綺麗に書くのがいいのかザクザク進んでいくのがいいのか、は経営の考え方にもよるけど某ECの会社が1年間60億をリファクタリングのみに費やしてしまった事実は、石橋を叩いて渡るプラクティスの重要性を示しているのではないか。

というかんじでした!

感想

こんな濃密な時間が過ごせるとは自分も思っていなくて、 予想外に自分が楽しいイベントでした。 今後もゆるく勉強/意見交換していく場として開催していきたいです!