Quel est le sous-ensemble minimal de pratiques les meilleures / les plus connues en développement logiciel pour un programmeur solo? [fermé]

Je suis le programmeur solitaire de mon travail depuis assez longtemps. Habituellement, j'ai lu des articles et des articles sur

• Systèmes de contrôle de version
• Intégration / livraison continue
• Méthodologies de développement: Scrum, Waterfall, V-Model, Agile, XP, etc.
• Gestion de projet logiciel

Mais presque tous semblent se concentrer sur les ÉQUIPES. Je ne suis pas une équipe, alors quel serait l'ensemble de pratiques absolument minimum pour un seul programmeur? Tenez compte des conditions suivantes:

• Je n'ai pas de conflits avec le code des autres personnes.
• Je n'ai pas besoin de maintenir des arborescences de fichiers / répertoires, mon environnement de développement se soucie du versioning par lui-même (développement basé sur l'image).
• Il n'y a pas d'exigences formelles, mes utilisateurs ne savent pas ce qu'ils veulent et ils sont d'accord avec ça.
• Le seul qui pourrait être intéressé à fournir une version ou une documentation, c'est moi, essentiellement le client veut des RÉSULTATS et ne se soucie pas des méthodologies logicielles, etc.

À mon avis, je ne veux pas consacrer (trop) de temps et d'énergie à tout ce qui n'est pas directement lié aux besoins des clients. Des recommandations?

Il n'y a pas de bonne réponse à cette question car cela dépend de chaque personne. Si vous utilisez un iPad pour faire tout votre travail de développement et que vos clients sont satisfaits de vous, vous n'avez aucune raison de changer du tout.

Si, toutefois, j'étais à votre place, j'appliquerais fortement ce qui suit:

• Un système de contrôle de version - Bien que vous puissiez penser qu'un système de développement basé sur l'image fait le travail concernant les sauvegardes régulières et ainsi de suite, vous n'avez aucune marge de manœuvre pour les fonctionnalités expérimentales où l'on utiliserait normalement une branche . Vous n'avez également aucun moyen de conserver une version importante du projet ( balisage ). Si vous vous développez au-delà de vous-même, les développeurs qui se joindront penseront qu'ils sont en enfer.
• Agile - Cette méthode est extrêmement applicable aux clients qui ne savent pas ce qu'ils veulent. Tôt ou tard, ils se rendront compte qu'ils ne veulent pas dépenser de l'argent pour chasser leur queue - ils voudront voir des progrès.
• Outil de gestion de projet - C'est un must. C'est très formidable de pouvoir tout garder en tête, mais ce n'est pas obligatoire. Être discipliné et utiliser un outil de gestion de projet (par exemple Redmine ) vous permettra de séparer vos tâches et vous donnera un historique facile à parcourir de votre travail. Ce sera très important lorsque vous commencerez à charger à l'heure.

Le contrôle de version est un must absolu pour tout programmeur, même seul. Cela signifie que vous pouvez récupérer simplement et rapidement des fichiers supprimés et des modifications complexes qui sont tout simplement erronées.

Fondamentalement, cela vous sauve de la merde stupide que vous faites lorsque vous allez travailler avec la gueule de bois.

Comme d'autres le disent, le contrôle de version ou la gestion du code source est extrêmement important. Utilisez un DVCS et apprenez tout à ce sujet. Peu importe celui-là, bien qu'il puisse vous être avantageux si vous en choisissez un populaire: git ou mercurial.

Une autre chose que je n'ai pas vue mentionnée, c'est un script de construction en une étape . Ce n'est pas une intégration continue directe (cette phrase est sujette à BS à mon avis), mais un outil très utile. Chaque fois que vous devez effectuer une mise à jour d'urgence, vous pouvez simplement exécuter le script et en finir avec lui. À l'approche de la fin du projet, il arrive également que plusieurs builds soient nécessaires par jour. D'après mon expérience, cela rapporte beaucoup, même si le processus de construction n'est pas trop compliqué. Vous pouvez même ajouter des capacités de téléchargement ftp, des rapports par e-mail, exécuter des tests unitaires, construire des installateurs, signer etc.

Je vais juste répondre à une, le contrôle de version est extrêmement important pour tout projet et pas seulement pour les équipes. Cela prend très peu de temps supplémentaire lorsque vous l'utilisez, mais il fournit une riche histoire pour vous replier, ce n'est pas une solution miracle, mais c'est certainement agréable de pouvoir revenir à une copie de travail si cela vraiment fonction expérimentale a cassé la plupart de l'application.

Le contrôle de version est un must absolu. Non seulement à cause du maintien de la source correcte, mais à cause de l'archéologie de la source. Un an après avoir pu vérifier comment une classe ou une procédure a évolué pourrait économiser beaucoup de peine si vous essayez de «corriger» un morceau de code bizarre.

Pour les méthodologies - je recommande fortement le manifeste des programmeurs . Cela donne généralement d'excellents résultats dans de petites équipes en raison de zéro surcharge et de ne pas avoir à garder à l'esprit le fonctionnement des cadres de conteneurs d'applications de service Web CMS basés sur des rôles MVC compatibles JSR compatibles avec les portlets J2EE .