Les méthodes de développement devraient-elles écraser l'individualisme d'un développeur?


9

Je suis dans mon dernier semestre de collège et je suis en train de suivre un cours de génie logiciel. Dans la classe, nous découvrons différentes méthodes de développement de logiciels. Celui sur lequel nous nous sommes concentrés et utilisé pour développer notre projet était la méthode de la cascade.

J'ai l'impression que l'instructeur l'a peut-être mal mis en œuvre. Dans nos diagrammes de classes, nous avons dû répertorier TOUTES les propriétés et méthodes, y compris les propriétés privées. J'ai lu quelques livres, à savoir Clean Code, qui disent de garder les fonctions aussi courtes et ciblées que possible. Il semble fastidieux de répertorier chaque petite fonction dans nos diagrammes s'ils n'aident pas les autres développeurs (ils sont privés, personne d'autre ne les utilisera). De plus, je ne pense pas à toutes les petites fonctions lors de la conception du programme, elles peuvent se produire lors de la refactorisation.

L'instructeur nous a-t-il dit tort en nous demandant de lister toutes les fonctions? Et, ces méthodes de conception écrasent-elles l'individualisme du développeur pour écrire du code comment le comprendre au mieux?


20
C'est assez mauvais que votre classe enseigne la méthode Waterfall, qui est un exemple canonique de mauvais processus de développement logiciel.
whatsisname

6
Je dirais que ce cours vous a beaucoup appris.
JeffO

7
En fait, la cascade d'origine a des itérations qui se rétroagissent. C'est l'enseignement incorrect de Waterfall au fil des ans qui a détruit son utilité. Même avec quelque chose comme Scrum, les étapes d'une histoire dans un sprint émulent celles d'une cascade en elle-même. Les diagrammes UML ne sont utiles que pour la conception de haut niveau. Dès que le code est écrit, tous les documents écrits avant ce code sont désormais obsolètes. C'est la réalisation de l'ingénierie. Au final, le code doit être la documentation.
Andrew T Finnell

10
Presque tous les développeurs ont vu des cas d'individualisme de développeur qui auraient dû être écrasés. (Bien que probablement pas selon la méthodologie de la cascade).
psr

2
@whatsisname, je suis fortement en désaccord. Chaque développeur doit apprendre le développement Waterfall afin de le COMPRENDRE et de L'EXPERIENCE comme un exemple canonique de mauvais développement logiciel. De plus, de nombreux magasins sont toujours Waterfall pour le bien ou le mal et il est important que les diplômés soient préparés pour cela.
maple_shaft

Réponses:


10

Avez-vous demandé à l'instructeur pourquoi vous deviez énumérer toutes les méthodes?

Il est possible que, comme pour une grande partie de ce qui est demandé dans un environnement de classe, l'intention n'était pas de rendre vos diagrammes de classe plus utiles aux développeurs, mais de vous aider, ainsi que vos camarades de classe, à réfléchir à la façon dont vous concevriez vos classes. Lorsque les élèves apprennent à décomposer des problèmes plus importants en problèmes plus petits, il est probablement utile pour eux de réfléchir aux méthodes privées dont ils auraient probablement besoin. Et il est probablement utile pour l'instructeur d'avoir une meilleure idée des méthodes que les étudiants envisagent de mettre en œuvre afin d'intervenir plus tôt dans le processus si la conception de quelqu'un est mal pensée. La documentation dans un environnement de classe est souvent beaucoup plus complexe que la documentation dans un environnement réel parce que l'instructeur '

Bien sûr, il est également possible que l'instructeur estime que ce niveau de documentation est utile dans un projet réel. Si tel est le cas, l'instructeur est probablement soit obsolète, soit issu d'une niche particulière où ce niveau de planification et de documentation est approprié. Si vous construisez le système de navigation pour la navette spatiale ou concevez des dispositifs médicaux, par exemple, il est généralement beaucoup plus approprié d'investir massivement dans la conception à l'avance plutôt que de refactoriser le code pendant le développement. Si vous développez un site de réseautage social, en revanche, une approche plus agile est plus appropriée.


+1 pour indiquer comment une conception différente est nécessaire à différentes fins. De bons points sur la conception de classe également; demander à l'instructeur est une bonne idée
Ethel Evans

1
Rappelez-vous la règle pour réussir un cours collégial: Découvrez ce que le professeur veut et livrez-le.
Christopher Mahan

9

Non, l'instructeur a raison de vous dire de répertorier toutes les propriétés et méthodes dès le départ si vous utilisez la méthode de la cascade. Wikipedia note une critique de la cascade:

Beaucoup soutiennent que le modèle en cascade est une mauvaise idée dans la pratique, estimant qu'il est impossible pour un projet non trivial de terminer parfaitement une phase du cycle de vie d'un produit logiciel avant de passer aux phases suivantes et d'en tirer des leçons. Par exemple, les clients peuvent ne pas savoir exactement de quelles exigences ils ont besoin avant d'examiner un prototype fonctionnel et de le commenter. Ils peuvent changer constamment leurs exigences. Les concepteurs et les programmeurs peuvent avoir peu de contrôle sur cela. Si les clients modifient leurs exigences une fois la conception finalisée, la conception doit être modifiée pour répondre aux nouvelles exigences. Cela signifie effectivement invalider une bonne partie des heures de travail, ce qui signifie une augmentation des coûts, surtout si une grande partie des ressources du projet a déjà été investie dans Big Design Up Front.

Ces méthodes de conception n'écrasent pas le réalisateur de l'individualisme de la conception car il y a encore des parties à interpréter et des façons de mettre ses touches uniques sur la structure, par exemple une image donnée un squelette et en ajoutant le muscle et d'autres tissus pour créer un animal se demandant combien avez-vous eu la liberté de concevoir cet animal?

Vous avez trouvé un défaut de cascade oui mais tout a ses forces et ses faiblesses.


4

Dans la classe, nous découvrons différentes méthodes de développement de logiciels. Celui sur lequel nous nous sommes concentrés et utilisé pour développer notre projet était la méthode de la cascade.

Vous avez probablement appris le modèle classique de Waterfall, que la personne a attribué à son introduction dans le monde du développement logiciel, a déclaré dès le départ qu'il était inapproprié pour développer des systèmes logiciels à grande échelle. Vous seriez probablement intéressé par la lecture du document de Winston Royce intitulé Managing the Developemt of Large Software Systems pour en savoir plus sur les problèmes avec ce que beaucoup de gens considèrent comme le modèle Waterfall.

Cependant, le modèle Waterfall est bon pour enseigner le cycle de vie du développement logiciel au fur et à mesure et peut passer du temps à apprendre et à effectuer l'ingénierie des exigences, la conception architecturale, la conception détaillée, la mise en œuvre, les tests et la maintenance en phases très claires et distinctes.

Dans nos diagrammes de classes, nous avons dû répertorier TOUTES les propriétés et méthodes, y compris les propriétés privées. J'ai lu quelques livres, à savoir Clean Code, qui disent de garder les fonctions aussi courtes et ciblées que possible. Il semble fastidieux de répertorier chaque petite fonction dans nos diagrammes s'ils n'aident pas les autres développeurs (ils sont privés, personne d'autre ne les utilisera). De plus, je ne pense pas à toutes les petites fonctions lors de la conception du programme, elles peuvent se produire lors de la refactorisation.

Ce sont tous des points très valables.

La liste de toutes les propriétés et méthodes pendant la phase de conception, même lorsque vous utilisez Waterfall, est probablement exagérée. Vous devez absolument répertorier tout ce qui est public, ainsi que les propriétés essentielles. En réalité, tout le reste est un détail d'implémentation que vous pouvez obtenir en inversant l'ingénierie de votre implémentation dans des diagrammes.

