Comment écrire moins de code [fermé]

Une qualité que j'aimerais développer est d'écrire du code plus concis. Avec une écriture plus concise, du moins à mon avis, la possibilité d'ajouter des bogues au code est plus petite. Il est plus facile de lire le code pour les autres.

Ma question est de savoir si c'est quelque chose qui vient juste avec l'expérience ou est-ce quelque chose que vous pouvez faire explicitement pour développer cette qualité?

Je dirais que dans l'ensemble, c'est quelque chose qui vient avec le temps et l'expérience, mais vous constaterez peut-être que si vous travaillez avec des langues plus laconiques, vous ramenez cette qualité à vos langues de travail habituelles.

Certes, après un an ou deux de travail avec Ruby, j'ai trouvé que mon C # était beaucoup plus tendu. Je pense que si je devais mieux comprendre la programmation fonctionnelle (une ambition permanente), j'en prendrais probablement plus.

Il existe également quelques directives qui peuvent vous aider, par exemple si vous écrivez les deux mêmes lignes plus d'une fois en les divisant en leur propre méthode. C'est une ligne directrice simple, mais qui réduit rapidement les lignes de code et la programmation couper-coller, dont la plupart d'entre nous sont coupables de temps en temps.

Si vous comprenez l'héritage, vous pouvez souvent économiser sur la répétition du même code à différents endroits en donnant des fonctionnalités communes aux classes parentes. C'est évident en principe mais quelque chose que les gens manquent souvent dans la pratique.

Il peut y avoir une différence entre écrire moins de code et avoir moins de code dans votre application - parfois, vous pouvez utiliser la génération de code pour éviter d'avoir à vous répéter, vous n'écrivez que quelques lignes de code, mais celles-ci génèrent alors beaucoup d'autres codes pour vous - cela peut vous donner beaucoup de poids. Regardez ce qu'un outil comme Rails ou Entity Framework fait à cet égard pour comprendre à quel point il peut être utile. Soyez clair quant à la nécessité de cela et réfléchissez à deux fois, trois fois puis quatre fois à la génération de votre propre code - cela peut vous faire tomber dans l'enfer YAGNI.

Comprenez votre langage, votre API et vos outils. Encore une fois, cela semble évident, mais au fil des années, j'ai écrit tellement de code que j'ai réalisé plus tard que je reproduisais des fonctionnalités que j'aurais pu hériter de l'API ou utiliser une fonctionnalité de langage pour simplifier, ce qui m'a permis de réaliser que quelques heures de lecture sur la documentation de l'API avec laquelle je travaille me fera gagner de nombreuses heures de codage ou de débogage plus tard. De même, la plupart des plates-formes avec lesquelles vous travaillez ont un grain - apprenez à travailler comme elles l'attendent et votre vie sera beaucoup plus facile. Passez un peu de temps à trouver la direction de la moindre résistance pour la plate-forme avec laquelle vous travaillez et vous obtiendrez des résultats bien meilleurs.

Si vous vous demandez s'il existe une meilleure façon de faire quelque chose, il y en a probablement et cela vaut toujours la peine de découvrir comment mieux faire les choses.

Une excellente façon d'écrire moins de code consiste à éviter de réinventer la roue et à utiliser les composants logiciels existants lorsqu'ils sont disponibles.

Une réponse commune que j'obtiens quand je demande pourquoi les gens ont fait leur propre ORM, ou leur propre moteur de journalisation, ou leurs propres composants d'interface utilisateur, ou leur propre tout:

Mais notre c'est mieux

Je crois que cette déclaration est correcte dans la plupart des cas, mais l'impact négatif sur le retour sur investissement est très élevé dans la plupart des cas. Ta maman fait les meilleurs plats non? Mais vous ne pouvez pas demander à maman de rentrer à la maison et de les préparer tous les jours.

C'est pourquoi je pense que les développeurs devraient s'intéresser à l'impact financier de leurs choix. Certains d'entre eux sont:

• Travail supplémentaire requis pour construire le composant
• Travail supplémentaire pour les nouveaux venus pour l'apprendre
• Un énorme travail supplémentaire pour le maintenir

J'aime à penser que ces fournisseurs de composants sont votre équipe étendue qui travaille pour vous pour une infime fraction de ce que vous auriez payé pour le construire, le maintenir et l'améliorer vous-même.

Il est préférable pour toute l'entreprise de maximiser le retour sur investissement plutôt que de travailler à maximiser notre satisfaction de l'ego;) Plus votre entreprise reçoit d'argent, plus vos conditions de travail et votre salaire augmenteront.

À mon avis, écrire moins de code peut se faire de plusieurs manières:

• Tu n'en auras pas besoin . Ne codez pas quelque chose dont vous n'avez pas encore besoin. Codez uniquement les exigences. De cette façon, nous réduirons le code nécessaire à l'écriture.

• Ne vous répétez pas . Je pense que l'utilisation d'un CMS, d'un framework ou d'une bibliothèque tierce est une façon d'appliquer le principe DRY.

• Abstraction . Enfin et surtout, la programmation d'abstraction peut également réduire considérablement le code. En faisant abstraction du code, la chance de réutiliser le code ira plus haut car cela réduit la duplication.

Au-delà de la compréhension d'un langage de programmation, je pense que la compréhension d'un problème et la recherche d'une bonne solution ont beaucoup à voir avec cela. Il existe de nombreuses solutions à la plupart des problèmes, mais elles ne sont pas toutes optimales. Vous pouvez conduire de la ville A à la ville B par différentes routes - l'une peut prendre deux heures, l'autre peut prendre le double. C'est la même idée en programmation. Vous connaissez peut-être très bien une langue, mais vous pouvez trouver une solution qui prend, disons, deux pages de code, tandis que quelqu'un d'autre trouvera une solution qui peut être implémentée dans un quart de la moitié de la taille du code. Je l'ai vu beaucoup au fil des ans.

Assurez-vous d'avoir une bonne compréhension du problème. Analysez-le, trouvez des solutions, pesez le pour et le contre (bien sûr, les «solutions avec un '» varieront considérablement d'un problème à l'autre - de manière générale ici). Ensuite, il y a la mise en œuvre de la solution choisie, qui est l'endroit où votre compréhension du langage (et du cadre, le cas échéant) entrera en jeu.

On peut dire que tout l'art de la programmation se résume à cela.

Vous pouvez étudier des langues qui mettent l'accent sur la clarté et la concision (par exemple Haskell, Scheme, Python), ou même des paradigmes tersers comme Factor et d'autres langues concaténatives, mais en fin de compte, tout ce que vous pourriez choisir d'étudier devrait finalement contribuer à vous aider à écrire plus court , code moins redondant.

Comme toutes les autres afflictions, si vous n'admettez pas avoir un problème, vous n'allez pas chercher de solution. L'expérience commence à être un facteur lorsque vous avez appris à quoi ressemble moins de code. Lorsque vous revisitez votre code, c'est le moment idéal pour déterminer si vous pouvez réutiliser le code ou refactoriser pour réduire le code. Microsoft a pu améliorer la vitesse d'impression avec Windows 2000 en ne le spoulant PAS deux fois (citation d'un employé de Microsoft lors d'une de leurs démos gratuites).

1. Revenez à votre ancien code à long terme,
2. le mettre sous contrôle de version,
3. écrire des tests pour avoir un espoir raisonnable de ne pas introduire de nouveaux bugs,
4. récrire.

Répétez ad libitum. Et bienvenue en enfer.

Le développement piloté par les tests peut être utile. En utilisant cela, vous écrivez uniquement le code minimum requis pour réussir ce test.