Prototypage et refactoring rapides

Parfois, lorsque je démarre un petit projet (comme une application Android), je ne sais pas quelle approche fonctionnera à la fin, et je vais juste pour une approche et je l'essaie. Mais si je n'ai jamais utilisé cette approche auparavant (pour une sorte d'application que je n'ai jamais programmée auparavant), c'est comme entrer dans un terrain inconnu. Je ne sais pas quelles bibliothèques utiliser (peut-être que je dois essayer plusieurs bibliothèques) et il y a tellement de inconnus (comme: comment obtenir des données audio brutes dans Android)

Alors mon processus de développement se déroule comme suit:

• Écrivez un morceau de code pour voir si l'approche a une chance. (Plus l'approche est incertaine, plus le code est laid)
• Si cela fonctionne, refactorisez beaucoup jusqu'à ce qu'il soit beau

Je pense que cela pourrait être une perte de temps si je planifiais en détail la conception de mon logiciel à ce stade, ce serait comme planifier un voyage sans carte.

Cela fait-il partie du développement aglie? Comment gérez-vous les terrains inconnus dans le développement de logiciels?

Cela n'a rien à voir avec l'agilité, mais les gens supposent que c'est le cas parce que c'est ce qu'ils pensent être Agile; développement de poulet sans tête dans une commune hippie.

Ce que vous faites, c'est évaluer les technologies parce que vous n'en avez pas suffisamment d'expérience pour porter un jugement. C'est bien et cela ne s'arrête jamais car de nouvelles bibliothèques, frameworks, langages et plates-formes apparaissent presque quotidiennement.

Comment vous traitez l'inconnu est une très bonne question en fait et cela revient à rechercher les alternatives, à les évaluer et à en sélectionner une.

Les compétences qui ont tendance à s'associer à Agile et qui aident ici impliquent de créer du code aussi facile et sûr à refactoriser. TDD est un bon exemple. Il vous encourage à considérer votre développement en termes de résultats. "Ce code devrait produire ce résultat" qui concentre l'esprit et réduit la quantité de code qui ne contribue pas à la résolution de l'objectif.

Si vous écrivez du code suivant les principes SOLID (Acronyme), vous serez en bonne position plus tard pour remplacer une bibliothèque si vous avez fait le mauvais choix ou, comme cela arrive souvent, vous devenez trop grand pour votre choix.

C'est bien que vous posiez ce genre de question. Il y a trop de développeurs qui, pour diverses raisons, ne risquent pas de paraître "ignorants" en prenant le temps de sélectionner la bonne technologie. Faites des erreurs tôt dans le projet pas tard. L'expérimentation est la clé, pas un gaspillage, donc je pense que vous allez dans la bonne direction.

Cela fait-il partie du développement aglie? Comment gérez-vous les terrains inconnus dans le développement de logiciels?

Ce que vous avez décrit n'est pas Agile. Le développement Agile consiste davantage à promouvoir la planification adaptative, le développement évolutif et la livraison avec une approche itérative limitée dans le temps. Agile encourage une réponse rapide et flexible au changement. Ainsi, la refactorisation de votre code à mesure que le développement progresse contient des éléments de méthodologie Agile.

Traiter une partie inconnue du projet commence par rassembler les exigences connues, avec une conception de haut niveau. Une fois la plupart des composants disponibles, vous pouvez rechercher la bonne solution. Cela dit, la construction d'une petite preuve de concept avant un développement complet est l'approche que notre équipe suit.

Il existe un principe de développement logiciel appelé SOLID . D'après mon expérience, les appliquer sur des questions / problèmes est toujours un pas en avant dans l'amélioration de la base de code de votre projet.

