¿Cuándo se vuelve excesivo?

En primer lugar, me disculpo porque no sé cómo hacer un hilo comunitario; entonces alguien me ayude por favor.

Como desarrollador, en muchas plataformas, tecnologías e incluso a nivel de infraestructura; Siempre me pregunto, ¿cuándo estoy haciendo DEMASIADO?

Ha sido un proceso de aprendizaje interminable desde que empecé. Una (1) cosa que aprendí es que los requisitos apenas son válidos por un período prolongado de tiempo, y como tal, una pequeña previsión puede ser muy útil.

Pero, ¿dónde está el equilibrio y cómo sabes cuándo estás perdiendo tiempo y no lo estás ganando?

Estás haciendo demasiado cuando el desarrollador promedio no puede entender lo que hiciste al leer tu código.

• Realice revisiones de código frecuentes con su equipo.
• Discuta con las arquitecturas, tecnologías o patrones que planea usar. (en reuniones diarias de pie si las tiene)

Lucho contra todos los "arquitectos" orientados al CV que encuentro. ¡Ojalá existiera la cúpula ! ;)

Creo que el mundo está desperdiciando una gran cantidad de dinero que podríamos usar para mejorar nuestra vida (de programador).

Cuando los procesos superan los resultados.

Demasiadas veces hemos visto que si los desarrolladores se centran más en el proceso que en los resultados (como la calidad, la fecha límite, etc.) comienzan las cosas malas.

Es por eso que nunca debe olvidarse que el propósito de las revisiones de código, los patrones de diseño, etc. es mejorar el código, pero no son el objetivo en sí mismos.

Para mí, me gusta el enfoque que presenta Kent Beck en XP (no estoy seguro si es "su" idea o la de otra persona, pero ahí es donde la escuché por primera vez):

Ya es bastante difícil resolver los problemas de hoy sin tratar de resolver cuáles son los problemas del mañana y resolverlos también.

Los desarrolladores pueden dedicar mucho tiempo a soluciones para requisitos que no existen, casos extremos que nunca ocurrirán o incluso problemas genuinos donde el impacto del problema es significativamente menor que el costo de prevenirlo.

Este es el momento que podría ponerse en cosas que los usuarios realmente querrán y usarán, cosas que les darán beneficios que superarán enormemente incluso los inconvenientes que se causarán en el improbable caso de que una de estas cosas realmente suceda.

Más allá incluso de este resultado no óptimo para el usuario, el impacto en el desarrollador de la sobre ingeniería de esta manera tiende a ser sobre un código complejo que es más difícil de soportar y más difícil de mejorar.

Entonces, para mí, si sabe, o puede estar bastante seguro, que algo es un requisito o que va a causar un problema, resuélvalo, si no, no lo haga.

Es posible que tenga que regresar y volver a trabajarlo cuando resulte que hubo un requisito más amplio que el que implementó originalmente, pero en general el esfuerzo total que realiza en el proyecto seguirá siendo menor porque en la mayoría de los casos eso no sucederá.

Su pregunta es bastante abierta, por lo que la interpretaré como "hacer demasiado en una parte del proyecto":

Para mí, es fácil dedicar demasiado tiempo a algo que realmente no proporciona mucha ganancia para el cliente. A menudo, son las cosas pequeñas como "Bueno, funciona, pero no del todo como yo también lo quiero", donde al cliente probablemente no le importaría si funcionara de esta manera u otra.

Cuando eso suceda, debería detenerlo y dedicar tiempo a cosas que son más importantes. Es mejor que el producto funcione como un todo que no, pero tiene estas piezas más pequeñas que funcionan perfectamente.

Escribir código de seguimiento (desde Code Complete ) es probablemente una buena idea para evitar esto: comienza su proyecto escribiendo código que conecta todo el código, desde la GUI (o cerca de él) hasta el backend y luego de regreso. De esa manera siempre tienes algo que funciona y no pasas tiempo perfeccionando las pequeñas cosas hasta que todo funcione.

Pero aún así, es una cuestión de disciplina y priorización.

Cuando respondo que no a "¿voy a enojarme? No hice esto más tarde y me muerde ...

Sin embargo, las limitaciones de recursos y tiempo de IRL generalmente me afectan antes de tener que hacer esta pregunta mucho. En ese punto, solo te enfocas en los bits más importantes / alcanzables y esperas lo mejor.

¡un proceso de aprendizaje sin fin! ... y creo que sigue así! El equilibrio es cuando las cosas son lo suficientemente eficientes y también tienes tiempo para hacer algo más aparte de la programación. Estoy de acuerdo con gablin "una cuestión de disciplina y priorización" y jim hopkins en que se convierte en instinto después de un tiempo. Sé que perfeccionar las piezas pequeñas es lo que nos hace felices, pero al final se trata de lo que hace feliz al usuario final. así que diría que el equilibrio (o tal vez el compromiso) es hacer que el usuario final / cliente / cliente esté contento primero (que debería ser el plan A) y luego, si hay tiempo para perfeccionar, hacer más eficientes sus "partes pequeñas" y / o todo lo que quieras. Sin embargo, en algún momento tienes que decir "suficiente" :) de lo contrario, sí, ¡se convertirá en una exageración!

¡el peor de los casos, por supuesto, es cuando el usuario / cliente / cliente final es usted! :)