Ce n'est pas du codage "Genius" s'il n'est maintenable par personne en dehors des codeurs originaux (s'ils se souviennent de ce qu'ils ont fait et pourquoi).

L'implication ici est que ces génies sont entrés dans le code -base, a ajouté leurs changements, les a testés à l'unité sans trop se demander si leur part de génie a interféré avec la tranche de génie d'un autre gars et l'a complètement brisée. Et je suppose (d'après l'attitude gung-ho), qu'il n'y a pas de documentation sur les changements ou de documentation fonctionnelle mise à jour, donc personne ne sait maintenant quels changements ont été apportés, par qui, dans quel but ou qui les a signés.

Et c'est la ligne que vous tournez vers la gestion

C'est peut-être génial, mais c'est impossible à maintenir.

Tout ce que vous pouvez faire pour le moment est en quelque sorte le faire fonctionner avant la date limite, puis analyser le diable et le rendre maintenable par étapes.

Si c'est vraiment ne peut pas fonctionner avant la production, alors c'est à vous d'émettre un «No Go» et d'en indiquer les raisons. Espérons que la direction comprendra et retardera le déploiement.

Ne tenez pas compte de la politique dans ce domaine - c'est le travail de votre responsable. Dites-lui simplement les faits et laissez-le gérer les retombées.

En règle générale, la direction "veut des solutions, pas des problèmes". En tant que tel, dire "il y a des secrets codés en dur dans le code" est un problème, alors que "Résoudre l'échec réglementaire des secrets codés en dur: 0,5 jour" est une solution.

Je prendrais quelques heures pour évaluer correctement le code, et documentez tout ce que vous voulez changer / corriger pour en faire un "produit minimum viable". S'il existe des outils d'analyse statique objectifs qui peuvent vous aider ici, tant mieux - 100 problèmes de sécurité dans Code Climate ou tout ce qui est plus difficile à discuter que votre opinion professionnelle. Cependant, votre opinion compte ici, et vous essayez de donner une évaluation honnête.

"Produit minimum viable" (MVP) est un terme légèrement subjectif. C'est vraiment à vous d'en faire à peu près assez pour exécuter quelque chose en production et laisser certains ou tous les utilisateurs proposés l'examiner. L'administrateur système peut faire des redémarrages progressifs toutes les heures, et il peut y avoir des configs et des secrets codés en dur tout au long du code, mais tant qu'il ne montre pas à la mauvaise personne vos coordonnées bancaires, il est prêt à fonctionner. Vous corrigerez tous les bugs, problèmes et mauvaises pratiques plus tard.

Vous avez maintenant une liste (un backlog), que vous devez hiérarchiser. Les estimations sont difficiles, mais essayez de quantifier la quantité de travail que chaque élément est susceptible de représenter. Assurez-vous de marquer tout cela comme une estimation et non comme un engagement.

Mettez tout cela par écrit - commencez par un résumé en un ou deux paragraphes des problèmes et des solutions. Ensuite, votre `` backlog '' complet (avec une ligne rouge, en dessous desquels se trouvent les tâches que vous pourriez faire après être passé en production). Enfin, des annexes avec une analyse de code statique ou tout ce que vous avez.

Ensuite, réservez un peu de temps avec votre patron et toute autre personne qui est vraiment, correctement pertinente (incluez suffisamment de personnes, mais personne qui n'est pas obligée à 100% d'être là). Incluez votre rapport en tant que «pré-lecture» dans votre invitation à une réunion. Présentez vos résultats (en résumé - pas plus de 10 à 15 minutes de conversation) et attendez les questions. Reportez-vous à votre rapport dans autant de réponses que possible.

Enfin, attendez une décision. La réaction de votre direction est importante. S'ils décident d'investir dans les solutions que vous avez proposées, alors tout va bien. S'ils choisissent de ne pas le faire parce qu'ils vont remplacer la solution par autre chose, alors ce n'est pas grave. S'ils essaient de vous amener à faire quelque chose «à bon marché» ou «plus rapidement» que vous ne l'avez proposé, vous devriez alors examiner votre position attentivement, car ils demandent des choses irréalistes et ne sont pas prêts à leur fournir les ressources appropriées. soit - c'est généralement le signe qu'ils ne décideront pas soudainement d'investir une fois le code en production non plus.

D'un point de vue pratique:

Votre direction ne sait rien du code. C'est une boîte magique qui fait la chose. On leur a promis la chose, ils ont probablement vu une présentation sur la chose. La chose est réelle. Ils le veulent. Ils ont payé pour cela et maintenant cela doit fonctionner.

J'ai rencontré que vous deviez travailler "autour" de la gestion, pas autant les intégrer dans le projet ou la prise de décision. Ils ne comprennent pas vos problèmes, vos besoins ou ce qu'est une bonne pratique.
Habituellement, ils ne se soucient pas de savoir comment, tant que cela fonctionne. Le tout pourrait être réécrit, à condition qu'en surface, il ressemble à la chose.

Je vous suggère de traiter ceci comme un nouveau projet.

• Analysez le but de la chose.
• Voyez si vous pouvez créer l'objet en code propre.
• N'utilisez que le mauvais code comme référence pour glaner ce qui a été discuté à ce sujet et comment il devrait fonctionner en théorie.
• Récupérez le code utilisable, refactorisez-le en quelque chose de pratique.
• Codez la chose proprement dans les deux mois.
• Une fois terminé, dites à la direction, c'est fait, la chose fonctionne.
• Sous aucune circonstance, mentionnez que vous avez "mis au rebut" l'ancien code. Dites simplement que vous l'avez remanié pour le rendre conforme aux spécifications.

