¿Dónde trazas la línea para tu perfeccionismo? [cerrado]

37

El perfeccionismo puede ser bueno y malo al programar.

  • ¿Cuándo y dónde trazas la línea cuando estás resolviendo problemas?
  • ¿Cuándo decide cuándo una solución es exagerada, demasiado general o simplemente demasiado futurista?

Por favor comente si la pregunta no está clara.

Amir Rezaei
fuente
77
Buena pregunta: siempre lucho con esto.
Nadie el

Respuestas:

40

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:

  • BESO = Mantenlo simple, estúpido = finge que eres un imbécil y tienes que entender el diseño
  • YAGNI = No lo vas a necesitar = deja de fingir que puedes predecir el futuro en tu diseño
Joeri Sebrechts
fuente
55
+1: es bastante difícil resolver los problemas que sabemos que tenemos, sin tratar también de resolver los problemas que creemos que podríamos tener.
Jon Hopkins
66
Me gusta esto, pero sería útil una definición clara de los acrónimos. Nunca había oído hablar YAGNIhasta hoy.
Philip Regan el
¡+1 para Philip que aprende algo hoy! +1 para KISS también.
Bueno, la respuesta es buena. Aunque, obviamente, cualquier interfaz (ya sea para almacenamiento permanente (archivos), red o IPC) debe ser al menos versionable o sabe que su rediseño hará imposible la compatibilidad inversa.
Deduplicador
7

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.

Sean McEligot
fuente
6

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.

Dan McGrath
fuente
6

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.

Pete
fuente
5

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.

Thomas Stock
fuente
1
+1 Por experiencia, te comprometes más.
Amir Rezaei
4

El límite de tiempo dibuja esta línea bastante clara.

Simon
fuente
1
Buen punto, pero una mala solución puede necesitar más tiempo para solucionarlo en el futuro.
Amir Rezaei
Creo que debe juzgar qué es un software "suficientemente bueno". La línea debe estar definida por la especificación y su sentido común.
Nadie el
3

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:

  • Formas que mejorarían la usabilidad y reducirían las posibilidades de que se produzca un error
  • Formas que reducirían las dependencias, mejorando el tiempo de compilación

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.

Matthieu M.
fuente
Comparto contigo las molestias. Creo que la programación es como una especie de arte donde no hay perfección.
Amir Rezaei
2

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).

BlairHippo
fuente
0

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 .

l0b0
fuente
El perfeccionismo no es posible incluso después de MUCHOS años de experiencia; es decir, si alguna vez quieres ENTREGAR algo. Lo más valioso que la experiencia enseña es cuándo reconocer "lo suficientemente bueno".
Jeff Knecht
0

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.

MPelletier
fuente