Je suis programmeur avec 1 an d’expérience, j’ai réalisé récemment que je commence rarement un projet correctement (la plupart de mes projets parallèles), normalement le cycle du projet se passe comme suit

1. Commencez avec quelques cas d'utilisation
2. Commencer à coder
3. Réalisez quelques choses que je n’ai pas bien manipulées et qui ne s’intègrent pas bien dans le code actuel.
4. Réécrire la majeure partie du code

et cela pourrait aller plusieurs fois

Donc mes questions sont

1. Cette pratique est-elle courante ou implique-t-elle que je ne suis pas compétent?
2. Comment puis-je m'améliorer sur cet aspect?

Le cycle que vous décrivez est normal. La façon d'améliorer les choses ne consiste pas à éviter ce cycle, mais à le rationaliser. La première étape consiste à accepter que:

1. Il est presque impossible de tout savoir le premier jour d'un projet.
2. Même si vous savez tout, à la fin du projet, quelque chose (les exigences du client, son marché, la technologie avec laquelle vous travaillez, les souhaits de ses clients) aura changé et sera pris en compte à au moins une 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 d'obsolète. Sachant cela, nous intégrons le changement dans notre planification. Regardons vos pas:

1. Commencez avec quelques cas d'utilisation
2. Commencer à coder
3. Réalisez quelques choses que je n’ai pas bien manipulées et qui ne s’intègrent pas bien dans le code actuel.
4. Réécrire la majeure partie du code

C'est en fait un excellent point de départ. Voici comment je l'aborderais:

1. Commencez par quelques cas d'utilisation

Bien. En disant « cas d'utilisation », vous vous concentrez sur ce que le logiciel est pour . En disant "quelques", 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, trouvez la réponse à cette question:

Quel est le logiciel le plus petit et le plus simple que je pourrais vous proposer pour améliorer votre situation?

Il s'agit de votre produit minimum viable - une solution plus petite ne vous sera d'aucune aide, mais une solution plus grosse risque de trop planifier trop tôt. Obtenez assez d'informations pour construire cela, puis passez à autre chose. Soyez conscient que vous ne saurez pas tout à ce stade.

2. Commencez à coder.

Génial. Vous commencez à travailler dès que possible. Jusqu'à ce que vous écriviez du code, vos clients n'ont reçu aucun avantage. Plus vous passez de temps à planifier, plus le client a passé longtemps à attendre sans aucun remboursement.

Ici, je voudrais ajouter un rappel pour écrire un bon code. Rappelez-vous et suivez les principes SOLID , é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 ultérieurement causer des problèmes. Vous souhaitez structurer votre code afin que les modifications ne causent pas de problèmes. Pour ce faire, chaque fois que vous prenez la décision de créer quelque chose de cette façon plutôt que de cette façon, vous structurez votre code de sorte que le moins de code possible soit affecté par cette décision. En général, un bon moyen de le faire est de séparer votre code:

• utilisez des composants simples et discrets (en fonction de votre langue et de votre situation, ce composant peut être une fonction, une classe, un assemblage, un module, un service, etc. une classe avec beaucoup de fonctions ou un assemblage avec beaucoup de classes)
• chaque composant effectue un travail ou des travaux relatifs à une chose
• les changements apportés à la manière dont un composant effectue son fonctionnement interne ne devraient pas entraîner le changement d'autres composants
• composants doivent être donnés choses qu'ils utilisent ou dépendent, plutôt que de chercher de ou créer les
• les composants doivent donner des informations aux autres composants et leur demander de faire le travail, plutôt que de chercher des informations et de faire le travail eux-mêmes
• les composants ne doivent pas accéder, utiliser ou dépendre du fonctionnement interne des autres composants - utilisez uniquement leurs fonctions accessibles au public

En procédant ainsi, vous isolez les effets d'une modification afin que, dans la plupart des cas, vous puissiez résoudre un problème à un endroit donné et que le reste de votre code ne le remarque pas.

3. Rencontrer des problèmes ou des lacunes dans la conception.

Cela va arriver. C'est inévitable. Accepte cela. Lorsque vous rencontrez l'un de ces problèmes, décidez quel type de problème il s'agit.

Certains problèmes de votre code ou de votre conception compliquent la tâche du logiciel. 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 manque d'informations ou par quelque chose auquel vous n'aviez pas pensé auparavant. Pour ces problèmes, vous devez contacter votre utilisateur ou client et lui demander comment il souhaite résoudre le problème. Lorsque vous avez la réponse, vous devez alors mettre à jour votre conception pour la gérer.