La direction regarde la boîte noire et dit hourra.

Si vous dites que le code est nul, votre direction a deux choix: vous faire confiance ou vous renvoyer. Ne pas vous faire confiance et vous garder sur le projet n'est pas un choix rationnel.

Et si vous ne comprenez pas le code parce qu'il est trop intelligent (j'ai vu du code que je ne voulais pas comprendre, mais pas de code que je ne pouvais pas comprendre), alors ce code doit être supprimé.

Il est temps de développer vos compétences en rédaction technique. Créez un rapport. Expliquez brièvement que vous ne pourrez pas rendre le produit viable dans 2 mois. Proposez ensuite une ou plusieurs solutions dans votre rapport et une estimation du temps et des avantages / inconvénients de ces approches. Par exemple:

'Option 1: une réécriture complète. Mon estimation initiale est que cela prendra 11 mois, mais cela nous laissera une base de code robuste, fonctionnelle et maintenable. (en aparté, bonne chance pour que cela soit approuvé, chaque développeur dans le monde venant sur un nouveau projet veut faire une réécriture complète)

'Option 2: jeter plus de développeurs sur le problème. Nous aurons besoin de X développeurs supplémentaires pour sortir cela dans 2 mois. Cela coûtera plus cher, et nous perdrons du temps de développement sur d'autres projets, mais nous allons (probablement) le sortir de la porte ».

« Option 3, je travaille de mon mieux, et j'essaie de réussir autant que possible. Je ne pense pas pouvoir terminer le produit dans son intégralité, mais voici un exemple de MVP que je pense pouvoir faire. Y a-t-il des fonctionnalités que vous aimeriez que je priorise par rapport à celles que j'ai présentées ici? »

Et ainsi de suite.

Puis, en annexe, décrivez brièvement (dans termes simples) les problèmes tels que vous nous les avez décrits, et pensez à fournir des références pour avoir une certaine crédibilité derrière vos arguments.

L'idée est de présenter immédiatement des solutions afin que vos responsables puissent prioriser ce produit. Est-ce qu'ils peuvent attendre plus longtemps? Ou ont-ils besoin d'y consacrer plus de ressources. Soyez raisonnable et professionnel.

Modifié pour se concentrer davantage sur l'offre de solutions que sur la critique du code, conformément aux commentaires ci-dessous.

Vous devez ébranler la réputation du doodad magique.

Vous ne pouvez pas leur dire que ça craint, parce qu'alors ils se sentiront stupides et ils décideront que vous êtes stupides afin qu'ils puissent redevenir intelligents.

Si vous l'avez déjà fait compiler, je l'ignorerais. C'était une opportunité d'éliminer le doodad magique, mais maintenant que vous l'avez corrigé, vous ne voulez pas vous en plaindre.

Je commencerais par le codé en dur, non- mots de passe cryptés. Amenez-les à la direction et faites remarquer que cela peut causer de nombreux problèmes. Corrigez les mots de passe et continuez.

Les fonctions non appelées et les API de charabia peuvent attendre. S'ils ne font rien, ils ne peuvent probablement rien casser non plus. Je passerais aux adresses IP ou aux bibliothèques.

Lorsque vous trouvez un problème avec le doodad magique, assurez-vous d'en informer la direction, puis dites-leur comment vous l'avez résolu . Au fil du temps, vous deviendrez leur doodad magique, ce qui est formidable.

Le regroupement des problèmes que vous voyez sous une forme structurée liée à leur impact commercial pratique vous aidera beaucoup:

Réfléchissez aux problèmes et aux preuves que vous pouvez trouver, et regroupez-les de cette façon :

