Penser le développement
Je travaille en tant que développeur d'applications depuis un an et demi maintenant (pas longtemps je sais), et je viens de recevoir mon premier gros projet.
Inutile de dire que cela ne s'est pas très bien passé, j'ai donc demandé conseil à un programmeur senior impliqué dans le projet sur la façon de l'aborder.
Il a dit que j'avais radicalement réfléchi à la tâche à accomplir et que parce que je n'avais jamais abordé un projet de cette envergure avant de passer trop de temps à réfléchir aux modèles de conception. Dans ses mots sages, il m'a dit "F * ck l'avenir, construire pour l'instant".
Est-ce une tendance que les programmeurs suivent généralement lorsqu'ils se lancent dans un projet comme celui-ci? Par exemple, si on vous demandait de faire un modèle de preuve de concept, est-ce une tendance typique de simplement écraser un exemple réalisable dès que possible?
Edit: À la lumière du débat qui a déclenché, je voudrais mentionner que cette situation est assez extrême: nous avons des délais très serrés en raison de facteurs hors de notre contrôle (c'est-à-dire que le marché que nous visons perdra de l'intérêt si nous ne ne leur montrez pas quelque chose) et ses conseils se sont avérés très efficaces pour cette tâche particulière.
Capitaine évident à la rescousse!
Je serai le capitaine Obvious ici et je dirai qu'il y a un terrain d'entente à trouver.
Vous voulez construire pour l'avenir et éviter de vous enfermer dans un choix technologique ou une mauvaise conception. Mais vous ne voulez pas passer 3 mois à concevoir quelque chose qui devrait être simple, ou ajouter des points d'extension pour une application rapide et sale qui aura une durée de vie de 2 ans et a peu de chances d'avoir des projets de suivi.
Il est difficile de trouver la distinction, car vous ne pouvez pas toujours prédire le succès de votre produit et si vous devez l'étendre plus tard.
Construisez pour l'instant si ...
- le projet va être abandonné
- le projet a une courte durée de vie
- le projet ne doit pas avoir d'extensions
- le projet n'a pas de valeur d'impact sur le risque (principalement en termes d'image)
En général, les projets internes ou quelque chose de construit pour un client doivent être développés pour l'instant. Assurez-vous d'avoir des exigences claires et de vous y référer au besoin pour savoir ce qui est nécessaire et ce qui ne l'est pas. Je ne veux pas passer trop de temps sur tout ce qui est "agréable à avoir". Mais ne codez pas non plus comme un cochon.
Laissez le problème général pour plus tard, s'il peut être nécessaire et en vaut la peine:
Construire pour l'avenir si ...
- le projet sera public
- le projet est un composant à réutiliser
- le projet est un tremplin pour d'autres projets
- le projet comportera des projets de suivi ou des versions de service avec des améliorations
Si vous construisez pour quelque chose de public, ou qui va être réutilisé dans d'autres projets, alors vous avez une probabilité beaucoup plus élevée qu'un mauvais design revienne vous hanter, alors vous devriez y prêter plus d'attention. Mais ce n'est pas toujours garanti.
Des lignes directrices
Je dirais que vous adhérez au mieux aux principes suivants, et vous devez vous mettre en position de concevoir des produits efficaces et adaptables:
- sachez que YAGNI ,
- BAISER ,
- chaque fois que vous avez envie de gratter une démangeaison et pensez à un ajout, notez-le. Revoyez les exigences de votre projet et demandez-vous si les ajouts sont prioritaires ou non. Demandez-leur s'ils ajoutent une valeur commerciale principale ou non.
Je sais que j'ai tendance à trop réfléchir et à suringérer. Cela aide vraiment à écrire des idées et à repenser très souvent si j'ai besoin de fonctionnalités supplémentaires. Souvent, la réponse est non ou "ce serait cool plus tard". Ces dernières idées sont dangereuses, car elles restent à l'arrière de ma tête, et je dois me forcer à ne pas les planifier.
La meilleure façon de coder sans ingénierie excessive et sans vous bloquer pour plus tard est de vous concentrer sur une bonne conception minimale. Décomposez bien les choses en tant que composants que vous pouvez étendre plus tard, mais sans penser déjà à la façon dont ils peuvent être étendus plus tard. Vous ne pouvez pas prédire l'avenir.
Construisez simplement des choses simples.
Dilemmes
Suringénierie
Est-ce une tendance que les programmeurs suivent généralement lorsqu'ils se lancent dans un projet comme celui-ci?
Enfer ouais. C'est un dilemme connu, et cela montre seulement que vous vous souciez du produit. Sinon, c'est plus inquiétant. Il y a désaccord sur le fait de savoir si moins est toujours vraiment plus et si pire est toujours vraiment meilleur . Vous pouvez être un MIT ou un gars du New Jersey . Il n'y a pas de réponse facile ici.
Prototypage/Quick-n-Dirty/Less is More
Est-ce une tendance typique d'écraser un exemple réalisable dès que possible?
C'est une pratique courante, mais ce n'est pas ainsi que la grande majorité des projets sont abordés. Pourtant, le prototypage est une bonne tendance à mon avis, mais avec une baisse moyenne. Il peut être tentant de promouvoir des prototypes rapides et sales pour des produits réels, ou de les utiliser comme base pour des produits réels soumis à une pression de gestion ou à des contraintes de temps. C'est à ce moment que le prototypage peut revenir vous hanter.
Il y a évidemment avantages du prototypage , mais aussi beaucoup de potentiel pour mauvaise utilisation et abus (beaucoup l'inverse exact des avantages énumérés précédemment comme résultat).
Quand utiliser le prototypage?
Il y a des indices sur les meilleurs types de projets pour utiliser le prototypage :
[...] le prototypage est plus avantageux dans les systèmes qui auront de nombreuses interactions avec les utilisateurs.
[...] le prototypage est très efficace dans l'analyse et la conception de systèmes en ligne, en particulier pour le traitement des transactions, où l'utilisation de dialogues d'écran est beaucoup plus évidente. Plus l'interaction entre l'ordinateur et l'utilisateur est grande, plus l'avantage est grand [...]
"L'une des utilisations les plus productives du prototypage rapide à ce jour a été comme outil pour l'ingénierie itérative des besoins des utilisateurs et la conception d'interfaces homme-machine."
D'autre part:
Les systèmes avec peu d'interaction avec l'utilisateur, tels que le traitement par lots ou les systèmes qui effectuent principalement des calculs, bénéficient peu du prototypage. Parfois, le codage nécessaire pour exécuter les fonctions du système peut être trop intensif et les gains potentiels que le prototypage pourrait fournir sont trop faibles.
Et si vous avez un monstre vert autour, assurez-vous de garder un prototype dans les limites du budget ...
Lorsque vous démarrez la programmation, tout est une preuve de concept même si ce n'est que pour vous. Il y a des cas où une idée nécessite quelque chose de rapide et sale ou un prototype parce que le temps est un facteur clé. La crainte massive des développeurs est que les parties prenantes pensent que la petite application est prête pour la production ou que vous devriez pouvoir ajouter des fonctionnalités au même rythme pour toujours. Vous travaillez sur un grand projet et découvrez que ce n'est pas le cas.
Les grands projets ont généralement des exigences plus complexes, il y a donc une tentation d'essayer de mettre en œuvre des conceptions complexes. Vous passerez beaucoup de temps à les lire, à faire des recherches et à essayer de les mettre en œuvre. Cela peut devenir une perte de temps considérable, mais tout cela fait partie de l'apprentissage et de l'acquisition d'expérience. Savoir quand utiliser un design particulier est difficile et vient généralement avec l'expérience. J'ai essayé "ça" sur "ce" projet et ça n'a pas marché mais maintenant je vois que ça devrait marcher "ici".
Vous devez planifier et planifier beaucoup, mais ne faites pas tout en même temps. Il n'est certainement pas nécessaire de tout faire au début. Je préfère voir quelqu'un créer son premier grand projet comme celui-ci:
- Concevez et discutez un peu.
- Écrivez un tas de code qui fait quelque chose.
- Reconnaître les problèmes et arrêter le codage.
- Soyez sérieux au sujet de la conception et arrêtez de vous soucier de perdre l'élan ou votre code-mojo et ignorez le chef de projet (vous lui rendez service.).
- Maîtrisez le projet. Réparez vos dégâts. Assurez-vous que tout le monde comprend le plan. Gardez le projet sous contrôle.
Parfois, vous atteignez l'une de ces fonctionnalités qui vous inquiète vraiment sur la façon de l'implémenter dans la base de code existante. Ce n'est pas le moment de "simplement le faire fonctionner". J'ai eu un patron qui a dit: "Parfois, vous devez attraper un tabouret au lieu d'un marteau." Il me l'a dit après m'avoir surpris en train de "penser" à mon bureau. Contrairement à beaucoup de patrons, il n'a pas supposé que je me moquais et s'est assuré que je comprenais qu'il voulait que j'en fasse plus. Génie.
En fin de compte, votre code est la conception. Il est soutenu par des documents, des diagrammes, des réunions, des courriers électroniques, des discussions sur le tableau blanc, SO questions, arguments, bavardages, crises de rage et conversations silencieuses autour d'un café. Il y a un point où vous ne pouvez pas concevoir plus et risquer d'avoir à perdre plus de temps de conception à cause des défauts que vous découvrirez seulement en essayant d'écrire le code. En outre, plus vous écrivez de code, plus vous aurez de chance de présenter un défaut de conception que vous ne pouvez pas coder pour sortir. Temps pour le tabouret à nouveau.
Les programmeurs construisent-ils généralement quelque chose qui fonctionne maintenant sans penser à l'avenir?
Oui.
Devraient-ils le faire?
Non.
À première vue, il semblerait que "penser à l'avenir" viole les principes de conception établis comme KISS et YAGNI , qui prétendent qu'il ne devrait pas y avoir d'implémentation de tout ce qui n'est pas nécessaire pour le moment.
Mais ce n'est pas le cas. Penser à l'avenir signifie concevoir un logiciel simple, extensible et gérable. Ceci est particulièrement important pour les projets à long terme. De nouvelles fonctionnalités seront nécessaires avec le temps et une conception solide facilitera l'ajout de nouvelles pièces.
Même si vous n'allez pas travailler sur un projet après l'avoir terminé, vous devez quand même le développer intelligemment. C'est votre travail, et vous devez bien le faire, au moins afin de ne pas oublier comment un bon travail est fait.
Les développeurs agiles ont un dicton, "Vous n'en aurez pas besoin (YAGNI)" qui vous encourage à concevoir ce dont vous avez besoin maintenant plutôt que ce dont vous pensez avoir besoin à l'avenir. Pour étendre une conception pour qu'elle fonctionne à l'avenir, la voie recommandée est de refactoriser.
L'aspect important est de garder à l'esprit les exigences de votre produit lors de la conception et de vous assurer que vous ne concevez pas pour un ensemble d'exigences qui pourraient se produire à l'avenir.
Il y a quelque chose à dire pour les développeurs qui peuvent penser à deux ou trois itérations à l'avance - ils connaissent si bien leurs clients ou le domaine qu'ils peuvent anticiper les besoins futurs avec un haut degré de précision et construire pour eux, mais si vous n'êtes pas sûr, il vaut mieux ne pas passer trop de temps sur des choses dont vous ou les clients n'avez pas besoin.
S'agit-il d'une tendance que les programmeurs suivent généralement lorsqu'ils effectuent un projet comme celui-ci?
Je soupçonne que votre mentor voulait dire que vous ne devriez pas créer de complexité supplémentaire qui pourrait ne pas être requise par la solution finale.
Il est trop facile de penser qu'une application devrait faire ceci et cela et se détourner massivement.
En ce qui concerne les modèles de conception, il convient de rappeler qu'ils sont un moyen de parvenir à une fin. Si vous constatez par expérience qu'un certain modèle de conception ne convient pas malgré votre intuition antérieure, cela pourrait indiquer une odeur de code.
Par exemple, si l'on vous demandait de faire un modèle de preuve de concept, est-ce une tendance typique de simplement écraser un exemple réalisable dès que possible?
Avant de commencer le projet, il vaut la peine de savoir quels jalons existent et s'ils veulent voir un peu de tout (tranche verticale) ou juste chaque partie en détail au fur et à mesure que vous le développez (tranche horizontale). Dans le cadre de la conception initiale, je trouve qu'il vaut la peine de monter à bord de l'application entière, donc même si le code n'est pas écrit, vous pouvez faire une vue en hélicoptère de l'ensemble ou une plongée profonde d'une zone donnée.
Il a dit que j'avais radicalement réfléchi à la tâche à accomplir, et que parce que je n'avais jamais abordé un grand projet comme celui-ci, j'avais passé trop de temps à réfléchir aux modèles de conception. Dans ses mots sages, il m'a dit "F * ck l'avenir, construire pour l'instant".
Je pense que c'est un peu une mentalité de cow-boy de l'autre développeur. La version moderne d'un nerd coriace qui "le fait maintenant". C'est devenu un thème populaire parmi les startups et non merci aux gens de Facebook pour avoir commencé l'expression "mieux faire que de bien le faire".
C'est séduisant. C'est encourageant et offre des visions de développeurs debout autour d'une console applaudissant alors qu'ils lancent leur grand projet dans le monde à temps, en respectant le budget et tout cela parce qu'ils n'ont rien fait d'ingénieur.
C'est un fantasme idéaliste et la vie ne fonctionne pas de cette façon.
Un imbécile se précipitera dans un projet en pensant qu'il peut simplement "le faire" et le faire. Le succès favorisera le développeur qui se prépare aux défis invisibles et traite son métier comme un travail artisanal.
Tout développeur senior peut critiquer, condamner et se plaindre - et la plupart le font!
Pendant qu'il/elle vous dit que vous "réfléchissez" au projet. Je vous félicite d'avoir réellement "réfléchi" en premier. Vous avez fait vos premiers pas pour devenir un meilleur développeur que l'autre gars.
Est-ce une tendance que les programmeurs suivent généralement lorsqu'ils se lancent dans un projet comme celui-ci? Par exemple, si on vous demandait de faire un modèle de preuve de concept, est-ce une tendance typique de simplement écraser un exemple réalisable dès que possible?
C'est exactement ce qu'est une preuve de concept. C'est une tentative de purger quelque chose le plus rapidement possible afin que les gens puissent prendre du recul et le regarder. Il est fait pour éviter les erreurs, les erreurs de direction et le gaspillage de temps/argent.
Il existe différents types de preuves de concept. Vous pouvez créer quelque chose qui est jeté à la poubelle une fois terminé, ou vous pouvez créer quelque chose qui représente un point de départ pour le projet. Tout dépend de ce dont vous avez besoin et de la proximité du concept avec le produit final.
C'est aussi l'occasion de montrer vos idées. Il y a eu des moments où j'ai présenté un prototype qui a amené les choses à un niveau auquel ils ne s'attendaient pas.
La conception est généralement ouverte, il est donc trop facile d'en appliquer trop ou trop peu. Et vous ne connaîtrez le montant exact qu'après la fin ou l'élimination du projet. Ou même pas alors.
Il n'y a pas de recette générale pour réussir, mais vous pouvez apprendre à reconnaître les extrêmes. La conception complète de tout à l'avant ne fonctionne presque jamais au-delà de choses triviales. Il est normal de laisser les composants pour le raffinage et d'avoir simplement l'impression que cela peut être fait, ou il existe un moyen de découvrir les problèmes tôt.
Vous pouvez voir comment fonctionne le développement incrémental si vous n'êtes pas familier. Les méthodes réussies sont généralement itératives à un ou plusieurs niveaux, recherchent une rétroaction serrée et se développent sur un squelette.
Il y a quelques bonnes raisons d'écouter les conseils pour arrêter la planification et commencer à coder;
Après seulement 18 mois en tant que développeur, il est peu probable que vous puissiez anticiper suffisamment bien l'avenir pour le planifier, quel que soit votre GPA universitaire. C'est quelque chose qui est extrêmement difficile à comprendre pour les développeurs brillants mais inexpérimentés, car il s'agit de ne pas savoir ce que vous ne savez pas. Les vieilles mains ont peut-être reconnu cette faiblesse dans votre vision et vous ont sagement encouragé à vous y mettre et à faire de votre mieux.
Les jeunes développeurs peuvent devenir obsédés par la perfection de la conception avant de commencer à coder. Ils peuvent couvrir une peur d'écrire le code (anxiété de performance), ou peuvent avoir un bloc de codeur (comme le bloc des écrivains). Ils se distinguent dans la conception car il n'y a pas de sortie de travail requise. Le jeune dev répondra probablement avec colère à la suggestion qu'ils ont "peur" de quoi que ce soit. Peut-être qu'à la fin du projet, ils se rendront compte qu'ils l'étaient. Le conseil de ne pas vous inquiéter et d'obtenir le codage constitue le seul remède connu pour le bloc du codeur. Une vieille main peut sagement offrir ce conseil.
En présence de contraintes de calendrier rigoureuses, vos chances de réussir le projet sont limitées. Planifiez trop longtemps, et peu importe la qualité du plan, vous ne pouvez pas l'exécuter à temps et vous n'arrivez jamais sur le marché. Commencez à pirater dès le départ, et peut-être aurez-vous de la chance et aurez raison la première fois. Vous livrez le produit par miracle. Ou, peut-être que vous n'êtes pas aussi chanceux et livrez un laitier à moitié cuit mais il arrive sur le marché à temps et vous apprenez quelque chose. Ou peut-être que vous échouez. Mais "peut-être que vous échouez" est toujours une meilleure chance que "jamais arrivé sur le marché" parce que vous avez prévu trop longtemps. La compréhension clé est que vos chances sont limitées dès le début, vous ne perdez donc rien en piratant. Votre responsable sait peut-être qu'il y a peu de chances de succès et a assigné une ressource junior tout comme un exercice d'apprentissage. Nous apprenons mieux de l'échec que du succès. Vous demandez-vous peut-être: "Quand puis-je avoir un projet entier?"
Il faut un développeur assez introspectif et sans ego pour voir ses propres imperfections, alors méditez un peu avant de lire le reste, de peur de vous donner des excuses pour ignorer vos propres faiblesses ...
Tous les développeurs ne sont pas particulièrement bons pour l'analyse, la planification et d'autres tâches qui nécessitent de la réflexion. La pensée est dure et dégueulasse. Il nécessite une sorte de sueur mentale qui vous met mal à l'aise et essore après une journée de travail. Ce n'est tout simplement pas aussi amusant que d'entrer en état de flux avec vos deux boîtes de Monster et votre rock bruyant et codant, codant, codant. Les développeurs qui n'aiment pas penser résisteront à l'idée que la planification est une bonne idée. Ils recommandent des méthodologies de développement qui ne nécessitent pas de planification préalable. Ils aiment les entreprises et les gestionnaires qui ne mettent pas l'accent sur la planification. Ils gravitent vers des emplois où le coût de la non-planification n'est pas trop élevé. Ils apprécient toutes les sessions de codage de nuit et la distribution de ce correctif aux clients dont toute l'activité est en panne en raison d'un bogue. (Et peu importe que la livraison de code cassé à un client soit un crime capital).
Certains développeurs ont même réalisé que faire fonctionner quelque chose assez bien pour faire une démonstration signifie que le faire fonctionner complètement et en toutes circonstances peut être différé, et peut-être même repoussé sur un autre développeur, alors qu'ils reçoivent des félicitations pour "faire le travail" au départ.
Il y a des managers qui ne peuvent eux-mêmes repérer une tendance avant qu'elle ne soit déjà sur Facebook. Au lieu de trouver un emploi dans la gestion d'un magasin de pneus discount, ces gestionnaires se font un problème d'avoir besoin du code en cours d'exécution vendredi. Ils ne veulent pas entendre que vous devez concevoir l'API ou tester si votre algorithme est évolutif. Pour eux, ce n'est que du mumbo technologique. Ils vous encourageront à coder car c'est tout ce qu'ils ont compris à propos des logiciels lorsqu'ils écrivaient des scripts Perl pour aider les clients à transférer leurs fichiers. (Ils avaient le titre d '"ingénieur logiciel" dans leur premier travail de vente. Qui savait que le logiciel allait être si ennuyeux et dur?)