Unha vez fun a unha xuntanza cun cliente que me solicitou que puxera un botón nunha pantalla para descontar un 5% do pedido. Como levaba pouco tempo no oficio, non o cuestionei e así o fixen.
Pouco tempo despois, o cliente pediume que o botón tivera cor vermella no canto de gris; así o fixen tamén.
Unhas semanas despois, pediume que o texto do botón fora un 20% máis grande. Aí foi cando, por fin, lle fixen a pregunta que lle tiña que ter feito desde o principio: por que quería facer ese cambio?
Porque sempre esquecía premer o botón, díxome. E por que quería premer o botón?, preguntei eu. Porque lle quería aplicar o desconto aos clientes preferentes, díxome.
Acabaramos! Eu cometera o típico erro de implementar a cegas a solución que me pedía o cliente sen saber o problema real que quería solucionar. Con esta nova información, engadín unha columna na base de datos, unha “checkbox” na pantalla de edición de clientes, e agora o sistema sabía quen eran os clientes preferentes e aplicáballes o desconto automaticamente sen que ninguén tivese que lembrar premer ningún botón.
Cóntovos esta historia porque a semana pasada decateime de que estaba a cometer o mesmo erro. Quería escribir unha Folla sobre monorrepositorios e multirrepositorios e por que unha desas opcións é claramente superior á outra, e estaba a consultar blogs e páxinas web para ver as avantaxes e desvantaxes que a xente vía en cada opción, cando de súpeto caín na conta de que todo este falar non xurdiu porque moita xente teña interese en como organizar o seu sistema de control de versións, senón que queren xestionar a súa organización.
Nun artigo sobre monorrepositorios e multirrepositorios, a porcentaxe do texto que fala sobre eles é mínima; do que falan é de como xestionar as dependencias no código e de como distintos equipos poden traballar de maneira acompasada e como evitar que Pepiño no módulo de tarxetas de crédito faga un cambio que estrague a páxina web, e mencionan como unha maneira de facelo é máis doada cun monorrepositorio ou cun multirrepositorio.
O caso é que ningunha desas cousas (dependencias, traballo en equipo, contención dos cambios) é responsabilidade do sistema de control de versións, senón que é o obxecto de normas e políticas e estándares e ferramentas que tedes que implantar na vosa organización.
Por exemplo, nun fío de discusión alguén dicía que o multirrepositorio era mellor porque así, se precisabas de ter distintas versións de jQuery, cada repositorio podía termar da súa. Outra persoa dicía que non, que era mellor o monorrepositorio no que tiñas unha soa versión de jQuery para todo o mundo.
Na realidade dá igual, porque ter múltiples versións de jQuery nun monorrepositorio é trivial, igual que é moi doado mandar ter unha soa versión nun multirrepositorio. Que é o que queredes ter? Unha soa versión ou múltiples versións? Escollede e implantádeo no voso repositorio actual; non escollades o repositorio por conta das políticas que queirades implantar na vosa organización, que é coma ter un rabo dándolle ao can e non un can dándolle ao rabo.
No final, esta discusión sobre os repositorios é como o botón vermello con texto grande que o meu cliente quería que lle puxera: podemos malgastar o noso tempo e o noso esforzo aplicándoo e refinándoo todo o que queiramos, pero na realidade, o problema que queremos solucionar é outro.
(Dos monorrepositorios e dos multirrepositorios falarei outro día; se cadra, a semana que vén.)
A ilustración desta Folla procede dun gravado de Anthonie Waterloo.
1 comentario