Concilier les conseils de programmation contradictoires: faire fonctionner quelque chose et répéter vs vraiment réfléchir avant de coder

Je suis un programmeur intermédiaire avec quelques années d'expérience professionnelle qui est à mi-parcours d'un master. En apprenant à programmer, j'ai souvent entendu deux conseils apparemment contradictoires.

Le premier conseil était de faire fonctionner quelque chose rapidement, de voir comment cela fonctionne (soit par prototypage soit par des tests informels), d'améliorer la version, de voir comment cela fonctionne à nouveau, de l'améliorer à nouveau ... puis de répéter le cycle jusqu'à ce que vous ayez terminé . Ceci est parfois appelé «développement en spirale» ou formulé comme «libération précoce, libération fréquente».

Le deuxième conseil était: réfléchissez vraiment à un projet avant d'écrire du code.

J'ai réussi avec les deux méthodes et je dirais que je suis d'accord avec chaque philosophie.

Mais maintenant, je commence à m'attaquer à des projets beaucoup plus complexes que je ne sais pas comment terminer (comme les applications distribuées et la programmation graphique axée sur les performances).

Comment puis-je aborder ces projets?

Dois-je simplement commencer à coder QUELQUE CHOSE et apprendre (plates-formes / méthodes / langages / architectures) au fur et à mesure - ou dois-je m'arrêter de coder et faire une tonne de recherches / lecture avant même d'ouvrir l'IDE?

Comment réconcilier ces conseils de programmation contradictoires?

Je ne suis pas sûr que penser à un problème à l'avance par rapport à une approche itérative soit contradictoire. Comme beaucoup d'autres choses, je pense que vous devriez vous efforcer de trouver l'équilibre entre les deux. Comment trouvez-vous l'équilibre? C'est quelque chose que vous apprenez avec l'expérience et souvent les meilleures leçons (c'est-à-dire des choses qui vous donnent de l'expérience), c'est quand vous ne comprenez pas tout à fait bien (ou encore une meilleure leçon: tout simplement à fond vous trompez). Comme vous l'avez déjà souligné, il y a un dicton "libérez rapidement, libérez souvent". Il y en a un autre, "échouer tôt, échouer rapidement, échouer souvent"

Penser à l'avenir est formidable et vous devez absolument le faire. Mais avec l'expérience, apprenez quand arrêter de penser et simplement construire quelque chose même si vous n'avez pas toutes les données. En le construisant, vous pourrez mieux comprendre le domaine problématique et potentiellement trouver une bien meilleure solution. Je recommanderais donc de ne pas exclure l'un de l'autre mais de faire de la "tête pensante" une partie de vos itérations et avec le temps, je pense que vous trouverez vous-même la bonne réponse à cette question.

Juste un petit exemple. L'autre jour, je me débattais avec une décision de conception de logiciel. Avec le recul, c'était relativement trivial mais j'avais deux alternatives et il semblait que les deux fonctionneraient. J'ai continué à tourner autour du pour / du contre de chacun, puis à revenir en arrière et à reconsidérer mes décisions. Avec le recul, c'est un peu gênant le temps que j'ai passé à réfléchir. Alors je me suis dit, f # @ k it! Et au lieu d'utiliser l'une ou l'autre des conceptions, je suis juste allé de l'avant et j'ai piraté du code ensemble, ignorant complètement toutes les bonnes choses que vous apprenez sur une bonne conception. J'ai réussi à faire fonctionner la fonctionnalité en 45 minutes environ. Ensuite, je suis retourné, j'ai regardé mon code et l'ai transformé en quelque chose de solide et quelque chose que je n'aurais pas honte de vérifier dans le contrôle de code source. Le plus drôle, c'est qu'après que le hack ait fonctionné, de trouver "

Une autre chose que je recommanderais spécifiquement pour les problèmes que vous rencontrez actuellement (c.-à-d. Une tâche importante et complexe qui se profile). Au lieu de faire les choses en série, faites-les en parallèle. Divisez votre journée en morceaux où vous effectuez des recherches, puis arrêtez-vous, changez de vitesse et codez pendant un certain temps, au moins sur des parties du projet qui ne sont pas des inconnues complètes. De cette façon, rester proche du code vous donnera une meilleure perspective et vous ne vous épuiserez pas en essayant d'absorber trop d'informations trop rapidement. Pour moi au moins, après quelques heures de recherche, il est bon de laisser le cerveau digérer des choses, changer de tâche et faire autre chose pendant un certain temps. Revenez ensuite à plus de recherches.

Certaines décisions doivent être prises à l'avance.

