[Boulot] Créer un formulaire gigantesque, on me demande de ne pas mettre en place les checks côtés serveur

Salut tout le monde,

Au boulot on m’a demandé de mettre en place un formulaire absolument gargantuesque avec environ 15 champs, certains dépendant d’autres en terme d’affichage ou d’activation, d’autres étant dynamiquement générés au clic de l’internaute.

Ce formulaire doit être envoyé dans deux mails, pas d’enregistrement en base de données.

Donc j’ai voulu faire les choses bien, c’est-à-dire mettre en place le HTML, le CSS, puis le JS pour tous les checks et l’aspect dynamique. Et aussi les vérifs côtés serveurs (vérifier que si tel champ est rempli, alors tel autre champ doit être rempli, que les champs ne soient pas vides, etc. (autres vérifs), échapper les caractères spéciaux/HTML).

Mon H+1 m’a engueulé parce que j’ai passé 3h à mettre en place le HTML, le CSS, 1 aprèm à mettre en place le JS et 2aprèm à mettre en place le PHP. Tout ce temps passé me semble tout à fait normal au vu de la complexité du formulaire (15 champs, des dépendances d’affichage/d’activation, du dynamisme). Il m’a dit que j’aurais pas dû faire les checks côté serveur …

Bon. Qu’est-ce que vous auriez fait à ma place ?

Difficile de répondre, parce que ça dépend énormément de ton contexte.

Cela dit, il n’a pas complètement tort en considérant que les checks côté serveur sont inutiles si tu n’insères rien dans la BDD : ces vérifications ne protègent rien, donc ce sont les premières à pouvoir sauter dans l’absolu. Enfin à sa place à lui, je ne t’aurais pas engueulé, mais expliqué gentiment pour la prochaine fois que c’était une perte de temps.

À quel point la feature était-elle urgente ?

Je vois aussi un problème de communication en amont qui n’a pas permis d’éviter le choix que tu as choisi. Si tu travailles en assistance de quelqu’un, tu aurais pu avoir une estimation de temps et une rapide description de ce que tu devais faire.

Quand on te donne une tâche à faire (qui est vague ou inhabituel), il peut toujours être bien de reformuler ou de décrire rapidement ce que tu vas faire en une phrase. Ceci permet d’avoir confirmation de ce que tu dois faire et peu aussi permettre de glisser une légère estimation de temps à l’intérieur, dans ton cas ça aurait été de dire : "Je fais le formulaire, l’affichage HTML/CSS, une vérification JS et une vérification PHP puis l’envoie, ce qui devrait me prendre 3 demi-journées.". Cette reformulation permet souvent d’avoir une correction de ton interlocuteur en cas d’erreur.

Mon H+1 m’a engueulé parce que j’ai passé 3h à mettre en place

Dans certain cas, quoi que tu choisisses ça finira par une engueulade.

Avant de commencer demande toi peut-être : "Est-ce que cette vérification est utile pour le temps que ça me coûte ? En son absence qu’elles sont les risques ?".

Si le mail est lu par un humain, on peut s’interroger de l’utilité d’une deuxième vérification en PHP des champs obligatoires et vides. Par contre pour sûr, la vérification que je n’oublierais pas est une boucle pour intercepter les injections MIME/d’header sur chacun des champs.

Je vois deux problèmes et tous les deux sont des problèmes d’organisation dans le cas que tu décris :

1. Tu as réalisé une tâche sans que toi et ton supérieur ne soient d’accord sur ce qu’il fallait faire,
2. Tu as réalisé une tâche sans que vous soyez d’accord sur le temps à y accorder.

(ce sont probablement deux facettes du même problème)

Ce que ça montre, c’est qu’il y a un problème d’organisation dans ton entreprise :

• Ce n’est pas normal qu’un manager donne des directives aussi floues à ses équipes,
• Ce n’est pas normal que tu te lances dans la réalisation d’une tâche aussi floue sans l’avoir cadrée.

Les détails dépendent à la fois de ton poste dans l’entreprise, de ton expérience et de la façon dont le projet est géré ; mais face à une tâche aussi floue, la bonne pratique de mon point de vue, c’est :

1. Tu étudies et cadres ce qu’il y a à faire,
2. Tu valides avec qui de droit,
3. Tu réalises.

L’enchainement des 3 points est pour moi primordial : on ne devrait jamais réaliser un sujet quelconque sans savoir quelles sont les contraintes associées (en terme de temps alloué, de qualité demandée, de sécurité…)

Le point 1 (étude / cadrage) dépend là encore de ton poste, de ton expérience, de la gestion du projet et aussi de la tâche en question. Ça peut aller de la simple reformulation en fin de réunion comme le propose A-312 à une étude complète avec plusieurs solutions chiffrées. Évidemment, ce travail est à proportionner à la tâche à effectuer (c’est une erreur classique : passer trop de temps à concevoir un détail mineur).

