En tant que développeur, vous entendrez de nombreuses théories folles et incroyables sur la signification des «lignes de code». Ne croyez pas un seul. Les lignes de code sont des mesures ridicules. Dans de très rares cas, elle dit quelque chose, généralement rien. Utiliser des lignes de code pour prendre des décisions, c'est comme évaluer la qualité d'un livre par le nombre de pages.

Certains diront que moins il y a de lignes de code dans une application, plus elle est facile à lire. Ce n'est que partiellement vrai. Voici mes mesures pour le code lisible:

• Le code doit être cohérent
  
• Le code doit être informatif.
  
• Le code doit être bien documenté.
  
• Le code doit utiliser des fonctions modernes stables.
  
• Le code n'a pas besoin d'être trop compliqué
  
• Le code ne doit pas être inefficace (n'écrivez pas intentionnellement du code lent)

Si la réduction du nombre de lignes de code contredit l'une de ces mesures, cela devient un problème. En pratique, cela interfère presque toujours et constitue donc presque toujours un problème. Mais voici la chose, si vous vous efforcez de répondre aux critères ci-dessus, votre code aura le nombre idéal de lignes - et vous n'avez pas besoin de les compter .

Les langues ne sont pas nécessairement «bonnes» ou «mauvaises»


Sauf php, bien sûr (une blague). Source

Je vois des gens dire de telles choses tout le temps:

• C est meilleur que X en raison des performances
  
• Python est meilleur que X à cause de la brièveté
  
• Haskell est meilleur que X à cause des extraterrestres

L'idée que les comparaisons linguistiques peuvent être réduites à une phrase est presque offensante. Ce sont des langues, pas des Pokémon.

Ne vous méprenez pas, il y a certainement des différences entre les langues. Il n'y a tout simplement pratiquement pas de langues «inutiles» (bien qu'il existe de nombreuses langues obsolètes / mortes). Chaque langue a son propre ensemble unique de compromis. À cet égard, ils ressemblent à une boîte à outils. Un tournevis peut faire ce qu'un marteau ne peut pas faire, mais quelqu'un dira-t-il qu'un tournevis est meilleur qu'un marteau?

(Évidemment, le marteau est meilleur)

Avant de parler d'évaluation linguistique, je veux clarifier quelque chose. Le choix d'une langue importe très rarement . Bien sûr, certaines choses ne peuvent pas être faites dans certaines langues. Si vous écrivez pour un frontend, vous n'avez pas le choix. Il existe des contextes spécifiques où les performances sont importantes et le langage X ne convient tout simplement pas, mais de telles situations sont assez rares. En général, la sélection de la langue est généralement l'un des problèmes les moins importants pour un projet.

Voici les principaux aspects dans l'ordre, qui, à mon avis, devraient influencer le choix de la langue (sans mesures spécifiques):

• Densité des ressources en ligne disponibles (densité StackOverflow)
  
• Vitesse de développement
  
• Prédisposition aux erreurs
  
• La qualité et la couverture d'un écosystème de packages (oui, npm, parler de qualité)
  
• Performance (plus de points)
  
• Opportunité d'emploi (Désolé, COBOL)

Certains facteurs importants au-delà de votre influence. Si vous travaillez dans le domaine de la science des données, vous devez vraiment utiliser Python, R ou Scala (éventuellement Java). S'il s'agit d'un projet de loisir, utilisez ce que vous aimez. Je n'ai qu'une seule règle incontestable. Je refuse d'utiliser des langues si la plupart des problèmes possibles avec cette langue ne sont pas déjà résolus sur StackOverflow. Ce n'est pas que je ne peux pas les résoudre, ça ne vaut tout simplement pas le temps.

La lecture du code de quelqu'un d'autre est difficile

La lecture du code de quelqu'un d'autre est difficile. Robert K. Martin en parle dans Pure Code: «En fait, le rapport entre le temps de lecture et d'écriture du code est bien plus de 10 pour 1. Nous lisons constamment l'ancien code lorsque nous essayons d'en écrire un nouveau. ... [Par conséquent] ce qui simplifie sa lecture, simplifie également son écriture. "

Pendant longtemps, j'ai pensé que j'étais juste faible à lire le code de quelqu'un d'autre. Au fil du temps, j'ai réalisé que presque tous les programmeurs sont confrontés à ce problème chaque jour. Lire le code de quelqu'un d'autre, c'est comme lire un texte dans une langue étrangère. Même si vous êtes à l'aise avec le choix du langage de programmation de l'auteur du code, vous devez toujours vous adapter aux différents styles et options d'architecture. Il suppose également que l'auteur a écrit un code cohérent et fiable, qui peut ou non être vrai. C'est vraiment dur. Il y a quelques choses qui m'ont beaucoup aidé.

Un examen du code de quelqu'un d'autre améliorera considérablement vos compétences. Au cours des deux dernières années, j'ai fait pas mal de critiques pour les demandes de pool sur Github. Avec chaque nouveau, je me sens un peu plus confiant dans la lecture du code de quelqu'un d'autre. Les demandes de pool GitHub sont particulièrement utiles pour les raisons suivantes:

• Ici, vous pouvez effectuer un examen à tout moment, il vous suffit de trouver un projet open source auquel vous souhaitez contribuer.
  