Faites-vous une application Web? Ensuite, vous devez savoir à quoi ressemblera l'architecture globale. Des architectures comme MVC définissent déjà ce que seront vos grandes pièces fonctionnelles (comme le routage, les contrôleurs, les modèles, les couches de service, les protocoles de communication, etc.); inventer tout cela à partir de rien va être long terme, inutile et probablement inférieur à ce qui est déjà inventé.

Ecrivez-vous un type d'application impliquant des collections d'objets ou de données? Ensuite, vous devrez savoir quels types de structures de données sont les plus appropriés pour votre scénario particulier et quelles sont leurs caractéristiques de performance. Avez-vous besoin d'un temps de recherche rapide? Qu'en est-il des ensembles de données commandés? Est-ce qu'une collection en mémoire fera l'affaire, ou avez-vous besoin de quelque chose de plus industriel comme une base de données? Vous ne pouvez pas simplement commencer à coder sans réfléchir à ces décisions, car si vous faites le mauvais choix, vous devrez recommencer.

Cela dit, une fois les décisions technologiques prises, vous avez la liberté dans le cadre que vous avez établi. Le but est alors de rester flexible, itératif et (oserais-je dire) suffisamment agile pour que lorsque le client change d'avis sur ce qu'il veut, vous pouvez l'accommoder avec un minimum d'agitation.

Comment tu fais ça? Expérience, surtout. Comme quelqu'un l'a déjà dit, l'expérience est ce que vous obtenez juste après en avoir besoin. Mais si vous suivez les décisions de conception réussies des autres (telles qu'incarnées dans les plates-formes, bibliothèques et autres outils du commerce), vous pouvez en tirer des enseignements et réduire vos risques.

Je ne considère pas les deux comme s'excluant mutuellement.

Comme tout type de gestion de projet, vous avez besoin à la fois d'une vision à long terme et d'objectifs à court terme.

Sans le premier, vous finirez par perdre du temps, par exemple, sur des fonctionnalités qui ne seront peut-être même jamais utilisées et sans le second, vous passerez toute la journée à réfléchir à la création de l'application parfaite sans terminer votre projet.

À quelle fréquence vous relâchez / etc. dépend de la méthodologie spécifique que vous utilisez.

Ce que vous devez rechercher dépend de ce que vous savez par rapport à ce avec quoi vous n'êtes pas à l'aise.

«Itération» et «réflexion» ne sont pas contradictoires, mais plutôt complémentaires.

Même à leurs extrêmes, ils reflètent deux chemins pour arriver au même endroit.

• L'extrême de l'itération est un millier de singes frappant un millier de claviers. Avec suffisamment de temps, vous obtiendrez peut-être quelque chose qui répond aux exigences.
• L'extrême de «réfléchir» est une approche en cascade. Si vous êtes chanceux, les exigences n'ont pas radicalement changé depuis le début du projet au moment où vous livrez le code. Ou vous vous retrouverez avec une paralysie d'analyse et vous n'aurez rien livré.

Vous devez avoir une certaine compréhension du domaine et du problème avant de commencer à coder. Il s'agit de la partie «pensez-y bien». Idéalement, vous verrez le chemin de haut niveau du début à la fin sur la façon de résoudre le problème.

Mais vous ne verrez peut-être que de grandes parties de ce chemin, et certainement pas tous les arrêts en cours de route. C'est là que l'itération entre en jeu. Vous pouvez commencer à parcourir les versions de l'application et à demander des commentaires afin de:

• Identifier les barrages routiers qui apparaissent dans les niveaux de détail inférieurs
• Consultez les commentaires des parties prenantes pour clarifier ces zones troubles dans le chemin de haut niveau.

La racine latine de décider signifie «couper». L'itération vous permet de décider ce qui fonctionne dans la pratique au lieu de simplement la théorie et l'itération vous permet de supprimer les autres options qui ne sont pas réalisables.

Vous devez donc réfléchir au problème afin de comprendre ce que vous allez faire. Mais vous devez ensuite parcourir les versions de l'application afin de transformer réellement l'idée en code réel.

Ma règle d'or: si vous ne comprenez pas complètement une partie du problème, vous devez prendre du recul et y réfléchir complètement (j'inclus le prototypage et le code à jeter pour comprendre les API, etc. dans le cadre de la "réflexion") . S'il s'agit essentiellement d'un ensemble de problèmes que vous avez résolus auparavant et que vous avez juste besoin de trouver la meilleure façon de tout assembler dans ce cas particulier, alors itérez.

Honnêtement, ce n'est pas une règle stricte et rapide. Je pense vraiment que vous devez faire un mélange des deux pour un projet donné. La part de chacun de vos projets dépendra probablement de la proximité du projet avec celui que vous avez déjà réalisé dans le passé.