Question:
Comment gérer la frustration causée par la gestion de la base de code des spaghettis et le sentiment que je ne peux pas livrer
Tyg13
2019-05-22 19:31:55 UTC
view on stackexchange narkive permalink

Un peu de contexte: je suis un développeur nouvellement embauché (1,5 an) dans une société de test de logiciels. Pendant un certain temps, les choses allaient très bien. J'ai pu plonger assez rapidement, mais il y a eu quelques ralentissements.

En particulier, je lutte beaucoup avec notre base de code. C'est particulièrement velu (écrit en C ++, Ada et Python) et il a 20 ans à ce stade. Plus frustrant, il y a très peu ou pas de propriété de code établie dans un outil qui couvre plus de 1,5 million de LOC. Il y a une sorte de compréhension ad hoc - l'outil peut être séparé en différents modes, et les mêmes personnes ont tendance à travailler sur les mêmes modes, mais ce n'est pas toujours le cas.

Récemment, j'ai été demandé de changer, de manière fondamentale, une partie de l'outil qui est utilisé dans chaque mode. J'ai déjà conçu et mis en œuvre des modifications de fonctionnalités, mais rien de compliqué. Mon patron semble très confiant dans ma capacité à le faire, mais il m'a fallu plus d'un mois pour comprendre exactement comment cela affecterait "ma" partie de l'outil et y mettre en œuvre le changement.

Maintenant, malgré plusieurs tentatives pour demander à mon patron de l'aider à mettre en œuvre le travail dans d'autres parties de l'outil, il insiste sur le fait que je dois les apprendre et le faire moi-même. J'ai exprimé des inquiétudes au sujet de la propriété du code et j'ai peut-être demandé aux gens qui travaillent dans ce domaine d'en faire une partie, mais la réponse a été que "ils sont occupés et c'est votre tâche". Il était clair que je pouvais poser des questions, mais en ce qui concerne ma tâche principale, je suis seul.

Il est conscient de l'ampleur de ce changement. Il le dit même lui-même et me dit de ne pas être dur avec moi-même si cela prend du temps. Mais malgré ses sympathies, le projet ne se fait tout simplement pas. Il y a tellement de code que je ne peux même pas tout comprendre. Parfois, je passerai une journée entière à essayer de cartographier une partie complètement différente de l'outil, à essayer de comprendre comment mon changement l'affectera, et je rentrerai chez moi n'ayant presque rien accompli. Parfois, je fais une erreur de conception, je m'en rends compte et je dois tout recommencer. Je rentre le lendemain, m'assois, regarde mes notes et soupire. J'espère que j'écrirai du code.

Dans les rares cas où une tâche différente me sera assignée, je la supprime toujours rapidement parce que cela ressemble à une bouffée d'air frais, mais quand je pense même à mon tâche principale, c'est tellement démoralisant que cela me donne envie de trouver un nouvel emploi.

Comment puis-je gérer le stress de me sentir comme si je n'accomplissais rien, et surtout, gérer un projet qui Je pense que c'est trop grand pour moi?

ETA: mon patron était le responsable technique pendant 16 ans. Je ne pense pas que son manque de savoir-faire technique soit le problème ici.

