Je travaille en tant que développeur d'applications depuis un an et demi (je ne sais pas longtemps) et je viens de recevoir mon premier grand projet.

Inutile de dire que cela ne s'est pas très bien passé, alors j'ai demandé conseil à un programmeur principal 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 d'avoir passé trop de temps à réfléchir aux modèles de conception. Dans ses paroles avisées, il m'a dit "Fachons l'avenir, construisez pour le moment".

Est-ce une tendance que les programmeurs suivent généralement lorsqu’il s’agit d’un projet comme celui-ci? Par exemple, si on vous demandait de créer 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 que cela 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 indépendants de notre volonté (le marché que nous visons perdra de l'intérêt si pas leur montrer quelque chose) et son conseil s’est avéré très efficace pour cette tâche particulière.

Capitaine évident à la rescousse!

Je serai capitaine évident ici et dirai qu'il y a un juste milieu à trouver.

Vous voulez construire pour le futur et éviter de vous enfermer dans un choix technologique ou un mauvais design. Mais vous ne voulez pas passer 3 mois à concevoir quelque chose qui devrait être simple, ni à ajouter des points d'extension pour une application rapide et sale qui aura une durée de vie de 2 ans et qui n'aura probablement pas de projets de suivi.

Il est difficile de faire la distinction, car vous ne pouvez pas toujours prédire le succès de votre produit et si vous devez l'étendre ultérieurement.

Construire pour maintenant si ...

• le projet va être abandonné
• le projet a une courte durée de vie
• le projet ne devrait 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 devraient être développés pour l'instant. Assurez-vous d’avoir des exigences claires et d’y répondre 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 code pas comme un cochon non plus.

Laissez le problème général pour plus tard, si cela peut s'avérer nécessaire et que l'effort 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 aura des projets de suivi ou des versions de service avec des améliorations

Si vous construisez pour quelque chose de public, ou que cela va être réutilisé dans d'autres projets, alors vous avez une probabilité beaucoup plus grande qu'un mauvais design revienne vous hanter, alors vous devriez porter plus d'attention à cela. Mais ce n'est pas toujours garanti.

Des lignes directrices

Je dirais que vous adhérez au mieux aux principes suivants et que vous devez vous mettre à la tâche de concevoir des produits efficaces et adaptables:

• sache que YAGNI ,
• KISS ,
• Chaque fois que vous avez envie de gratter une démangeaison et de penser à un ajout, écrivez-le. Examinez 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 personnellement tendance à trop penser et à trop d'ingénieurs. Il est vraiment utile d’écrire des idées et de 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 me restent à l’arrière de la tête et je dois me forcer à ne pas les planifier.

La meilleure façon de coder sans trop d'ingénierie et sans vous bloquer pour plus tard est de vous concentrer sur un bon design minimal. Décomposez bien les éléments en composants que vous pouvez étendre ultérieurement, mais sans penser à la manière dont ils peuvent être étendus ultérieurement. Vous ne pouvez pas prédire l'avenir.

Il suffit de construire des choses simples.

Dilemme

Sur ingénierie

Est-ce une tendance que les programmeurs suivent généralement lorsqu’il s’agit d’un projet comme celui-ci?

Enfer ouais. C'est un dilemme connu, et cela montre seulement que vous vous souciez du produit. Si vous ne le faites pas, c'est plus inquiétant. Il existe un désaccord sur le point de savoir si moins est toujours vraiment plus et si pire est toujours vraiment meilleur . Vous pouvez être un gars du MIT ou du New Jersey . Il n'y a pas de réponse facile ici.

Prototypage / Rapide-sale / Moins c'est plus

Est-ce une tendance typique d’éliminer un exemple réalisable dès que possible?

C'est une pratique courante, mais ce n'est pas ainsi que l'on aborde la grande majorité des projets. Néanmoins, le prototypage est une bonne tendance à mon avis, mais avec un inconvénient moyen. 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 à des pressions de gestion ou à des contraintes de temps. C'est à ce moment que le prototypage peut revenir vous hanter.

Le prototypage présente des avantages évidents , mais aussi beaucoup de risque d' abus et d'abus (de nombreux résultats étant l'inverse exact des avantages mentionnés précédemment).

Quand utiliser le prototypage?

Il existe des indices sur les meilleurs types de projets pour utiliser le prototypage :

Le prototypage est le 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 de transactions, où l'utilisation de dialogues à l'écran est beaucoup plus évidente. Plus l'interaction entre l'ordinateur et l'utilisateur est importante, plus l'avantage [...]

"L’une des utilisations les plus productives du prototypage rapide à ce jour a été l’outil utilisé pour l’ingénierie itérative des besoins des utilisateurs et la conception d’interfaces homme-ordinateur."

D'autre part:

Les systèmes avec peu d'interaction utilisateur, tels que le traitement par lots ou les systèmes qui font 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, 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é. Les développeurs 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 est donc tentant d'essayer de mettre en œuvre des conceptions complexes. Vous passerez beaucoup de temps à les lire, à les rechercher et à 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. Il est difficile de savoir quand utiliser un modèle particulier et cela 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 beaucoup, mais ne le faites pas tous en même temps. Ce n'est certainement pas nécessaire de tout faire au début. Je préférerais que quelqu'un crée son premier grand projet comme celui-ci:

1. Concevez et discutez un peu.
2. Ecrivez un tas de code qui fait quelque chose.
3. Reconnaître les problèmes et arrêter le codage.
4. Prenez au sérieux la conception et arrêtez de vous inquiéter de perdre votre élan ou votre code-mojo et ignorez le chef de projet (vous lui rendez service.).
5. Obtenez le projet sous contrôle. Réparez vos dégâts. Assurez-vous que tout le monde comprend le plan. Gardez le projet sous contrôle.

Parfois, vous utilisez l'une de ces fonctionnalités qui vous inquiète vraiment pour son implémentation dans la base de code existante. Ce n'est pas le moment de "simplement le faire fonctionner". Un chef m'a dit: "Parfois, il faut prendre un tabouret à la place d'un marteau." Il m'a dit cela après m'avoir surpris en train de "penser" à mon bureau. Contrairement à beaucoup de patrons, il n'a pas supposé que j'étais gaffeur et s'est assuré de bien comprendre qu'il voulait que je 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 courriels, des discussions au tableau blanc, des questions SO, des arguments, des discussions, des accès de colère et des conversations silencieuses autour d'un café. À un moment donné, vous ne pouvez plus concevoir et vous risquez de perdre plus de temps de conception à cause des défauts que vous ne découvrirez qu'en essayant d'écrire le code. En outre, plus vous écrivez de code, plus vous aurez de chances d'introduire un défaut de conception que vous ne pourrez pas coder. Temps pour le tabouret encore.

Les programmeurs construisent-ils généralement quelque chose qui fonctionne maintenant sans penser à l'avenir?

Oui.

Doivent-ils le faire?

Non.

À première vue, il semblerait que "penser à l'avenir" viole les principes de conception établis tels que KISS et YAGNI , qui affirment qu'il ne devrait pas être mis en œuvre tout ce qui n'est pas requis pour le moment.

Mais en réalité ça ne marche pas. Penser à l'avenir signifie concevoir des logiciels simples, extensibles et faciles à gérer. 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 le développer intelligemment. C'est votre travail, et vous devriez le faire bien, au moins pour ne pas oublier la qualité du travail accompli.

Les développeurs agiles ont un dicton "Vous n’en aurez pas besoin (YAGNI)" qui vous encourage à concevoir pour ce dont vous avez besoin maintenant plutôt que pour ce que vous pensez avoir besoin à l’avenir. Pour prolonger une conception afin qu'elle fonctionne dans le futur, la méthode recommandée consiste à refactoriser.

L’important est de garder à l’esprit les exigences de votre produit lors de la conception et de vous assurer que vous ne concevez pas une foule d’exigences susceptibles de 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 une grande précision et les développer, mais en cas de doute, il est préférable de ne pas consacrer trop de temps à des tâches inutiles pour vous ou vos clients.

Est-ce une tendance que les programmeurs suivent généralement lorsqu’il s’agit d’un projet comme celui-ci?

Je soupçonne que ce que votre mentor voulait dire, c'est que vous ne devriez pas créer de complexité supplémentaire qui ne serait peut-être pas requise par la solution finale.

Il est trop facile de penser qu'une application doit faire ceci ou cela et se laisser détourner de façon massive.

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 avec expérience qu'un certain motif de conception ne vous convient pas, cela peut indiquer une odeur de code.

Par exemple, si on vous demandait de créer 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 lancer le projet, cela vaut la peine de se renseigner sur les jalons et de déterminer s'ils souhaitent voir un peu de tout (tranche verticale) ou seulement chaque partie en détail au fur et à mesure que vous la développez (tranche horizontale). Dans le cadre de la conception initiale, je trouve intéressant de raconter l'histoire de l'application dans son intégralité. Même si le code n'est pas écrit, vous pouvez créer une vue en hélicoptère de l'ensemble ou effectuer une plongée profonde dans 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 projet aussi important, j'avais passé trop de temps à réfléchir aux modèles de conception. Dans ses paroles avisées, il m'a dit "Fachons l'avenir, construisez pour le moment".

Je pense que c'est un peu une mentalité de cow-boy de l'autre développeur. La version moderne d'un nerd difficile qui "le fait maintenant". C'est devenu un thème populaire parmi les startups et nous ne remercions pas les gens de Facebook d'avoir lancé la phrase "Il est préférable de le faire que de le faire correctement".

C'est attrayant. 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, dans les délais, dans les budgets et tout simplement 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 inédits et traite son métier comme un travail d'artisan.

Tout développeur expérimenté 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 de réellement "penser" en premier. Vous avez fait vos premiers pas en tant que meilleur développeur que l’autre type.

Est-ce une tendance que les programmeurs suivent généralement lorsqu’il s’agit d’un projet comme celui-ci? Par exemple, si on vous demandait de créer 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 pour écraser quelque chose le plus rapidement possible afin que les gens puissent prendre du recul et le regarder. C'est fait pour éviter les erreurs, les erreurs d'orientation et les pertes de temps / argent.

Il existe de nombreux types de preuves de concepts. Vous pouvez créer quelque chose qui est jeté à la poubelle lorsque vous avez 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é entre le concept et le produit final.

C'est aussi l'occasion de démontrer vos idées. Il m'est parfois arrivé de présenter un prototype qui prenait les choses à un niveau inattendu.

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 du projet ou son rejet. 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 ce qui se passe à l’avant ne va presque jamais au-delà de choses triviales. Vous pouvez laisser des composants pour le raffinage et avoir le sentiment que cela peut être fait, ou il existe un moyen de détecter les problèmes plus tôt.

Vous pouvez vérifier comment fonctionne le développement incrémental si vous ne le connaissez pas. Les méthodes qui réussissent sont généralement itératives à un ou plusieurs niveaux, recherchent un feedback étroit et se développent sur un squelette.

Il y a quelques bonnes raisons d'écouter les conseils pour arrêter de planifier et commencer à coder;

1. Après seulement 18 mois en tant que développeur, il est peu probable que vous puissiez anticiper suffisamment l'avenir, quel que soit votre avenir. Il est extrêmement difficile à comprendre pour les développeurs brillants mais inexpérimentés, car il s’agit avant tout de ne pas savoir ce que vous ne savez pas. Les personnes âgées ont peut-être reconnu cette faiblesse dans votre vision et vous ont sagement encouragé à y entrer et à faire de votre mieux.

2. Les jeunes développeurs peuvent devenir obsédés par le perfectionnement du design avant de commencer à coder. Ils peuvent couvrir une peur d'écrire le code (anxiété liée aux performances) ou avoir un blocage du codeur (comme le blocage des écrivains). Ils sont de conception courante car il n’ya pas de travail requis. Le jeune dev va probablement réagir avec colère à la suggestion qu'ils ont "peur" de rien. Peut-être qu'à la fin du projet, ils se rendront compte qu'ils l'étaient. Le conseil de ne pas s'inquiéter et d'obtenir le codage constitue le seul remède connu pour le blocage du codeur. Une vieille main peut sagement offrir ce conseil.

3. En présence de contraintes de calendrier sévères, vos chances de mener à bien le projet sont limitées. Planifiez trop longtemps et quelle que soit la qualité de votre plan, vous ne pouvez pas l'exécuter à temps et vous n'arrivez jamais sur le marché. Commencez dès le début par le piratage, et peut-être aurez-vous de la chance et aurez-vous raison du premier coup. Vous livrez le produit miraculeusement. Ou alors, peut-être que vous n'êtes pas aussi chanceux et que vous 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 cote que "jamais arrivé au marché" parce que vous avez planifié trop longtemps. La compréhension clé est que vos chances sont limitées dès le début, de sorte que vous ne perdez rien en piratant. Votre responsable sait peut-être qu'il y a peu de chance de réussir et a affecté une ressource junior simplement à un exercice d'apprentissage. Nous apprenons mieux de l'échec que du succès. Avez-vous peut-être demandé: "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 moment avant de lire le reste, de peur que vous ne vous donniez des excuses pour oublier vos propres faiblesses ...

Tous les développeurs ne sont pas particulièrement doués pour l'analyse, la planification et d'autres tâches qui nécessitent une réflexion. La pensée est dure et dégueulasse. Cela nécessite une sorte de sueur mentale qui vous laisse mal à l'aise et essorée après une journée de travail. Ce n’est tout simplement pas aussi amusant que de passer à l’état d’écoulement avec vos deux canettes de Monster et que votre rock se met à jouer fort, codant, codant, codant. Les développeurs qui n'aiment pas penser vont résister à 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 nocturnes et la transmission de ce correctif aux clients dont l'activité est en panne à cause d'un bogue.

Certains développeurs ont même réalisé que faire fonctionner quelque chose assez bien pour une démonstration signifiait que le faire fonctionner complètement et dans toutes les circonstances pouvait être différé et peut-être même renvoyé à un autre développeur, tout en recevant des félicitations pour avoir "fait le travail" au départ.

Il y a des gestionnaires qui ne peuvent pas eux-mêmes déceler une tendance avant que celle-ci ne soit déjà sur Facebook. Au lieu de chercher un emploi dans la gestion d’un magasin de pneus à prix réduit, ces responsables s’attachent à ce qu’ils aient besoin du code en cours d’exécution le vendredi. Ils ne veulent pas savoir que vous devez concevoir l'API ou vérifier si votre algorithme est évolutif. C’est juste pour eux la technologie mumbo-jumbo. Ils vous encourageront à coder car ils ne comprenaient tout simplement pas les 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 les logiciels allaient être si ennuyeux et difficiles?)

Montre-moi ton code et je te dirai qui tu es

Votre code est votre carte de visite. Si vous écrivez du code compliqué, qu'est-ce qui vous parle de vous aux autres? Pensez à cela. Chaque fois que nous trouvons au pouvoir un très mauvais fragment de code, nous nous demandons qui l'a écrit et comment diable a-t-il passé à l'université?

Vous devenez ce que vous codez

Votre code est votre programme pour la vie.

Un programmeur écrivant du mauvais code, c'est comme un danseur de ballet dansant dans un club de strip-tease

Certaines personnes ne s’inquiètent pas de danser dans un club de strip-tease. Mais s’ils sont des danseurs de haut niveau, ils gaspillent leurs compétences. Si vous êtes un pauvre danseur mais que vous avez de belles jambes, vous pouvez vous déshabiller pour beaucoup.

Enfin, vous devriez lire la nouvelle de Gogol "Le Portrait" et vous devriez être prévenu par l’histoire du personnage principal. Votre ami est semblable à l'homme du portrait. Il vous attire avec de l'argent, mais vous en paierez le prix fort.