1. Observations qui suggèrent, si sa mise sur le marché, il échouera dans l'utilisation et le contrecoup . Il ne peut pas être compilé. Il y a des erreurs logiques dans le code. L'entrée n'est pas validée. Les données ne sont pas traitées de manière à garantir une forte probabilité de non-corruption. Les aspects de sécurité ne sont pas en place et les données pourraient être exfiltrées / piratées. Il n'est pas garanti que les fonctions clés fonctionnent pour une bonne raison, ou vous pouvez montrer que les quelques-unes que vous avez vérifiées parmi elles ne fonctionnent souvent pas comme prévu. Ce genre de chose.
2. Des observations suggérant qu'il pourrait bien y avoir des problèmes qui ne se révéleront pas lors des tests, mais qui entraîneront un risque important de problèmes s'ils sont mis sur le marché Comme ci-dessus, mais le n ° 1 est ce que vous avez trouvé, c'est une preuve qui suggère que des problèmes non trouvés importants sont à prévoir / anticipés / considérés comme un risque important. Par exemple, si vous avez corrigé des cas extrêmes liés à un mauvais traitement dans certains cas de validation de données, cela suggère que d'autres cas peuvent exister et ne pas être connus, ce qui pourrait entraîner la perte / la corruption des données. S'ils ont utilisé des approches obsolètes / douteuses connues pour un problème, cela suggère qu'ils ont fait de même sur d'autres problèmes. Si la base de données est soumise à des conditions de concurrence / mises à jour non atomiques dans une zone, cela suggère que cela pourrait être un problème dans le code en général. Et s'il s'agit d'un multi-utilisateur mais que le traitement côté serveur ne permet pas aux entrées / processus de plusieurs utilisateurs de se heurter de manière subtile, cela suggère qu'il pourrait tomber sous des charges appropriées.
3. Observations suggérant que l'équipage d'origine a trompé la direction (délibérément ou non, ou peut-être simplement en n'étant pas énergique et trop facilement annulée / ignorée: cela aurait pu être la faute de la direction, pas la leur!). À l'heure actuelle, l'équipage précédent est un cadeau de Dieu à la direction car ils ont livré un produit brillant. Vous doutez d'eux parce que même si c'est un excellent produit, vous n'êtes pas heureux, ne pouvez pas le faire fonctionner, ne le comprenez pas, etc. Mais si vous avez des observations qui contredisent directement ce qu'ils ont déclaré, alors celui qui sait ce qui se passe et la chaussure se retourne contre eux. Votre travail devient alors plus facile. Par exemple, s'ils ont dit à la direction que le projet a une sécurité WebUI appropriée et que vous observez des endroits où ils n'ont pas validé l'entrée / les scripts croisés / l'injection SQL, ou la direction pense que le projet peut gérer quelque chose d'important et vous pouvez montrer spécifiquement qu'il peut 't et n'aurait jamais pu le faire, vous pouvez montrer à la direction qu'ils ont été trompés.
4. Observations qui montrent que, si elles sont mises sur le marché, les niveaux habituels de suivi / d'attente / de service seront irréalisables / irréalisables, ou les coûts seront beaucoup plus élevés que prévu . Par exemple, si le code est trop pauvre ou manque d'aspects de débogage, alors lorsqu'un client a un problème, il n'y aura aucun moyen pratique de suivre les bogues et quel que soit le problème, cela peut prendre des semaines et non des heures pour y remédier. Si le code est répété, cela signifie que la modification de la validation ou l'amélioration des structures de données ne peuvent pas être effectuées "juste en un seul endroit". S'il n'est pas documenté ou mal structuré, les tentatives de l'améliorer ou de l'améliorer seront gravement entravés car il n'y aura aucun moyen pratique de faire un développement significatif et de s'assurer que les choses ne se casseront pas, sinon la vérification de la casse prendra tellement de temps que être non rentable. Si c'est un mauvais gâchis, une fois sur le marché, ils dépendront de vous personnellement chaque fois qu'un problème se posera; comme vous ne pouvez pas garantir d'être là le week-end et à 23h juste à cause d'une échéance client frappée par un bug, ou vous pourriez tomber sous un bus, que vont-ils faire? Si les données peuvent être déplacées mais nécessitent une attention manuelle excessive, alors en production, votre support peut ne pas être en mesure de s'adapter pour fournir cela, ou pour garantir qu'il peut rester assez simple, de sorte que les erreurs de traitement peuvent être plus risquées. Si cela dépend de plates-formes spécifiques et que ces plates-formes ne sont pas clairement gérées dans le code, alors les modifications apportées aux plates-formes (mises à jour de Windows, versions de navigateur, versions de bibliothèque) peuvent ne pas être réalisables dans les délais habituels ou commerciaux, ou corriger ce qu'ils cassent peut être complexe. , empêchant les clients de maintenir ou d'utiliser leurs plates-formes comme prévu.
5. Des observations qui ne font que vous ennuyer . C'est ton travail. S'ils ne relèvent pas des catégories ci-dessus, corrigez-les du mieux que vous pouvez pendant votre temps libre. Le problème de la direction concerne les 4 premiers éléments ci-dessus, pas celui-ci.

Celles-ci vous aideront à aligner votre perspective technique et pratique sur leur perspective commerciale. Si vous pouvez montrer qu'il y a des problèmes dans les 4 premières catégories ci-dessus et les exposer clairement, vous serez sur la bonne voie pour résoudre votre propre problème - en leur montrant de bonnes raisons pour lesquelles c'est leur problème, et non votre manque de

Si vous mettez une liste comme celle-ci ensemble et qu'elle semble convaincante, faites une présentation, présentez-la-leur et expliquez-leur des exemples de problèmes - y compris des extraits de code ou de flux de données spécifiques qui illustrent ce point.

Votre présentation

Pour la rendre efficace,

• Trouvez un autre codeur en qui ils ont confiance - ou demandez la permission de faire venir un collègue pour une journée - et ayez quelqu'un qui est prêt à vous soutenir. De cette façon, ce n'est pas tout ce que vous dites; vous avez quelqu'un d'autre qui peut dire: "Oui, il m'a montré ce code, et je suis désolé, il n'exagère pas le sérieux."
• Attendez-vous à devoir éduquer un peu - brièvement. Ils ne sont pas des codeurs mais ont du bon sens. "C'est pourquoi nous utilisons du code structuré, exactement pour pouvoir effectuer chaque tâche une seule fois, isoler les parties et être sûrs de l'interaction des éléments. Mais ces types ne l'ont pas fait, regardez ici , ici et ici . Le problème se pose donc que dans leur code, vous ne pouvez pas voir comment les pièces interagissent, ou si il y a des erreurs logiques ou des incohérences, et vous ne pouvez pas être sûr que les parties indépendantes sont vraiment indépendantes, ou que tout doit être changé ailleurs si quelque chose doit être changé, ou même qu'il se comportera sous des charges réelles, comme lors des tests. En supposant que nous puissions le tester de manière réaliste et le réparer en moins de 3 ans de travail à plein temps par une équipe de dix, ce qui est douteux. C'est exactement pourquoi les professionnels codent de manière prudente - car nous connaissons le autrement, l'impact commercial est grave. "
• Attendez-vous à être poussé ou forcé à dire que ce n'est pas si mal. Parlez clairement. "Je suis désolé, quoi qu'ils vous aient dit, ce n'est clairement pas le cas. Je comprends que c'est un choc, mais en tant que professionnel, c'est aussi comme ça." Dites-leur: "Non, ce n'est pas un travail de haute qualité, c'est un travail criminellement bâclé et on vous a menti, jusqu'au bout." (Oui, vous pouvez dire que pour mettre l'accent, ce n'est pas comme si vous disiez que ce sont des criminels !!) Dites "Oui, désolé, mais je suis sûr".
• Entrez avec des détails. Si vous dites simplement "Les clés Ssh sont en texte brut", c'est super pour quelqu'un de votre niveau et le voir comme vous le faites. Pour la direction sous pression et croyant que c'est génial et pourquoi le tapage, c'est beaucoup trop peu spécifique. Au lieu de cela: "Les clés de chiffrement utilisées pour empêcher le panneau de configuration du client pour les utilisateurs distants sont stockées de manière non sécurisée, d'une manière que toute personne ayant une légère connaissance dirait qu'elle est à la limite du délit criminel. (Encore une fois, oui, vous pouvez dire que pour mettre l'accent, c'est pas comme si vous disiez qu'ils sont des criminels !!) . Si vous regardez ici (OK, ils ne peuvent pas suivre le code, mais tirez le code et pointez quand même sur ce bit , pour la crédibilité) vous verrez que la clé est stockée dans un format ouvert. Ils n'ont même pas fait de chiffrement de base des années 90. Mettez ces données en ligne et les données client / utilisateur seront piratées dès que quelqu'un pense que cela vaut le 10 cela prendra quelques minutes. " Montrez-leur "Plus de ici , ici et ici que vous pouvez voir un appel système de routine [API] qui peut ou non être interrompu dans divers cas, car il reçoit des données incorrectes pour l'appel. " Dites-leur "Ce sont des erreurs fondamentales de base. C'est comme ça partout". Montrez-leur "Dans ce module, ils utilisent cette bibliothèque, mais sur ici ils utilisent cette bibliothèque. Mais le fabricant indique clairement que les deux bibliothèques ne sont pas réellement compatibles. Elles ne devraient jamais, jamais être utilisées toutes les deux dans le même code, car cela peut laisser des données incorrectes / peut corrompre des données / parce que la sortie de l'une d'entre elles sera mal traité / corrompu / mal géré s'il est donné à l'autre. " Comme ça, en termes pour qu'ils puissent en comprendre le sens et en voir l'importance. Dites-leur: «Puis-je résoudre le problème? Eh bien, en d'autres termes, si ce problème est si grave, à quel point pensez-vous qu'il est réaliste de refaire toute l'infrastructure de sécurité du projet en moins de 6 mois?» Ce genre d'approche. Faites-leur voir.
• Choisissez une solution pré-pensée. Que feriez-vous à leur place? En fait, optez pour 3 solutions, et des avantages / inconvénients / estimations approximatives de leur impact. N'oubliez jamais que «ne rien faire» ou «allez-y quand même» est une option , incluez-la également (et ses avantages / inconvénients / risques) dans votre liste.
• Donnez-leur du temps être choqué, bouleversé, dans le déni et en mode blâme. C'est humain et eux aussi ont des pressions. Attendez-vous à ce que cela se produise, et soit restez assis à travers, acceptez leur choc, guidez-les au-delà, rappelez-leur doucement que la recherche de blâme et les autopsies peuvent attendre; ils ne résolvent pas réellement les problèmes de l'entreprise. Soyez leur conseiller.
• Si nécessaire, après un certain temps, dites simplement: "J'ai quelques solutions proposées. Aucune n'est idéale - l'idéal serait que ce gâchis n'existait pas. Mais elles sont viables. Prenons 10 minutes / Pouvons-nous nous revoir après une courte pause-café / après le déjeuner / J'ai une réunion, rencontrons-nous après cela, pour nous concentrer sur les solutions et ce que nous faisons pour résoudre ce problème. " dans une réunion séparée après un «changement de décor» mental - même juste de l'autre côté d'une pause-café - aidera beaucoup.
• Dire que vous avez des solutions peut souvent attendre un peu, jusqu'à ce que les premières explosions se produisent, car la réaction humaine sera souvent de l'ignorer ou de nier le besoin, au tout début. Ce n'est qu'une fois qu'ils ont dispersé une partie de leur colère (s'ils sont de ce type) que cela vaut la peine de le dire, car chez tant de gens, ils ne l'entendront tout simplement pas si cela est dit alors qu'ils sont toujours en mode de blâme embarrassé en colère. Si ce n'est pas un problème, passez directement aux solutions après avoir expliqué la gravité / le risque de l'impact, si vous pensez qu'ils écoutent.

