🏍️ 🈯️ 🔸 Huit habitudes de programmation importantes 🛃 🥢 🛳️

«Une personne ne peut devenir une personne que par l'éducation. Il est ce que l'éducation fait de lui. »
I. Kant

À mon avis, cette citation convient très bien aux programmeurs. En fait, un programmeur n'est pas seulement un spécialiste qui connaît bien les questions techniques. Un programmeur est avant tout un artisan qui crée chaque jour du code à partir de ses connaissances. Créer un bon code est impossible sans l'utilisation disciplinée de certaines compétences. Et cette utilisation régulière est ce que sont les habitudes.

Il se trouve que de mauvaises habitudes nous empêchent de vivre et de travailler, et que les bonnes accroissent la productivité, et en général, une personne obtient plus de plaisir de la vie. Si vous faites un effort et commencez à acquérir et à pomper de bonnes habitudes, vous remarquerez très vite comment vous devenez un spécialiste d'un niveau supérieur. Mais ce n'est pas tout, vos collègues remarqueront également rapidement des changements positifs, ce qui les forcera à apprendre et à adopter des techniques utiles. Lorsque vous travaillez avec du code dans une équipe, vous pouvez lire l'attitude de la personne à l'égard du travail dans chaque commit.

Alors, passons en revue les huit habitudes utiles d'un programmeur qui feront de vous le meilleur professionnel.

1. Ne répétez pas (SEC - Ne vous répétez pas)

Vous êtes probablement tombé sur le fait qu'en regardant la prochaine section de code, vous pensez: "Hmm, ici j'ai déjà fait quelque chose de similaire, mais avec des arguments différents, et en général il y avait un tableau de données différent."

Cela devrait être un appel à vous que ce code sera répété à l'avenir, encore une fois avec de petits changements dans les conditions et les données. Mais si vous ne faites pas attention à ce signal ou si vous êtes pressé, vous devrez probablement réécrire l'algorithme à partir de zéro lorsqu'une solution similaire sera nécessaire à l'avenir. Peu à peu, ces algorithmes s'accumuleront, le code augmentera et, à la fin, vous perdrez complètement la motivation pour apporter des modifications et des améliorations à ces nouilles.

Par conséquent, développez une bonne habitude de suivre le principe SEC (ne pas répéter). Chaque fois que vous vous surprenez à écrire un algorithme similaire, prenez le temps de réfléchir à plusieurs options possibles avec différentes entités. Organisez une petite fonction générique ou même une classe si l'algorithme est complexe. Cela prendra un peu plus de temps que d'écrire une solution rapide pour une tâche spécifique, mais cela permettra d'économiser une quantité incroyable d'heures à l'avenir pour le débogage et les tests.

Peu à peu, toute une bibliothèque de ces blancs s'accumulera en vous et vous pourrez facilement les utiliser dans n'importe quel projet.

La programmation dans son ensemble consiste en de si petits efforts qui sont effectués dans le processus. Faites-vous sortir un peu plus que ce qui est actuellement requis. Ensuite, vous commencerez à grandir.

Il existe toute une liste de principes similaires qui sont très utiles à respecter. Mais, à mon avis, DRY est fondamental pour tout le reste dans le travail d'un programmeur.

2. Une fois que vous avez décidé que tout est fait, refactorisez

La plupart des programmeurs, en particulier les débutants, pensent que leur travail est terminé dès que le code commence à effectuer la tâche comme prévu. Ce n'est que maintenant que le mot «fait» inclut un concept plus large que l'écriture triviale de code.

Le code fonctionne-t-il correctement? Oui! Alors, quel est le problème?

Oui c'est vrai. Juste avant de passer à la tâche suivante, passez en revue ce que vous avez écrit. Du début jusqu'à la fin. Très probablement, vous remarquerez que certaines variables sont déclarées à un endroit gênant et on ne sait pas pourquoi elles sont nécessaires. Il peut également y avoir une ligne trop longue qui ne rentre pas dans l'écran, ce qui signifie qu'ici, vous devez réfléchir à la façon de la rendre plus belle. Ou la fonction s'est avérée trop volumineuse et peut être divisée en deux parties.
Pensez aux personnes qui liront votre code à l'avenir. Qu'ils aiment ce code ou qu'aucune bière ne puisse le comprendre.

Prenez une belle décision, pas seulement une décision efficace. Tout comme les bons écrivains après avoir rédigé un brouillon: ils lisent leur travail plusieurs fois et jettent des parties inutiles pour que le lecteur l'apprécie et saisisse le sujet sans avoir à entrer dans trop de détails.

