Un día en la vida de un desarrollador Kotlin: código, café y corutinas

La mañana no empieza con café, sino con un Merge Request

7:45 de la mañana. El teléfono vibra — no es el despertador, es GitLab que envió una notificación: tu Merge Request de ayer pasó el pipeline de CI/CD. Mientras hierve la tetera, abro el portátil y veo una marca verde. Primera victoria del día. Buenos días, Kotlin.

Me llamo Alexey, soy desarrollador Kotlin en una empresa de productos. Los últimos tres años he estado escribiendo en Kotlin para Android y un poco en el backend con Ktor. Si crees que el trabajo de un programador es un interminable "Hola Mundo", hoy voy a romper ese mito. Bienvenido a mi día laboral real.

8:30 — Daily Standup: sincronización y contexto

Lo primero que ocurre es la reunión diaria. Nos reunimos en Zoom, pero sin los típicos "ayer-hoy-problemas". Somos concisos: qué se hizo, qué está planeado, si hay bloqueos. Hoy estoy trabajando en la función de Notificaciones Push para los usuarios.

— Ayer terminé la refactorización de NotificationService, lo reescribí con corutinas. Hoy conecto Firebase Cloud Messaging y pruebo Flow. Sin bloqueos.

Por cierto, a menudo es en las reuniones diarias donde nacen las mejores ideas de arquitectura. Por ejemplo, la semana pasada un colega sugirió reemplazar RxJava por Kotlin Flow — y redujimos la cantidad de código boilerplate en un 40%. Así es como se ve ahora:

// En lugar del antiguo RxJava:\n// Observable.just(data).subscribeOn(Schedulers.io())\n\n// Usamos Kotlin Flow:\nfun observeNotifications(): Flow<Notification> = flow {\n    val service = NotificationService()\n    while (true) {\n        emit(service.getNextNotification())\n        delay(5000) // sondeo cada 5 segundos\n    }\n}.flowOn(Dispatchers.IO)

La diferencia es obvia: legibilidad, seguridad de tipos y nada de callback hell.

9:15 — Desarrollo: escribiendo código en Kotlin

Después de la reunión, me sumerjo en el código. La tarea de hoy es implementar el procesamiento de notificaciones push entrantes. Uso Kotlin Coroutines y StateFlow para gestionar el estado de la UI. Así es como se ve mi ViewModel:

class PushViewModel(\n    private val repository: NotificationRepository\n) : ViewModel() {\n\n    private val _uiState = MutableStateFlow<PushUiState>(PushUiState.Loading)\n    val uiState: StateFlow<PushUiState> = _uiState.asStateFlow()\n\n    fun loadNotifications() {\n        viewModelScope.launch {\n            repository.getNotifications()\n                .catch { e ->\n                    _uiState.value = PushUiState.Error(e.message ?: "Error desconocido")\n                }\n                .collect { notifications ->\n                    _uiState.value = PushUiState.Success(notifications)\n                }\n        }\n    }\n}\n\nsealed class PushUiState {\n    object Loading : PushUiState()\n    data class Success(val data: List<Notification>) : PushUiState()\n    data class Error(val message: String) : PushUiState()\n}

Observa: uso sealed class para el estado de la UI. Esta es una práctica estándar en el desarrollo moderno de Android con Kotlin. Nada de cadenas if-else — solo tipado puro.

Por cierto, si eres nuevo en Kotlin, te recomiendo prestar atención a las Scope functions: let, apply, also. Hacen el código más conciso. Por ejemplo:

// Sin scope functions\nval user = User()\nuser.name = "Alex"\nuser.age = 30\nsaveUser(user)\n\n// Con apply\nval user = User().apply {\n    name = "Alex"\n    age = 30\n}\nsaveUser(user)

11:00 — Code Review: aprendiendo de los colegas

Después del almuerzo (sí, almuerzo a las 11 — costumbre del trabajo remoto) abro un Merge Request de un colega. Está reescribiendo el módulo de autenticación con Kotlin Multiplatform. Leo el código y veo un punto interesante:

// Era (