Combien de détails mettre dans la première itération du projet?

Je viens de commencer un nouveau projet personnel (Python), et j'écris ce qui équivaut à une "ébauche" du programme, le minimum requis pour faire ce que je veux faire. Je ne mets pas encore dans la gestion des erreurs / exceptions ou des éléments d'interface utilisateur esthétiques (même dans les cas où je sais que ces choses seront finalement nécessaires), et la documentation est juste suffisante pour m'aider à voir ce que je faisais.

Est-ce contraire à des principes définis de conception / gestion de projet de commencer si brutalement? Je suis un scientifique, pas un programmeur, donc je ne suis pas au courant de ces choses. La question principale est donc de savoir s'il existe un consensus sur la position à adopter entre les deux extrêmes de:

1. Écrivez un code complet et de haute qualité dès le départ, avec toute la gestion des exceptions et tel que vous savez que vous en aurez finalement besoin.

2. Écrivez un brouillon de travail minimal dès le début, et entrez pour remplir toutes les minuties plus tard.

Question connexe: Quand est-il acceptable de sacrifier la «propreté» de la conception pour réaliser un projet?

Il n'y a pas de réponse unique, car cela dépend entièrement du projet. Nous devons penser à deux choses ici. Quel est votre objectif final? Comment comptez-vous y arriver?

Résultat final

Ecrivez-vous un logiciel de contrôle Mars Orbiter? Ensuite, vous feriez mieux de vous assurer que vous écrivez le code le plus robuste possible, vous feriez mieux de vérifier que chaque exception est gérée de manière saine.

Êtes-vous en train d'écrire un programme que vous seul exécuterez et que vous n'exécuterez manuellement que de temps en temps? Alors ne vous embêtez pas avec des exceptions. Ne vous embêtez pas avec une architecture lourde. Faites-le fonctionner au point où cela fonctionne pour vous.

Comment comptez-vous y arriver?

Faites-vous du développement lourd en cascade, où vous passez beaucoup de temps à déterminer ce qui est nécessaire, puis vous partirez pendant des mois pour vous développer? Si c'est le cas, vous souhaitez atteindre assez tôt la qualité cible mentionnée ci-dessus. Obtenez toutes vos infrastructures de vérification des erreurs planifiées au début.

Faites-vous un développement agile lourd, où vous préparez quelque chose pendant une semaine ou deux, qui sera ensuite montré aux parties prenantes, qui peuvent demander des révisions radicales, et où vous vous attendez à pouvoir itérer sur de nombreux sprints de 1 à 2 semaines jusqu'à ce que vous atteigniez la cible? Ensuite, vous feriez mieux de faire fonctionner quelque chose, mais de les fragiliser rapidement ensemble, et d'ajouter uniquement des ceintures et des bretelles à mesure que les exigences du produit se solidifient.

Si vous contrôlez la cascade ou la décision agile (qui est en fait un continuum et non un choix binaire), prenez cette décision en fonction du changement attendu. Si vous êtes sûr de savoir exactement à quoi ressemblera le résultat final, la cascade est votre meilleur choix. Si vous n'avez qu'une vague idée de ce dont vous avez besoin, Agile est votre meilleur choix. (L'agilité est plus populaire de nos jours non pas parce qu'elle est intrinsèquement meilleure mais parce que la deuxième situation est beaucoup plus courante.)

Trouvez maintenant votre propre réponse

Pour la plupart, la réponse se situera quelque part au milieu. Répondez à ces deux questions sur votre projet et cela devrait vous conduire dans une direction de base.

Je peux dire cela pour moi, si j'écris souvent des scripts uniques qui sont abyssalement conçus et qui n'ont aucune erreur de vérification. Je gère également le code de production, où la gestion des erreurs et l'architecture reçoivent une grande attention. Tout dépend de ce que vous faites.

Une dernière mise en garde: si vous décidez que vous faites des scripts ponctuels qui peuvent être faits rapidement et en sale, assurez-vous. Malheureusement, il arrive souvent que des scripts rapides et sales qui font quelque chose d'intéressant soient utilisés à grande échelle lorsque d'autres les remarquent. Assurez-vous que lorsque cela se produit, du temps est donné pour le durcissement.

Tous les concepts et modèles de conception et de codage de logiciels surviennent en réponse à un problème. Le modèle ou le concept est une solution à ce problème. Au fil du temps, certains modèles deviennent «bien connus» en tant que solutions préférables car ils résolvent le problème d'une manière qui remplit certaines conditions de cohérence, de familiarité, de performances, de maintenabilité, etc.

