Brièvement sur ce qui est le plus préoccupant dans le monde moderne du développement et pourquoi vous devez prouver, apprendre, tester et ne pas être paresseux.
Je suis développeur, mais je n'ai pas écrit le code depuis longtemps
Nichrome vous n'êtes pas développeur.
Si vous pensez que l'écriture de code est une exigence facultative pour un bon développeur, alors quittez cette planète. Il existe de nombreuses opportunités pour vivre, mais arrêtez d'écrire du code. Vous pouvez aller à la gestion, vous pouvez migrer vers la gestion du personnel, vous pouvez accéder à un poste élevé ou simplement vous rendre au monastère. Mais dans l'une de ces situations, vous cessez d'être développeur si vous n'écrivez plus de code.
Pourquoi? Premièrement: le code n'est pas un vélo, si vous ne pratiquez pas, vous l'oubliez. Deuxièmement: les développeurs sont très offensés quand "une sorte de manager" essaie de se faire passer pour le leur (oui, en général, cela est vrai pour n'importe quelle profession). Troisièmement: il est nocif pour le CSV; si vous avez déménagé dans un autre domaine / industrie, développez à nouveau vos compétences avec le charisme et ne faites pas glisser les références aux succès passés (voir le dernier péché).
D'après les exemples.
- J'étais une fois à une entrevue au bureau américain. Là, à l'une des étapes, un monsieur qui s'est présenté comme PDG a commencé à poser un jeu féroce sur Ruby par morceau de papier (dans le sens de modèles préparés dans Google). Pour savoir s'il écrit le code lui-même et pourquoi une telle indécence à demander aux candidats, il a inversé la conversation avec tact et a demandé de se concentrer sur les tâches.
- Il y a un gestionnaire de ressources familier qui travaille comme psychologue à loisir. Donc, ce monsieur, jusqu'à présent, écrit le code pendant son temps libre et peut parfois grandement surprendre le candidat avec des connaissances curieuses dans un domaine apparemment inhabituel. Il ne semble pas être un programmeur, mais tout le monde le prend pour lui-même.
J'ai effectué des tests, pourquoi tester l'application avec mes mains?
Se fier uniquement aux résultats des tests (même si parmi eux des mannequins d'intégration de bout en bout) est un grave péché. Au moins une fois pendant le développement d'une fonctionnalité, vous devez prendre et utiliser vos mains pour cliquer sur tout le cycle de cette fonctionnalité. Premièrement, vous serez un peu mieux familiarisé avec la plate-forme et la façon dont l'utilisateur la voit, et non comment elle est disposée à l'intérieur. Et deuxièmement, vous suivez un nouveau scénario et le bon sens et vous pouvez trouver quelque chose d'évident pour vous, mais invisible pour les autotests. Dans tous les cas, les autotests sont un ajout à la vérification manuelle par le développeur, et non un remplacement.
Immédiatement, je vais dire sur les fonctionnalités. Je ne parle pas de tests manuels complets par le développeur, il y a des gars QA spécialement formés pour cela. Je parle de la nécessité d'exécuter un projet local et de la vérification minimale de tout changement. Et puis dans les autotests, sur la jeune fille, la scène, le préprod et la prod.
Alors oui, il devrait y avoir des holivars sur la complexité de nombreux projets et leur «incapacité» à fonctionner localement. Personnellement, je ne crois pas à de tels projets épiques. Mais par paresse et avidité - je crois. Passons donc brièvement en revue les éventuels problèmes de lancement local d'un projet.
- Un petit projet indépendant - il n'y a pas d'obstacles aux patriotes!
- Nombreuses intégrations externes. Vous avez donc des bacs à sable pour chacun d'eux. Soit vous avez des talons ou des émulateurs locaux de services externes. Ou vous avez de gros problèmes qui seront bientôt renvoyés.
- Beaucoup de microservices. La ligne du bas est le paragraphe précédent. La seule différence est que les possibilités d'émulation locale se développent. Par exemple, un ensemble de dockers avec de vrais microservices au lieu de stubs.
- Beaucoup de données sont nécessaires pour que le projet fonctionne. Mais très rarement, vous avez besoin d'un tableau de données multi-téraoctets complet pour le développement. Et si vous en avez toujours besoin, plusieurs instances pour les développeurs sont faites pour cela. Par exemple, 2 à 3 énormes instances par équipe de 10 à 15 développeurs. Alors oui, ce n'est pas très pratique et cher pour les affaires, mais sinon vous paierez encore plus pour le développement en production, qui sera réalisé indépendamment des souhaits des top managers.
- Un monolithe monstrueux qui fonctionne sur un fer spécifique et uniquement dans la bonne phase de la lune. Si oui, alors vous êtes probablement dans une entreprise sanglante et le bon sens n'y fonctionne pas.
J'en sais déjà assez et ne peux plus apprendre
En bref: "celui qui ne se développe pas, il se dégrade".
Dans les sciences théoriques, il y a des cas où vous pouvez trouver la base et vous y arrêter. Tout y est plus ou moins stable, éprouvé et immuable. Heureusement, les lois physiques ne changent pas tous les cinq ans. Donc, si vous n'allez pas à la pointe de la science, vous pouvez vivre et même travailler. Voici, par exemple, les intégrales le long du contour: Feynman les a résolues à Los Alamos après la Seconde Guerre mondiale et maintenant elles sont résolues par approximativement les mêmes méthodes analytiques.
Mais avec le développement et la programmation, cela ne fonctionnera pas comme ça. Un seul langage de programmation divin invariable n'a pas encore été trouvé (le concept de l' Avalanche est intéressant, mais pas encore ouvert). La vitesse de la technologie passe de quelques décennies dans le cas des systèmes d'exploitation et des bases de données à quelques mois dans le cas de JavaScript. Et si vous ne vous développez pas, dans un an ou deux, vous pouvez à peu près perdre le niveau, et dans la période de cinq ans, vous obtenez simplement zéro.
Afin de ne pas être trop holistique quant à la vitesse du changement technologique, je vais donner quelques exemples. Il existe un livre sur l'embouteillage de Kernigan et Soldering 1992. En l'utilisant, vous pouvez bien apprendre Unix et ne pas être très surpris des changements survenus 15 ans plus tard. Vous pouvez prendre le livre de Tom Kite sur Oracle 8, qui a été publié vers 2000 et ne pas être très surpris des différences qui se sont produites dans la version 18c. Mais tout livre sur JS d'il y a cinq ans peut être mis en sécurité en toute sécurité.
Je suis assez cool et je ne peux pas le prouver
À mon avis, c'est le plus difficile et le plus courant.
Malheureusement ou heureusement, vous devez prouver vos compétences, votre aptitude professionnelle et votre santé mentale toute votre vie. Lorsque vous arrêtez de faire cela, vous pouvez constater que vous êtes à la retraite, ou que vous souffrez de démence, ou que vous venez de vous épuiser. Dans tous les cas, vous devriez consulter un spécialiste.
La fréquence des preuves est différente. Dans le cas d'amis et de parents, la preuve n'est pas nécessaire si souvent. Et dans le cas des étrangers - sur une base régulière et complète. Les lieux où la preuve est nécessaire sont très divers: lors d'entretiens, de conférences, de nouveaux collègues, de nouveaux amants ... même en magasin, si l'achat est un peu plus compliqué qu'un tabouret.
Si vous pensez qu'une histoire de votre expérience sans confirmation des compétences est normale et suffisante, alors visitez une planète voisine. Quant à moi, cela s'appelle fopping et arrogance.
En ce qui concerne les exemples dans ce domaine, c'est serré, car la plupart d'entre eux sont négatifs et, je pense, le lecteur lui-même se souviendra de quelque chose de convenable de son expérience. Et avec le positif, c'est encore plus difficile, car ils ne sont pas remarqués et se traduisent simplement par un dialogue constructif. Par conséquent, je fais confiance à l’expérience de vie du lecteur et, j’espère que tout le monde donnera un bon exemple.