Évitez soigneusement tout ce qui pourrait impliquer que vous êtes perfectionniste ou faites pas plus que le minimum pour la viabilité du marché. Rien de plus que l'essentiel, à ce stade, n'est tout simplement pas une priorité.

Solutions et argumentaire à l'avance

En ce qui concerne une solution pré-réfléchie, la mienne serait, des ressources supplémentaires. S'ils ne vous croient pas, tout est mort de toute façon (en supposant que vous avez raison). Le logiciel va tanker et vous serez brûlé par association: cherchez un nouveau travail à partir de maintenant. Mais si après votre présentation, ils vous croient, ils sont inquiets ou ils attendent de vous que vous régliez le problème, cela tourne à votre avantage.

Parce qu'il vous faut une équipe . Présentez quelque chose comme ceci:

"Désolé les gars, mais 1,5 G de code comme celui-ci, sans bases ni documentation, prendra environ un an juste pour comprendre, peut-être 5 ans pour corriger. Peut-être qu'une réécriture le fera être nécessaire et nous pouvons enregistrer ce qui peut être réutilisé, peut-être seulement des parties de l'interface graphique, les concepts de base du flux de données, pour ne pas réinventer la roue, puis refaire le back-end et tout le reste. "

" Le Selon moi, la première priorité est l'évaluation. Je peux voir que c'est mauvais, mais à quel point, et quel est le minimum pour rendre la production en toute sécurité? " [reflète leur préoccupation principale]