Dans les deux cas, vous devriez être attentif aux parties de votre code qui ont dû être modifiées et au fur et à mesure que vous écrivez plus de code, vous devriez penser aux parties qui devront éventuellement être modifiées à l'avenir. Il est ainsi plus facile de déterminer quelles parties pourraient être trop interconnectées et quelles parties pourraient nécessiter une plus grande isolation.

4. Réécrire une partie du code

Une fois que vous avez identifié la manière dont vous devez modifier le code, vous pouvez procéder au changement. Si vous avez bien structuré votre code, il ne faudra généralement modifier qu'un seul composant, mais dans certains cas, cela peut également nécessiter l'ajout de certains composants. Si vous constatez que vous devez changer beaucoup de choses dans de nombreux endroits, réfléchissez à la raison. Pourriez-vous ajouter un composant qui conserve l'intégralité de ce code, puis que tous ces emplacements utilisent simplement ce composant? Si vous le pouvez, faites-le, et la prochaine fois que vous devrez modifier cette fonctionnalité, vous pourrez le faire à un endroit.

5. Test

Une cause fréquente de problèmes dans le logiciel est la connaissance insuffisante des exigences. Ce n'est souvent pas la faute des développeurs - souvent, l'utilisateur n'est pas sûr de ce dont il a besoin. Le moyen le plus simple de résoudre ce problème consiste à inverser la question. Au lieu de demander "que devez-vous faire par le logiciel?", Chaque fois que vous suivez ces étapes, donnez à l'utilisateur ce que vous avez construit jusqu'à présent et demandez-lui "J'ai construit ceci - est-ce qu'il fait ce qu'il vous faut?". 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 refusent, ils pourront vous dire plus précisément ce qui ne va pas avec votre logiciel, et vous pouvez aller améliorer cette chose en particulier et revenir pour plus de commentaires.

6. apprendre

Tout au long de ce cycle, faites attention aux problèmes que vous rencontrez et aux changements que vous apportez. Y a-t-il des modèles? Pouvez-vous améliorer?

Quelques exemples:

• Si vous continuez de constater que vous avez négligé le point de vue d'un utilisateur donné, pouvez-vous le faire participer davantage à la phase de conception?
• Si vous continuez à avoir à changer des choses pour être compatibles avec une technologie, pourriez-vous créer quelque chose d'interface entre votre code et cette technologie afin que vous n'ayez qu'à changer d'interface?
• Si l'utilisateur change constamment d'avis sur les mots, les couleurs, les images ou d'autres éléments de l'interface utilisateur, pouvez-vous créer un composant qui fournisse au reste de l'application celles-ci de manière à ce qu'elles soient toutes au même endroit?
• Si vous constatez que bon nombre de vos modifications concernent le même composant, êtes-vous certain que ce composant ne concerne qu'un seul travail? Pourriez-vous le diviser en quelques morceaux plus petits? Pouvez-vous changer ce composant sans avoir à en toucher d'autres?

Être agile

