Goで作ったシステムをRubyでリプレイスすることを検討してみた

はじめに 弊社にはGoで作ったシステムが存在しますが、作られてから数年が経過して、メンテナンスも十分にできていない状況でした。 そこで、このシステムをリファクタリングして生産性を上げようという結論になりました。 リファクタリングにあたり、Goのままで行くのか、弊社でよく使われているRubyで行くのかを検討してみましたので、その過程を紹介したいと思います。 Rubyでリプレイスしようと思った理由 Goで動いてて言語やライブラリのバージョンアップなどメンテナンスがされてない部分はありますが、 そこを解消すればGoのままで行った方が良いのでは？と思うかもしれません。 しかし、あえてRubyでリプレイスしようと思うに至ったのは以下の点があります。 Rubyの方が開発速度があがりそう Goのリファクタリングをするのに時間がかかりそう Goのリファクタリングと機能追加でコード修正箇所が被るとスケジュー

[u06nh]

“弊社にはGoで作ったシステムが存在しますが、作られてから数年が経過して、メンテナンスも十分にできている状況でした。そこで、このシステムをリファクタリングして生産性を上げようという結論になりました”ん？

[razokulover]

別に社内的に全員がそれでワークすると思ってやってんなら別に何でも良い気がする

[sue445]

どの技術スタック選ぶにしても社内に知見があるかどうかって重要よね

[zentarou]

式年遷宮はそれ自体に価値がある

[YassLab]

"実装に掛かった時間は1日程度 / Goのコード量は1,000行を超える / Rubyでは300行ほど / やはりAPIとDBの処理時間が全体の大半を占めている / 処理時間に大きな差が発生してない / CPUリソースは多く使いそうなのでその点は考慮”

[hasiduki]

「RubyクソGoのがいいだろ！！！」と言えるのは実務でRubyを使ってみた人だけです！！！！！！！！なので遊べる箇所を探してたまには素振りしてみるべきなのだ！！！！！

[sonots]

リプレイスのコストを払うほどなのかは分からないが、社内技術スタックをRubyにしていこうということなら理解できる

[circled]

割と最終的なボトルネックってDBになりがちだから(全データの出し入れの根幹だし)、アプリ側で余程データをこねくり回したりしない限りは何使っても大差無いよね

[xanaduuu]

リファクタリングを検討し、将来に備える良い会社だね

[koyancya]

Rails重そうだけど、ついRailsを使ってしまうのも分かる

[chasers]

中身を逆にしても通じそう。結局サービスを早く安定的にリリースできてエンジニアのDXを維持できるならそれでいい。

[slack_pulse]

計測してRubyとGoのメリット・デメリットを検討しているし、 “社内にGoのコードレビューできる人が少ない”　はわかる。Goは将来のエンジニアの採用しやすさというのもあるからそのへんの検討も必要かもしれない

[peketamin]

よさそう

[door-s-dev]

なんか？が浮かぶ内容ね

[chiroruxx]

比較するなら言語モデルの違いも比較したほうがいいんでは。