"D'après moi, nous devons savoir que d'ici 4 à 6 semaines - je dirais 3 semaines, mais c'est un tâche à part entière et doit être revue ligne par ligne. 4 à 6 semaines avec une équipe de 3, et nous saurons à quel point les dégâts sont graves. " [Si vous ne pouvez pas, ou si c'est trop énorme, remplacez ce qui est sensé à la place]

"Ensuite, nous devons le réparer. Je peux brûler les bougies pour savoir quoi faire , mais j'ai besoin de mains sur des claviers. De 4 à 6 d'entre eux, jusqu'à 6 mois. "

[Le cas échéant, ajoutez: "Et j'ai besoin d'un n ° 2 compétent pour cela. Je ne peux pas revoir tout ce qu'ils ont mis, seul, si je suis également en train de parcourir les problèmes et les correctifs. " ]

"C'est dommage que ce soit aussi grave, mais c'est ce que c'est, et nous devons d'abord creuser le trou, et faire des reproches et des litiges plus tard. Pour cela, donnez-moi deux personnes pour le moment et prévoyez un budget pour encore 2 ou 4 dans environ 4 à 6 semaines, et je vais vous le faire, bien fait. Ou du moins à peine réalisable. " [Encore une fois, si vous ne pouvez pas, ou si c'est trop énorme, remplacez ce qui est sensé à la place]

"Vous pouvez également demander à [nom d'un contact qu'ils connaissent, qui est un directeur dans une entreprise informatique appropriée] pour envoyer quelqu'un pendant une journée, pour vérifier mon point de vue initial, mon approche et mon timing, avant d'engager un budget. Ce sera bien et aussi rassurant. Mais si ça marche, et ça va - alors nous devons agir rapidement, et la seule chose qui nous fera gagner du temps sur le marché est d’y injecter des ressources rapidement et massivement. "

" Ce serait, à mon avis, la solution sensée . Nous ne pouvons pas l'utiliser tel quel, et nous perdons plus en raison des retards et des dommages que nous économisons en payant des sous-traitants ou en retirant du personnel d'autres travaux. "

" Je suis désolé de vous annoncer de mauvaises nouvelles. La bonne nouvelle est que nous pouvons creuser dans le trou. "

" Des questions? "

Ce que j'essaierais de faire:

Organisez une réunion en personne avec le responsable (votre patron, chef de projet, celui qui est le plus responsable de ce code). Dites-lui avec des mots gentils mais clairs que le code ne fonctionne pas, et le réparer ne sera pas une question de semaines. S'il ne vous croit pas, proposez-lui de le montrer à d'autres développeurs pour obtenir un deuxième avis.

Ce que vous pensez et ce que la direction pense n'est pas pertinent. Ils ont un produit qu'ils veulent livrer et vous avez une pile de code hérité qui a tenté de devenir ce produit.

Dans son état actuel, il fonctionne correctement en tant que produit ou non. Si ce n'est pas le cas, il reste à développer un plan pour utiliser les ressources disponibles (votre temps et vos compétences ainsi que les composants utiles du code dont vous avez hérité) pour produire ce produit. Il ne faut pas s'attarder sur les lacunes du code dont vous avez hérité - ce qui compte, c'est que vous développiez un plan pour en faire le produit qu'il était censé être.

Votre direction aimerait que cela se produire dans un délai donné. Soit vous pouvez gérer votre temps pour atteindre cet objectif, soit vous ne le pouvez pas. Si vous ne pouvez pas, vous avez besoin de plus de ressources et vous devez le leur faire savoir. Si plus de ressources ne sont pas disponibles, le délai doit être sacrifié. C'est vraiment aussi simple que cela. Ce qu'ils attendent de vous, c'est un plan - vous devez déterminer comment peut le faire. S'attarder sur toutes les raisons pour lesquelles cela ne peut être fait n'est pas constructif. C'est ce que c'est - vous devez y faire face et aller de l'avant.

Il y a deux choses que je ferais ici:

1. Cadrez la situation. Il y a des signaux d'alarme, il est donc essentiel que vous ne disiez rien pour inciter qui que ce soit ou pour les rassurer que les choses seront prêtes à temps. N'oubliez pas que les problèmes / l'état de la base de code sont le résultat de ceux qui y ont travaillé auparavant, mais dès que vous commencez à prendre la responsabilité, c'est sur vous. Ne vous permettez pas d'être un bouc émissaire.

2. Évaluez ce que fait le produit dans son état actuel par rapport aux exigences commerciales énoncées. L'erreur que vous faites est que vous vous concentrez trop sur la qualité du code, qui est subjective (vous ne pouvez pas vous permettre de mener cette bataille maintenant). Les gens plus hauts ne vont vraiment pas s'en soucier, ils se soucient de savoir si cela fonctionne ou non. Faites-le de manière objective. Si on leur dit que quelque chose fonctionne, et que ce n'est pas le cas, vous devez être en mesure de le documenter et de le démontrer. À partir de là, vous pouvez commencer à estimer le temps dont vous avez réellement besoin et le sauvegarder avec des faits / éléments de travail réels.

En résumé: soyez honnête, soyez objectif, don Ne faites pas trop de promesses et évaluez en fonction des exigences commerciales plutôt que de la qualité du code. Vous voulez également être considéré comme un résolveur de problèmes, pas comme un créateur de problèmes, alors assurez-vous de vous concentrer sur la solution et la voie à suivre.

Je suis désolé d'être le porteur de nouvelles cyniques mais ...

Si c'était si génial, cela ne vous aurait pas été remis 2 mois avant la date de lancement à moins qu'ils ne pensent que vous possédez autant ou plus de génie que le (s) développeur (s) précédent (s).

Cela ressemble à une configuration pour l'échec. La direction sait que c'est un gâchis, mais elle doit renvoyer la balle à un travailleur acharné sans méfiance afin qu'ils puissent rejeter le blâme sur toute la ligne plutôt qu'eux-mêmes une fois que la haute direction commence à demander des mises à jour de statut.

En guise d'approche alternative, vous pouvez suggérer qu'un autre développeur l'examine. Deux, trois ou quinze personnes disant que cela ne fonctionne pas et que cela ne fonctionnera pas bientôt pourraient convaincre la direction.

Ne fonctionne que s'il y a quelqu'un d'autre qui n'est pas concerné par le projet et n'a donc pas à masquer la vérité.

Si vous nous avez présenté l'état de ce code à la direction comme vous l'avez fait, et qu'ils sont toujours convaincus qu'il est en parfait état de fonctionnement avec seulement deux mois pour la livraison ...

Vous ne peut pas changer d'avis - ils en sont déjà convaincus. Ou pire encore, ils sont conscients du problème et essaient de jouer à l'ignorance afin de pouvoir vous transmettre la responsabilité en cas d'échec.

Tout ce que vous pouvez faire à ce stade, si vous voulez rester engagé dans le projet, tout ce que vous pouvez faire est de vous atteler et de faire tout ce qui est en votre pouvoir pour que ce code fonctionne, jusqu'à et y compris. heures supplémentaires.

De plus, je vous invite fortement à vous entraîner à travers la documentation, à la fois dans le code et en dehors de celui-ci, de sorte qu'en cas d'échec de l'application, vous puissiez , à tout le moins, montrez que vous êtes allé au-delà de l'appel du devoir pour en sauver autant que vous le pouviez.

Avec un peu de chance, quelqu'un dans la gestion sera assez sage pour reconnaître un codeur qui travaille dur qui veut mettre l'effort à résoudre son projet de catastrophe.

Cela étant dit, ce projet semble extrêmement mal géré. Je vous conseillerais de mettre un peu de temps à rafraîchir votre CV ou à rechercher un transfert au sein de votre entreprise vers un nouveau projet. Parce que d'après ce que vous avez dit, les choses ne semblent pas bonnes pour celui-ci.

Tout d'abord, ne présumez pas que le code est si "mauvais".

Pratiquement chaque fois que je vois un nouveau développeur venir sur un projet, il prononce le code mal, peu importe comment bon ou mauvais c'est ou qui l'a écrit. Une fois, j'ai travaillé sur un produit pendant deux ans et ils ont embauché un nouvel entrepreneur et il a dit à mon patron que mon code était un code «spaghetti» sans valeur et qu'il fallait le réécrire. Il a été licencié environ 2 mois plus tard pour manque de productivité.

En général, vous devriez résister à l'envie de tout réécrire.

Essayez de limiter vos modifications à ce qui est nécessaire. Vous n'essayez pas de créer la Joconde ici; commencer par faire le minimum pour accomplir tout ce qui doit être fait. Si vous pensez que cela signifie réécrire tout le projet, vous êtes probablement le problème, pas le code.

Il n'y a absolument aucune raison de faire des remarques éditoriales sur la qualité du code à votre patron. Vous êtes là pour ajouter des fonctionnalités, pas pour être un critique de cinéma. Gardez vos opinions pour vous, jusqu'à ce que vous ayez prouvé votre valeur.

Je pense que je dois ajouter une réponse spécifiquement car vous en avez déjà accepté une. Ce n'est pas tout à fait faux, mais, IMO, un peu rater le point.

Oubliez le code pendant un moment. Ce ne sera ni le premier ni le dernier code p-o-s que vous devrez maintenir. Comme suggéré, rectifiez-le jusqu'à ce que vous obteniez un semblant de base de code fonctionnelle, essayez de respecter les délais, etc.

La partie qui nécessite tout autant de préparation et de soin est votre propre situation: vous vous vous dirigez tête baissée vers une phase critique de votre vie, où vous pourriez vous-même aller voir les chiens si vous ne faites pas attention. Dans l'état actuel des choses, d'après votre description de votre situation, tout le monde pense que tout va bien, qu'il a une mine d'or et qu'il n'y a vraiment aucun problème.

Les quelques citations vous avez déjà donné l'air de suggérer qu'ils ne vous croient pas, et qu'ils ne pensent pas vraiment mal de vous, mais au moins de manière neutre; vous ne semblez pas être avec eux. Peu importe à quel point le code est mauvais. Si cela ne fonctionne pas à la date limite, ce sera de votre faute, et de votre seule faute. Vous pouvez documenter autant que vous le souhaitez, mais les citations que vous avez données semblent claires dans la mesure où elles ne sont pas intéressées par les arguments et ne vous croient pas entièrement non plus.

Le problème n'est pas nécessairement qu'elles sont mauvaises ou pour vous chercher. C'est un problème courant que les gens à un certain niveau pensent très différemment des gens à un autre. Ce n'est pas la faute de personne, mais c'est souvent comme ça. Voir; ils entendent si souvent les techniciens se plaindre de la difficulté d'une tâche, ou de la panne d'une application, que c'est comme un bruit de fond pour eux. Ils ne veulent pas l'entendre. Ce n'est pas un argument valable dans leur esprit. Et ils ont raison avec cela - ce n'est pas leur travail de connaître les détails techniques (et la qualité du code fait partie d'un détail technique ...). Ce qu'ils doivent savoir, c'est ce qui vous manque pour atteindre cet objectif.

Donc, dans une situation optimale, vous auriez suffisamment d'influence pour leur dire "J'ai besoin de 3 personnes supplémentaires et d'un expert en XYZ pour respecter cette échéance". Ils fournissent ce que vous demandez, vous atteignez la date limite et tout va bien.

Malheureusement, je ne vois aucun signe dans votre message indiquant que vous avez cette influence. Ils semblent prédéterminés que vous, et vous seul, réglerez les problèmes. Lorsque vous manquez la date limite (et surtout lorsque vous commencez à blâmer le code), alors, selon l'endroit où vous vivez, c'est soit un nouvel emploi pour vous, soit au moins votre carrière dans cette entreprise pourrait bien être terminée.

Alors: mettez un manager à vos côtés, peut-être un chef d'équipe qui a encore des racines techniques. Trouvez un coach dans votre entreprise qui peut parler pour / avec vous et vous aider à affecter plus de travailleurs. Mais surtout: préparez-vous à une phase de stress extrême, non pas parce que vous devez faire des heures supplémentaires, mais parce que vous pourriez rencontrer des discussions qui vous sembleront extrêmement injustes / blessantes, extrêmement difficiles et déprimantes. . Surveillez les signes d'épuisement professionnel, de dépression ou d'autres syndromes de stress (par exemple: ne plus trouver l'énergie pour faire du sport; ne pas pouvoir parler normalement avec votre famille; etc.), et tirez la ligne avant de vous blesser.