Le point 2 permet de faire l’arbitrage entre les différentes contraintes. C’est fréquent d’avoir plusieurs chemins de réalisation possibles, chacun avec différents avantages / inconvénients. Il faut que la solution choisie soit adaptée au projet, et pour ça il faut connaitre les contraintes du projet, ce qui n’est pas toujours le cas. Ici, tu as fait le choix d’une solution sécurisée, or c’était une solution rapide qui était attendue – ce qui ne t’était pas précisé, mais que tu n’as semble-t-il pas demandé non plus.

Il est fréquent qu’on te demande quelque chose d’irréalisable (typiquement, faire vite un programme fiable et performant). Dans ce cas, n’hésite pas à proposer plusieurs solutions et à décrire leurs avantages et limites : ça permettra à qui de droit de choisir le meilleur compromis en fonction de contraintes que tu ne connais pas forcément, ou servira de base de discussion, voire parfois permettra de comprendre qu’il faut allouer des ressources supplémentaires pour que ça marche.

Si jamais tu as une liberté totale (ou plus vraisemblablement un manque d’information malgré les demandes) sur un critère, tu fais au mieux mais surtout tu préviens de ce que tu vas faire, si possible par écrit. Ça évite qu’on puisse te le reprocher (et si on te le reproche quand même, tu auras de quoi répliquer).

Et donc, une fois que tu t’es mis d’accord sur ce qu’il y a à réaliser et en combien de temps (ou une fois que tu as constaté qu’il n’y a pas d’information récupérable et que tu as prévenu de ce que tu allais faire), là seulement tu réalises.

Dans ton cas particulier, en l’absence d’autre information, une bonne technique est de sortir un minimum vital (le formulaire avec le minimum de vérifications pour éviter que ça n’explose), puis si besoin j’aurais codé les validations complémentaires. Mais ça dépend tellement de plein de paramètres qu’on a pas que c’est dur d’être plus précis.

PS : par contre, si tu peux profiter de cette mésaventure pour parler de l’organisation du travail, du découpage des tâches, de ce qui est attendu de toi et des priorités du projet (on ne traite pas un POC comme une application critique), ça peut être très bénéfique pour le futur.

Mon H+1 m’a engueulé parce que j’ai passé 3h à mettre en place le HTML, le CSS, 1 aprèm à mettre en place le JS et 2aprèm à mettre en place le PHP.

Franchement, ça me paraît pas si énorme. On sait tous que les formulaires c’est une super tannée en soi, quand on a pas de framework pour les générer automatiquement. Styliser les formulaires, ça aussi c’est connu pour être long et fastidieux pour que tout s’aligne bien et que le rendu final soir agréable à l’œil. Pour le côté serveur, c’est aussi un peu chiant à faire si tu n’as pas, là encore, un framework pour te mâcher le boulot de la validation d’input.

Sinon, juste comme ça : c’est quoi un H+1 ? C’est comme un N+1 ?

En plus des réponses ci dessus avec lesquelles je suis d’accord,

Le dernier formulaire de 15 champs ça m’a pris 3h aussi pour le HTML et CSS. Rien de choquant de ce côté là pour quelqu’un qui connaît le HTML mais ne fait pas des formulaires à longueur de journée. Je pense que les checks en JS m’auraient aussi pris du temps. Pour moi les durées sont normales pour quelqu’un qui ne fait pas ça tous les jours.

Pardon, N+1 !

OK merci pour toutes vos réponses et conseils ! Je vois qu’on partage le même avis !

Y’a un truc que je comprends pas : ici tu nous parles d’une mésaventure au boulot, mais dans cet autre topic tu précises que tu es au chômage depuis 5 mois. Du coup, le cas que tu nous soumets ici est un vieil exemple, ou il y a une autre subtilité ?

Oui c’est un vieil exemple !

Ah, je pensais que cette promesse d’embauche c’était concrétisé

Je pense qu’elle s’est concrétisée. Une promesse d’embauche, n’est pas une embauche. C’est un engagement de l’employeur d’embaucher, …, plus tard. Selon des termes négociés en amont.

Après, je suis pas juriste. C’est ce que m’ont expliqué les RHs que j’ai rencontré. Ça s’utilise souvent pour débaucher un salarié d’une autre entreprise (qui peut alors démissionner plus sereinement)

@ache @A-312 j’ai fait ma première journée aujourd’hui donc oui elle s’est concrétisée !

Post qui décrit ma première journée : https://zestedesavoir.com/forums/sujet/13446/je-reprends-le-boulot-apres-plusieurs-mois-de-chomage-demain/?page=1#p213278

Oui, et c’est un engagement fort. Si l’une ou l’autre des parties change d’avis au dernier moment alors qu’une promesse d’embauche est signée, elle est tenue de payer une somme assez dissuasive en dédommagement.

On m’a toujours dit qu’une promesse d’embauche "valait un contrat", en termes de garanties.