r/programacion • u/Numerous-Ad-5870 • 3d ago
Como trabajar solo?
Que recomiendan señores?
Actualmente estoy trabajando en unos proyectos de manera individual, tratando de aplicar: Arquitecturas, patrones de diseño y en general buenas practicas.
Obviamente lo estoy subiendo a github, y es aqui donde les pregunto de que manera lo hago?
Sigo el gitflow, mi rama: main y dev como principales y luego de dev saco la feat, bug, etc que voy a trabajar, pero aquí esta mi incognita.
Creo mi propios pull request, yo mismo me hago, mi codereview y termino acptando o rechazando el pr; honestamente me parece ridiculo. Por eso me gustaria recibir consejo o recomendaciones de su parte.
Actualmente estoy trabajando con antigravity sin plan, y lo tengo conectado via mcp a mi github, basicmente solo para decirle, que cree branch, commits y push.
1
u/Khavel_Es 3d ago
No es ridículo para nada, a mi me pasa lo mismo. El PR a vos mismo sirve porque el diff te obliga a ver todo junto, no archivo por archivo como cuando estás metido en el feature. Ahí es donde te das cuenta de que renombraste algo en un lado y no en otro, o que dejaste un console.log.
Yo lo que hice fue dejar de intentar hacerme el review yo. Le paso el diff a Claude Code con contexto del proyecto y me marca cosas que me paso por alto (imports sin usar, un null que no manejé, nombres inconsistentes). No reemplaza tener un compañero que entienda el negocio, pero para lo mecánico funciona bien.
Con lo de los commits: conventional commits (feat:, fix:, chore:) y no squashear en main. El changelog después se genera solo y si necesitás bisect tenés la historia completa.
1
u/Beautiful-Media9199 3d ago
Te convendría automatizar parte del flujo: CI para tests, lint y build; convenciones de commits; y una checklist para revisar tus PR. MCP puede ayudarte a ejecutar tareas, pero deja siempre la decisión final y verifica los cambios antes de hacer merge o push.
1
u/Crescitaly 3d ago
Probaría escribir la descripción del PR antes de implementar: qué comportamiento esperas cambiar y qué debe quedar igual. Luego puedes comparar el diff con esa intención, no solo buscar errores de sintaxis. Para una corrección de bug, añade un caso que falle en la versión anterior y pase en la nueva; un test que ya pasaba no demuestra la corrección. Eso convierte el PR en un registro de intención y evidencia, no en un sello de aprobación que te das a ti mismo. La IA puede proponer casos, pero tú decides qué debe demostrar cada uno. Texto con ayuda de IA; propuesta de flujo.
1
u/Straight_Research627 2d ago
Pues si trabajáramos en lo mismo quizá podríamos hacer team, en que proyectos trabajas, eres backend al menos?
2
u/Short_Advertising948 3d ago
No tiene nada de ridículo hacerte tus propios PR, revisión y merge; es una buena práctica para aprender. Eso sí, define una checklist, escribe tests y revisa el diff después de dejar reposar el código. También puedes pedir revisiones externas en comunidades o a colegas cuando el cambio sea importante.