Je travaille avec des concepts de programmation extrême de base depuis deux semaines, pour un jeu d'arcade multijoueur à petite échelle et à but lucratif. J'ai passé une semaine à développer des user stories et à déterminer les exigences pour créer un plan de release. J'ai également passé une semaine à coder et à appliquer le premier plan d'itération que j'ai trouvé. J'ai identifié quelques-uns des concepts évidemment utiles pour un seul développeur.
- Intégration continue
- Ne jamais ajouter de fonctionnalité tôt
- Développement piloté par les tests
- Choisissez une métaphore du système
- Utilisez un seul point d'intégration
- Testez tous les bugs
- Refaçonner constamment
- Établissez un rythme durable
- Simplicité
- Versions fréquentes
Je suis curieux de savoir si je manque quelque chose en particulier qui pourrait convenir à travailler avec un seul projet de développeur?
De plus, dans cette optique, étant donné l'idée de simplicité et de développement piloté par les tests, est-il préférable d'utiliser des plates-formes établies, riches en fonctionnalités et prêtes à l'emploi?
Ou devrais-je travailler de fond en comble, lorsque cela est possible, pour éviter de rencontrer les problèmes présentés avec des règles telles que la refactorisation constante et l'ajout de fonctionnalités au début?
la source
Réponses:
En fin de compte, la programmation extrême concerne un ensemble de pratiques et de méthodologies qui conduisent à une valeur commerciale améliorée. La meilleure illustration de cela que j'ai trouvée est de http://c2.com/cgi/wiki?ExtremeProgrammingEnablingChart
Tout en bleu fait partie du noyau de XP.
Il y a des parties à l'extérieur qui aident à activer les choses dans la zone bleue et font partie de XP dans son ensemble, mais ne sont pas critiques pour elle. Notez que je ne suis personnellement pas un pratiquant XP et j'ai lu pas mal de critiques à l'encontre des gens qui suivent "presque" XP et que diverses personnes ont dit que ce n'est pas XP. Laissons de côté cet aspect du dogme de XP et regardons ce que nous avons.
Sachez que l'une des premières et pour la plupart des choses est d'avoir un engagement envers le processus de la part du client. Un élément clé de XP est l'implication des clients. Cela apparaît dans un certain nombre de points tels que la planification des versions, les petites versions, l'évaluation des clients hors site. Ce sont des choses auxquelles vos clients devront s'abonner si vous voulez réussir à XP en tant que développeur solo. S'ils demandent à la place une conception, puis une période de développement, puis des tests et autres, vous n'aurez pas l'engagement d'eux pour aller plus loin.
XP ne signifie pas aucune planification. Il y a plusieurs points dans ce domaine où la planification en fait partie - la priorisation, l'estimation de la user story, la planification des itérations et la définition des tâches. Même si vous êtes un développeur à ce sujet, ce sont des choses dont vous aurez besoin pour travailler avec votre client sur la livraison.
Des points tels que la propriété collective du code et la programmation par paires sont des choses qui en impliquent plus d'un. Décider de choses telles que les normes de codage est beaucoup plus facile, mais cela ne signifie pas que vous n'avez pas à les suivre. La propriété collective de code s'applique toujours - c'est juste que la propriété est également le prochain développeur - n'écrivez pas de code qui est pour vous et pour vous seul. Notez que cela est en quelque sorte en conflit avec le `` code révèle toute intention '' qui est activé par la programmation par paire - vous n'avez pas cette personne pour vérifier que vous écrivez du code maintenable, donc la documentation du code est également essentielle.
En dehors de ces mises en garde, de nombreux principes de conception XP s'appliquent toujours. Des choses telles que la première conception de test, l'intégration continue, les réunions avec le client, la refactorisation, YAGNI, les solutions de pointe - ces appels peuvent être effectués en solo.
Sachez que l'XP solo prend autant ou plus de discipline que l'XP ordinaire. XP est souvent considéré comme une méthodologie de haute discipline en ce qu'il oblige les gens à maintenir une adhésion rigoureuse aux meilleures pratiques qu'il essaie d'incarner. Lorsque vous n'avez pas d'entraîneur ou d'autres personnes pour soutenir la discipline dont vous avez besoin, cela peut se transformer en un méli-mélo de pratiques qui ressemblent à XP.
Lecture connexe:
Je voudrais extraire une citation du premier des liens c2:
la source