はじめに
記事を見てくださりありがとうございます!
@HayatoHanaoka と申します。
今日仕事で起こった出来事を備忘録がてら残します。
また、今回の内容には以下の記事の内容が多少関係してきますので、お時間がある方は目を通していただけると幸いです。
この記事より実装が進んでいるのですが、見ておくことで多少の前提を把握できると思います。
起こった出来事
社内のつよつよエンジニアとプログラミングの振り返りをした際に、
以前実装したClinet
にフィードバックをいただきました。
このClient
は Driver
の内部で呼び出し、外部からリソースを取得するために使っています。
import Config
import io.ktor.http.*
import kotlinx.serialization.Serializable
interface Client {
suspend fun getResource(
keywords: String?,
order: String?,
tags: String?,
page: Int?,
type: String?,
limit: Int?,
sort: String?
): EntrepediaCompanies
}
class ClientImpl(private val client: HttpClient): Driver {
override suspend fun getResource(
keywords: String?,
order: String?,
tags: String?,
page: Int?,
type: String?,
limit: Int?,
sort: String?
): Resource {
val url = URLBuilder("http://localhost").apply {
parameters.apply {
keywords?.let { append("keywords", it) }
order?.let { append("order", it) }
tags?.let { append("tags", it) }
page?.let { append("page", it.toString()) }
type?.let { append("type", it) }
limit?.let {
append("limit", it.toString())
}
sort?.let {
append("sort", it)
}
}
}.buildString()
return client.get<Resource>(url)
}
}
この実装に対して、皆さんならどのようなフィードバックを行いますか?
もしあったらコメントしてくださると嬉しいです!
社内のつよつよエンジニアさんからは、
👨🦱 「HttpClientのライブラリをラップするとかえって使いにくくなりますよ。」
と言われました。
また、
- HttpClintのライブラリが十分に抽象化されているので、そのまま活かした方が良い
- 下手にラップする方がと、そのうち色々なところにロジックが漏れ出す
- 今後同じような処理を持つメソッドを大量に生やすことになると予測される
といったこともフィードしていただきました🙏
結論
HttpClient
のライブラリ自体そのものがHTTPを効率よく使うための汎用ライブラリなので、それを自分等が扱いやすいように再度加工するのは、よほどライブラリの中身を理解していない限りは避けた方が良いみたいです。
確かに、 今このような使い方をしたいから、この形にする という非常に具体的な内容の実装になっていました。
- もし数日後に使い方が変わったら?
- もしライブラリ自体の仕様が変更されたら?
こういったことを考慮すると、わざわざ自分たちで既存のライブラリを用いた新しい実装をするよりは、直接ライブラリを Driver
からライブラリそのものを直接呼び出す方が良いのかもしれません。
最後に
コードレビューは死ぬほど大事。
新たな発見があったり、より良い実装にできる要素を気付けますね。