Vous vous dirigez vers un style de travail appelé Agile. Agile n’est pas une méthodologie, c’est une famille de méthodologies incorporant une foule de choses (Scrum, XP, Kanban, pour n'en nommer que quelques-unes), mais ce qu’elles ont en commun, c’est l’idée que les choses changent et que nous, développeurs 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 ce que vous pouvez prédire avec confiance
• Faites en sorte que les choses changent au fur et à mesure
• Plutôt que de construire en même temps quelque chose de grand, construisez quelque chose de petit, puis améliorez-le progressivement
• Impliquez l'utilisateur final dans le processus et obtenez des commentaires rapides et réguliers
• Examinez votre propre travail et vos progrès et tirez les leçons de vos erreurs

C'est normal.

Vous pouvez adopter l'une des deux approches suivantes:

1. Bienvenue changement

Si vous présumez que vous vous tromperez, vous devez créer une base de code ouverte au changement. Cela implique principalement de prendre le code à la fin d'un livre sur le refactoring et de le construire de cette manière dès le début (décomposabilité, bonne couverture de test, ...).

2. Éviter le changement

Dans ce cas, vous devez faire un BDUF (gros design à l’avant). Vous devez faire beaucoup de prototypage sur papier, discuter d'idées avec des utilisateurs potentiels ou vous-même en esquivant du doigt, essayer diverses choses dans des prototypes ou des maquettes, rédiger un cahier des charges complet, et seulement une fois que vous avez l'impression d'avoir trouvé la solution, puis finalement peut commencer à coder. Faire tout ce qui ne supprime pas réellement les changements inattendus, cela les réduit un peu, la première année environ. Donc, vous devez toujours construire votre code pour pouvoir le changer facilement.

Donc, fondamentalement, le changement est une donnée. Supposons que cela va arriver. Construisez votre code en conséquence. En pratique, vous pouvez trouver un juste milieu entre les approches de conception initiale et de codage juste pour commencer, qui évite les modifications gratuites 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 "méchants" .

Horst Rittel et Melvin Webber ont défini un problème "pervers" comme un problème qui ne pouvait être clairement défini que par sa résolution ou par la résolution d'une partie de celui-ci *. Ce paradoxe implique essentiellement que vous deviez "résoudre" le problème une fois pour le définir clairement, puis le résoudre à nouveau pour créer une solution qui fonctionne. Ce processus a été la maternité et la tarte aux pommes dans le développement de logiciels pendant des décennies

Cela décrit parfaitement le problème auquel vous êtes confronté. Fondamentalement, ce que nous faisons est difficile . Si une partie peut être qualifiée de "routine", nous l'isolons et l'automatisons avec le temps. Il ne reste donc que le nouveau ou le difficile.

Il existe d'autres moyens de surmonter des problèmes comme celui-ci; Certaines personnes passent beaucoup de temps à examiner les problèmes à l'avance et à ne pas écrire de code tant qu'elles ne sont pas à l'aise avec la conception. D'autres demandent conseil à des personnes qui ont déjà traité de tels problèmes, via une programmation en binôme ou simplement des sites comme celui-ci.

Mais votre approche ne suggère certainement pas d'incompétence. Le seul problème pourrait être que si vous reveniez au début, vous ne réfléchissiez pas sur la raison pour laquelle vous aviez choisi de faire les choses de cette façon, et si vous auriez pu voir la "meilleure" façon sans le récrire.

Dans de nombreux cas, il y en avait et vous pouvez l'intégrer à votre processus de conception pour la prochaine fois. Dans certains cas, il n'y en avait pas (ou le coût aurait été égal ou supérieur au coût de votre autre approche), et vous pouvez simplement laisser aller votre préoccupation.

1. Oui, c'est courant, sauf peut-être pour la partie "réécrire la majeure partie du code". Vous ne rencontrerez jamais toutes les conditions requises dès le début, il est donc important de bien gérer les changements. C'est la notion de "maintenabilité du code". Bien entendu, il est également utile de consacrer plus de temps à la définition des exigences et à la conception.
2. En premier lieu, réfléchissez aux changements nécessaires dans les projets antérieurs et à la manière dont vous auriez pu mieux les prévoir ou les 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 composants principaux du code et comment communiquent-ils, quelles sont leurs API) avant de commencer à implémenter. 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.

Cette pratique est-elle courante ou implique-t-elle que je ne suis pas compétent?

Ceux-ci ne sont pas mutuellement exclusifs. Le modèle pourrait être commun, et vous pourriez toujours être incompétent. Votre compétence peut être déterminée en mesurant votre performance par rapport à vos objectifs. Êtes-vous en train d'atteindre vos objectifs?

Ce modèle est-il commun? Malheureusement oui. De nombreuses personnes se lancent dans des projets sans avoir une idée précise du problème qu’elles résolvent, de la façon dont elles élaboreront une solution correcte et des paramètres qui constitueront un succès.

Comment puis-je m'améliorer sur cet aspect?

Si vous décidiez d'aller quelque part et que vous commenciez tout juste à marcher, puis que vous découvriez un jour où vous deviez vraiment transporter un éléphant du Cap à New York, tout le temps que vous passiez à marcher était perdu. Déterminez ce que vous faites avant de commencer.

Une fois que vous avez commencé à le faire, considérez: à quoi ressemble un code qui n’a pas à être réécrit ? Ce code:

• Fait une chose utile.
• Est-ce correctement.
• Le fait avec des performances suffisantes.

Ainsi: plus vous écrivez de code là où ce code est utile, correctement, avec de bonnes performances, moins vous aurez de code à réécrire.

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 à bord de ce bateau.

Ce que je pense que vous êtes absent est que, bien que vous déterminez ce que vous voulez, vous ne vous arrêtez pas faire le même processus pour la façon dont vous le faites.

