Lors de plusieurs stages et de mon premier emploi, j'ai eu le même problème dans 3 entreprises différentes. Alors oui, c'est assez courant.

Ce que vous pouvez faire, c'est pendant que vous apprenez comment tout fonctionne, écrivez-le dans des documents Word ou même txt afin d'avoir une documentation de base à laquelle vous pouvez toujours vous référer ou si quelqu'un de nouveau arrivez dans l'entreprise vous pouvez le lui donner et il le complétera avec ce qu'il pense manquer.

Cela peut aider à avoir une première documentation ....

Les autres réponses semblent prendre le point de vue qu'un "cadre profondément spécifique et non documenté" est 1) problématique, 2) doit être changé et 3) vous devriez faire quelque chose. Je suggérerais d'abord d'identifier s'il y a un problème, et si oui quel est ce problème.

Ils ont écrit leur propre cadre spécifique avec des types, des structures et des modèles personnalisés.

Cela peut être dû au fait que ce cadre permet aux développeurs de l'entreprise de mettre en œuvre les produits / solutions de l'entreprise de manière efficace et efficiente. Ou cela pourrait être un cas de Non inventé ici.

Vous n'avez fourni aucune information pour dire lequel de ces éléments est la réalité.

Il y a peu ou pas de documentation pour cela.

Je pense que la plupart des logiciels qui ne sont pas utilisés par d'autres développeurs, y compris la grande majorité des logiciels d'entreprise, ne disposent pas de documentation. Donc, à lui seul, ce n'est pas du tout surprenant.

L'équipe du logiciel est essentiellement composée de 3 développeurs qui sont ici depuis plus de 10 ans et qui connaissent le framework principalement par cœur.

Produisent-ils des logiciels et des solutions qui fonctionnent? Le font-ils de manière efficace?

Je suis un employé junior avec 1 à 3 ans d'expérience. Je suis censé me familiariser avec ce framework.

Je suis d'accord que cela peut être difficile.

Le framework est énorme et jusqu'à présent il a été presque impossible de développer quoi que ce soit indépendamment à part des choses mineures.

«Énorme» et «pas indépendamment» ne vont pas nécessairement de pair. Un cadre qui a de nombreuses interdépendances est souvent difficile à développer pour un nouveau venu, car il faut tout comprendre pour ne pas casser quelque chose. Un projet bien organisé avec des principes fondamentaux de CS comme la responsabilité unique, l'encapsulation, les limites d'interface définies peut totalement être travaillé de manière relativement "indépendante", vous ne fonctionnerez que dans un sous-système particulier.

J'ai rencontré l'un des développeurs pour essayer d'apprendre d'eux, mais ça ne va pas aussi vite que je pense que ça devrait.

Vous devrez peut-être ajuster vos attentes. Dans les grands systèmes, l'intégration complète prend mois ou années . Si vous êtes habitué à de petits projets ou à des entreprises en démarrage, c'est une expérience très différente d'avoir travaillé pour une grande entreprise pendant, par exemple, 6 mois et d'avoir toujours l'impression de ne pas en savoir grand chose. C'est normal dans les grandes entreprises.

