kintoneチームの前田です。 2023年6月4日に開催されたJJUG CCC 2023 Springに、サイボウズはスポンサーとして協賛しました。 さらに、スポンサーセッションとして「複雑性に立ち向かうためのサーバーサイドコード分割」というタイトルで登壇させていただきました。
JJUG CCCについて
JJUGは日本におけるJavaユーザーグループであり、JJUG CCCは日本最大のJavaコミュニティイベントで、春と夏に2回開催されています。 今回は東京でのオフラインとオンラインでのハイブリッド開催となりました。私は東京に行くことができなかったのでオンラインで参加させていただきました。
登壇内容
登壇の資料はSpeaker Deckにアップロードしております。 speakerdeck.com
内容は、同名で執筆したブログ記事のプレゼン版になります。 blog.cybozu.io
しかし、プレゼン版とはいえブログ記事のものとまったく同じというわけではなく、登壇に当たって内容を見直しています。 とくに、分割前後での可読性の違いや分割を通して気づいた複雑性や関する考察は、ブログ記事のものよりも詳しく説明されているかなと思います。 ブログ記事をご覧いただいた方も、登壇は登壇でまたご覧いただければと思います。
登壇の映像はYouToubeにアップロードいただいています。 www.youtube.com
登壇の映像には質疑応答も含まれていますが、その中で誤った返答をしてしまったので、この場で訂正させてください。 質疑応答でプロダクションのコード行数を10万行、テストを合わせて35万行と発言しておりましたが、これは誤りです。 正確には、スライドにもある通り、プロダクションコードだけで35万行です。 緊張していたのか、間違った数値を提示してしまっていました。。申し訳ありません。
登壇後に気づいたことがあったので、せっかくなのでこの場に書いておこうと思います。 資料の冒頭で、既存の実装を基にしたコード分割をしても、複雑性は解消されないのではないか、とありました。 ここでは抽象的な意見があるだけでしたが、後半では、同じApiTokenを返すlistとgetTokenというメソッドが出てきます。 登壇後に気づいたのは、これがまさしく、既存の実装を基にしてコードを分割しても複雑性は下がらない、ということの一例になりそうだなということでした。
というのも、既存の実装を基に分割をする場合、 同じApiTokenを返すという理由でこのlistとgetTokenとを一つのサービスにまとめよう、という分割になってしまうと思われるためです。 この分割はPMのメンタルモデルに沿ったものになっていませんし、 そもそもの用途が使うデータクラスを利用していたり、アクセス権などの前処理が違う二つのメソッドを一つのサービスに同居させています。 以上の理由から複雑性は下がらなさそうです。 このことで、既存の実装を基にしたコードの分割をしても複雑性の解消は期待できない、ということの説得力がちょっとは増しそうかなと思っています。
参加してみて
そもそも私自身JJUG CCCに参加するのは今回が初めてで、どのような感じなんだろうかとワクワクしながら参加しました。 セッション内容は、非同期処理などの大掛かりな話や、Webサービスをその場で作成するライブコーディングなど、 いろいろなものがあって、大変楽しく、また勉強させていただきました。 普段の開発ではなかなか触れないような内容が多々あり、とても刺激になりました。
kintone開発チームでもサーバーサイドにJavaを使った開発をしているので、 今後もまた新たな発見などがあれば、ブログ記事や登壇等でアウトプットしていきたいなと思いました。 そうすることで、同様にJavaで開発していらっしゃる方々とつながり、コミュニティを盛り上げる一助になれればと思います。
最後に、このような登壇の機会を与えてくださった運営やスタッフの皆さん、本当にありがとうございました。