Cela dépend du projet, si vous travaillez seul sur un petit projet, il peut être parfaitement logique d'effectuer vos recherches et enquêtes technologiques dans le cadre du développement. Et bien que ne faisant pas partie d'Agile, bien sûr, une méthodologie Agile pourrait être utilisée pour ajouter un certain contrôle à cela. Cependant, cela rend le processus très difficile à prédire / ou la boîte de temps. Cela pourrait aller bien, encore plus rapidement, si vous travaillez seul sur un petit projet qui vous appartient entièrement, laissez vos exigences évoluer au fur et à mesure que vous les apprenez. Utilisez de bons principes en cours de route et soyez cohérent et vous ne devriez pas avoir à refactoriser autant.

Au travail, nous utilisons Kanban, Scrum et des approches plus traditionnelles en cascade. Cela dépend du projet, je trouve que les développements complexes avec des exigences initiales bien définies ne sont pas les mieux adaptés à l'agilité, cependant, beaucoup seront en désaccord.

Avant de commencer à travailler même sur un projet agile (tout sauf le plus simple qui soit), nous créons de la documentation. Nous avons une maquette (si elle est axée sur l'interface utilisateur), un ensemble d'exigences et une spécification fonctionnelle.

Le développement sera invité à créer la spécification technique à partir de la spécification fonctionnelle, et au cours de ce processus, nous spécifierons la technologie et effectuerons les recherches initiales dont nous avons besoin. Ce processus me semble si important, car il donne l'occasion de voir les lacunes dans les exigences / spécifications fonctionnelles - et donne les grandes décisions technologiques à l'avance aux personnes ayant l'expérience et les connaissances du système pour prendre de telles décisions.

L'important, cependant, est que la spécification fonctionnelle pourrait être une liste de puces, et la spécification technique sera généralement un modèle, avec des puces et des orientations technologiques, peut-être seulement 3 ou 4 pages dans certains cas.

Même lors de l'exécution d'un projet agile, nous créons de la documentation:

• Toute documentation a un coût.
• Se développer contre des exigences de haut niveau mobiles et mal définies a un coût.
• L'équilibre correct avec ce qui précède dépend de votre projet, de la culture et des personnes.
• Nous documentons Juste à temps, les documents sont périmés.
• Nous documentons à peine assez / juste assez.
• Nous ne conservons ni ne mettons à jour ces documents, nous n'y mettons pas beaucoup d'efforts. Ils sont petits. Nous comptons les jeter.
• Nous résolvons les grandes inconnues telles que les décisions technologiques, les exigences floues et l'architecture dès le départ.
• Nous savons ce que nous développons avant de commencer.
• Nous faisons confiance aux développeurs pour prendre des décisions éclairées concernant la documentation et discuter de tout problème.
• Nous privilégions la communication à la documentation, en tant que telle, nous attendons de toutes les personnes impliquées qu'elles communiquent souvent.
• Nous documentons les systèmes (aperçu) après le développement, pas pendant, pas avant.

Vous voyez, il y a une petite cascade dans notre processus agile.

Si vous travaillez seul, créez un modèle initial (diagramme!) Et jouez avec et choisissez la technologie, puis lorsque vous avez ce concept des exigences de haut niveau, poursuivez et développez de manière itérative agile, mais considérez les bons principes et cohérence au fur et à mesure et vous devrez refacturer moins, plus refondre au fur et à mesure.

Mais en général, s'il y a un coût réel (pas un passe-temps), sachez ce que vous développez avant d'écrire du code, mais ne perdez pas trop de temps à écrire de la documentation qui deviendra rapidement redondante car vous changerez d'avis, et devriez changez d'avis pendant le développement à mesure que vous devenez mieux informé. Et votre projet pourrait changer de cap énormément, mais partir d'une bonne base bien définie.

C'est à peu près ainsi que je commence de nouveaux projets et cela a plutôt bien fonctionné, en supposant que nous parlons de petits projets. Par exemple, je n'irais pas dans cette voie si j'écrivais un ORM ou quelque chose de cette ampleur. Parfois, je vais recourir à des recherches plus formelles quand je suis vraiment au-dessus de ma tête. Mais pour la plupart, je commence juste à écrire du code et vois ce qui se passe. Cependant, vous devez être prêt à jeter beaucoup de code.