Les conseils de Clean Code (je ne l'ai jamais lu - je ne fais que suivre ce que vous avez publié) semblent être justes et applicables même lorsque vous utilisez la méthodologie Waterfall. Vous pouvez concevoir vos classes et méthodes en respectant le principe de responsabilité unique , la séparation des préoccupations et d'autres principes de SOLID . La cascade ne vous dit pas comment concevoir, juste au moment où vous en avez besoin. Cela dit, il est plus difficile à l'avance lorsque vous apprenez et réfléchissez à de meilleures façons de le faire pendant la mise en œuvre.

Je pense que cela souligne le fait qu'il doit y avoir une itération entre la conception et la mise en œuvre très clairement - un problème que la cascade traditionnelle ne prend pas en compte.


1
@pillmuncher Si peu de gens l'ont lu, c'est un peu triste.
Thomas Owens

3
La chose la plus triste à propos de ce document est que la plupart des gens ont découvert des chutes d'eau, alors que c'est un document qui discrédite complètement la pratique.
Joeri Sebrechts

3

Il semble fastidieux de répertorier chaque petite fonction dans nos diagrammes s'ils n'aident pas les autres développeurs (ils sont privés, personne d'autre ne les utilisera).

Si vous pensez que c'est fastidieux, attendez d'avoir une vraie programmation de travail. Considérez, pendant un moment, que le logiciel peut ne pas être une carrière viable pour vous.

De plus, je ne pense pas à toutes les petites fonctions lors de la conception du programme, elles peuvent se produire lors de la refactorisation.

Donc?

l'instructeur nous a-t-il dit du mal en nous demandant d'énumérer toutes les fonctions?

Non, c'est une exigence courante.

Et, ces méthodes de conception écrasent-elles l'implémentateur de l'individualisme de conception (le développeur) pour écrire du code comment le comprendre au mieux?

Oui. L'écrasement de l'âme des individus est une partie importante du développement logiciel. Toute individualité sera battue à tout moment de tous les programmeurs de toutes les manières possibles. Il dit que quelque part dans les "règles de programmation de Dieu" transmises d'une montagne à un prophète.

Non. Vous rechignez juste à l'ennui. Dépassez-vous et retournez au travail.


1
@FreshDaddy. "Ils (pour la plupart) ne verront jamais de fonctions privées." Faux. Après avoir gagné à la loterie, d'autres programmeurs reprendront votre code et verront les fonctions privées. Aussi. Certaines langues (par exemple Python) évitent ce type de confidentialité.
S.Lott

2
@ S.Lott - Lister chaque fonction privée n'est pas du tout une exigence courante. Cela arrive, ne vous méprenez pas, mais une "liste complète de toutes les fonctions privées avant d'écrire du code" est certainement assez rare. Il y a "le tedius nécessaire" et ensuite le "tedius sans valeur". Étant donné que les programmeurs sont en train d'éliminer les «tedius sans valeur», les clients du monde réel ne demanderaient presque jamais quelque chose d'aussi coûteux et inutile, à moins qu'il ne s'agisse d'un code de type «vie ou mort».
Morgan Herlocker

1
@ironcode: '"répertorier toutes les fonctions privées avant d'écrire du code" est certainement assez rare.' Pas d'après mon expérience. C'est ainsi que les gens apprennent à faire du design. Les programmeurs juniors sont souvent tenus à cette norme jusqu'à ce qu'ils puissent prouver que leur travail ne nécessite pas ce niveau de surveillance. Généralement moins d'un an. Une organisation qui a pris n00bs de l'école et les a jetés à la programmation sans surveillance crée principalement d'énormes problèmes. Ce niveau de surveillance est essentiel pour être sûr que le code a des chances de fonctionner.
S.Lott

1
@S Lott - ma devise est que si le développement logiciel est fastidieux, vous le faites mal. Nous sommes programmeurs. Nous automatisons l'ennui. Nous ne nous répétons pas dans le code, et il n'y a pas non plus de raison de nous répéter dans la documentation.
Kevin Cline

1
@kevin: cette réponse est un pur sarcasme. En tant que tel, il est complètement inapproprié et je l'ai signalé.
Michael Borgwardt

1

La programmation est l'art de travailler avec des contraintes. Le CPU fournit un jeu d'instructions limité; IO est contraint par la conception du matériel; Les API du système d'exploitation sont créées pour encourager certains comportements et en restreindre d'autres; les langages de haut niveau sont souvent conçus pour promouvoir un ensemble d'expressions idiomatiques par rapport à d'autres ...

Et les méthodologies sont également conçues pour restreindre.

Votre défi, dans tous les aspects du processus de développement, est de réaliser votre vision dans ces contraintes. Allez-vous vous frapper la tête contre chaque mur érigé par le matériel, le langage, l'API et la méthodologie? Ou allez-vous trouver un moyen d'harmoniser ce que vous souhaitez réaliser avec ce qui est autorisé et encouragé?

Pensez-vous vraiment que votre instructeur souhaite lire des pages interminables de détails? Testez ensuite cette théorie: décomposez un programme et documentez chaque atome. Lorsque son bureau s'affaisse sous le poids, je soupçonne plutôt que vous constaterez que son véritable désir est quelque peu différent de ce que vous attendez.

Ou préparez la documentation comme bon vous semble. Soyez clair, compréhensible, lisez-le comme un roman de Dashiell Hammett. Et puis asseyez-vous et parlez-lui, montrez-lui ce que vous avez fait, convaincez-le de son mérite.


1

Je pense que l'instructeur est génial pour vous faire réaliser ce projet, et donc vous enseigner les avantages et (principalement) les inconvénients du développement de Waterfall.


1

Une règle empirique simple pour mesurer la complexité de l'analyse de projet est "Le développeur ou l'entreprise pour laquelle il travaille peut-il être tenu responsable de quelque chose d'assez dramatique (y compris généralement la mort ou une énorme perte d'argent) qui se produit avec le logiciel créé?".

J'ai eu la même expérience que vous pour certains de mes cours. Des gens qui avaient une formation dans l'industrie militaire nous apprendraient l'analyse. Et ce serait une analyse complète et exhaustive, planifiant tout au long du projet, même dans les moindres détails. Vous ne pouvez pas vous permettre beaucoup d'itérations avec ce type de projet (l'explosion d'une bombe peut également être correcte, l'explosion du budget ne l'est pas), donc pas de place pour la créativité ici, vous devez suivre le plan.

D'un autre côté, si vous avez lu un peu, vous avez certainement lu sur les méthodologies agiles. Il y a généralement moins de documentation et plus de place pour que le développeur utilise sa créativité tout en développant une solution au problème qu'il rencontre.

En conclusion, plus vous acquérez d'expérience, mieux c'est, et ce que votre instructeur vous montre s'applique dans une certaine partie de l'industrie. Sachez simplement qu'il existe certainement autant de façons de gérer et de concevoir un projet que de les coder. Et vous trouverez des défenseurs et des critiques pour chacun d'eux. Testez-les pendant que vous étudiez et choisissez celui qui vous convient.


Et faites attention à "Peut-il tuer des gens s'il se bloque", il y a un autre type appelé "Est-ce que quelqu'un peut aller en prison si cela imprime des données erronées" et cela reviendra souvent au gars qui doigte le clavier, donc c'est bien d'avoir exigences, dans les moindres détails.
Christopher Mahan

@Christopher: ajusté ma réponse en conséquence, merci pour le commentaire :)
Matthieu

