Así que ahí estaba yo
Unos pocos colegas y yo estábamos felizmente codificando en nuestra mafia diaria, escribiendo un servicio que se encargaba de escuchar los mensajes y persistiéndolos en una base de datos. Finalmente llegamos a esto:
publicvoid ManejarMensaje(DirecciónActualizarMensaje){varaddress=newAddress{Street=message.Street,City=message.City,State=message.State,Zip=message.Zip};addressCache.Save(address);}Siendo el patrón basura que soy a veces, se me ocurrió que necesitamos un mapeador para mapear el mensaje de AddressUpdated al modelo de Address que estamos persistiendo en la base de datos. Unas pocas pulsaciones más tarde:
publicvoidHandleMessage(AddressUpdatedmessage){addressCache.Save(Address.MapFrom(message));}Me senté con orgullo, confiado en que había hecho del mundo un lugar mejor. Mis siempre astutos colegas ayudaron a guiarme a la realidad con las siguientes preguntas:
<¿Realmente necesitamos ese mapeador? Sólo estamos haciendo este mapeo en un lugar, ¿es prematuro este refactor? ¿Conseguimos algo por esta complejidad adicional?
Mi mente comenzó a enumerar las razones por las que de hecho lo necesitábamos. Podíamos probarlo en aislamiento, hacía el código más conciso y podíamos beneficiarnos de la reutilización. La cosa es que no necesitábamos ninguna reutilización todavía. Además, ya estábamos probando este componente fácilmente. Hizo nuestro código más conciso, pero sólo moviendo el código de mapeo a otro lugar. Al darnos cuenta de que la mafia tenía razón, lo cual es típico, borramos el mapeador y seguimos avanzando.
Una solución en busca de un problema
Al viajar a casa esa noche, me vino a la mente la experiencia del mapper. Después de pensarlo un poco, concluí que tenía una solución en busca de un problema . En un proyecto anterior había usado este patrón de mapeo con éxito y estaba emocionado de usarlo de nuevo.
En la mafia, vi una oportunidad de usar este patrón de mapeo. Haciendo hincapié en la palabra oportunidad aquí, lo que no tenía era una necesidad para el mapper. El dogma dentro de mí exigía que todo mapeo necesitara un mapeador. Afortunadamente, el pragmatismo de mis colegas se interpuso y nos condujo de vuelta al rumbo y lejos de gastar ciclos en algo que no necesitábamos.
La Regla de 3
El perfeccionismo y el pragmatismo a menudo están en desacuerdo. ¿Cómo se logra un equilibrio entre hacer lo perfecto y lo correcto?
En , hablaremos a menudo de la Regla de 3. Esta regla establece que hasta que no se repita en al menos 3 lugares, probablemente no tengas que hacer nada al respecto. La idea detrás de esto es que «hacer algo al respecto» típicamente significa introducir complejidad. El ejemplo de la cartografía, aunque podría decirse que es trivial, destaca esta regla. Siguiendo la regla del 3, no debería escribir un mapper hasta que haya mapeado de AddressUpdatedMessage a Address al menos 3 veces.
Tiendo a entusiasmarme con los nuevos patrones. Por muy excitantes que sean, mantener y ampliar una base de códigos llena de patrones aplicados a principios de año puede convertirse rápidamente en algo difícil. La Regla de 3 me ayuda a tener esto en mente. ¿Qué opina usted?
Categorías: technicalTags: clean code, mobbing