Je recommande fortement de lire Robert Martin sur ce sujet . Un livre instructif qui devrait être dans la bibliothèque de chaque programmeur.

3. Se concentrer sur les tâches commerciales

De nombreux programmeurs ont tendance à se concentrer sur l'étude du côté technique de leur travail et pensent que les affaires n'ont rien à voir avec eux. L'essentiel est de donner de bonnes spécifications techniques, puis je ferai tout de la meilleure façon possible. Ce n'est que pour devenir vraiment un maître de votre métier que vous devez comprendre pourquoi ce que vous faites a pris l'entreprise.

S'il est très grossier d'imaginer un programmeur qui travaille uniquement sur les savoirs traditionnels sans en comprendre l'essence, alors un exemple peut être donné. Le chauffeur de bus, à côté duquel les passagers s'assoient et lui disent: "Tournez à gauche, tournez à droite, maintenant à droite." Et donc les passagers «conduisent» le bus. Mais si le chauffeur prend l'initiative et demande: "Où dois-je aller?", Alors le passager peut simplement dire: "Nous allons en ville N", et tout devient beaucoup plus facile. Le conducteur connaît la destination finale et peut, grâce à son expérience, construire indépendamment un itinéraire et se dire où et comment tourner.

Curieusement, mais de nombreux programmeurs ne prennent pas la peine de comprendre le but du projet. Et, d'une part, vous pouvez comprendre ce point de vue, car la programmation est un travail mental très difficile. Parfois, la connaissance de votre instrument occupe une si grande part dans l'esprit qu'il n'y a tout simplement pas assez de ressources pour tout le reste. Il s'avère donc que les programmeurs, comme les conducteurs dans un réservoir sans fenêtre de visualisation, ne peuvent tourner les boutons que lorsque le commandant d'équipage les frappe.

De plus, la compréhension du problème commercial ne vous permettra pas de plonger dans le développement de quelque chose de complètement inutile à un moment donné. Par exemple, si la tâche consiste à créer une fonction qui aide à compiler des statistiques lors de la réussite des tests, sachant que ce n'est pas une tâche critique en termes de performances, vous n'avez plus besoin de consacrer du temps à une optimisation excessive et à l'accélération de l'algorithme. Cela n'affectera pas pour autant le résultat final. Les tests ne seront exécutés que par les développeurs, et seulement une fois par semaine.

Un autre exemple, si le programme a une fonction que tous les utilisateurs exécutent plusieurs fois par jour, il est logique de consacrer plus d'efforts à l'élaboration de la version idéale de cette fonction et de son accessibilité idéale dans l'interface. Ici, vous pouvez déjà gagner du temps.

Mais, voyez-vous, du point de vue d'un programmeur qui n'est pas familier avec les tâches métier, ces deux tâches sembleront équivalentes.

Pour une meilleure compréhension, je vous conseille de lire le livre «Commencez par pourquoi» de Simon Sinek .

4. Petits commits

Le fait qu'un programmeur ait besoin d'utiliser un système de suivi de version, je pense, est évident. Je veux parler d'une autre habitude très utile - c'est de faire des commits aussi souvent que possible et en aussi petites portions que possible. En même temps, ajoutez des commentaires significatifs et utiles à chaque validation.

Souvent, les programmeurs débutants et les plus expérimentés juste à la fin de la journée font une pression avec tous les fichiers modifiés et une sorte de commentaire inutile comme «fix issue29». Ou "correction d'un bug dans la demande". Personne d'une telle description ne comprendra ce qui a été fait spécifiquement. Et lorsque vient le temps de fusionner un commit aussi important dans une branche commune, le propriétaire du référentiel obscurcit d'abord mentalement le développeur paresseux. Deuxièmement, si un conflit se produit pendant la fusion, il est probable que le propriétaire annule simplement cet engagement et ne l'accepte pas. Qui veut obtenir une partie des bogues du fait qu'il a mal compris quelle condition s'est avérée superflue lors de la résolution manuelle des conflits.

D'un autre côté, si vous poussez régulièrement vos modifications une fois par heure et fournissez à chaque commit une description plus détaillée, de sorte qu'à l'avenir, il sera facile, sans regarder le code, de comprendre ce que vous avez changé et quelles considérations vous avez eues à ce sujet changements, vous atteindrez un nouveau niveau de compréhension de la philosophie générale de l'écriture de code. Maintenant, vous ne «réparerez pas seulement le primus», vous ferez désormais partie de l'équipe créative et communiquerez avec vos collègues par le biais de vos commits, tout comme dans un chat. Ce sera un dialogue significatif.

