En mi humilde opinión, si solo pudieras hacer una cosa antes de entregar tu proyecto (ya sea directa o indirectamente), te recomendaría que verifiques dos veces y triples que se compila tal como está desde el control de origen.
Sin reír, pero no puedo decirte cuántas veces recibí el "último" de un control de fuente y no se compiló, solo para descubrir más tarde que no estaba "en la vieja caja de Fred" porque aparentemente el código "solo compila en la vieja caja de Fred ". Incluso tuve un antiguo empleador que eliminó de inmediato mi escritorio de mi cubo y lo reemplazó con "la vieja caja de Fred" para poder trabajar en el proyecto que se suponía que debía hacer.
Como una extensión de la recomendación anterior, ya que a veces obtener la última versión no es todo lo que es necesario para compilar una aplicación, le recomiendo que cree un archivo README.txt y lo coloque en el directorio raíz de su aplicación y lo coloque en el control de origen. Este documento README debe contener una lista de dependencias externas que no se pueden verificar en el control de origen (si existe), cómo configurar la base de datos y cualquier otra rareza sobre los ciclos de compilación, ejecución o implementación de la aplicación.
Cualquier cosa por encima y más allá de las dos sugerencias anteriores solo sería gravy, pero en mi humilde opinión, las dos anteriores son casi necesarias en cualquier proyecto más grande que "Hello World".
EDITAR:
Sobre el tema de la documentación ...
A lo largo de los años, he escrito y leído una buena cantidad de documentación de software con el fin de facilitar la transición de un desarrollador. Diría que esos documentos rara vez valen el papel en el que se imprimen. Los desarrolladores (incluido yo mismo) rara vez piensan en las partes importantes de la aplicación mientras escriben dichos documentos, solo tendemos a pensar en los incendios más recientes que hemos combatido. Más allá del hecho de que estos documentos tienden a no cubrir todos los aspectos importantes del software, también se desactualizan MUY rápidamente. Una vez que el documento esté desactualizado, es probable que un futuro desarrollador lo ignore por completo en lugar de volverlo a poner en práctica para que coincida con la realidad (piense en los requisitos cambiantes).
En lugar de la documentación per se, recomiendo pruebas unitarias. Sé que probablemente suena viejo en este punto, pero deja que el código haga la documentación por ti. Las pruebas unitarias rotas son difíciles de ignorar (y más fáciles de detectar) que un documento de Word. Además, el idioma inglés es terriblemente impreciso para articular los puntos más finos del diseño de software. Simplemente hay demasiadas formas de interpretar el significado de incluso la más simple de las oraciones en inglés, y esto solo lleva a confusión y / o errores.
readmearchivo. Si el código se compila y se ejecuta, ya está todo listo.Esto es exactamente por qué los comentarios no son código de olor. Por eso también debemos documentar nuestro código.
Debe asegurarse de tener una documentación sólida. Existen programas que pueden generar documentación a partir de los comentarios según el formato de los comentarios y el lenguaje de programación.
Considere qué información desearía sobre una biblioteca o base de código cuando la tome. Pídale a un amigo que sea programador que eche un vistazo rápido y vea si encuentra alguna pregunta obvia.
¡Buena suerte!
fuente
Asegúrese de que su código se está compilando y empacando en la forma final con solo un comando / clic.
No puedo votar a favor la respuesta. ¿Cuáles son algunas cosas a tener en cuenta al preparar un proyecto? suficiente, así que tengo que escribir esto de nuevo.
Soy muy quisquilloso con esta compilación de un solo clic , porque ya dediqué tanto tiempo en descubrir cómo compilar o empaquetar un proyecto que solo tuve que arreglar un pequeño error. Comencé a poner pequeños scripts de lotes / bash en mis proyectos para empaquetar el ZIP, JAR o EAR final.
Además de eso, agrego un archivo README.txt al directorio raíz que describe el diseño general , las partes complejas y el entorno del proyecto (en términos de comunicación con otros departamentos o personas).
Intento mantener este README.txt pequeño , porque nadie lee más de 200 páginas de documentos de especificación si todo lo que quiere hacer es corregir un error, compilarlo y empaquetarlo. El detalle de la implementación se documenta en las pruebas unitarias , por lo que no es necesario volver a escribirlo todo en un libro ...
fuente
Mi lista de verificación de transferencia predeterminada:
Si algo está roto, lo arreglaría antes de entregarlo. Nada hace que alguien empiece a funcionar y luego verifique, construya y ejecute el proyecto el día en que lo obtenga.
fuente