À mon humble avis, si vous ne pouviez faire qu'une seule chose avant de remettre votre projet (directement ou indirectement), je vous recommande de vérifier et de tripler qu'il compile tel quel à partir du contrôle de code source.
Pas de rire, mais je ne peux pas vous dire combien de fois j'ai obtenu le "dernier" d'un contrôle de source et il n'a pas pu être compilé, pour découvrir plus tard que je n'étais pas "sur l'ancienne boîte de Fred" car apparemment le code "seulement compile sur la vieille boîte de Fred ". J'ai même demandé à un ancien employeur de retirer rapidement mon bureau de mon cube et de le remplacer par «l'ancienne boîte de Fred» afin de pouvoir travailler sur le projet que j'étais censé faire.
En tant qu'extension de la recommandation ci-dessus, car il n'est parfois pas nécessaire d'obtenir la dernière version pour compiler une application, je vous recommande de créer un fichier README.txt et de le placer dans le répertoire racine de votre application et de le placer dans le contrôle de code source. Ce document README doit contenir une liste des dépendances externes qui n'ont pas pu être vérifiées dans le contrôle de source (le cas échéant), comment configurer la base de données et toute autre bizarrerie concernant les cycles de compilation, d'exécution ou de déploiement de l'application.
Tout ce qui est au-delà des deux suggestions ci-dessus ne serait que de la sauce, mais à mon humble avis, les deux ci-dessus sont presque nécessaires sur tout projet plus grand que "Hello World".
ÉDITER:
Au sujet de la documentation ...
Au fil des ans, j'ai à la fois écrit et lu ma juste part de la documentation logicielle dans le but de faciliter la transition d'un développeur. Je dirais que ces documents valent rarement le papier sur lequel ils sont imprimés. Les développeurs (moi y compris) pensent rarement aux parties importantes de l'application en écrivant de tels documents, nous avons seulement tendance à penser aux incendies les plus récents que nous avons combattus. Au-delà du fait que ces documents tendent à ne pas couvrir tous les aspects importants du logiciel, ils deviennent également TRÈS rapidement obsolètes. Une fois que le document est obsolète, un futur développeur va très probablement l'ignorer complètement au lieu de le remettre en conformité avec la réalité (pensez à changer les exigences).
Au lieu de la documentation en soi, je recommande les tests unitaires. Je sais que cela semble probablement vieux à ce stade, mais laissez le code faire la documentation pour vous. Les tests unitaires brisés sont difficiles à ignorer (et plus faciles à repérer) qu'un document Word. De plus, la langue anglaise est horriblement imprécise pour articuler les points les plus fins de la conception de logiciels. Il existe tout simplement trop de façons d'interpréter la signification des phrases anglaises les plus simples, et cela ne fait que créer de la confusion et / ou des bugs.