0

Certains cours de génie logiciel, comme celui que j'ai suivi, sont enseignés dans un style étrange où `` l'échec est un succès '', le succès est une occasion gaspillée d'apprendre de l'échec, et plus c'est de moins en moins, c'est plus. Si c'est l'un de ceux-là, alors respectez simplement les affectations et profitez de l'étrangeté.


0

Je pense que votre instructeur est déconnecté. Les logiciels commerciaux sont rarement conçus ou documentés dans cette mesure. C'est beaucoup trop cher et la documentation qui en résulte ne peut pas être conservée sans encore plus de dépenses. De telles pratiques de l'OMI sont un héritage des jours où le codage était souvent effectué en langage assembleur. Il aurait mieux valu passer votre temps à essayer des pratiques plus agiles: développement piloté par les tests, programmation en binôme, refactoring continu.

L'instructeur vous a-t-il dit «mal»?

Je le pense.

Attribuer un travail ennuyeux aux travailleurs de la propriété intellectuelle est un gaspillage. À l'école, le travail ennuyeux a peu ou pas de valeur pédagogique, sauf peut-être pour inciter les élèves à un travail ennuyeux. De tels exercices ont des conséquences négatives, tant pour les étudiants que pour l'industrie. Les étudiants sont blessés parce que leur temps est perdu. L'industrie est lésée, car certains étudiants peuvent conclure qu'une telle ennui est nécessaire et utile. Ce n'est ni l'un ni l'autre. En trente ans dans le domaine du logiciel, le seul travail auquel je puisse penser était à la fois ennuyeux et utile: changer les bandes de sauvegarde. Il y avait des robots qui pouvaient le faire, mais ils étaient d'un coût prohibitif.


2
J'ose dire que vous n'avez jamais travaillé pour une entreprise qui gagne de l'argent grâce à des contrats avec le gouvernement. (modifier) ​​Vous avez dit Logiciel commercial. Ma déclaration n'a plus de sens maintenant.
Andrew T Finnell

@Andrew Finnel: La vérité est si douloureuse, à tant de niveaux.
Peter Rowell

2
@Andrew - J'ai travaillé pour DOD2167. C'était horrible et improductif tel qu'il était pratiqué. Plus tard, j'ai travaillé pour une autre entreprise qui fait du développement agile pour le gouvernement avec des livraisons fréquentes. Le client est extrêmement heureux. Ils ont eu une application utile en six mois et bénéficient de nouvelles fonctionnalités chaque trimestre.
Kevin Cline

@Andrew J'ai plus de 2 ans d'expérience dans le travail du DoD américain, en tant qu'employé du gouvernement et en tant qu'entrepreneur. Des méthodes agiles sont en cours d'adoption. Une équipe sur laquelle j'ai travaillé utilisait activement Scrum, produisant "juste assez" de documentation "juste à temps". Oui, la documentation (même "juste assez") est beaucoup plus étendue que de nombreux autres endroits, mais elle est généralement motivée par le nombre de parties impliquées (les contrats peuvent changer de mains, d'autres parties peuvent développer d'autres systèmes, etc.) et / ou la sûreté ou la criticité de la vie et l'importance des systèmes en cours de développement.
Thomas Owens

2
@Andrew, ce n'est pas seulement les gouvernements. J'ai vu 40 pages de spécifications pour les "produits"; normalement, vous pouvez tout sélectionner dans ce tableau et me le donner, s'il vous plaît. Personne ne peut jamais être dérangé de les lire ...
Ben
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.