En tant que littérature, je recommande fortement de lire au moins le premier chapitre du livre "Git for a Professional Programmer" de Scott Chacon et Straub Ben. Lorsque vous découvrez quelles sont les merveilleuses fonctions de Git et ce dont il est capable, il ne reste plus qu'à s'engager plus souvent, et le reste peut être réglé avec les outils nécessaires.

5. Comptez le temps

Toute œuvre a un début et une fin. L'efficacité d'un programmeur se mesure en nombre d'heures nécessaires pour résoudre certains problèmes. Plus les tâches sont résolues rapidement, mieux c'est. Ceci est assez évident et ne nécessite aucune explication.

Mais il y a un autre côté à cette preuve, qui échappe souvent aux programmeurs - vous devez calculer avec précision le temps passé sur la solution. Pas ce que vous ressentez lorsque vous êtes assis au travail de neuf à cinq heures, entrecoupé de sceaux et de réunions. Et le présent est votre travail.
Au tout début, j'ai développé l'habitude de compter le temps en écrivant simplement des rapports sur ce que j'ai fait pendant la journée et en calculant une heure approximative. Même alors, j'ai approximativement calculé que je ne disposais que de 4 heures sur 8 pour travailler efficacement.

Et puis il a installé des programmes spéciaux qui comptaient le temps automatiquement. Au début, j'ai utilisé www.rescuetime.com . Grâce à ce programme, j'ai vu que les réseaux sociaux, même si cela me semblait un gaspillage mineur, gâchaient vraiment ma performance. Finalement, j'ai décidé de désactiver complètement l'accès à certains sites pendant les heures de travail. Pour cela, il existe également des plugins spéciaux dans le navigateur.

L'étape suivante du suivi du temps a été requise lorsque j'ai décidé de fixer l'heure exacte du travail avec le code du programme. Pour cela, j'ai d'abord essayé hubstaff.com . En fin de compte, une solution plutôt coûteuse si vous l'utilisez lorsque vous travaillez en équipe.

Puis essayé wakatime.com. Et il s'est avéré que c'était la balle d'argent. Ce service a la capacité de s'intégrer dans tous les IDE populaires, ainsi que l'intégration avec github. Par conséquent, vous pouvez déterminer avec précision jusqu'à une minute le nombre de minutes utiles que vous avez passées à programmer. De plus, il y a une obligation de commettre. C'est tout simplement merveilleux de voir non seulement les commits eux-mêmes, mais aussi de découvrir le temps passé sur ce commit.
Une étonnante collection de recettes pour l'organisation correcte du temps et du travail sur les projets se trouve dans le livre "Jedi Techniques" de Maxim Dorofeev .

6. La stabilité est un signe de maîtrise.

Comme vous l'avez probablement déjà compris, vous pouvez sans cesse développer vos compétences et capacités. Ce que vous avez fait il y a un an peut sembler ridicule et sans prétention en ce qui concerne votre nouvelle expérience. Bien sûr, vous aurez de meilleures façons d'écrire des expressions complexes.
Mais parmi tout cela, il faut développer l'habitude de s'en tenir à certaines règles. Même si elles ne vous semblent pas complètement élaborées, utilisez ces méthodes de travail partout.

En utilisant l'exemple de code: si vous décidez d'utiliser un schéma spécifique pour nommer des variables ou utiliser des espaces au lieu d'onglets, suivez ce principe en permanence. Vous n'avez pas besoin d'essayer un nouveau style chaque semaine et d'appliquer de nouvelles pratiques avancées. Vous perdez donc votre concentration.

Le problème avec l'inconstance est que le temps détruit tout produit logiciel. Plus quelques personnes travaillent sur le programme, plus le processus est modifié, ce qui crée finalement le chaos. Si chacun des membres de l'équipe ne respecte pas un accord spécifique.

Alors, que faut-il faire pour respecter le principe de constance?

La première chose que vous devez adopter est d'adhérer définitivement à un style dans le code. Chez les éditeurs JetBrains , j'aime vraiment l'outil qui indique la qualité de votre code. J'avais peur de tant d'avertissements, mais lorsque vous commencez à suivre les conseils d'un linter de manière disciplinée, le code devient clair et esthétique.

