Buenas prácticas de programación frente a la velocidad de la programación ad-hoc

Question

Sé que las buenas prácticas de programación siempre ayudan en el "largo plazo" para un proyecto, pero a veces parecen costar mucho tiempo. Por ejemplo, sugirió que mantenga un archivo de cabecera y un archivo cpp para cada clase que hago, mantenga solo las declaraciones en los encabezados mientras las definiciones en cpp. Incluso con 10-12 clases, este proceso se vuelve muy engorroso. Actualizar el archivo MAKE cada vez que se agrega una clase nueva depende y todo ... toma mucho tiempo ...

Mientras estoy ocupado haciendo todo esto, otros simplemente escriben todo en un solo archivo, emite un solo comando de compilación y ejecutar sus programas ... ¿por qué no debería hacer lo mismo? Es rápido y funciona?

Incluso tratando de llegar a los nombres cortos y significativos para las variables y funciones requiere mucho tiempo, de lo contrario se terminan de escribir 30 caracteres nombres largos, completamente unmanagable sin auto completo

Editar:

Vale permítanme decirlo un poco diferente: digamos que estoy trabajando en un proyecto de tamaño pequeño-mediano, que nunca requerirá ningún mantenimiento por parte de un desarrollador diferente (o incluso de mí). Es básicamente un desarrollo de una sola vez. Son prácticas de programación que vale la pena seguir en tal caso. Supongo que mi pregunta es, ¿las buenas prácticas de programación realmente ayudan durante el desarrollo, o simplemente pagan durante el mantenimiento?

Answer 1

La desventaja del ad-hoc es a la larga, cuando se trata de mantenimiento (especialmente cuando los codificadores de mantenimiento son personas distintas de usted). Dichas técnicas podrían estar bien para la prueba rápida de conceptos, pero causarán más problemas en el futuro si no se reconstruye correctamente.

Answer 2

No he estado trabajando en el campo por mucho tiempo, pero no aflojarme y documentar sobre la marcha, definir variables con nombres útiles, etc ... definitivamente ahorra tiempo a largo plazo. Ahorra tiempo cuando los otros desarrolladores/yo volvemos al código para mantenimiento.

No me asombré preguntándome qué significa esta variable, por qué hice eso, etc. :)

Answer 3

Sí, vale la pena hacerlo "bien", es decir, bueno, porque básicamente me pagan ahora o me pagan más tarde, y usted no es la única persona que verá el código. Si ahora demora 15 minutos en hacerlo "bien", ¿cuánto tiempo le tomará 6 meses (o más) a partir de ahora para descubrir qué se entiende en su propio código?

Ahora, podría utilizar la idea de 3 strikes de Martin Fowler para refactorizar. Primera vez en el código para arreglar algo, observe que podría ser refactorizado, pero está demasiado ocupado y déjelo ir. Segunda vez en el mismo código, lo mismo. Tercera vez: refactorizar el código.

Answer 4

La eficacia de las prácticas de programación no parece ser su problema, aquí. Lo que debería preocuparle son las herramientas que está utilizando para desarrollar. Hay muchos IDE y otras opciones para mantener sus archivos make automáticamente actualizados, por ejemplo.

Answer 5

La pereza puede dar sus frutos en este momento, pero solo pagará una vez. Tomarse el tiempo para hacerlo bien no compensa inmediatamente, pero lo hará varias veces y durante un período de tiempo más largo.

Además, no hay nada de malo con los nombres de variables y métodos muy largos, a menos que se suscriba a la vista ingenua que la mayoría de las veces que usa programación se usa para escribir y no resolver problemas.

Adición: Si es difícil nombrar de manera sucinta, probablemente deba desglosarse en más unidades modulares.El método o las variables que son difíciles de nombrar es un olor de código definido.

Answer 6

Todo se trata de compatibilidad a largo plazo. Claramente, o no has estado codificando en un equipo o no has tenido que mirar el código que has escrito hace años. Puedo abrir el código que he escrito hace 15 años y modificarlo con curvas de reaprendizaje muy pequeñas si he dado nombres de variables significativos, mientras que si no lo he hecho, me tomará un tiempo descubrir qué estaba haciendo con esa X y esa H, y por qué T no debería ser mayor que 4.

Intenta compartir el código con 10 personas en un equipo y haz que cada una de ellas simplemente coloque el código en el lugar que desee ... He trabajado con gente así. Si los linchamientos todavía tuvieran apoyo público, habría liderado a muchos. Imagínate esto ... Sé que necesito modificar la firma en Foo.SetFoos (int FoosInFooVille), pero busqué Foo.h y no fue encontrado, bueno ahora solo busco Foo.cpp ¿verdad? Vaya, para ahorrar ... ¿tiempo? ... metieron Foo.cpp en Chew.cpp ... así que miro allí ... ¡no está en la parte superior del archivo! ¿Encuentro Foo en ese archivo y veo si está por encima de eso ... claro ... no, no lo encontré ... está en Chew.h. Ahora estoy listo para verificar el registro de SVN y dirigir mi lanzador de misiles con USB a ese tirón la próxima vez que pase.