Bonne chance!

(Source: BTDT)

Cette situation est typique des événements suivants:

Au point A dans le temps, un ensemble de règles métier pour un processus existe et est connu, mais pas formellement documenté (ou la documentation est détruite par erreur plus tard , voir le point D).

Au point B dans le temps, ces règles métier sont implémentées dans le code, en collaboration avec ceux qui les connaissent. L'existence du code est une incitation à ne pas documenter les règles métier, à les oublier et / ou à ne plus se soucier de ne pas les oublier.

Au point C dans le temps, le code est en cours d'utilisation, et comme cela fonctionne, il n'est pas nécessaire de connaître les règles commerciales derrière cela la plupart du temps. Le code EST maintenant l'ensemble de règles métier de facto.

Au point D dans le temps, un nombre critique de personnes ayant les connaissances du point A ont quitté l'entreprise, ou oublié les règles métier ou abandonné les règles existantes. documentation comme obsolète. Personne ne le remarque.

Au point E, le code commence à montrer des défauts dus à des changements d'environnement, ou nécessiterait des changements fonctionnels. Ces besoins sont contournés au lieu d'être satisfaits, car si des extensions de code ou des correctifs peuvent être techniquement réalisés, il n'y a pas de moyen facile de les TESTER, car les règles métier qui dictaient ce qui doit être considéré comme une entrée valide et ce qui est une sortie valide sont partiellement ou totalement inconnus.

