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

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?

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.

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.

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.

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.

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.

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.

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.

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é.

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.