Il s'ensuit que, si le problème que le modèle logiciel est censé résoudre n'existe pas dans votre logiciel particulier, vous n'avez pas besoin du modèle. De plus, toute discussion sur les modèles que votre logiciel pourrait avoir besoin doit également inclure des discussions détaillées sur votre logiciel proposé: que doit-il faire? Quel problème résout-il? Combien d'utilisateurs y aura-t-il? Les utilisateurs partageront-ils les données d'une manière ou d'une autre? Et ainsi de suite.

Le problème que les exceptions sont censées résoudre est quand quelque chose se produit que le code ne peut rien faire. Un exemple serait une opération Fichier / Ouvrir où un nom de fichier est spécifié qui n'existe pas sur le support de stockage. Les exceptions donnent au code un moyen de dire à l'appelant "Quelque chose s'est produit qui m'empêche de continuer, et je ne peux rien y faire, alors j'abandonne." Si vous n'avez pas d'endroits dans votre code où de telles conditions existent, alors vous n'avez pas besoin d'exceptions. Ou, vous pouvez simplement renvoyer un code d'erreur et éviter complètement l'exception.

Au fur et à mesure que vous acquérez de l'expérience, vous en apprendrez davantage sur les modèles de logiciels et sur leur utilisation appropriée. Vous saurez également de combien de conception initiale vous avez besoin; encore une fois, cela dépend totalement de l'application que vous écrivez. Les petits utilitaires sont écrits d'une manière fondamentalement différente des grandes applications d'entreprise, en d'autres termes.

Il existe une approche très simple et pratique à cela, qui fonctionne pour un large éventail de projets de petite à moyenne taille. Même si cela ne fonctionnera probablement pas bien pour Mars Explorers.

Tout d'abord, déterminez ce que vous voulez que le système fasse et notez chacune des fonctionnalités individuelles. Cela peut être aussi sophistiqué qu'un tableau de bord de l'utilisateur ou aussi simple que quelques puces notées sur un morceau de papier devant vous. Mais il est important que vous sachiez quoi vous voulez qu'il fasse.

Sur cette base, on établit la structure générale du système. Encore une fois, il s'agit très souvent d'un simple dessin rapide des différentes classes / modules et de la façon dont ils sont liés les uns aux autres, mais peut être aussi complexe qu'un document entier. L'important est que vous ayez une idée de la façon dont vous allez mettre en œuvre le système. Mais cela va probablement être affiné au fur et à mesure que vous y travaillez, alors n'essayez pas d'aller vers des détails complexes et détaillés.

Parmi toutes ces fonctionnalités, déterminez quels sont les éléments clés que le programme doit faire - les fonctionnalités de base.

Ensuite, implémentez-les un par un. Maintenant, l'essentiel est de s'assurer que, une fois que vous avez implémenté une fonctionnalité, celle-ci est effectuée et fonctionne pleinement - idéalement, elle est accompagnée d'un test unitaire qui garantit qu'elle continue de fonctionner. Je suppose généralement que je serai tellement occupé que je n'aurai jamais le temps de revenir sur la fonctionnalité et de la corriger.

Une fois les fonctionnalités de base implémentées, j'essaie généralement de mettre le système à utiliser le plus près possible de l'environnement de production. Cela vous donne a) tous les bugs que vous avez pu manquer plus tôt et b) vous avez une bonne idée de la priorité des prochaines fonctionnalités.

Ensuite, vous pouvez continuer à implémenter les fonctionnalités restantes selon vos besoins.

Qualité du code et fonctionnalités

Compte tenu de ce qui précède, j'ai tendance à sacrifier les fonctionnalités à la qualité du code, si je dois respecter une date limite. Tout simplement parce que, au moins dans mon domaine de travail, lorsque je termine quelque chose, ma direction suppose que c'est fait. Et qu'ils peuvent me confier la prochaine tâche. Je n'ai pas beaucoup de temps pour rendre le code plus agréable après coup.

Maintenant, qu'en est-il de la gestion des exceptions?

Si vous ne voulez pas l'implémenter dès le départ, vous pouvez simplement le répertorier comme une autre fonctionnalité de la liste. Et quand vous y arrivez, vous pouvez l'implémenter. Mais très probablement dans votre cas, il y a probablement beaucoup d'autres choses qui sont plus importantes en premier.

Cependant, il existe une exigence minimale pour les exceptions: assurez-vous que l'utilisateur est averti en cas de problème - quelle que soit la laideur de la sortie. N'avalez pas d'exceptions quelque part.