Ce qui aggrave cette situation est une éternelle énigme sur la documentation: il est important de conserver une documentation ancienne et obsolète - en même temps, ne pas savoir ultérieurement si la documentation dont vous disposez est encore plus obsolète que ce qui existait, car personne ne sait si une version plus récente pourrait exister et avoir été égarée ou détruite.

Puis-je vous demander pourquoi vous souhaitez travailler ici? Votre projet est un gâchis, ce qui est mauvais en soi, mais certains aiment le défi de nettoyer quelque chose comme ça. Le vrai problème ici, c'est qu'apparemment un groupe de programmeurs a été autorisé à travailler sur un produit pendant des mois (1,5 Go de code, mauvais ou pas, ce n'est pas quelques semaines de travail), ils ont aussi apparemment tous quitté ce projet, et la direction a été si éloignée du projet qu'elle n'en connaît même pas l'état actuel.
Ce sont d'énormes signaux d'alarme pour moi. Comment la direction pourra-t-elle vous gérer et vous permettre de faire efficacement votre travail si elle ne pouvait pas le faire avec le groupe précédent? Pourquoi tous les programmeurs précédents sont-ils partis? Comment allez-vous grandir et apprendre dans cette entreprise quand, apparemment, ils ne se soucient pas de la qualité du code? Mais peut-être la question la plus importante de toutes, à qui s'adressera-t-il en cas de problème?
Dans l'état actuel des choses, vous n'avez aucune assurance que vous ne serez pas jeté sous bus la prochaine fois que les parties prenantes demanderont une démo. C'est un environnement toxique et il y a de bonnes chances que les programmeurs précédents aient quitté à cause de cela, et maintenant la direction essaie de dissimuler cela en prétendant que c'est un `` code génial '' et `` déjà en production '', tout ce qui peut vous distraire du tas de fumier géant. c'est votre projet hérité.

Votre plan de haut niveau devrait être le suivant:

1. Créez une voie à suivre. (*)
2. Estimez le temps qu'il faudra pour mettre en œuvre votre "voie à suivre".
3. Rencontrez les parties prenantes de l'entreprise et communiquez ce qui suit:
   1. Que vous ne pouvez pas compilez / exécutez le code actuel (si cela est toujours vrai).
   2. Qu'il vous faudra «X» jours / semaines pour réhabiliter la base de code dans un état compilable / constructible / exécutable.
   3. Qu'il y a travail supplémentaire , au-delà de simplement rendre ce code compilable, que vous devez faire pour rendre le code supportable et extensible.
   4. Que cela vous prendra 'X' mois pour mettre en œuvre votre voie à suivre. Puis expliquez votre chemin. (**)

-

(**) Ceci est le plus important car vous aurez besoin pour persuader les parties prenantes non techniques et commerciales que votre plan est solide, réalisable et utile.

-

(*) Voici ma recommandation pour aller de l'avant, qui peut commencer immédiatement après avoir compilé, construit et exécuté le code.

1. Créez des tests unitaires automatisés.
   1. Les tests unitaires démontreront que vous comprenez le code.
   2. Les statistiques de couverture du code vous rappelleront en permanence les parties de la base de code que vous comprenez et les parties que vous devez encore explorer.
2. Ne laissez personne fusionner avec le maître branche sans pull-request qui a été approuvée par au moins deux personnes.
   1. Les pull requests permettront à votre équipe de mieux comprendre la base de code.
3. Encouragez une culture de soutien, en particulier pendant cette période difficile, parmi vos développeurs.
   1. Essayez de ne pas perdre votre sang-froid. D'autres développeurs ressentiront votre frustration et peuvent devenir eux-mêmes frustrés.
   2. Lorsqu'un développeur a des difficultés avec un code hérité et délicat, encouragez d'autres développeurs à donner un coup de main et abordez le code difficile ensemble, peut-être en binôme- programmation.

Dev ici avec quelques entrées:

Vos préoccupations concernant le code sont au mieux semi-valides:

Il y a la même fonction, les mêmes noms de variables de même portée dans toute la base de code (dans un langage qui ne le prend pas en charge).

Si le langage ne le prend pas en charge, comment est-ce qu'une version de celui-ci est alors disponible? Il semble que vous manquez quelque chose ici.

Les fonctions sont définies mais jamais appelées.

Qu'est-ce que cela affecte? Peut-être qu'il a été écrasé pour quelque chose qui n'a jamais été mis en œuvre? Peut-être que c'est pour l'achèvement de l'API?

Utilisation et initialisation des variables dans le désordre.

C'est courant dans le code sous maint, alors que ce n'est pas idéal dans votre situation , encore une fois, c'est courant dans le code plus ancien.

Versions incompatibles des bibliothèques utilisées.

Voir # 1, comment est-il arrivé?

URI et adresses IP codés en dur sans documentation sur ce qu'ils font.

Pas idéal, mais encore une fois, qu'est-ce que cela affecte en termes de livraison?

Routes API demandées au hasard qui ne renvoient rien ou du charabia; qui ne sont alors pas utilisés.

Voir à nouveau # 2

Mots de passe codés en dur et non chiffrés et clés ssh privées.

Voir à nouveau le n ° 5

Après avoir abordé ces préoccupations comme étant peu pratiques, mais triviales, j'aurais une inquiétude légitime à ce que vous définissiez une direction quelconque, désolé, c'est comme ça que ça se passe dans l'industrie depuis ce que j'ai vu.

J'ai un petit conseil cependant: vous avez besoin d'un autre type d'environnement de codage, comme ... un magasin de code, alors recherchez un e-comm ou une entreprise de technologie, où les normes de codage sont un beaucoup plus proche de la vie de l’entreprise que de la finance ou de la fabrication.

Pour ce qui est de faire part de vos préoccupations à la direction, j'aime la réponse de Tschallacka. Il suffit de corriger ce qui ne va pas sans en parler à la direction et de le considérer comme une expérience de carrière que vous pouvez ensuite ajouter à un CV. Je pense que je connais le type de gestion dont vous parlez (à part les opinions personnelles) et ils sont là pour gérer, pas pour innover, donc travailler autour d'eux est la voie à suivre si vous voulez faire ce dernier.