• Lecture dans un contexte limité (fonction unique ou bug).
  
• Cela nécessite une attention aux détails, ce qui vous fera apprécier chaque ligne.

La deuxième technique, qui aidera à lire le code de quelqu'un d'autre, est un peu plus unique. C'est une technique que j'ai inventée, et elle a vraiment réduit le temps dont j'ai besoin pour me sentir à l'aise dans la base de code de quelqu'un d'autre. Après avoir regardé le style de code que je veux lire, j'ouvre d'abord vi et commence à écrire du code dans le même style. Lorsque vous écrivez du code dans un nouveau style, cela améliore également vos compétences en lecture. Le style deviendra moins étranger lorsque vous l'avez vous-même expérimenté. Même si je regarde juste un projet aléatoire sur Github, j'applique rapidement cette technique. Essayez-le vous-même.

Vous n'écrirez jamais de code "parfait"

J'avais programmé seul pendant quatre ans avant de commencer à travailler en équipe. La plupart du temps, j'ai simplement supposé que tous les programmeurs de l'industrie avaient écrit un code parfait. J'ai décidé que c'était juste une question de temps et d'efforts avant d'écrire également le code «parfait».

C'est quelque chose qui m'inquiétait beaucoup auparavant. Dès que j'ai rejoint l'équipe, il est rapidement devenu évident que personne n'écrivait du code «parfait». Mais le code inclus dans le système était presque toujours «parfait». Comment? Réponse: révision du code.

Je travaille avec une équipe d'ingénieurs vraiment brillants. Ce sont quelques-uns des programmeurs les plus compétents et les plus confiants que vous puissiez acheter pour de l'argent. Chaque membre de notre équipe (y compris moi) commencera une véritable attaque de panique si quelqu'un propose de valider le code sans examen. Même si vous pensez être le prochain Bill Gates, vous ferez certainement des erreurs. Je ne parle même pas d'erreurs logiques, je parle de fautes de frappe, de caractères manqués. Que votre cerveau ne le remarque tout simplement pas. À quoi servent une autre paire d'yeux.

Essayez de travailler avec d'autres personnes attentives aux détails et disposées à critiquer votre travail. Entendre la critique est difficile au début, mais c'est le seul moyen cohérent d'améliorer la situation. Faites de votre mieux pour ne pas prendre une position défensive lors de la révision du code et ne prenez jamais de commentaires personnellement. Vous n'êtes pas votre code.

Dans une revue de code, si l'auteur a fait un choix que je ne connais pas, je vais immédiatement google si son choix est différent de l'opinion populaire. Ce n'est pas que l'opinion populaire a toujours raison, juste l'opinion populaire est le choix par défaut. Si quelqu'un décide de ne pas accepter le choix populaire, c'est bien, je veux juste savoir qu'il est justifié. Lors de l'examen du code, il est très important que vous compreniez la justification des décisions prises. De plus, en regardant le même problème du point de vue d'un débutant , on peut souvent remarquer des choses auxquelles une personne n'aurait jamais prêté attention.

Le travail d'un programmeur ne signifie pas 8 heures de programmation par jour

C'est une question très courante, mais les gens ne donnent jamais de réponse claire. Combien le développeur moyen ou «excellent» développeur dépense-t-il chaque jour pour écrire du code?

Très peu de code plus de quatre heures par jour

Ceux qui ne sont pas d'accord avec cela sont soit des exceptions à la règle, soit travaillent pour des entreprises qui les exploitent trop. La programmation est une tâche intense et épuisante sur le plan mental. Il est totalement déraisonnable de s'attendre à ce que quelqu'un écrive le code 8 heures par jour, cinq jours par semaine. Il y a des moments où vous devez respecter les délais ou en faire un peu plus par session, mais il y en a peu et ils sont rares. Quand je dis «rarement», je veux dire presque jamais. Évitez les flux de travail qui vous abusent et vous obligent à faire des heures supplémentaires en raison d'une mauvaise planification / pénurie de personnel.

Pour le protocole, même l'entreprise elle-même n'est pas rentable pour vous de programmer activement 8 heures par jour. Votre patron peut penser que c'est le cas, mais c'est à courte vue et il ignore les conséquences à long terme, car cela affecte la productivité et la santé mentale.

Pour plus de clarté, je ne vous suggère pas de travailler seulement quatre heures par jour. Les quatre heures restantes sont généralement mieux consacrées à:

• Recherche, à la fois liée au travail et non liée
  
• Discussion de votre travail avec des collègues
  
• Aider les collègues qui ont des problèmes avec leur propre travail
  
• Planification des travaux futurs
  
• Vérification du code
  
• Réunions

Je recommande également fortement de faire des pauses régulières pendant la journée et de faire du sport (du moins pas longtemps). Les bienfaits de l'exercice pour lutter contre la fatigue mentale sont bien documentés. J'ai personnellement trouvé que l'exercice est particulièrement utile en cas de problèmes de concentration.

Ce sont des choses que j'aimerais apprendre à l'université au lieu d'une pure théorie. En cours d'écriture, j'ai pensé à une tonne d'autres nuances, mais c'est un sujet pour un article séparé!