Il a été l'un des principaux développeurs de l'outil pendant plus de 16 ans.Il sait que la base de code est nul, mais je pense qu'il a été retiré du problème depuis trop longtemps maintenant (les 4 dernières années)
dans ce cas, faites confiance à son jugement.La réponse de Dwizums est probablement le meilleur conseil ici.Ne mesurez pas la réussite en fonction de la quantité de code que vous avez écrite - j'ai perdu le compte du nombre de fois où j'ai passé des jours à travailler sur une seule ligne de solution de code.
La question en ce moment manque de choses spécifiques pour lesquelles vous voulez de l'aide.** Que voulez-vous qu'il se passe? ** Cela ressemble plus à une diatribe en ce moment avec toute la sympathie due à votre problème
@aaaaaa Idéalement, j'aimerais être retiré de ce projet.C'est beaucoup de travail laborieux pour obtenir quelque chose qui aurait dû être dans l'outil en premier lieu.Nous avons bâti sur une structure depuis des années qui doit maintenant être presque complètement remaniée.Je ne pense pas que ce soit un changement qu'un développeur avec une expérience d'un an avec une base de code massive devrait apporter.Mais j'ai peur du pire si je disais ça à mon patron, mot pour mot
* "Parfois, je passe une journée entière à essayer de tracer une partie complètement différente de l'outil, essayant de comprendre comment mon changement va l'affecter, et je rentrerai chez moi n'ayant presque rien accompli" * - hé, ça sonne unbeaucoup comme mon travail!Et je suis le genre d'homme senior dont vous avez besoin pour obtenir des informations sur les autres parties de l'outil (et n'hésitez pas à demander; s'ils sont bons (s'il vous plaît, laissez-les être bons ...), Je suis sûr qu'ils préfèrent vous aider à l'obtenir maintenant, plutôt que de souffrir plus tard si vous vous trompez).Embrasse le!C'est une carrière romantique passionnante de pointe dans le domaine des STIM!
Oubliez l'idée de «posséder» le code.Le code appartient à l'entreprise, pas à un employé en particulier.Les développeurs ne devraient jamais penser qu'ils possèdent une partie particulière de la base de code.
@SimonB Je suis conscient que personne ne devrait avoir l'impression de "posséder" le code dans le sens où d'autres personnes ne devraient pas y toucher, mais (et peut-être que c'est juste mon inexpérience qui parle) j'ai l'impression que le projet devient désorganisé et dessiné -sans elle.La spécialisation est une bonne chose - cela signifie que vous pouvez faire avancer les choses dans votre domaine spécialisé plus efficacement qu'un touche-à-tout qui doit constamment basculer entre des domaines disparates.Je reconnais le mérite de garder les développeurs des yeux frais et frais sur le code.Mais "il n'y a pas du tout de propriété de code" me rend fou.Je ne peux pas tenir tout ça dans ma tête.
* il a 20 ans * Je pense que c'est un problème en soi
@MilkyWay90, il y a une quantité incroyable de code qui remonte à 1999.
@Tyg13 Utilisez-vous Python 1 ou avez-vous mis à jour votre code?
@MilkyWay90 la plupart des parties de Python ont été écrites au cours des cinq dernières années.La direction a déplacé des parties de l'outil vers Python pour "accélérer le temps de développement" * frisson *
@Tyg13 Je vois.Donc, le code * est * mis à jour avec les dernières versions des langages de programmation utilisés, non?
@MilkyWay90 toujours sur C ++ 03, malheureusement
Laissez-nous [continuer cette discussion dans le chat] (https://chat.stackexchange.com/rooms/93990/discussion-between-milkyway90-and-tyg13).
-1
@dwizum Je suis d'accord avec la réponse que vous m'avez donnée.C'est probablement la réponse la plus constructive que vous puissiez donner à cette question.
Heureux que vous soyez satisfait des informations que vous avez obtenues, mais si la question reste en suspens, personne d'autre ne peut y répondre et elle finira par se fermer pour de bon et deviendra beaucoup moins précieuse pour le site.Quelques modifications simples et la réouverture de la question pourraient lui permettre de gagner en valeur pour l'ensemble de la communauté.
@dwizum est en attente parce que je n'avais pas d'objectif solide en tête en posant cette question, et je ne l'ai toujours pas.J'adorerais modifier la question, mais je ne suis pas sûr de ce qui satisferait les modérateurs.
Pas une réponse à votre question mais sur la tâche.À quoi ressemblent vos tests unitaires, avez-vous une couverture de test pour être sûr de pouvoir détecter les erreurs si vous les introduisez?Sinon, vous pouvez créer des tests unitaires qui vous donnent cette confiance.
Cinq réponses:
dwizum
2019-05-22 19:43:07 UTC
view on stackexchange narkive permalink

Vous avez dit,

J'espère que j'écrirai du code.

Un de mes mentors avait une plaque sur son bureau: Résistez l'envie de coder. Oui, le logiciel peut être votre produit de travail, mais cela ne signifie pas que votre travail consiste uniquement à écrire du code. Vous devez comprendre ce que vous faites, et cela prend du temps. Le but de la plaque était d'amener les développeurs à réfléchir attentivement à leurs tâches et à s'assurer qu'ils tiennent compte de l'approche qu'ils adoptent, plutôt que de s'asseoir immédiatement devant un clavier et d'écrire du code basé sur une notion incomplète ou à moitié cuite.

De plus, pour se rattacher à votre choix de formulation dans votre titre, lorsque ses développeurs se plaignaient du code spaghetti, il leur disait de "prendre une fourchette et une cuillère et commencer à tourner". Le fait est que oui - parfois on nous sert un désordre et nous ne pouvons pas simplement plonger et manger, nous devons d'abord organiser le désordre.

Donc - quand vous avez une journée comme,

Parfois, je passe une journée entière à essayer de cartographier une partie complètement différente de l'outil, à essayer de comprendre comment mon changement l'affectera, et je rentrerai chez moi n'ayant presque rien accompli.

vous ne devriez pas penser que cela n'accomplit rien, puisque vous apprenez la tâche que vous avez à faire. C'est un accomplissement. Même si vous pensez "J'ai essayé de tracer ceci et je me suis trompé", vous avez au moins exclu quelque chose.

Pour aller au cœur de votre préoccupation, oui - c'est C'est bien quand nous travaillons dans des parcelles facilement identifiables que nous pouvons envelopper et accomplir en morceaux discrets. Mais parfois, ce n'est pas le cas. Puisque vous vous sentez tellement dépassé, vous voudrez peut-être demander de l'aide (via votre responsable, les développeurs seniors, le Web, etc.) sur la cartographie des processus ou d'autres méta-outils et méthodes pour les développeurs, afin que vous puissiez vous améliorer apprendre à s'attaquer à de gros problèmes, au lieu de simplement résoudre le problème devant vous ou simplement de vous sentir dépassé.

Il convient également de souligner que vous avez fait plusieurs commentaires très encourageants à propos de votre patron, indiquant qu'il comprend la difficulté de la tâche et qu'il est prêt à vous laisser une marge de manœuvre pour l'accomplir. c'est un compliment qu'il tient tellement à vous. Il a indiqué que vous êtes en mesure de poser des questions aux autres propriétaires de code, ce qui est un bon point de départ lorsque vous êtes vraiment coincé.

En fin de compte, vous devez décider si c'est un travail acceptable que vous êtes heureux de faire, par rapport à quelque chose qui vous fera quitter votre emploi. Prenez-le à cœur: lorsque vos limites sont repoussées, c'est soit une opportunité d'apprendre et de grandir, soit une opportunité de fuir le problème. Nous faisons tous les deux, à différents moments de notre vie. Le choix vous appartient vraiment.

Ce.Ne commencez pas à coder tant que vous n'avez pas compris ce qu'il va faire et ne paniquez pas si la partie compréhension prend beaucoup de temps dans des cas comme ceux-ci.Chaque jour, on apprend quelque chose de plus sur le système qui permettra plus tard d'apporter des changements est un accomplissement.Le succès ne peut pas être mesuré en lignes de code.Lambdas / LINQ n'aurait pas été introduit si tel avait été le cas.
+1 pour "prenez une fourchette et une cuillère et commencez à tourner."
Mes meilleurs jours sont ceux où je supprime le code.
À ce stade, je suis allé aussi loin en imprimant des modules de spaghettis entiers pour analyser le flux de contrôle, comme lire un livre "Choisissez votre propre aventure" en collant mes doigts ou en le postant des notes pour marquer les endroits où revenir et le lire comme un roman.De nos jours, j'essaie de lancer Doxygen au maximum verbeux sur une base de code non documentée pour au moins obtenir les graphes d'appels avant de plonger.
Parfois, quand je ne comprends pas la base de code sur laquelle je dois travailler, j'essaye de la refactoriser d'abord.Il n'est pas nécessaire que ce soit un refactor complet, même des choses simples telles que la modification des noms de variables peuvent vous aider à le comprendre.Cela vous aide également à vous sentir comme si vous «faisiez» quelque chose - ce qui aide à éliminer l'anxiété et permet à votre cerveau de se concentrer sur l'apprentissage.
Simon B
2019-05-23 03:18:56 UTC
view on stackexchange narkive permalink

Un jour, la cartographie du code n'est rien, dans le grand schéma des choses. S'il s'agit d'une grande base de code, cela peut prendre des semaines de travail long et fastidieux. Ce n'est pas amusant, surtout pas par vous-même.

Essayez de déterminer quels éléments vous devez savoir. Essayez de déterminer quels modules seront affectés par vos modifications et lesquels ne le seront pas. Documentez ce que vous trouvez - des diagrammes, des notes sur les interdépendances et les interfaces entre les modules de code, tout ce qui pourrait vous être utile à l'avenir. Même avertissements de ne pas faire certains changements car ils casseront quelque chose d'autre.

Pour commencer, mesurez la progression de ce que vous avez réussi à documenter, pas la quantité de code que vous avez écrit.

Mesurer la progression de la programmation par lignes de code revient à mesurer la progression de la construction d'un avion en fonction du poids.

Bill Gates

Ertai87
2019-05-22 21:03:16 UTC
view on stackexchange narkive permalink

La façon dont vous le faites sonner donne l'impression que votre code est écrit dans des "modules", sauf qu'un tas de modules sont enchaînés de spaghettis parmi d'autres modules non liés. Que se passerait-il si vous teniez compte de cette partie partagée dont vous êtes responsable et déterminiez comment créer une solution universelle à ce que l'on vous demande de faire, plutôt que de réimplémenter chaque élément individuellement?

À défaut, il ne semble pas qu'on vous demande de réimplémenter un "module", car un "module" est censé fonctionner de la même manière dans tous les cas. Il semble que l'on vous demande peut-être de prendre en charge une très grande partie de l'application par vous-même, ce qui me semble déraisonnable. Vous devez soigneusement déterminer lequel de ces cas est correct.

De plus, si votre patron comprend l'ampleur de cette entreprise, mais qu'il n'alloue pas non plus de personnes pour vous aider, il me semble qu'il essayant de te jeter sous le bus. J'ai déjà eu une situation similaire, et cela a abouti à mon licenciement pour ne pas avoir effectué le travail requis dans un délai raisonnable, malgré les répétitions de mon patron: «Je comprends combien de travail cela représente et je ne m'attends pas être fait rapidement ". Si c'est la même chose qui m'est arrivée, votre patron n'est pas amical et compréhensif, il vous prépare à l'échec et vous sourit en vous poignardant dans le dos. Sortez.

Relatif à votre dernier paragraphe.Nous avons tendance à penser que notre boutique est divisée en deux moitiés: l'une dirigée par mon patron et l'autre par un co-patron.Les deux ont une autorité égale, mais aussi leurs propres subordonnés.Au sujet de la mise en œuvre de cette fonctionnalité, mon co-patron est en désaccord avec mon patron et moi, et pense que cela aurait pu être fait beaucoup plus facilement d'une manière différente.Récemment, un autre développeur a commencé à travailler sur une implémentation parallèle de cette fonctionnalité sous un angle totalement différent.Je ne savais même pas à ce sujet jusqu'à ce que le développeur vienne me voir lui-même.
@Tyg13 Ma recommandation à la lumière de cela est double: Premièrement, si votre co-patron est également ingénieur, demandez-lui quelques suggestions.Expliquez-lui que vous êtes coincé et que vous aimeriez avoir un aperçu de cette énorme base de code.Voyez ce qu'il dit.S'il prend le "Je connais la réponse mais je ne vous dis pas haha!"tactique, puis fuyez aussi vite que vous le pouvez.Ce ne serait pas seulement non professionnel (car votre co-patron ne travaillerait pas dans le meilleur intérêt de l'entreprise), mais cela indiquerait également clairement que vous êtes en cours de création.
En ce qui concerne le deuxième conseil, le fait que l'on vous donne du travail en double et que l'autre personne se soit vu dire de ne pas collaborer avec vous explicitement (c'est mon avis sur la base des informations fournies) signifie que vous êtes probablement mis en concurrence aveclui.Déterminez lequel d'entre vous est le mieux placé du point de vue du travail et de la politique, et cette personne sera probablement bientôt sur le billot.Comme c'est lui qui a été informé de la duplication du travail et non vous, celui à couper est probablement vous.Sortez.
Malheureusement, d'après ce que j'ai vu de la structure de cette entreprise, il est plus probable que personne n'ait dit à ce développeur que je travaillais sur le projet.Nous n'avons pas de réunions autres que le tête-à-tête hebdomadaire avec le directeur.Personne ne sait ce que fait les autres à moins que nous ne nous le demandions ou que notre responsable ne nous le dise.
pestatije
2019-05-23 05:59:54 UTC
view on stackexchange narkive permalink

Eh bien, vous avez des difficultés à livrer et quelqu'un d'autre travaille sur la même tâche.

Essayez de rejoindre l'autre gars: il peut vous déléguer des tâches que vous pouvez livrer, il prend la responsabilité de sa solution ne fonctionne pas, vous êtes soulagé de cette tâche que vous ne voulez pas vraiment faire.

Dragan Juric
2019-05-28 03:43:01 UTC
view on stackexchange narkive permalink

La question ici est: quelle est la date limite - combien de temps vous a-t-on laissé pour cela? S'il vous reste suffisamment de temps, faites-le, faites-le lentement et prudemment, faites-le bien.

Si il n'y a pas assez de temps, et l'entreprise demande impossible, commencez à chercher un nouvel emploi.

Votre expérience est également au niveau de la complexité du code ? Retravailler quelque chose dans un 1,5 million de lignes de code spaghetti déjà foiré est un travail pour un développeur très expérimenté avec beaucoup d'expérience. Est-ce que votre expérience d'un an et demi avec eux - et vous avez beaucoup plus au total - ou est-ce plus ou moins votre expérience professionnelle totale? Parce que si c'est comme ça, ils vous préparent à l'échec. Voir le cas précédent ... comme dans, commencer à chercher un nouvel emploi.

La question suivante est de savoir si l'entreprise envisage de retravailler sérieusement ce code pour qu'il ne soit pas un gâchis spaghetti, ou sont-ils simplement en train de corriger un correctif au-dessus d'un changement et ainsi de suite? Dans ce cas également, commencez à chercher un nouvel emploi.

Si votre Le manager a 16 ans d'expérience en tant que responsable technique et fait les choses comme décrit ci-dessus, c'est intentionnel, c'est une décision consciente soit d'obtenir plus de travail de votre part que ce qui est normalement possible, soit de vous préparer à l'échec, et quel que soit le cas, il ne changera pas d'avis, quoi que vous disiez.

En vous basant sur les réponses à ces questions, vous verrez s'il s'agit d'une partie difficile mais attendue de votre travail, ou un projet et une équipe en désordre - et cela vous dira tout ce que vous devez savoir.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...