Donc, au lieu de vous en tenir à votre idée de la vitesse à laquelle vous devriez accélérer, demandez à votre patron (ou même l'un des autres développeurs avec lesquels vous êtes le plus sympathique, à quel point il pense que vous maîtrisez le système.

Rappelez-vous: de votre propre aveu, il leur a fallu 10 ans pour arriver à leur état actuel.

J'ai soulevé le problème de la documentation avec le responsable, et bien qu'il soit d'accord, les 3 personnes qui pourraient documenter le cadre sont toujours occupées par des projets qui rapportent de l'argent.

C'est aussi normal. Il est peu probable que vous réussissiez à obtenir la documentation du système. Vous pouvez réussir à l'apprendre, ou vous pouvez constater que votre cerveau ne fonctionne pas dans ce langage / architecture / style de codage particulier. Par exemple, je n'aime généralement pas regarder le code Java même si la bibliothèque / le programme en question est plus petit qu'un grand framework Ruby avec lequel je n'ai aucun problème.

Que puis-je faire à ce sujet ?

Premièrement, et le plus important:

Parlez à votre patron de ce que l'on attend de vous et si vous répondez aux attentes. Si votre patron est perspicace, il peut comprendre que vous avez besoin de quelques mots d'encouragement et donnez-les, en supposant que vous répondez aux attentes.

Ensuite, formulez le problème. Vous n'êtes pas satisfait de votre vitesse d'intégration? N'aimez-vous pas l ' architecture du système? Pensez-vous que vous ne recevez pas suffisamment de soutien^?

Selon ce que vous percevez comme étant le problème, la marche à suivre variera.

Note finale :

Vous dites que les autres développeurs génèrent des revenus pour l'entreprise. Cela signifie qu'ils doivent chaque jour décider de générer des revenus ou de vous former. Selon les priorités de l'entreprise, ils peuvent donner la priorité à la génération de revenus et ne pas allouer beaucoup de temps à votre intégration.

Cela peut être pris en compte dans les attentes que votre patron a pour vous.

Quoi qu'il en soit , ce n'est pas le meilleur endroit car une entreprise a besoin de ses employés pour générer des revenus. Pour résoudre ce problème, je suggère de prendre des initiatives , mais pas en exigeant de la documentation, mais en travaillant sur tout ce qui, selon vous, aidera l'entreprise à générer des revenus . Essayez de trouver un moyen de faire quelque chose qui se traduirait par des dollars gagnés. Vous devez formuler cela d'une manière qui soit clairement bénéfique pour l'entreprise en termes de résultat net ($$$ gagné plus que $$$ dépensé pour vous aider). Cela incitera votre patron et, à travers lui, les autres développeurs à vous accorder plus de temps.

Malheureusement, c'est assez courant. Il y a certaines choses que vous pouvez faire pour aider.

Premièrement, je suggère de tenir un journal de vos questions. Souvent, le simple fait d'écrire les questions vous aidera à trouver les réponses vous-même, mais si vous ne le faites pas, vous pouvez les poser à votre contact.

Au fur et à mesure que vous en apprendrez sur le cadre, rédigez votre propre documentation. Ne doit pas être trop formel. Lorsque vous avez documenté une section, vous pouvez demander à vos collègues de la consulter pour vérifier qu'elle est correcte, et éventuellement la société aura une documentation pour ce logiciel apparemment important.

Utilisent-ils un type quelconque du système de génération de documentation où la documentation est écrite dans le code lui-même? Si c'est le cas, l'améliorer et soumettre des correctifs / demandes d'extraction est un excellent moyen de vous familiariser, de vérifier votre compréhension et d'apporter quelque chose d'utile.

Assurez-vous que votre patron est conscient qu'il y a une courbe d'apprentissage raide mais que vous s'efforcent de se mettre à niveau tout en étant productif.

C'est malheureusement plus courant que vous ne le souhaiteriez.

J'ai eu des expériences avec plusieurs entreprises qui avaient un environnement similaire. La cause principale a toujours été que la direction (qui ne sont pas des développeurs) a microgéré la charge de travail de leurs développeurs et n'a pas pris soin de consacrer du temps à des éléments non facturables tels que le refactoring ou la documentation (que ce soit parce qu'ils niaient catégoriquement son importance ou que leurs développeurs manquaient du bien pratiquez l'expérience ou l'épine dorsale pour demander du temps pour le faire)

J'ai soulevé le problème de la documentation avec le responsable, et bien qu'il soit d'accord, les 3 personnes qui pourraient documenter le cadre sont toujours occupées des projets qui rapportent de l'argent.

"Nous le ferons un jour, quand nous aurons le temps" est plus souvent dit que fait. Dans tous les cas que j'ai vus, les mêmes personnes n'ont jamais gagné le temps, et si le temps était fait, ils trouveraient encore d'autres moyens de le remplir. Ne croyez pas à une promesse vide, surtout si elle a été faite plusieurs fois sans qu'aucune action réelle ne soit entreprise.

À moins que vous ne puissiez influencer les bonnes personnes (la direction, ou une majorité suffisante des développeurs qui, à leur tour, peuvent force de la gestion à écouter), vous ne pourrez pas faire grand-chose à propos de cet environnement sans assumer à lui seul une tâche herculéenne.

Ce que vous faites à partir d'ici dépend de vous.

• Vous pouvez simplement vous aligner et faire le travail comme vous pouvez le faire. Si cela nécessite une assistance constante des experts, qu'il en soit ainsi. Il est de la responsabilité de l'entreprise de fournir des ressources afin que vous puissiez travailler avec leur cadre. En l'absence de documentation ou de code clair, cela signifie avoir accès à des experts auxquels poser des questions. S'ils ne sont pas disponibles non plus (ou si vous vous plaignez de vos questions), indiquez que vous ne pouvez pas exercer vos fonctions tant que les problèmes ne sont pas résolus.
• Vous pouvez quitter le navire dès que possible si vous n'aimez pas cet environnement et préférez chercher une autre entreprise. Sachez qu'il y a toujours une chance de se retrouver dans une situation similaire, et vous ne comprenez généralement pas cela pendant la phase de l'entretien (à moins qu'ils ne soient manifestement explicites sur leurs pratiques)
• Vous pourriez voir cela comme un possibilité de remplir un rôle indispensable dans l'entreprise. Documenter le processus, améliorer les bonnes pratiques, prendre en charge la création d'un meilleur environnement de pratique. Si cela est bien fait, cela peut améliorer considérablement votre position dans l'équipe de développement. Mais c'est une bataille difficile quand le reste de l'équipe n'est pas à bord.
• Vous pouvez essayer de convaincre les décideurs de prendre conscience des failles du processus de développement. Que ce soit par le biais de discussions ou de preuves solides, vous pouvez convaincre les gens qu'ils peuvent améliorer leur productivité s'ils améliorent leur processus. Mais méfiez-vous de ceux qui n'ont aucun intérêt à faire les choses différemment ("mais c'est comme ça que les choses se font ici").

Dans mon expérience, j'ai donné à chacun de ces projets entre 3 et 6 mois de véritables efforts et demandes pour améliorer le processus de développement. Dans un cas, j'ai réussi à renverser la vapeur. Dans d'autres cas, il a fini par être en conflit avec la direction qui a refusé d'écouter la raison même lorsque plusieurs entrepreneurs indépendants ont tous souligné les mêmes problèmes, recourant plutôt à blâmer ces personnes pour leur non-qualification. Des environnements toxiques existent et certains d'entre eux vous tueront avant que vous ne réussissiez à les nettoyer.

Que vous vouliez ou non mener cette bataille difficile, c'est votre décision.

Eh bien, cela dépend de la manière dont vous souhaitez aborder la situation, du soutien de la direction dont vous disposez et de la facilité / difficulté de passer à un cadre standard pour ce que vous faites.

I signifie, au plus basique, vous avez 3 options:

• Quitter.
• Apprenez le nouveau cadre.
• Convainquez votre patron de vous permettre de commencez à standardiser le nouveau développement dans un cadre régulier.

Pour être honnête, je préconiserais l'option 3. Et vous devriez avoir un support de gestion. Si cela aide, évoquez: que se passe-t-il lorsque ces 3 mecs partent? Si votre framework homebrew était petit et facile à apprendre, cela pourrait être une chose. Mais vous avez beaucoup de mal à faire autre chose que de petits changements. Si ces «3 mecs» partaient, votre entreprise survivrait-elle?

La chose la plus importante à garder à l'esprit est: vous devez avoir un chemin à parcourir. La direction ne veut pas entendre: «Nous faisons XYZ et ça va nous détruire!»

Ils veulent entendre: «Eh bien, nous faisons XYZ, mais cela ne fonctionnera pas longtemps -term. Donc, à la place, nous devrions immédiatement démarrer Small Change A, puis faire B pour chaque nouveau projet qui apparaît, suivi de C. " En d'autres termes, un plan avec le moins de douleur possible.

Comme beaucoup d'autres répondeurs, je me suis trouvé exactement dans la même situation, donc je comprends bien les inconvénients. Cependant, je vais en fait essayer de souligner certains des avantages de cette situation - principalement sous l'égide de l'apprentissage.

Soyons clairs, vous êtes au début de votre carrière, donc la probabilité est que vous " Je changerai d’emploi avant trop longtemps, que ce soit pour cette raison ou pour toute une série d’autres. Mon conseil serait de recadrer votre point de vue à ce sujet d'une raison de partir, à une opportunité d'apprendre pendant que vous êtes encore là.

Je pense que pour mieux voir les opportunités d'apprentissage offertes en travaillant avec une coutume cadre interne, nous devons revenir à ce qu’est un framework . Fondamentalement, une abstraction sur un grand nombre de problèmes courants dans la création d'une application que vous pouvez exploiter pour concentrer davantage votre énergie sur les parties de l'application qui rendent votre produit / entreprise spécial, et moins sur le produit éléments que la plupart des produits / entreprises doivent mettre en œuvre.

C'est bien sûr pourquoi la plupart des entreprises utilisent des frameworks prêts à l'emploi. 99% du temps, ces pièces de base sont vraiment tout ce dont ils ont besoin. La première chose à essayer d'apprendre alors, lorsqu'un framework personnalisé est choisi par votre entreprise, c'est pourquoi . Il est assez facile de qualifier cela d'incompétence, et peut-être parfois dans une certaine mesure, mais probablement le plus souvent la vraie raison est que les pièces de base fournies par les frameworks populaires (du moins au moment où l'application a été écrite pour la première fois) étaient t adapté à l’application et au problème commercial qu’elle résout.

De quelles parties, et pourquoi, est une question vraiment intéressante sur laquelle vous allez beaucoup apprendre - qu’ils aient eu raison ou tort dans leurs choix! (Apprenez quoi faire, bien sûr, mais apprenez également ce qu'il ne faut pas faire). En fin de compte, c'est l'essence même du travail d'un ingénieur logiciel: proposer, ou du moins cartographier, des solutions techniques appropriées aux problèmes commerciaux. La mesure dans laquelle vous êtes un bon ingénieur est plus ou moins la mesure dans laquelle vous pouvez bien faire cela, et apprendre comment et pourquoi d'autres ingénieurs plus expérimentés de votre entreprise ont choisi de résoudre les problèmes commerciaux spécifiques de votre entreprise avec des solutions personnalisées qui sont entièrement ouverts à vous (comme dans, littéralement, vous avez le code devant vous) est une opportunité d'apprentissage en or qui n'est disponible que pour le moment, dans ce poste. Prends-le.

En dehors de la perspective plus de résolution de problèmes commerciaux, d'un point de vue purement technique, il y a aussi une opportunité d'apprentissage en or ici. C'est-à-dire que vous êtes obligé de vous retrouver dans une situation où vous devez comprendre en profondeur et même dans certains cas faire de l'ingénierie inverse les solutions personnalisées aux problèmes courants d'ingénierie d'application qui, dans d'autres frameworks populaires largement utilisés, sont simplement résolus pour vous et remis à vous sur une assiette.

En ingénierie, la plupart de l'apprentissage est dirigé par nécessité. Vous arrivez à réfléchir et à comprendre profondément les problèmes et les solutions parce que vous devez le faire. Lorsqu'ils sont résolus pour vous, vous pouvez étudier comment ils fonctionnent sous le capot par intérêt, mais en général, vous n'irez pas dans autant de profondeur ou n'y consacrez pas autant de temps que vous le feriez autrement. si vous deviez vraiment travailler.

Devoir implémenter un framework vous-même à partir de zéro, ou inverser la tentative de quelqu'un d'autre comme dans votre cas, est comme je le dis une autre opportunité d'apprentissage en or pour vraiment comprendre les détails des problèmes qui sont résolus, ce qui sera vraiment bénéfique pour le reste de votre carrière. Le fait que vous puissiez faire cela en tant qu'ingénieur junior est particulièrement formidable. Encore une fois, oui, ce n'est peut-être pas la chose la plus agréable et peut être carrément frustrante à certains moments, je comprends, mais profitez de cette opportunité tant que vous l'avez!

Vous êtes au début de votre carrière et il est normal que vous n'ayez pas encore expérimenté de grands projets, vous ne savez donc pas à quoi vous attendre lorsque vous travaillez avec du code hérité. Vous recherchez spécifiquement de la documentation car c'est ainsi que vous travailleriez avec un grand framework open-source populaire (comme Qt en C ++, ou choisissez un exemple dans votre langage de base).

Ce n'est pas ainsi que les choses fonctionnent dans le code hérité interne et cela facilitera votre future vie professionnelle si vous apprenez à trouver votre chemin dans une grande base de code non documentée, comment obtenir l'aide d'experts internes sans les aliéner et comment écrire du code auto-documenté avec un besoin minimal de l'effort en double dans la documentation.

Mon conseil serait:

• Réinitialisez vos attentes. Ne vous attendez pas à ce que la lecture de la documentation soit le principal moyen d'apprendre le code hérité.
• Découvrez d'autres façons d'apprendre un projet existant. Il existe des ressources sur le net pour cela, vous pouvez commencer avec cette question. Comme beaucoup de choses, cela s'améliore avec la pratique. Pour moi personnellement, le refactoring du code donne le plus d’apprentissage par minute de codage, même si je jetterais ce refactoring plus tard.
• Vous pouvez souvent trouver une réponse à «comment faire cela» dans un code existant utilise cette fonctionnalité. N'hésitez pas à commencer par le copier.

Dans l'ensemble, il y a beaucoup de bonnes raisons de fuir un projet ou une entreprise. Un vaste cadre interne avec une documentation insuffisante en soi ne me semble pas être une bonne raison de partir.

Je pense que beaucoup de choses ont déjà été dites, mais j'aimerais vous donner quelques durées d'expérience afin que vous ayez une meilleure idée de ce à quoi vous attendre;

J'ai effectué un stage dans l'entreprise i travaille maintenant pour, tout droit sorti de l'école.Pendant le processus d'embauche, ils m'ont littéralement donné un ensemble de jalons (d'une manière légèrement humoristique bien qu'ils soient tous basés sur la réalité):

• 1 jour avant de partir , la personne la plus courte travaillait et partait
• 2 semaines avant de partir, ce qui était le plus courant
• 4 mois, car c'était surtout lorsque les employés étaient restés avec l'entreprise jusqu'à la vieillesse.
• 4 mois pour les juniors et les seniors pour apprendre et comprendre le logiciel

Je me suis spécialisé en génie logiciel technique (C / C ++, systèmes embarqués, etc.) et je voulais passer à plein génie logiciel (C #, Web, applications de bureau, etc.) donc je connaissais à peine les constructions de base comme la POO ou les langages avec lesquels je travaillais.

Il m'a fallu six mois pour avoir l'impression de contribuer au moins quelque chose et un plein oui r se sentir enfin suffisamment compétent pour travailler avec le logiciel. Il m'a fallu encore six mois pour me sentir comme le match de mes collègues sur le plan technique, et avant de me sentir compétent pour pouvoir toucher chaque ligne de logiciel.

La situation était la même, pas de documentation (bien que le code lui-même ait été assez bien maintenu), et personne ne m'a tenu la main - et je ne connaissais même pas la pile technologique.

Mon point ici est que cela prend du temps et que vous ne devriez pas vous inquiéter le temps à venir. Détendez-vous - je suis bien sorti et vous aussi.

Quelques autres conseils que j'ai pris en cours de route:

• N'ayez pas peur de décomposer les choses. La peur m'a gardé longtemps en arrière, et vivre c'est apprendre.
• Lorsque vous finissez par casser des choses, assurez-vous d'avoir la bonne raison de le faire et assurez-vous de l'exprimer.