Habr regorge de prévisions et de conseils sur ce qu'il faut faire l'année prochaine - quelles langues apprendre, dans quels domaines se diriger, comment gérer sa santé. Cela semble inspirant ! Mais pour toute médaille, il y a deux côtés, et nous trébuchons non seulement sur de nouvelles choses, mais surtout sur ce que nous faisons chaque jour. « Pourquoi personne ne m'a prévenu ! », s'exclamons-nous souvent, nous adressant généralement à nous-mêmes. Nous attirons le feu sur nous - nous avons rassemblé pour vous une liste de ce qu'il NE faut PAS faire en 2020 (ou peut-être toujours).
Et la gravité, on ne l'a pas demandée.
Nous aimerions vraiment classer les anti-recommandations par ordre d'importance, de la plus importante à la moins significative. Mais elles sont si répandues, équivalentes et familières à presque tout le monde, que nous allons écrire de manière désordonnée. Alors, vérifions la liste ?
Il ne faut pas aller dans l'informatique si tout va bien.
N'apprenez pas une nouvelle technologie pour changer de profession ou repartir de zéro. Notre époque est merveilleuse en ce sens que l'on peut se former, changer de travail, changer radicalement de domaine - et ce jusqu'à la retraite. C'est une chose séduisante. Mais si vous avez plus de 28-30 ans, il ne vaut pas la peine de tout abandonner pour entrer dans l'informatique ou changer de stack (par exemple, si vous développez des systèmes hautement chargés en Java et que vous décidez soudainement de passer aux réseaux de neurones en Python). La raison est simple : cela ne sera pas facile. D'abord, la concurrence est forte avec des spécialistes qui travaillent avec ce stack depuis le début de leur carrière, ensuite, vous devrez redevenir junior avec un faible salaire, et enfin, il sera moralement difficile de devenir subordonné du niveau le plus bas de la hiérarchie. Donc, si vous souhaitez avancer dans une autre direction, essayez de le faire soit en lien avec votre travail actuel et vos tâches actuelles, soit développez de nouvelles compétences comme un hobby, développez un projet personnel, afin d'arriver dans un nouveau travail en n'étant pas junior.
Changer de stack en stack est une perte de temps.
Ne vous précipitez pas entre les stacks technologiques pour votre développement. Si vous travaillez sur un projet dans un langage, utilisez un certain framework et des bibliothèques spécifiques, ne jetez pas tout à la poubelle et ne réécrivez pas en Dart juste parce que cela vous semble intéressant. Prenez pour règle de trouver une justification pour changer de technologie - pas seulement au niveau « je veux-je ne peux pas », mais aussi au niveau financier et technique.
Il ne faut pas s'entêter et devenir rigide.
S'en tenir à un seul langage ou technologie et ne pas explorer de nouvelles options est tout aussi extrême que de changer de pile à chaque nouvelle technologie. Assurez-vous d'étudier de nouvelles bibliothèques et frameworks, ne soyez pas obstiné en pensant que tout a déjà été pensé et peaufiné avant vous. Pratiquement chaque langage reçoit constamment des mises à jour qui peuvent améliorer considérablement votre projet. Ne vous laissez pas aller, suivez l'évolution de votre pile et, dès que vous trouvez quelque chose d'innovant et d'utile, intégrez-le sans hésiter dans votre projet !
Une tête, c'est bien, mais toujours mieux.
Ne pensez pas avec la tête des autres, la vôtre est meilleure. Hélas, certains développeurs s'assoient et attendent qu'on leur donne l'ordre de coder depuis l'erreur précédente jusqu'à la fin, sans essayer d'apporter quelque chose de leur propre cru au projet, de développer une nouvelle fonction, de tester et de proposer en production. Pourquoi se fatiguer, quand on peut compter sur la tête du team leader ou du dirigeant de l'entreprise qui décidera de tout à votre place ? Si vous vous reconnaissez là-dedans, nous avons de mauvaises nouvelles : une attitude passive ne vous aidera ni dans votre carrière ni dans votre développement. Vous avez l'opportunité de tenter votre chance en tant qu'ingénieur développeur, et non comme simple coder dans un vrai projet en production, et de comprendre quelle direction prendre, ce qui vous manque, mais vous préférez passer votre temps à autre chose et faire simplement « d'ici à là ». Ceux qui adoptent cette position dans l'informatique moderne peinent de plus en plus à s'en sortir, sortez de votre léthargie.
Les utilisateurs sont des créatures redoutables.
Ne surestimez pas les utilisateurs de votre logiciel : si vous ne codez pas pour des programmeurs, attendez-vous à ce que votre programme se heurte à une incompréhension totale. Pendant les premiers jours ou semaines, l'utilisateur détestera votre logiciel, car « l'ancien n'était pas aussi stupide ». Pour éviter cela, créez une excellente documentation et des supports de formation. Lors de l'installation ou de l'achat, faites subtilement remarquer qu'il est conseillé de lire les manuels avant de commencer à utiliser le programme, et non après l'effondrement de la base de données, la perte de mot de passe et l'auto-contrôle.
Il ne faut pas non plus sous-estimer les utilisateurs : ils sont plus rusés, plus intelligents et plus curieux que vous ne le pensez. Si vous pensez que ce bug lié au format de variable et l'exception à la 138ème pression de la touche Entrée avec un intervalle d'une seconde ne vont pas surgir, vous vous trompez — ils apparaîtront et influenceront le fonctionnement de votre application de manière des plus étranges. La règle du dilettante s'applique : c'est lui qui réussit le mieux à faire des tests. Mais les utilisateurs n’aiment pas trouver des bugs en production — aucune solidarité IT à ce sujet. En somme, plus vous avez confiance en votre logiciel, mieux c'est. Après tout, il vaut mieux retarder la sortie de certaines fonctionnalités que de les ajouter à une application en fonctionnement et de la rendre soudainement instable.
Assez de Google !
Cessez de vous fier uniquement à Google. Pas besoin de discuter — dans le domaine du développement, il est possible de trouver énormément de choses avec une recherche directe sur le moteur. Plus vous creusez dans votre quête d'informations, plus vous obtiendrez de données « latérales » et plus vous apprendrez, car vous découvrirez quelque chose de nouveau, non lié à votre recherche, mais potentiellement utile à l'avenir. Consultez des ressources complètes, des livres, des articles, etc. Les langages et bibliothèques disposent de spécifications, de communautés, de tutoriels, et c'est ainsi que vous obtiendrez le moyen le plus fiable de développer vos compétences de développeur — en lisant simplement la documentation et non en cherchant des solutions locales d'autres personnes et des fragments de code. Et si votre solution s'avérait plus optimale, rapide et intéressante ?
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 aveuglément à cet auteur de code que vous ne connaissez pas du tout. Oui, les éléments malveillants intentionnels dans le code tiers ne sont pas si fréquents et il ne faut pas sombrer dans la paranoïa, mais une copie aveugle de parties de code prêtes à l'emploi dans votre projet peut entraîner des conséquences imprévisibles. Par conséquent, lisez et analysez toujours le code avant de l'utiliser et effectuez des tests après l'implémentation du code.
Faites des sauvegardes !
Ne faites plus de sauvegardes ou ne les stockez sur des serveurs tiers où votre projet est hébergé. Pensez-vous que c'est un conseil ridicule et inutile ? Plus de 700 participants d'un chat sur Telegram, qui ont récemment connu une situation désagréable avec l'arrêt d'un célèbre centre de données, ne le pensaient pas — il y avait de tout : des projets secondaires aux grands sites des organismes gouvernementaux et des bases d'entreprise 1C et de facturation. Une part significative — sans sauvegardes ou avec des sauvegardes à cet endroit même. Alors, diversifiez les risques et conservez la sauvegarde au minimum sur l'hébergement principal, sur un VDS fiable et sur votre serveur local. Au final, cela vous coûtera beaucoup moins cher.
Assez de porter vos désirs au détriment du projet
Ne faites pas dans un projet de travail ce qui vous plaît, faites ce qui est nécessaire pour les clients. Oui, il est incroyablement intéressant et fantastique de créer votre propre réseau de neurones, de l'entraîner et de l'intégrer dans votre logiciel, mais si vos clients ont besoin d'un simple gestionnaire de contacts, c'est un luxe coûteux. Regardez comment fonctionne le projet, lisez la documentation, lisez les avis et les demandes des clients et mettez en œuvre ce qui apportera une valeur commerciale au projet. Si vous voulez créer quelque chose de scientifique ou de très complexe, commencez par votre propre projet.
Pas de code, mais une boule de nerfs
Ne rédigez pas de code illisible et non documenté. Nous sommes familiers avec ce phénomène : un développeur écrit du code comme il l’entend, le rendant un peu confus pour que personne ne puisse comprendre ce qui a été écrit — une sorte de revanche préventive avant que quelque chose ne se produise. Cependant, vous risquez non seulement l'entreprise (qui vous paie pour le travail), mais aussi vous-même : il est fort probable que vous n'ayez pas de souvenir de ce que vous vouliez exprimer avec cette obfuscation involontaire. Il en va de même pour le code non documenté : en comptant sur votre logique de nommage des variables et des fonctions et sur votre bonne mémoire, dans quelques années, vous pourriez ne pas vous rappeler pourquoi vous avez choisi ce cycle, cette méthode, ce modèle, etc. Documenter le code et avoir une bonne structure est un excellent service pour vos collègues, votre employeur et surtout pour vous-même.
Gardez-le simple, stupide
Ne compliquez pas le code, les solutions et les projets. Il n'est pas nécessaire de créer une structure complexe et de multiplier les entités sans importance particulière. Plus votre code est compliqué, plus vous devenez son prisonnier — il vous sera extrêmement difficile de le maintenir et de le développer. Bien sûr, le célèbre principe KISS («Keep it simple, stupid») ne s'applique pas toujours, mais il n'a pas été créé en vain : la simplicité et l'élégance du code sont la clé de son utilisation réussie et de sa réutilisation.
Protégez-vous
N'ignorez pas la sécurité — en 2020, c'est littéralement criminel. Même si votre entreprise, votre développement et vous-même n'intéressez pas les malfaiteurs, vous pouvez être affecté par des problèmes liés à un segment de réseau, un fournisseur d'hébergement, une attaque sur un centre de données, le vol de mots de passe de courriel et un comportement peu sûr des employés qui peuvent voler des données de l'entreprise, détourner des clients ou le code source de l'ensemble du projet. Si vous en avez la capacité et que cela relève de votre domaine de compétence, essayez de protéger les projets avec lesquels vous travaillez. Et veillez à respecter la sécurité de l'information, cela n'a jamais nui à personne.
Ne crachez pas dans le puits
Ne nuisez pas à votre employeur. Aujourd'hui, les communications ont atteint un tel niveau que, par exemple, tous les recruteurs de la ville se connaissent à distance et peuvent échanger des informations dans des chats et des groupes fermés (tant pour aider à se faire embaucher que pour dire «Vassili Ivanov, architecte système, avant de partir, a tué tous les comptes, a effacé les sauvegardes et a coupé le réseau, la récupération a duré 3 jours. Ne l'embauchez pas»). Ainsi, votre comportement jouera uniquement contre vous — et parfois même une relocalisation dans une autre ville ou capitale ne pourra pas vous sauver. Même si vous partez avec ressentiment, il n'y a pas de meilleure revanche que de devenir un employé utile et formidable chez un concurrent 🙂 Et surtout, totalement sans conséquences.
Il ne faut pas non plus faire ainsi. Mais, comme le montre l'expérience, nous ne cesserons pas.
En fait, mes amis, lisez les conseils, mais agissez comme vous le jugez le mieux — car les véritables découvertes se font lorsque nous remettons en question des vérités déjà établies. Nous vous souhaitons une bonne année, que vos projets soient réussis, que votre carrière soit passionnante, que vos collègues et supérieurs soient raisonnables, et que la vie en général réussisse. En gros, à la nouvelle année et à un nouveau code !
Avec amour,
l'équipe de RegionSoft Developer Studio
L'année prochaine, nous continuerons à travailler pour vous et à développer un puissant système CRM de bureau. et un service d'assistance simple et pratique ainsi qu'un système de tickets. .
Source : habr.com
