Je voulais me lancer dans le développement depuis longtemps, mais, comme cela arrive souvent, je ne croyais pas vraiment en moi. Je croyais que mon train était parti depuis longtemps et que les cerveaux n'étaient plus ceux qui maîtrisaient ce métier difficile. Heureusement, j'étais persuadé, en plus, ils m'ont donné une chance de faire mes preuves et ont fait un stage dans le département de développement. C'est arrivé si simplement et simplement qu'au début je ne pouvais pas y croire. Pendant tout ce temps, il me semblait que maintenant tout le monde comprendrait enfin que j'étais un ignorant et lui ferait signe au revoir. Mais cela ne s'est pas produit, ils ont continué à me soutenir et j'ai fait de mon mieux pour ne laisser tomber personne.
Je suis stagiaire dans notre département backend, qui s'occupe du suivi des produits, et en même temps je travaille dans mon propre département d'intégration technique (depuis 6 mois maintenant). Le langage principal de l'équipe est Python . Je lui ai appris par moi-même à faire un stage. Fondamentalement, bien sûr, sur des manuels et des vidéos sur Internet.
J'avais une petite base - j'ai écrit plusieurs projets de formation en C, mais en général, je ne peux pas dire que j'étais au moins un codeur un peu expérimenté lorsque j'ai été accepté pour un stage. Du haut de cette humble expérience, je voudrais vous parler de quelques choses que je ne savais pas ou que je savais à peine au départ.
Travail d'équipe avec Git
Quand une personne vient à son premier stage, elle imagine ce qu'est Git (sinon il est peu probable qu'elle soit prise du tout), mais a peu d'idée de la façon dont ils travaillent avec lui en équipe. Nous avons tous créé un compte sur GitHub à un moment donné et avons volontiers engagé la première ligne de code dans la branche principale, se sentant comme de vrais pros. Donc: ce n'est pas la meilleure approche pour les grands projets.
Dans le développement d'équipe, le travail avec Git est effectué conformément au git-flow approuvé . Par exemple, nous avons deux branches: développer et master. Personne, à l'exception du chef d'équipe, ne peut télécharger du code dans la branche principale, car l'équipe doit s'assurer qu'il existe un code de travail qui ne détruira pas la production une fois déployé. La responsabilité de cela incombera au chef d'équipe, et personne ne veut mettre le chef d'équipe en colère.
Pour éviter de telles situations, il y a une revue d'équipe. Chaque développeur travaille sur une tâche dans sa propre branche et à la fin du travail met une demande de fusion dans la branche de développement. Et le chef d'équipe place déjà la demande de fusion dans la branche principale et est responsable de la qualité du code auprès de son propriétaire. Ainsi, la pureté du code qui aboutit à la production est garantie, et les risques de verser quelque chose qui va gâcher le travail du projet sont minimisés.
À retenir: si vous voulez mieux vous préparer au travail d'équipe, lisez sur git-flow et commencez à ajouter de nouveaux commits à votre projet familier via des branches.
L'architecture du code est importante
Quand je suis arrivé au stage, je m'attendais à ce qu'ils me disent quoi faire, qu'ils me donnent des petits tests fonctionnels ou unitaires, et que je travaille dessus sous la supervision de l'équipe.
Cependant, tout s'est passé différemment. Non, personne ne m'a demandé de faire quelque chose d'ultra-compliqué, mais on m'a assigné un mini-projet (jalon) pour la surveillance (Python + Prometheus + Grafana ), que j'ai dû faire pendant mon stage. De plus, j'ai moi-même dû réfléchir à l'architecture, décomposer le projet en tâches et le déplacer à travers les étapes Kanban. C'était excitant, mais très correct. Cette approche a permis à mon conservateur et à moi-même de comprendre clairement quels sont mes problèmes et de commencer à les résoudre.
Pour être honnête, ma première décision a échoué. Et le second aussi. J'ai fait des tâches trop volumineuses, je les ai renvoyées plusieurs fois dans le backlog, construit une architecture infructueuse et n'ai pas pu prendre en compte les nuances.
Cependant, pour le moment, la majeure partie du projet a déjà été implémentée et je suis de plus en plus conscient de la façon dont mon code affecte le reste du projet. C'est exitant. J'ai lu plusieurs articles sur l'architecture propre, étudié les classes abstraites, appris à planifier d'abord une interface et ensuite seulement commencer l'implémentation. Je ne peux pas dire que j'ai tout compris, mais j'ai bien compris la phrase "Tout problème peut être résolu en introduisant un niveau supplémentaire d'abstraction, sauf le problème d'un nombre excessif de niveaux d'abstraction." Et j'ai aussi appris à évaluer correctement ma force (mais ce n'est pas exact).
: . , , . , Netflix, . , .
Dans notre entreprise, tous les services sont lancés dans des conteneurs. En conséquence, chaque développeur doit comprendre comment fonctionne le même Docker , comment écrire un simple Dockerfile ou augmenter ses services via Docker Compose .
Pour une personne qui n'écrit que pour elle-même et sur son ordinateur, il est difficile de comprendre pourquoi la conteneurisation est nécessaire. Cependant, sur les grands projets, il est nécessaire de s'assurer que le code fonctionne quel que soit l'environnement. Un peu plus tard, lorsque vous aurez compris les bases, il deviendra évident à quel point c'est pratique. Vous n'avez pas besoin d'installer de dépendances dans votre environnement, il n'est pas nécessaire de lancer un projet long et difficile. Vous pouvez exécuter des tests ou séparer pro et dev en écrivant simplement quelques configurations une fois.
Le même conseil peut inclure le travail avec l'EDI. Avant de commencer le stage, j'ai écrit tous mes programmes exclusivement dans Emacs, mais quand j'ai commencé à travailler, j'ai décidé de passer à un outil plus avancé, et au final je ne l'ai pas regretté. Dans certains endroits, je préfère toujours utiliser la console (par exemple, il est plus pratique d'omettre tous les conteneurs
docker stop $(docker ps -qa)), mais sinon je suis reconnaissant à l' interface graphique de Git et aux conseils de PyCharm.
À emporter: en savoir plus sur Docker. Essayez d'exécuter votre code dans un conteneur. Essayez un IDE pour votre langue et voyez ce qu'il peut faire pour vous.
La documentation et les tests sont tout aussi importants que le code
Mon conservateur a dit un jour que les tests sont la documentation du deuxième développeur. Et cela est très vrai, car si la documentation réelle fait défaut, vous pouvez toujours passer des tests et voir quel comportement est attendu.
Avant mon stage, j'ai utilisé UnitTest et PyTest, mais uniquement dans le cadre de ma formation. Et Mock , par exemple, ne l'utilisait pas du tout, car mes projets n'étaient pas si complexes qu'il fallait remplacer les données (enfin, ou mes tests étaient si mauvais).
Je recommanderais à tous les développeurs novices d'écrire des tests pour toute la logique qui se produit dans le projet. Même si vous pensez que le comportement est évident, il est préférable de le jouer prudemment. Après tout, lorsqu'une autre personne écrit une fonction qui utilise votre code, il y a une chance qu'elle n'entre pas dans les détails et c'est votre test échoué qui sauvera le projet des ennuis.
Et pour minimiser davantage les risques, rédigez une documentation claire. Dans Admitad, une méthode ou une fonction sans documentation soulèvera des questions à examiner. Deux semaines plus tard, personne ne veut perdre de temps à essayer de comprendre à nouveau le code de quelqu'un d'autre. C'est juste une question de respect pour les collègues.
De plus, je dirai que nous annotons également les types en Python en détail, mais si vous écrivez dans un langage fortement typé, ce commentaire n'est pas pour vous. (L'utilisation d'un linter comme Flake8 aide beaucoup à cet égard ).
Conclusion: faites attention aux tests et à la documentation. Commencez avec un readme Git normal - décrivez comment exécuter le projet, ce qu'il fait et ce que vous attendez. Essayez d'écrire des tests pour les principales méthodes et fonctions, ou mieux encore, créez Docker Compose qui exécute tous les tests.
Quelle expérience avez-vous?
Pour les développeurs confirmés, mes conseils peuvent sembler triviaux et évidents. Je vous comprends parfaitement, mais au début, je manquais cruellement de connaissances système. Je suis convaincu que bon nombre de ceux qui maîtrisaient seuls la profession ont été confrontés à ce problème.
Par conséquent, je vous encourage à partager les expériences et les observations que vous avez apprises après les premiers mois (ou années) dans l'industrie. Quels conseils vous donneriez-vous au début de votre carrière? Quelles compétences recommanderiez-vous de développer? Les autres personnes autodidactes et moi-même avons peut-être besoin de vos conseils, alors n'hésitez pas à laisser des commentaires.