Comment faire les choses correctement au début d'un projet logiciel?
Je suis programmeur avec 1 an d'expérience, récemment j'ai réalisé que je démarre rarement un projet correctement (la plupart de mes projets parallèles), normalement le cycle du projet se déroule comme
- Commencez avec quelques cas d'utilisation
- Commencez à coder
- Réalisez quelques choses que je n'ai pas bien gérées et qui ne correspondent pas bien à la base de code actuelle.
- Réécrire la majeure partie du code
et cela pourrait aller plusieurs fois
Donc mes questions sont
- Une telle pratique est-elle courante ou implique-t-elle que je ne suis pas compétent?
- Comment puis-je m'améliorer sur cet aspect?
Le cycle que vous décrivez est normal. Le moyen d'améliorer les choses n'est pas d'éviter ce cycle, mais de le rationaliser. La première étape consiste à accepter que:
- Il est presque impossible de tout savoir le premier jour d'un projet.
- Même si vous savez tout d'une manière ou d'une autre, au moment où vous avez terminé le projet, alors quelque chose (les exigences du client, le marché dans lequel il se trouve, le technologie avec laquelle vous travaillez, les souhaits de leurs clients) auront changé et feront au moins partie de ce que vous saviez invalide ou incorrect.
Par conséquent, il est impossible de tout planifier à l'avance, et même si vous le pouviez, suivre ce plan vous conduirait à construire quelque chose d'imparfait ou obsolète. Sachant cela, nous intégrons le changement dans notre planification. Regardons vos étapes:
- Commencez avec quelques cas d'utilisation
- Commencez à coder
- Réalisez quelques choses que je n'ai pas bien gérées et qui ne correspondent pas bien à la base de code actuelle.
- Réécrire la majeure partie du code
C'est en fait un excellent point de départ. Voici comment je l'aborderais:
1. Commencez avec quelques cas d'utilisation
Bien. En disant "cas d'utilisation", vous vous concentrez sur ce qu'est le logiciel pour . En disant "quelques-uns", vous n'essayez pas de tout découvrir; vous vous en tenez à une quantité de travail gérable. Tout ce que j'ajouterais ici, c'est de les hiérarchiser. Avec votre client ou utilisateur final, élaborez la réponse à cette question:
Quel est le logiciel le plus petit et le plus simple que je pourrais vous offrir pour améliorer votre situation?
Ceci est votre produit minimum viable - tout ce qui est plus petit que cela n'est pas utile à votre utilisateur, mais tout ce qui est plus gros risque également de planifier beaucoup trop tôt. Obtenez suffisamment d'informations pour construire cela, puis passez à autre chose. Gardez à l'esprit que vous ne saurez pas tout à ce stade.
2. Commencez à coder.
Génial. Vous commencez à travailler dès que possible. Jusqu'à ce que vous ayez écrit du code, vos clients n'ont reçu aucun avantage. Plus vous passez de temps à planifier, plus le client passe de temps à attendre sans récupération.
Ici, j'ajouterais un rappel pour écrire un bon code . Rappelez-vous et suivez les principes solides , écrivez des tests unitaires décents autour de tout ce qui est fragile ou complexe, prenez des notes sur tout ce que vous risquez d'oublier ou qui pourrait causer des problèmes plus tard. Vous voulez structurer votre code afin que le changement ne cause pas de problèmes. Pour ce faire, chaque fois que vous décidez de construire quelque chose de cette façon au lieu de que façon, vous structurez votre code afin que le moins de code possible soit affecté par cette décision. En général, une bonne façon de procéder consiste à séparer votre code:
- utiliser des composants simples et discrets (en fonction de votre langue et de votre situation, ce composant peut être une fonction, une classe, un assembly, un module, un service, etc. Vous pouvez également avoir un grand composant construit à partir de plus petits, comme une classe avec beaucoup de fonctions, ou un assemblage avec beaucoup de classes.)
- chaque composant effectue un travail ou des travaux liés à une chose
- les changements apportés à la façon dont un composant effectue son fonctionnement interne ne devraient pas obliger d'autres composants à changer
- les composants doivent être donnés les choses dont ils utilisent ou dépendent, plutôt que aller chercher ou en les créant
- les composants doivent donner des informations aux autres composants et leur demander de faire le travail, plutôt que d'aller chercher l'information et faire le travail eux-mêmes
- les composants ne doivent pas accéder, utiliser ou dépendre du fonctionnement interne des autres composants - utilisent uniquement leurs fonctions accessibles au public
En faisant cela, vous isolez les effets d'une modification de sorte que dans la plupart des cas, vous pouvez résoudre un problème en un seul endroit et que le reste de votre code ne le remarque pas.
3. Rencontrez des problèmes ou des lacunes dans la conception.
Cela arrivera. C'est inévitable. Accepte cela. Lorsque vous rencontrez l'un de ces problèmes, décidez de quel type de problème il s'agit.
Certains problèmes sont des problèmes dans votre code ou votre conception qui font qu'il est difficile de faire ce que le logiciel doit faire. Pour ces problèmes, vous devez revenir en arrière et modifier votre conception pour résoudre le problème.
Certains problèmes sont causés par le fait de ne pas avoir suffisamment d'informations ou d'avoir quelque chose auquel vous n'aviez pas pensé auparavant. Pour ces problèmes, vous devez revenir à votre utilisateur ou client et leur demander comment ils souhaitent résoudre le problème. Lorsque vous avez la réponse, vous allez ensuite mettre à jour votre conception pour la gérer.
Dans les deux cas, vous devez faire attention aux parties de votre code qui doivent être modifiées et, au fur et à mesure que vous écrivez plus de code, vous devez penser aux parties qui devront peut-être changer à l'avenir. Cela permet de déterminer plus facilement quelles parties pourraient être trop interconnectées et quelles parties pourraient devoir être plus isolées.
4. Réécrivez une partie du code
Une fois que vous avez identifié la façon dont vous devez modifier le code, vous pouvez procéder à la modification. Si vous avez bien structuré votre code, cela impliquera généralement de ne changer qu'un seul composant, mais dans certains cas, cela peut également impliquer l'ajout de certains composants. Si vous constatez que vous devez changer beaucoup de choses dans beaucoup d'endroits, réfléchissez à pourquoi. Pourriez-vous ajouter un composant qui conserve tout ce code à l'intérieur de lui-même, puis avoir tous ces endroits simplement utiliser ce composant? Si vous le pouvez, faites-le et la prochaine fois que vous devrez modifier cette fonctionnalité, vous pourrez le faire au même endroit.
5. Test
Une cause fréquente de problèmes dans les logiciels est de ne pas bien connaître les exigences. Ce n'est souvent pas la faute des développeurs - souvent, l'utilisateur n'est pas sûr non plus de ce dont il a besoin. La manière la plus simple de résoudre ce problème consiste à inverser la question. Au lieu de demander "de quoi avez-vous besoin pour faire le logiciel?", À chaque fois que vous passez par ces étapes, donnez à l'utilisateur ce que vous avez construit jusqu'à présent et demandez-lui "J'ai construit ceci - fait-il ce dont vous avez besoin?". S'ils disent oui, alors vous avez construit quelque chose qui résout leur problème et vous pouvez arrêter de travailler! S'ils disent non, ils pourront vous dire en termes plus spécifiques ce qui ne va pas avec votre logiciel, et vous pouvez améliorer cette chose spécifique et revenir pour plus de commentaires.
6. Apprenez
Au cours de ce cycle, faites attention aux problèmes que vous rencontrez et aux changements que vous apportez. Existe-t-il des modèles? Pouvez-vous vous améliorer?
Quelques exemples:
- Si vous continuez à découvrir que vous avez négligé le point de vue d'un certain utilisateur, pourriez-vous faire en sorte que cet utilisateur soit plus impliqué dans la phase de conception?
- Si vous continuez à devoir changer des choses pour être compatible avec une technologie, pourriez-vous créer quelque chose pour interfacer entre votre code et cette technologie afin que vous n'ayez qu'à changer l'interface?
- Si l'utilisateur change constamment d'avis sur les mots, les couleurs, les images ou d'autres choses dans l'interface utilisateur, pourriez-vous créer un composant qui fournisse au reste de l'application ceux-ci afin qu'ils soient tous au même endroit?
- Si vous constatez que la plupart de vos modifications sont dans le même composant, êtes-vous sûr que ce composant se limite à un seul travail? Pourriez-vous le diviser en quelques morceaux plus petits? Pouvez-vous modifier ce composant sans avoir à en toucher d'autres?
Soyez agile
Vous vous dirigez vers un style de travail connu sous le nom d'Agile. Agile n'est pas une méthodologie, c'est une famille de méthodologies intégrant un tas de choses (Scrum, XP, Kanban, pour n'en nommer que quelques-unes), mais ce qu'elles ont toutes en commun, c'est l'idée que les choses changent, et en tant que développeurs de logiciels, nous devrait prévoir de s'adapter aux changements plutôt que de les éviter ou de les ignorer. Certains de ses principes fondamentaux - en particulier ceux qui sont pertinents pour votre situation - sont les suivants:
- Ne planifiez pas plus loin que vous ne pouvez le prévoir en toute confiance
- Faites en sorte que les choses changent au fur et à mesure
- Plutôt que de construire quelque chose de grand en une seule fois, construisez quelque chose de petit, puis améliorez-le progressivement
- Gardez l'utilisateur final impliqué dans le processus et obtenez des commentaires rapides et réguliers
- Examinez votre propre travail et vos progrès et apprenez de vos erreurs
C'est normal.
Vous pouvez adopter l'une des deux approches:
- Changement de bienvenue
Si vous supposez que vous vous tromperez, vous devez créer une base de code ouverte à modification. Généralement, cela implique de prendre le code à la fin d'un livre sur la refactorisation, et de construire votre code de cette façon dès le début (décomposabilité, bonne couverture des tests, ...).
- Évitez le changement
Dans ce cas, vous devez faire un BDUF (grand design à l'avant). Vous devez faire beaucoup de prototypage papier, discuter d'idées avec des utilisateurs potentiels ou vous-même en esquivant, en essayant diverses choses dans des prototypes ou des maquettes, en écrivant une spécification complète, et seulement une fois que vous sentez que vous avez cloué la solution, puis finalement vous peut commencer à coder. Faire tout ce qui ne se débarrasse pas réellement des changements inattendus, cela les réduit juste un peu, la première année environ. Donc, vous devez encore construire votre code pour qu'il soit facile à modifier.
Donc, fondamentalement, le changement est une donnée. Supposons que cela se produise. Créez votre code en conséquence. Dans la pratique, vous pouvez trouver un juste milieu entre les approches de conception initiale et de codage juste au début qui évite les changements gratuits sans rester coincé dans la paralysie de l'analyse. Cela prend juste un peu d'expérience.
Le développement logiciel a été décrit comme une série de problèmes intrinsèquement "mauvais" .
Horst Rittel et Melvin Webber ont défini un problème "méchant" comme un problème qui ne pouvait être clairement défini qu'en le résolvant ou en en résolvant une partie *. Ce paradoxe implique, essentiellement, que vous devez "résoudre" le problème une fois afin de le définir clairement, puis le résoudre à nouveau pour créer une solution qui fonctionne. Ce processus a été la maternité et Apple tarte dans le développement de logiciels depuis des décennies
Cela décrit parfaitement le problème auquel vous êtes confronté. Fondamentalement, ce que nous faisons est difficile . S'il existe une pièce qui pourrait être qualifiée de "routine", au fil du temps, nous l'isolons et l'automatisons. Il ne reste donc que le nouveau ou le difficile.
Il existe d'autres façons de surmonter des problèmes comme celui-ci; certaines personnes passent beaucoup de temps à considérer les problèmes à l'avance et à ne pas écrire de code tant qu'elles ne sont pas à l'aise avec la conception. D'autres cherchent des conseils auprès de personnes qui ont déjà traité des problèmes comme celui-ci, soit via la programmation en binôme, soit uniquement sur des sites comme celui-ci.
Mais votre approche ne suggère certainement pas l'incompétence. Le seul problème pourrait être si, lorsque vous revenez en arrière, vous ne réfléchissez pas à la raison pour laquelle vous avez choisi de faire des choses de cette façon pour commencer, et si vous auriez pu voir la "meilleure" manière sans récrire.
Dans de nombreux cas, il y en avait, et vous pouvez l'intégrer dans votre processus de conception pour la prochaine fois. Dans certains cas, il n'y en avait pas (ou le coût aurait été aussi élevé ou plus élevé que le coût de votre autre approche), et vous pouvez simplement laisser votre inquiétude disparaître.
- Oui, c'est courant, sauf peut-être pour la partie "réécriture la plupart du code". Vous n'aurez jamais toutes les exigences dès le début, il est donc important de bien gérer le changement. C'est à cela que sert le concept de "maintenabilité du code". Bien sûr, cela aide également à consacrer plus de temps à la définition des exigences et à la conception.
- Réfléchissez d'abord aux changements qui étaient nécessaires dans les projets antérieurs et à la façon dont vous auriez pu les prévoir ou mieux vous y préparer. Au début d'un projet, réfléchissez davantage aux détails des cas d'utilisation. Faites une conception abstraite (quels sont les principaux composants du code et comment communiquent-ils, quelles sont leurs API) avant de commencer la mise en œuvre. Plus important encore, essayez de garder le code aussi simple et facile à modifier que possible, lisez des concepts tels que SOLID, DRY, KISS et YAGNI.
Une telle pratique est-elle courante ou implique-t-elle que je ne suis pas compétent?
Ce ne sont pas mutuellement exclusifs. Le schéma peut être courant et vous pouvez toujours être incompétent. Votre compétence peut être déterminée en mesurant votre performance par rapport à vos objectifs. Réalisez-vous vos objectifs?
Ce schéma est-il courant? Malheureusement oui. De nombreuses personnes se lancent dans des projets sans avoir une idée claire du problème qu'ils résolvent, de la manière dont ils vont concevoir une solution correcte et des mesures qui constitueront le succès.
Comment puis-je m'améliorer sur cet aspect?
Si vous décidiez d'aller quelque part et que vous commenciez à marcher, puis découvriez un jour que ce que vous deviez vraiment faire était de transporter un éléphant du Cap à New York, tout ce temps que vous passiez à marcher était gaspillé. Découvrez ce que vous faites avant de commencer.
Une fois que vous commencez à le faire, considérez: à quoi ressemble le code qui n'a pas besoin d'être réécrit? Ce code:
- Fait une chose utile.
- Le fait correctement.
- Le fait avec des performances suffisantes.
Donc: plus vous écrivez de code là où ce code fait bien une chose utile, correctement, avec de bonnes performances, moins vous devrez réécrire de code.
Je pense qu'il est prudent de dire que vous n'êtes pas si loin d'une meilleure façon de travailler et que vous n'êtes pas le seul sur ce bateau.
Ce que je pense que vous manquez, c'est que, même si vous déterminez quoi vous voulez, vous ne vous arrêtez pas de faire le même processus pour comment vous le ferez.
Cette étape d'arrêt et de réflexion sur la façon d'aborder le problème dans son ensemble est appelée conception, c'est l'étape qui vous fait passer un peu de temps à développer la structure ou l'architecture du système afin que tout ce que vous faites à partir d'eux contribue à la solution finale, comme insérer des pièces dans un puzzle une fois que vous avez travaillé les bords.
Beaucoup de gens ne font pas cette étape, mais quand j'ai commencé à coder, c'était obligatoire. Je pense que la différence réside dans les outils de développement - alors que j'ai commencé avec un éditeur de texte, vous disposez désormais de toutes sortes de fonctionnalités qui vous permettent d'intervenir et de taper.
Alors, prenez un peu de temps pour comprendre les grands domaines, les composants et l'interopérabilité entre eux, et définir les objets qui composeront votre solution avant de commencer à coder. Cela ne doit pas être dans les moindres détails, et comprenez que vous ne l'obtiendrez pas parfaitement au début, donc cela évoluera avec le temps, mais ce que cela fait est de vous aider à vous empêcher de gaspiller vos efforts à revoir des choses qui ne devraient pas Il faut beaucoup changer.
Je voudrais ajouter quelques pointeurs
1) Personnellement, j'ai trouvé incroyablement utile de commencer avec visualisation des trucs. Dessinez des boîtes, des flèches, des lignes ... Peu importe le langage de modélisation que vous utilisez. En premier lieu, vous le faites POUR VOUS-MÊME. Cela devrait aider votre flux de pensées.
2) Trouvez un sparring partner - prenez un café et le tableau à feuilles mobiles/diagramme etc. d'en haut et allez en ville. À mon humble avis, c'est encore mieux si vous n'avez pas les compétences techniques correspondantes. Vous faites rebondir les idées pour la mise en œuvre du cas d'utilisation. Vous trouvez une ou deux impasses - vous trouvez une solution. Avec un esprit agile, il y a souvent moins de temps passé à cette étape que si vous écrivez du code, cela ne fonctionne pas et vous devez tuer des morceaux de votre travail ou les refaire
3) Trouvez un patron qui peut comprendre que vous avez probablement jamais terminé d'améliorer votre logiciel écrit. Si vous branchez toujours de nouvelles fonctionnalités/exigences qui sont déversées sur votre bureau et jamais soins pour votre logiciel, il vous réprimandera avec des bugs, une maintenance peu conviviale et beaucoup de cheveux tirant quelques années en bas de la ligne. Obtenez ce temps/budget de maintenance logicielle alloué! Un bon chiffre magique rond représente environ 20% du temps nécessaire au développement du logiciel par an pour le maintenir en forme au cours de sa durée de vie.
4) Ce processus d'apprentissage incrémental ne s'arrête jamais (et ne devrait pas)! Vous regarderez en arrière dans 10 ans et vous sourirez.
J'espère que cela aide un tout petit peu et bonne chance!
Vous avez déjà d'excellentes réponses, mais votre question me rappelle certaines choses que je pensais essayer de toucher.
Comme vous l'avez remarqué en cours de changements, je suggérerais de réfléchir à l'impact des choses sur votre projet et à la façon dont vous auriez pu minimiser l'impact avec des choix de conception/codage tout en générant une carte mentale de l'endroit où les gens apportent souvent des modifications tardives. Avec l'expérience, vous pouvez anticiper et coder avec une certaine flexibilité pour les choses que vous savez être importantes - bien qu'il y ait un désaccord sur ce concept dans l'industrie car certains vous contreront, vous investissez des efforts dans un domaine non spécifiquement demandé, en soi .
Sur le front des tests, lancer un prototype pour la partie prenante de votre projet peut être un excellent moyen d'affiner les exigences. Cependant, au cours du développement, vous pouvez rechercher des moyens de "voir" ce qui se passe dans votre code sans causer beaucoup d'encombrement ou de complexité. Il existe certainement des outils pour vous aider, mais vous pouvez aussi faire beaucoup sans eux si vous le souhaitez. Dans les deux cas, sortir du code pour regarder ce qui se passe avec un œil critique peut fournir différents types d'informations.
Recherchez des activités courantes. Vous allez vous retrouver à gérer les mêmes problèmes encore et encore. Après un certain temps, vous devriez découvrir les lacunes ou les compromis de divers choix et vous concentrer sur une méthodologie qui vous aide à les éviter. Bien sûr, si vous travaillez dans un cadre, certains de ces problèmes peuvent être intégrés dans les outils que vous utilisez déjà.
Si vous travaillez dans un cadre, passez du temps, si vous pouvez le ménager, à réfléchir à la façon de faire les choses à partir de zéro. Par exemple, vous pouvez facilement assembler un message de demande, ouvrir un socket et émettre une demande GET ou POST manuellement. Si vous le souhaitez, vous pouvez analyser manuellement les messages XML. Quoi que vous fassiez, les questions que vous générez et les réponses que vous trouverez augmenteront vos compétences. Bien sûr, vous pouvez choisir quels types de problèmes sous-jacents sont importants ou intéressants. Je considérerais ce développement personnel et je ne m'attends pas à passer beaucoup de temps sur l'horloge ici.
Les balles d'argent, les méthodologies et les problèmes de facteur de buzz élevé sont partout. Fondamentalement, les réalités sous-jacentes de l'utilisation des informations ne changent pas aussi rapidement. Notez si le cadre, l'ensemble d'outils ou la méthodologie en place est une aide ou un obstacle dans diverses situations. Dans les grandes entreprises, j'ai vu beaucoup de méthodologies tentées, mais l'entreprise n'était pas en mesure de les exécuter efficacement. Tout comme les frameworks, les méthodologies ne sont pas un moyen sûr de fonctionner à un niveau élevé même si elles sont basées sur les pratiques de certaines équipes hautement fonctionnelles.
Il est difficile de résumer l'expérience et de la rendre accessible. Je suppose qu'un moyen court de mettre tout cela est de garder les yeux ouverts, de penser à ce que vous voyez et de ne jamais arrêter d'apprendre.