Cette étape d’arrêt et de réflexion sur la façon de traiter le problème dans son ensemble s’appelle conception, c’est l’étape qui vous oblige à consacrer du temps au développement de la structure ou de l’architecture du système, de sorte que tout ce que vous en faites contribue à la solution finale, comme insérer des pièces dans un puzzle une fois que vous avez défini 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’avais commencé avec un éditeur de texte, vous disposez maintenant de toutes sortes de fonctionnalités qui vous permettent d’intervenir et de taper à l’écran.

Alors, prenez un peu de temps pour comprendre les vastes domaines, les composants et l’interopérabilité entre eux, et définissez les objets qui composeront votre solution avant de commencer à coder. Il n'est pas nécessaire que les détails soient immenses et que vous compreniez que vous ne l'obtiendrez pas parfaitement au début. Cela évoluera avec le temps, mais cela vous aidera à ne pas gaspiller vos efforts en revoyant des choses qui ne devraient pas. Pas besoin de changer beaucoup.

Vous avez déjà d’excellentes réponses, mais votre question rappelle quelques points que je pensais pouvoir aborder.

1. Lorsque vous avez noté des changements sur la route, je suggérerais de réfléchir à l'impact de votre projet sur la manière dont vous auriez pu minimiser l'impact des choix de conception / codage tout en générant une carte mentale de l'endroit où les personnes apportent souvent des modifications tardives. Avec l'expérience, vous pouvez anticiper et prévoir une certaine flexibilité pour des choses qui, à votre avis, seront importantes - bien qu'il existe un désaccord sur ce concept au sein de l'industrie, car certaines personnes vont vous empêcher d'investir dans un domaine qui n'est pas spécifiquement demandé. .

2. L'un des fronts des tests: lancer un prototype pour les parties prenantes 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 de fouillis ou de complexité. Il existe certes des outils pour vous aider, mais vous pouvez également en faire beaucoup si vous le souhaitez. Quoi qu'il en soit, sortir du code pour regarder ce qui se passe avec un œil critique peut fournir divers types d'informations.

3. Rechercher des activités communes. 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, certaines de ces questions peuvent être résumées dans les outils que vous utilisez déjà.

4. Si vous travaillez dans un cadre, prenez le temps, si vous le permettez, d’examiner comment faire les choses à partir de zéro. Par exemple, vous pouvez facilement assembler un message de requête, ouvrir un socket et émettre une requête 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 développeront vos compétences. Bien entendu, vous devez choisir les types de problèmes sous-jacents importants ou d’intérêt. Je considérerais ce développement personnel et ne m'attendrais pas à passer beaucoup de temps ici.

5. Les balles d'argent, les méthodologies et les problèmes de facteurs de bourdonnement élevés sont partout. Fondamentalement, les réalités sous-jacentes du travail avec l'information ne changent pas aussi rapidement. Notez si le cadre, les outils ou la méthodologie en place est une aide ou un obstacle dans diverses situations. Dans les grandes entreprises, de nombreuses méthodologies ont été tentées, bien que la société n’ait pas été 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 pense qu'un moyen simple de résumer tout cela est de garder les yeux ouverts, de penser à ce que vous voyez et de ne jamais arrêter d'apprendre.

J'aimerais ajouter quelques pointeurs

1) J'ai personnellement trouvé très utile de commencer par visualiser des éléments. 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 partenaire de sparring - prenez un café et le tableau de papier, le diagramme, etc. ci-dessus et partez en ville. À mon humble avis, c'est encore mieux si vous n'avez pas les compétences techniques correspondantes. Vous échangez les idées pour mettre en œuvre le 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 n’aurez probablement jamais fini d’améliorer votre logiciel écrit. Si vous branchez toujours de nouvelles fonctionnalités / exigences qui sont déversées sur votre bureau et que vous ne vous souciez pas de votre logiciel, il vous attaquera avec des bugs, des difficultés de maintenance et de nombreuses tentatives d'arrachage de cheveux quelques années plus tard. Obtenez ce temps / budget de maintenance logicielle alloué! Un bon chiffre magique représente environ 20% du temps nécessaire pour développer le logiciel, une année par an, pour le maintenir en forme tout au long de sa vie.

4) Ce processus d'apprentissage progressif ne s'arrête jamais (et ne devrait pas)! Vous regarderez dans 10 ans et sourirez.

J'espère que cela vous aide un tout petit peu et bonne chance!