Le hub regorge de prévisions et de conseils sur ce qu'il faut faire l'année prochaine - quelles langues apprendre, sur quels domaines se concentrer, que faire de votre santé. Cela semble inspirant ! Mais chaque médaille a deux faces, et nous trébuchons non seulement face à quelque chose de nouveau, mais surtout dans ce que nous faisons chaque jour. « Pourquoi personne ne m’a prévenu ! » nous exclamons-nous avec irritation, en nous tournant généralement vers nous-mêmes. Mettons le feu à nous-mêmes - nous avons compilé pour vous une liste de ce qu'il ne faut PAS faire en 2020 (et peut-être toujours).
Mais ils n'ont pas posé de questions sur la gravité
On aimerait vraiment ranger les anti-recommandations, de la plus importante à la moins importante. Mais ils sont si courants, équivalents et familiers à presque tout le monde que nous les écrirons au hasard. Eh bien, vérifions la liste ?
Pas besoin d'aller voir l'informatique si tout va bien
N'apprenez pas une nouvelle technologie pour changer de carrière ou recommencer. Notre époque est merveilleuse car on peut étudier, changer d'emploi, changer radicalement de domaine - et ainsi de suite, même jusqu'à la retraite. C'est une chose cool et séduisante. Mais si vous avez plus de 28-30 ans, vous ne devriez pas tout abandonner pour vous lancer dans l'informatique ou passer à une nouvelle pile (par exemple, vous écrivez des systèmes très chargés en Java et décidez soudainement de vous lancer dans les réseaux de neurones en Python). La raison est simple : ce ne sera pas facile pour vous. Premièrement, il y a une forte concurrence de la part des spécialistes qui sont « assis » sur cette pile depuis le début de leur carrière, deuxièmement, vous devrez redevenir un junior avec un faible salaire, et troisièmement, il vous sera moralement difficile de devenir un subordonné du niveau le plus bas de la hiérarchie. Par conséquent, si vous souhaitez évoluer dans l'autre sens, essayez de le faire soit en fonction de votre travail actuel et de vos tâches actuelles, soit en développant de nouvelles connaissances en tant que passe-temps, démarrez un projet favori afin que lorsque vous arrivez à un nouvel emploi, vous puissiez ne plus être un junior.
Changer pile après pile n'est qu'une perte de temps
Ne vous précipitez pas entre les piles technologiques pour votre développement. Si vous écrivez un projet dans un seul langage, en utilisant un certain framework et des bibliothèques, vous ne devriez pas tout jeter au diable et le réécrire dans Dart simplement parce que vous le trouvez intéressant. Faites-en une règle pour trouver une justification au changement de technologie - non seulement au niveau « je le veux ou je ne peux pas », mais également au niveau financier et technique.
Pas besoin de tenir bon et de devenir bronze
S'en tenir à une seule langue ou à une seule technologie et ne pas apprendre de nouvelles choses est aussi extrême que de changer de pile à chaque nouvelle technologie. Assurez-vous d'étudier de nouvelles bibliothèques et de nouveaux frameworks, ne vous entêtez pas en sachant que tout a été mieux inventé avant vous et réalisé exclusivement par vous. Des mises à jour sont constamment publiées pour presque toutes les langues, ce qui peut parfois grandement améliorer votre projet. Ne soyez pas paresseux pour surveiller la dynamique de votre stack et, dès que vous trouvez quelque chose de sympa et d'utile, n'hésitez pas à le glisser dans le projet !
Ta propre tête est bonne, toujours bonne
Ne pensez pas dans la tête des autres, la vôtre est meilleure. Hélas, certains développeurs restent assis et attendent de recevoir une tâche pour coder de l'erreur précédente jusqu'à la fin, sans essayer d'apporter quelque chose qui leur est propre au projet, développer une nouvelle fonction, la tester et la proposer en production. Pourquoi s'embêter quand il y a un chef d'équipe ou un chef d'entreprise qui décidera de tout lui-même ? Si vous vous reconnaissez, alors nous avons une mauvaise nouvelle : un poste passif ne vous aidera ni dans votre carrière ni dans votre évolution. Vous avez la chance de vous essayer en tant qu'ingénieur de développement, et non en tant que codeur, dans un vrai projet de combat et de comprendre où aller, ce qui manque, mais vous préférez consacrer votre temps à autre chose et faire exactement « à partir d'ici jusqu'à maintenant." Ces personnes survivent de pire en pire dans l’informatique moderne, sortant d’une animation suspendue.
Les utilisateurs sont des gens terribles
Ne surestimez pas les utilisateurs de votre logiciel : si vous n'écrivez pas pour des programmeurs, attendez-vous à ce que le programme se heurte à un malentendu impénétrable. Les premiers jours ou semaines, l’utilisateur détestera votre logiciel parce que « l’ancien n’était pas si stupide ». Pour éviter cela, créez une excellente documentation et des didacticiels. Lors de l'installation ou de l'achat, laissez entendre de manière très intrusive que les manuels doivent être lus avant de commencer à travailler avec le programme, et non après un crash de la base de données, une perte du mot de passe et une maîtrise de soi.
Il ne faut pas non plus sous-estimer les utilisateurs : ils sont plus rusés, plus intelligents et plus curieux qu’on ne le pense. Si vous pensez que le bug avec le format variable et l'exception à la 138ème pression sur Entrée à intervalles d'une seconde n'apparaîtront pas, vous vous trompez - ils apparaîtront et affecteront le fonctionnement de votre application de la manière la plus bizarre. La règle de l'amateur s'applique : c'est lui qui gère le mieux les tests. Mais pour une raison quelconque, les utilisateurs n'aiment pas trouver des bugs en production - ils n'ont aucune solidarité informatique. En général, plus vous avez confiance dans votre logiciel, mieux c'est. Après tout, il est préférable de retarder la sortie de certaines fonctionnalités plutôt que de les ajouter à une application fonctionnelle et de la rendre soudainement brute.
Arrêtez de chercher sur Google !
Arrêtez de vous tourner uniquement vers Google. Nous ne discuterons même pas - dans le domaine du développement, vous pouvez trouver beaucoup de choses en faisant une demande directe à un moteur de recherche. Plus vous creusez à la recherche d'informations, plus vous recevrez de données « latérales » et plus vous en apprendrez, car vous apprendrez quelque chose de nouveau qui n'est pas lié à votre demande, mais qui sera probablement nécessaire à l'avenir. Reportez-vous à des documents complets, des livres, des articles, etc. Les langages et les bibliothèques ont des spécifications, des communautés, des procédures, et vous obtenez ainsi le moyen le plus fiable de développer les compétences du programmeur - il suffit de lire la documentation et de ne pas rechercher les solutions locales et les fragments de code d'autres personnes. Et si votre solution était plus optimale, plus rapide et plus froide ?
Faites confiance, mais vérifiez
N'utilisez pas de bibliothèques et de frameworks créés par des développeurs tiers sans vérifier le code et l'adapter à vos besoins. Vous n'avez aucune raison de faire confiance inconditionnellement à cet auteur de code que vous ne connaissez pas du tout. Oui, divers éléments malveillants délibérés dans le code tiers ne sont pas si courants et vous ne devriez pas souffrir de paranoïa, mais copier aveuglément des parties de logiciels prêtes à l'emploi dans votre projet peut entraîner des conséquences imprévisibles. Par conséquent, assurez-vous de lire et d’analyser le code avant de l’utiliser et de le tester après avoir implémenté le code.
Faites des sauvegardes !
Arrêtez de faire des sauvegardes ou de les conserver sur les mêmes serveurs tiers sur lesquels votre projet est hébergé. Pensez-vous que ce soit un conseil ridicule et inutile ? Mais plus de 700 participants au chat sur Telegram, qui se sont récemment retrouvés dans une situation désagréable avec la fermeture d'un centre de données bien connu, ne le pensaient pas - il y avait de tout là-bas : des projets favoris aux grands sites Web gouvernementaux. autorités et bases de données 1C et de facturation d'entreprise. Une partie importante est sans sauvegardes ou avec des sauvegardes au même endroit. Répartissez donc les risques et stockez la sauvegarde au moins sur l'hébergement principal, sur certains VDS fiables et sur votre serveur local. Cela finira par revenir beaucoup moins cher à long terme.
Arrêtez d'apporter les vôtres au détriment du projet
Ne faites pas ce que vous voulez dans un projet de travail, mais faites ce dont les clients ont besoin. Oui, c'est incroyablement intéressant et génial de créer votre propre réseau neuronal, de le former et de l'implémenter dans votre logiciel, mais si vos clients ont besoin d'un simple gestionnaire de contacts, ce sera exagéré. Découvrez comment fonctionne le projet, lisez la documentation, lisez les avis et les demandes des clients et mettez en œuvre ce qui ajoutera de la valeur commerciale au projet. Si vous souhaitez créer quelque chose de scientifique ou d’extrêmement complexe, commencez par votre propre projet.
Pas un code, mais une boule de nerfs
N'écrivez pas de code illisible et non documenté. Cette astuce nous est familière : le développeur écrit du code à sa guise, en le confondant délibérément un peu pour qu'aucun de ses collègues ne puisse comprendre ce qu'il a écrit - c'est une sorte de vengeance préventive avant que quelque chose n'arrive. Cependant, vous mettez en danger non seulement l'entreprise (qui vous paie de l'argent pour votre travail), mais aussi vous-même : il est probable que vous ne vous souveniez pas vous-même de ce que vous vouliez dire avec cet obscurcissement involontaire. C'est la même chose avec du code non documenté : en vous appuyant sur votre logique de dénomination de variables et de fonctions et sur une bonne mémoire, après quelques années, vous ne vous souviendrez peut-être plus pourquoi vous avez choisi cette boucle, cette méthode, ce modèle, etc. Documenter votre code et sa bonne structure est un grand service rendu à vos collègues, à votre employeur et surtout à vous-même.
Restez simple, stupide
Gardez votre code, vos solutions et vos projets simples. Il n’est pas nécessaire de s’enfermer dans une structure complexe et de produire des entités sans signification particulière. Plus votre code est complexe, plus vous en devenez l'otage - il vous sera aussi difficile que possible de le maintenir et de le développer. Bien sûr, le fameux principe KISS (« Keep it simple, stupid ») n'est pas toujours adapté, mais il a été créé pour une raison : la simplicité et l'élégance du code sont la clé de son application et de sa réutilisation réussie.
Protège toi
N'ignorez pas la sécurité : en 2020, c'est littéralement criminel. Même si votre entreprise, votre développement et vous n'intéressent pas les attaquants, vous pouvez être affecté par des problèmes liés à la défaite de certains segments de réseau, du fournisseur d'hébergement, à l'attaque du centre de données, au vol de mots de passe de messagerie et au comportement dangereux des employés qui peuvent voler des données à l'entreprise, en volant des clients ou le code du programme de l'ensemble du projet. Si cela est en votre pouvoir et dans votre domaine d'expertise, essayez de protéger les projets sur lesquels vous travaillez. Eh bien, observez vous-même la sécurité des informations, cela n'a jamais dérangé personne.
Ne crache pas dans le puits
Ne plaisantez pas avec votre employeur. Aujourd'hui, les communications ont atteint un tel niveau que, par exemple, tous les RH de la ville se connaissent par contumace et peuvent échanger n'importe quelle information dans des chats et des groupes fermés (à la fois pour aider à trouver un emploi et pour écrire « Vasily Ivanov, architecte système, "J'ai tout tué avant de quitter les comptes, supprimé les sauvegardes et éteint le réseau, la récupération a pris 3 jours. Ne l'engagez pas." Ainsi, votre comportement jouera uniquement contre vous - et parfois même un déménagement dans une autre ville ou capitale n'aidera pas. Même si vous partez avec rancune, il n'y a pas de meilleure vengeance que de devenir un employé utile et cool d'un concurrent :) Et surtout, en toute impunité.
Tu ne devrais pas faire ça non plus. Mais, comme le montre l'expérience, nous n'arrêterons pas
En général, mes amis, lisez les conseils, mais faites ce que vous pensez être le mieux - après tout, de vraies découvertes se font lorsque nous doutons de vérités déjà découvertes. Bonne année, que vos projets réussissent, que votre carrière soit agréable, que vos collègues et managers soient adéquats et que votre vie en général soit réussie. En général, place à la nouvelle année et au nouveau code !
Avec amour,
L'équipe de RegionSoft Developer Studio
Au cours de la nouvelle année, nous continuerons à travailler pour vous et à développer un puissant système CRM de bureau. et un service d'assistance et un système de tickets simples et pratiques .
Source: habr.com