El perfeccionismo puede ser bueno y malo al programar.
Por favor comente si la pregunta no está clara.
Respuestas:
KISS y YAGNI , especialmente YAGNI.
Solo diseñe una solución para las cosas que sabe que va a necesitar pronto. No lo diseñes para las cosas que podrían necesitarse en dos años, porque lo más probable es que necesites cosas muy diferentes y tendrás que rediseñarlo de todos modos.
En el momento en que empiece a hablar de "con este diseño en algún momento en el futuro podríamos hacer X, o incluso Y", en lugar de "este diseño nos permite cumplir con los requisitos del cliente Z en la próxima versión", es cuando está obteniendo en arquitectura astronomía.
En respuesta a los comentarios:
YAGNIhasta hoy.
Utilice un enfoque iterativo y este problema desaparece en su mayoría. Su código debe ejecutarse el primer día y casi todos los días después de eso. Cumpla con los requisitos mínimos primero y agregue más a medida que tenga tiempo. Nunca se desvíe de grandes cambios donde no pueda ejecutar su código durante mucho tiempo.
Una solución es exagerada cuando el tiempo extra que lleva completarla vale más que el impacto negativo potencial desde que se termina la solución más fácil hasta la próxima actualización / modificación natural.
Básicamente estás intercambiando tiempo ahora con tiempo después. Si pasa más tiempo ahora, ahorrará más tarde, lo está haciendo mal. Si realmente ha superado la ingeniería, está gastando tiempo ahora que no afecta la cantidad de tiempo (o incluso lo hace más) que pasa más tarde.
Mejoras en resolver esto mientras más experiencia tengas. La mejor manera de hacer las cosas (desde mi experiencia) es hacer lo que necesita ahora, pero de una manera que se aumente más fácilmente si los requisitos posteriores lo exigen. Resolver cómo hacerlo es la parte difícil.
Solía ser muy perfeccionista (pasar tiempo creando marcos, no soluciones).
Pero lo que realmente me ayudó a acelerar mi producción fue aprender y seguir los principios de BDD / TDD, incluido el exterior en principio (que me ha resultado particularmente difícil de aprender).
Esto realmente me enseñó a no escribir una sola línea de código antes de que exista una prueba para ello. Pero las pruebas unitarias tampoco existen antes de que exista una prueba de aceptación. Y las pruebas de aceptación provienen de las necesidades reales del usuario.
Por lo tanto, todas las líneas de código se originan a partir de una necesidad real del usuario.
Si no está familiarizado con el exterior en principio, dicta que comience a escribir pruebas para la capa más externa de su aplicación (es decir, la GUI en prácticamente todos los casos) utilizando dobles de prueba para simular el comportamiento de las capas inferiores. Luego implementa lo suficiente para que las pruebas pasen. Esta implementación de la capa superior dicta las pruebas que necesita escribir para la siguiente capa, etc., hasta que llegue a la capa inferior de su aplicación.
Noto que mejoro en esto por experiencia.
Cuando era (muy) joven siempre buscaba la solución más perfecta, sin compromisos. Ahora soy mejor teniendo en cuenta cosas como el presupuesto y el tiempo.
El límite de tiempo dibuja esta línea bastante clara.
Mi jefe realmente lo hace :)
Debo admitir que estoy mejorando, pero todavía no tengo mucho compromiso. Afortunadamente tengo a mi jefe para controlarme;)
Sin embargo, me gustaría plantear otro problema que la sobreingeniería, ya que la sobreingeniería es bastante fácil de detectar.
Mi principal problema es con la refactorización. El problema es que la mayoría de las veces, a pesar de que intenté escribir el código lo mejor que pude, en ese momento no sabía lo que sé ahora (vi más códigos, más patrones, nuevas expresiones idiomáticas, nuevos problemas, nuevos soluciones). Y así, aunque funciona, ahora sé mejores formas de hacerlo:
Sin embargo, está funcionando como está y, por lo tanto, refactorizarlo no es una prioridad, y la verdad es que me está molestando; Entiendo las razones económicas y entiendo las expectativas del cliente (no ven el código y prefieren nuevas características y correcciones de errores), pero desearía tener tiempo para trabajar en ello.
Por ahora, solo sigo las órdenes de mi jefe, pero debo admitir que me siento incómodo al saber que el código entregado en producción no es lo mejor que se me ocurre ahora. El perfeccionismo, supongo.
Tanto profesional como personalmente, el estándar que trato de aplicarme es:
Contentarse con ganar.
Si mi código resuelve el problema que está destinado a resolver y no crea ningún problema nuevo *, es muy probable que sea hora de seguir adelante. Cuando aprende a poner el listón tan alto como debe establecerse, "Lo suficientemente bueno" se convierte, bueno, en lo suficientemente bueno.
La perfección es como la velocidad de la luz: nunca llegarás allí, pero la energía que puedes gastar no tiene límite.
(* - Tenga en cuenta que "Buggy" y "Difícil de mantener" caen firmemente bajo el título de "Nuevos problemas". Por lo tanto, no lo llamo completo hasta que se haya probado el código, se hayan recortado los bits superfluos y la documentación de comentarios / API actualizada).
Con experiencia, me he dado cuenta de que el perfeccionismo ni siquiera es posible hasta que tenga al menos unos años en un contexto particular (lenguaje, marco, plataforma, estándar). Como novato , habrá todo tipo de idiosincrasias de las que no se dará cuenta (escape, precedencia, palabras reservadas, azúcar sintáctica, tiempos de espera, llamadas asincrónicas, características indocumentadas y errores), así que solo trato de encontrar una buena solución, todos los mientras aprendes tanto como sea posible. Es importante destacar que siempre trato de simplificar la refactorización del resultado: arquitectura modular, comentarios donde sea necesario y sin trucos ingeniosos .
Yo, como muchos otros programadores, tengo mucho código heredado que mantener. La tentación de rehacer todo siempre estará ahí, pero esencialmente lo he reducido a un principio:
¿Estoy (u otra persona) va a tener que resolver esto de nuevo ?
Eso generalmente se encarga de una gran cantidad de código de espagueti en un código de fragmento de espagueti algo más manejable. Extraiga algunos de los trozos, agregue sus pruebas, y ahora no parece que necesite tanta perfección.