Étudiez également la littérature sur la façon de nommer les classes, les méthodes et les variables. Je recommande le livre "Perfect Code" de Steve McConnell.

À un moment donné, j'ai lu ce livre pendant une demi-heure le soir, alors que tout le monde quittait déjà la maison. Le livre était dans la bibliothèque du bureau. Quelques mois plus tard, j'ai vu toute l'horreur que j'avais encodée avant cette époque. J'ai dû progressivement introduire de nouvelles techniques et refactoring.

7. Faites-le une fois

"Je vais le réparer un peu plus tard." Chacun de nous s'est prononcé cela lorsque nous avons rencontré un bogue dans notre code ou une condition insuffisamment correcte pour le traitement en boucle. Et chacun de nous sait que ce "correctif plus tard" puis reste dans le code sous forme de commentairesfaire. Et quand vous voyez vous-même des commentaires de code dans le stylefaire, cela signifie seulement que quelqu'un ne suit pas le principe du "faire ici et maintenant". Au moment où ce commentaire a été écrit, le programmeur comprend très probablement très bien quel est le problème et comment le résoudre. Parce que c'est dans le contexte de la tâche en cours. Mais si vous revenez à cette section du code plus tard, il sera plus difficile de comprendre pourquoi une telle réservation était requise.
Par conséquent, prenez une habitude très importante pour vous - trouver la solution à partir de zéro jusqu'à ce que la tâche soit entièrement terminée. Le plus complet - car il est vraiment irréaliste de couvrir toutes les options à cent pour cent. Mais au moins ne laisse pas de place à cesfaire-commentaires. Après tout, si vous avez trouvé et passé du temps à commenter, cela signifie que pour la prochaine étape - la mise en œuvre - il reste très peu.

Un bon moyen de comprendre que vous avez vraiment terminé ce morceau de code est de créer un test pour vérifier plusieurs conditions entrantes.

8. N'arrêtez jamais d'apprendre

Il semblerait que ce soit une compétence évidente dont tout spécialiste, et pas seulement un programmeur, a besoin. Mais, malheureusement, beaucoup l'oublient. Parfois, je demande à mes amis qui participent à la programmation, quels livres ils ont lus récemment. Souvent, beaucoup commencent à se rappeler avec difficulté ce qu'ils ont lu il y a un an ou deux. Dans le même temps, ils maîtrisent quelques astuces à l'université ou à certains cours et les utilisent tout le temps.

Cependant, si dans une sphère si en développement rapide vous vous arrêtez au moins une fois par mois pour vous familiariser avec un nouvel outil, une technologie ou un concept intéressant, après un certain temps, vous constaterez peut-être que vous ne comprenez pas littéralement ce qui se passe dans le présent.

Ca m'est déjà arrivé une fois. J'ai développé un produit réussi et l'ai vendu pendant un certain temps. Bien sûr, j'ai entendu des histoires sur de nouveaux cadres, mais je n'y ai pas prêté beaucoup d'attention. Il était profondément immergé dans le développement et le soutien de sa solution.

Ce n'est que lorsque le flux de clients a diminué que j'ai réalisé que mon produit devait être modernisé. Et puis je suis tombé sur une énorme barrière. J'avais l'habitude d'utiliser uniquement des fonctions PHP et très rarement AJAX. Et pour comprendre les cadres modernes React, Angular, Vue JS, j'avais besoin de passer d'urgence environ un an pour les étudier à travers des livres. La chose la plus intéressante est que si j'avais consacré suffisamment de temps à la formation auparavant, mon produit ne perdrait pas sa compétitivité. C'était juste qu'au lieu de prendre en charge les anciennes fonctions, il était nécessaire d'en apprendre de nouvelles et d'introduire les technologies progressivement, et non dans un tel mode d'urgence.

Conclusion

Même si vous êtes à cent pour cent confiant dans vos compétences, n'oubliez pas qu'il n'y a pas de limite à la perfection. Ne cessez pas de vous poser des questions provocantes. Admettez-vous que dans certains domaines, vous n'avez pas une formation suffisante ou que vous ne connaissez pas les points subtils dans les cadres familiers, mais que vous aimeriez les connaître. Passer quelques heures et exécuter la version de test directement depuis github sur le serveur local est maintenant très facile.

Dans de si petites expériences, vous entraînerez vos compétences et développerez toutes les habitudes importantes.

Huit habitudes de programmation importantes