＼回答があります！／

• 

  Offers(オファーズ) 公式

  エンジニア

  1年前
  ※本投稿は、2023年6月29日に開催されたイベント「KotlinとScala 活用者が語る技術選定のヒント（https://offers.connpass.com/event/287192/）」における、フリーランスエンジニア 竹端 尚人氏の回答内容を元にしています。
  
  初めてKotlinを導入したときのプロジェクトは印象に残っています。
  もともと会社の中で持っていたJavaの基盤のような形で、認証など共通のある程度色々な機能が盛り込まれた、新しいプロジェクトを作る時のペースのプロジェクトがありました。
  その基盤をKotlinに全部置き換えて、それを持って新しいプロジェクトに入ってプロダクトを作っていきました。
  
  基盤のコードとかは、一回IntelliJ IDEAの機能で何万行かのコードを全部Kotlinに変換しました。
  もちろん何万行もあると全然動かないですが、それを一個一個コンパイルエラーを潰しながら、新しくKotlinっぽく書き換えていきました。
  その上で新しいプロダクトを作っているので、Kotlinで一通り大きいものをちゃんと作ることが体感できました。
  
  あと、後悔という意味で「今だったら、もうちょっとこうつくれたな」みたいなのは山ほどあるプロジェクトでもあったので、Kotlinの良さを活かしきれなかった記憶が印象に残っているプロジェクトでもあります。
  view数 27

• 

  Offers(オファーズ) 公式

  エンジニア

  1年前
  ※本投稿は、2023年6月29日に開催されたイベント「KotlinとScala 活用者が語る技術選定のヒント（https://offers.connpass.com/event/287192/）」における、Chatwork株式会社 テックリード 加藤 潤一氏の回答内容を元にしています。
  
  現職で2016年末に、Chatworkのビジネスチャットのサービスで、PHPの技術的負債を返済するみたいなプロジェクトで立ち上げていろいろ紆余曲折あったのですが、メッセージング、メッセージのデータを扱うところをScalaで置き換えました。
  
  その当時でメッセージの総数が10億件ぐらいあって、それをAkkaと、データベースはKafkaとhベースを使った分散システムに移行しました。
  
  それを使っていろいろ経験ができたのですが、例えば本当に障害に強いシステムがつくれるというのがAkkaの特徴で、何か障害が起きてもほっとくと自動的に回復するというような、そういう仕組みをAkkaのフレームワークを使って実現できたりとか、データベースのネットワーク障害が起きても、そのネットワーク障害が回復すると残りのタスクを自動的に再開する仕組みがAkkaには備わっていて、そういう耐障害性が高いシステムをわりと簡単につくることができて、それなりにもちろん分散システムの知識が必要になるのですが、そういったことに使って夜中叩き起こされないサービス運用が当たり前になりました。
  
  それからChatworkでは基本的にAkkaを使う考え方で、とにかく障害が起きてもシステム自体が復元力を持ってリカバリーしていって、基本障害が起きても全体障害に拡大しないようなシステム設計というのをやるというのでやっています。
  
  それがScalaとかAkkaの文化圏ではわりとメジャーな考え方だったりするので、そういうのを関数型とかそういう障害に強い考え方、設計の考え方みたいなCQRSとかイベントソーシングというのを上手く使ってやってきたという、これがわりと大きな経験になっているかなと思います。
  view数 20

• 

  杉田大樹

  プロジェクトマネジメント

  1年前
  ECサイト、サブスク、物流、在庫管理、受発注、決済、ETL、ありとあらゆるものを内製開発せずにSaaSを組み合わせて開発を行ったことがあります。結果うまくいきました。
  当時は海外でのEC展開も視野にしており、特に中国での販売が可能なECや周辺システムの選定は大変でした。
  ECだけでも60以上の候補の中から絞り込みを行いました。
  view数 15
  • 1