Comment les équipes professionnelles de développement de logiciels gèrent-elles la complexité de la conception dans des projets non triviaux?

Premièrement, je me rends compte que cette question peut être quelque peu longue et vague et je m'en excuse. C'est probablement un problème de base avec un nom court pour quiconque "l'a compris", mais comme je me trouve à ce sujet manquant, je vous prie de bien vouloir me décrire le problème.

Je fais de la programmation de cette façon ou de l'autre depuis que j'ai environ 11 ans. Cela signifie que j'ai surtout tout appris moi-même depuis le début. J'ai reçu une formation technique, mais pas strictement en informatique (j'ai obtenu un diplôme en génie photonique). Nous avions des cours de programmation bien sûr, mais c'était surtout des trucs de base pour moi et je n'ai pas appris beaucoup de nouvelles choses. J'ai continué à m'instruire en cours de route pour le plaisir et j'ai toujours su que je poursuivrais une carrière dans la programmation, mais tous mes projets étaient assez petits à l'époque. Je n'ai eu aucun mal à les garder à l'esprit et à les entretenir.

Maintenant, je me retrouve à la tête d'une équipe, mais pas dans un environnement d'entreprise - je travaille pour l'université en développant des logiciels scientifiques (en C ++) pour des applications d'ingénierie. Soudain, le projet prend de l'ampleur (relativement) grand et j'ai du mal à m'en occuper la plupart du temps. Je perds beaucoup de temps et d'efforts sur deux choses principalement:

1. Quand je dois revenir sur une section de code sur laquelle je n'ai pas travaillé depuis un moment, j'ai du mal à me souvenir comment cela a fonctionné. Je passe beaucoup de temps à revoir les fichiers d'en-tête des classes pertinentes et à lire les commentaires que j'ai placés en cours de route dans les fichiers source. J'aimerais qu'il y ait une forme de "schéma" que je pourrais entrevoir et retrouver l'image plus facilement;
2. Lorsque j'introduis des changements, je réalise parfois à mi-chemin que ce que j'essaie de faire va casser les choses ailleurs (ou pire, cela n'apparaît que lors de l'exécution comme une surprise). Je reviens et commence à le faire différemment, seulement pour découvrir que j'ai négligé l'influence sur un autre composant. Je souhaite qu'il y ait un "diagramme d'architecture" où je pourrais voir comment les choses se font, comment ce que j'essaie de faire va influencer d'autres composants et un moyen pour moi de planifier en détail avant de commencer à implémenter des changements.

La plupart des gens avec qui je travaille ont des histoires similaires aux miennes - une forte orientation technique et parfois de grandes compétences, mais sans aucun moyen d'organiser leur travail. Cependant, leurs projets sont généralement beaucoup plus petits que les miens, donc ils se débrouillent d'une manière ou d'une autre. Quoi qu'il en soit, cela signifie pour moi que je suis seul et que je n'ai personne pour apprendre les bonnes pratiques.

J'ai suivi un cours de troisième cycle en gestion informatique et bien que je trouve cela très satisfaisant, il est principalement destiné aux non-programmeurs, enseignant les méthodologies de gestion de projet, les estimations de budget / calendrier, l'architecture d'entreprise, etc. - pas la conception et la planification de logiciels en tant que telles. Ça va, j'essaie d'apprendre ça aussi. Bien sûr, certains outils (comme UML) et les types de processus de développement de logiciels (cascade, itératifs, agiles ...) ont été introduits, mais évidemment pas en détail et j'ai du mal à décider ce que je devrais choisir et utiliser ( et dans quelle mesure).

J'ai lu de nombreuses questions et réponses sur la conception de logiciels sur SO - il y en a beaucoup sur le faire en utilisant tel ou tel outil ou méthodologie particulier, et si j'étais convaincu que la documentation UML résoudrait mes problèmes - je la ramasserais et commencez à l'utiliser. Mais certaines personnes ne jurent que par cela, d'autres disent que c'est inutile. Je cherche une réponse à un niveau d'abstraction plus élevé - existe-t-il des moyens de résoudre les deux problèmes que j'ai, et comment le faites-vous personnellement? Que dois-je apprendre pour pouvoir le faire, éventuellement sans être lié à un outil particulier? Celles-ci vont et viennent de style de temps en temps, et je m'attends à ce que leur applicabilité varie en fonction du type de projet.

Merci beaucoup d'avoir lu, je n'ai pas pu dire ce que je veux dire plus brièvement (manque d'expérience en conception de logiciels et de vocabulaire).

Quand je dois revenir sur une section de code sur laquelle je n'ai pas travaillé depuis un moment, j'ai du mal à me souvenir comment cela a fonctionné. Je passe beaucoup de temps à revoir les fichiers d'en-tête des classes pertinentes et à lire les commentaires que j'ai placés en cours de route dans les fichiers source.

Imaginez ce que ressentira le pauvre gars qui vient après vous - il n'a même pas l'avantage d'avoir une fois connu le fonctionnement de votre code. Au lieu d'essayer de déchiffrer votre code, vous devriez revoir la documentation que vous avez écrite pour le module en question. Cette documentation devrait offrir une vue raisonnablement précise de ce que fait le module et pourquoi. Ce n'est pas "le module commence par initialiser trois tableaux en utilisant une boucle triple for ...", mais plutôt: "ce module récupère les données collectées par le capteur principal du Fabulotron, les réorganise au format standard néopolitain (chocolat, vanille, fraise), et le remet au module d'analyse. "

Dans un monde parfait, vous auriez un document de conception qui décrit les différents modules du système et décrit leurs responsabilités respectives, et chacun de vos modules pourrait simplement se référer à ce document pour expliquer ce qu'ils font: "Ce module fournit les Service de collecte de données Fabulotron tel que détaillé dans la section 4.8 du document de conception: http://fabulotron.org/design/section4-8.html . " Si vous n'avez pas quelque chose comme ça, commencez à écrire un aperçu de chaque module pendant que vous travaillez dessus. Vous n'avez pas besoin d'écrire un livre - quelques paragraphes suffisent souvent pour vous orienter.

Lorsque j'introduis des changements, je réalise parfois à mi-chemin que ce que j'essaie de faire va casser les choses ailleurs (ou pire, cela n'apparaît que lors de l'exécution comme une surprise). Je reviens et commence à le faire différemment, seulement pour découvrir que j'ai négligé l'influence sur un autre composant.

Cela pourrait indiquer que vos modules sont trop interconnectés. Plus vous pouvez rendre vos modules / classes / unités indépendants, moins vous risquez de rencontrer ce type de problème. Essayez de rendre les interfaces entre les modules aussi explicites que possible, et essayez de les limiter à ce qui doit être là. Une interface est un contrat - si vous savez qu'un module remplit ses obligations telles que spécifiées dans l'interface, vous n'avez pas besoin de savoir autre chose à ce sujet. Cela empêche les modifications du module sur lequel vous travaillez d'affecter les autres modules.

J'aimerais qu'il y ait un "schéma d'architecture" où je pourrais voir comment les choses se font

L'utilisation de pièces standard peut être utile à cet égard. C ++ fournit des parties standard sous la forme de la bibliothèque de modèles standard et l'utilisation de ces parties le cas échéant vous permet de travailler à un niveau d'abstraction plus élevé. Si vous avez écrit votre propre code pour gérer les structures de données comme les listes, vous et celles qui suivent vous devrez constamment lire la source pour comprendre ce qui se passe. Si vous utilisez à la place des pièces standard fournies par la STL, tout programmeur C ++ pourra rapidement dire ce que fait votre code sans creuser dans vos routines de gestion des données.

Un autre type de pièce standard provient des modèles de conception. Ce sont des concepts standard qui peuvent être utilisés comme raccourci pour expliquer comment fonctionne la relation entre deux objets.

Je n'ai été développeur professionnel que pendant une courte période et j'ai eu beaucoup de mal à le faire lorsque j'ai commencé. J'étais principalement autodidacte, même à l'université. Heureusement pour moi, les gens avec qui j'ai travaillé ont beaucoup d'expérience et ont pu m'instruire sur les façons de gérer et de travailler sur de grands projets.

L'une des premières choses que j'ai dû faire était de m'asseoir et de lire du code propre . C'est un livre fantastique qui m'a aidé à comprendre comment écrire du code que je pouvais comprendre quand j'y revenais ou que quelqu'un d'autre pouvait comprendre.

La deuxième chose était d'écrire des tests de bonne qualité, Unité, Intégration, Acceptation. Si votre code est bien testé, vous saurez rapidement quand vous avez cassé quelque chose et pourrez rapidement diagnostiquer le problème. Il existe de nombreuses bonnes ressources de test sur Internet, et je ne sais pas quelles sont les meilleures à vous suggérer.

Mes points clés sont les tests et le code propre.

Voici quelques idées de haut niveau pour organiser de grands systèmes logiciels. La plupart de mon expérience concerne les systèmes Internet, mais je pense que ces idées s'appliquent aux logiciels d'ingénierie.

• Séparez les fonctionnalités en blocs modulaires relativement isolés. Par exemple, vous pouvez avoir un module pour chaque famille de calculs fournie par votre logiciel.
• Appliquez le modèle de conception MVC pour l'interface utilisateur, le cas échéant. Gardez l'interface et le modèle séparés avec des limites bien définies.
• Envisagez d'utiliser des couches pour regrouper les modules. Dans une application qui utilise des couches d'abstraction, chaque couche dépend uniquement de la couche située en dessous.
• Lors de la rédaction de la documentation, supposez que vous oublierez tous les détails de mise en œuvre. Vous écrirez beaucoup de documentation sous cette hypothèse - peut-être que la moitié de votre code sera des commentaires, mais vous serez beaucoup moins confus plus tard.
• Les tests unitaires, d'intégration et d'acceptation automatisés sont excellents dans certains espaces, mais les développeurs C ++ semblent avoir des sentiments mitigés à leur sujet.
• Dessinez fortement sur les modèles de conception . En plus d'être généralement de bonnes idées, les modèles de conception fournissent un vocabulaire commun en génie logiciel. Appeler une classe un WidgetFactory est un moyen concis de communiquer qu'il s'agit d'une classe qui existe pour créer des widgets.

Cela fait longtemps que je n'ai pas travaillé avec un logiciel d'ingénierie, donc votre kilométrage peut varier en fonction de ces suggestions. Bonne chance!

La réponse est le génie logiciel.

C'est-à-dire que pour les grands projets, vous suivez une séquence définie de collecte des exigences, de définition de processus, de spécification, etc. bien avant que le codage réel ne soit effectué.

Il existe différentes méthodologies utilisées en fonction de l'environnement et de la culture. Les entreprises de type entreprise ont tendance à suivre " Rational Unified Process " ou similaire, les start-ups technologiques optent généralement pour une certaine variation sur Agile , les ministères certaines méthodes surmenées Waterfall .

Dans tous les cas, le processus vous aide à définir exactement ce que vous faites et, vers la fin du projet, vous permet de prouver que vous l'avez fait.

Je recommande fortement de mettre la main sur Enterprise Architect , qui, bien qu'il ne soit pas gratuit, offre des tarifs universitaires. C'est un excellent outil pour schématiser des projets à la fois au niveau macro et micro. Il peut également inverser l'ingénierie de vos fichiers source dans des diagrammes de classes, ce qui serait probablement un bon début pour vous dans la documentation et la réorganisation de la façon dont votre application va de pair.

J'appuierais également les recommandations de @ Klee. Ne vous laissez pas rebuter par les outils supposés "agiles", car ce ne sont vraiment que des éléments de meilleures pratiques qui sont également pratiques (sinon obligatoires) si vous suivez un processus agile. Mais l'intégration continue (par exemple) est précieuse quelle que soit votre méthodologie. De plus, les tests unitaires (cppUnit?) Sont vos amis. Les tests unitaires devraient être très réalisables si vous testez les classes logiques qui sont appelées par votre interface utilisateur, plutôt que de tester directement l'interface utilisateur. Il existe également des outils qui pourraient vous aider à automatiser les tests d'interface utilisateur, mais j'essaierais de rassembler les éléments principaux en premier.

Bonne chance!

Je crois que votre problème a trois dimensions

1. Orienté programmeur
2. Orienté programme
3. Maintenance du programme - Orienté

En ce qui concerne le premier problème, vous pourriez avoir des programmeurs qui ne comprennent pas le concept de ce que fait le programme (cela se produit souvent dans les configurations d'entreprise). Mais en vous basant sur votre question et le domaine dans lequel vous vous trouvez, il semble que vous et votre équipe contrôliez ce que fait le programme, mais ne pouvez tout simplement pas le traduire en un programme de travail en un temps court (pour citer un exemple, j'ai entendu parler de personnes avoir des diplômes post-doctoraux en physique ayant du mal à comprendre les pointeurs en programmation et je suis sûr que la physique est beaucoup plus difficile que le C ++). Si tel est le cas, votre problème est principalement axé sur le programme (vous devez vous sentir assez chanceux pour que les gens autour de vous puissent comprendre ce que fait votre programme et l'apprécier).

En cas de problèmes centrés sur le programme, une de mes suggestions scandaleuses serait de passer à un niveau d'abstraction plus élevé que le C ++, comme l'apprentissage d'un nouveau langage comme Python ou Haskell (Python est assez facile à apprendre et si vous avez de bons mathématiciens, Haskell est tout simplement génial). Passer à un niveau d'abstraction plus élevé réduirait la taille de votre code, serait facile à comprendre et à maintenir à long terme et effectuerait des changements rapidement. Vous pouvez donc avoir 10 lignes de code à la place des 50 lignes de code d'origine. De plus, avoir quelqu'un avec une expertise en programmation informatique serait certainement utile. Être dans une université, vous pouvez également prendre l'engagement de quelques étudiants dans l'interface graphique et les interfaces afin que vous puissiez vous concentrer davantage sur la fonctionnalité. Je recommande également le livre Large-Scale C ++ Software Design de John Lakos(C'est un livre assez gros, vous pouvez devenir un programmeur Python compétent dans le temps que vous pourriez prendre pour lire le livre)

Si vous triez les 2 premières dimensions de votre problème, la troisième est automatiquement résolue. Puisque je crois que vous travaillez sur un seul grand projet, tout logiciel de gestion de projet décent que vous obtenez. Une planification initiale est nécessaire. Si vous commencez à coder tout de suite, vous risquez de vous impliquer trop dans le programme pour oublier la vue d'ensemble. Garder les choses à l'esprit ne fonctionnerait pas pour un grand projet. Mettez tout dans du papier (ou dans l'ordinateur). Utilisez un wiki pour partager des informations. En ce qui concerne les méthodologies, je préfère la méthodologie agile (simplement, agile est un nom élégant pour le développement logiciel incrémentiel). Je suggère également d'embaucher une personne ayant une expertise dans ce domaine afin qu'il s'en occupe afin que vous puissiez vous concentrer sur votre programme de base. L'essentiel ici est que toutes les méthodologies de gestion de projet ne sont qu'un moyen d'assurer le succès du programme; afin que vous puissiez choisir quelqu'un qui vous convient et votre équipe au lieu de sélectionner quelque chose que quelqu'un recommande le mieux. De plus, les logiciels suivants peuvent également vous aider

• Free Mind - Logiciel de cartographie mentale
• Trac - Programme de bogue logiciel simple et rapide et un wiki
• MoinMoin - Wiki rapide pour permettre le partage des connaissances sur le programme

Bien que les conseils ci-dessus nécessitent une certaine courbe d'apprentissage, cela en vaut la peine à long terme. Et enfin, la programmation est plus facile que l'ingénierie photonique (mais pas la programmation C ++)

Comme votre question, toute réponse qui vous sera utile sera très longue et vague - mais la réponse courte est "Génie Logiciel"

Je vous suggère de libérer du temps libre, autant que possible si vous êtes sérieux au sujet d'une carrière en développement de logiciels, et commencez par visiter le site de Steve McConnells . La programmation est facile et peut être enseignée en un semestre, le génie logiciel est un ordre de grandeur plus complexe et a besoin de beaucoup plus de temps pour apprendre.