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.