Façons de briser le «syndrome du programmeur parfait» [fermé]

Je ne suis probablement pas le seul à ressentir cela. Mais j'ai ce que j'ai tendance à appeler «le syndrome du programmeur parfait», ce que beaucoup pourraient dire comme étant perfectionniste, mais dans ce cas, c'est dans le domaine de la programmation. Cependant, le domaine de la programmation est un peu problématique pour un tel syndrome.

Avez-vous déjà ressenti que lorsque vous programmez, vous n'êtes pas sûr ou jamais assez convaincu que votre code est un code propre et bon qui suit la plupart des meilleures pratiques? Il y a tellement de règles à suivre que j'ai l'impression d'être submergé d'une manière ou d'une autre. Non pas que je n'aime pas suivre les règles, bien sûr je suis programmeur et j'adore la programmation, je vois cela comme un art et je dois suivre les règles. Mais je l'aime aussi, je veux dire que je veux et j'aime suivre les règles afin d'avoir une bonne idée de ce que je fais va dans le bon sens .. mais je souhaite seulement pouvoir tout avoir un peu plus en "contrôle" concernant les meilleures pratiques et un bon code.

C'est peut-être un manque d'organisation? C'est peut-être un manque d'expérience? Peut-être un manque de pratique? C'est peut-être un manque d'autre chose que quelqu'un pourrait souligner? Existe-t-il un moyen de se débarrasser de ce syndrome d'une manière ou d'une autre?

Prioriser . Tout d'abord. Concentrez-vous sur ce qui compte.

Vos priorités peuvent varier, mais en général, vous devez vous soucier de:

• Code correct
• Code maintenable
• Code propre
• Code simple et élégant
• Code efficace

Peut-être dans cet ordre. Cependant, le premier point est le plus important. Sans lui, le code est inutile. Que faites-vous avec un programme qui ne fonctionne pas correctement?

Faites-le fonctionner, tout le reste est presque hors de propos pour résoudre les problèmes que vous devez résoudre. Bien sûr, moi aussi j'en souffre. Ce que j'ai appris qui aide, c'est de se concentrer uniquement sur les solutions qui fonctionnent . C'est assez. C'est 99% du travail.

Vous voudrez peut-être penser à quelque chose comme un bon code . Qu'Est-ce que c'est? Quel genre de personnes l'écrivent? Comment écrire du bon code ? C'est très simple. Écrivez du code qui fonctionne . Le code de travail est un bon code. Tout le reste vient plus tard.

Bien sûr, lors de l'écriture de code dans un environnement professionnel, en équipe, un code évident et lisible et un code maintenable deviennent de plus en plus importants. Cependant, la première tâche consiste toujours à le faire fonctionner et à se concentrer sur cela. Ce n'est qu'alors que vous pouvez commencer à affiner et à refactoriser pour le mieux - si nécessaire.

Il est souvent assez évident que l'exactitude du code est très importante - mais nous ne parvenons pas tous à en apprécier l'importance lors de l'écriture de code. Nous coupons les coins, nous utilisons une optimisation prématurée, nous essayons d'écrire du code élégant avant même d'avoir du code de travail écrit. C'est la nature humaine de rechercher la perfection dès le début, mais la programmation et le développement de logiciels sont des processus itératifs et des priorités existent. Ainsi, encore une fois, faites-le fonctionner , souciez-vous de tout le reste plus tard. Comprenez l'importance d'un code correct et efforcez-vous de le faire.

Bien qu'il existe des tonnes et des tonnes de soi-disant bonnes pratiques , je pense que le bon sens est le plus important, réfléchissez à la raison pour laquelle les pratiques sont considérées comme bonnes, quand et où les appliquer. Cependant, ne vous efforcez pas de respecter toutes les bonnes pratiques. Il n'y a aucun remplacement ou substitut à l'expérience personnelle. Vous ne pouvez pas éviter les pièges courants - peu importe le nombre de livres que vous lisez, les séminaires auxquels vous participez ou autre chose. Ce qui compte, c'est d'apprendre en faisant, de faire les choses correctement et de s'amuser - chaque fois que c'est possible.

Le moyen le plus simple d'éviter ce problème est de ne changer que ce qui fait mal. Ne polissez pas un code correct, lisible et maintenable, même si vous pensez que certains changements pourraient le rendre encore meilleur. Mais une fois que vous essayez, par exemple, de changer quelque chose et de vous arrêter sur une variable dont le but n'est pas clair, ou une fonction qui est tout simplement trop longue à comprendre, corrigez-la. Pas plus tôt.

Cela ne signifie pas que vous ne devriez pas vous efforcer d'obtenir un code propre et propre en premier lieu, bien sûr que vous le devriez, mais vous devriez considérer votre première tentative comme «suffisamment bonne», sauf preuve contraire.

Je pense que le meilleur antidote à cela est de se rappeler que toutes ces meilleures pratiques et règles de propreté du code n'existent pas pour elles-mêmes, pas plus que le code lui-même.

Au final, ce qui importe plus que tout, c'est que le logiciel fonctionne et puisse être utilisé. Et cela n'arrivera pas si vous ne le terminez pas.

Je n'aime pas la comparaison du codage avec l'art, mais à cet égard, cela fonctionne: les artistes (en particulier les auteurs ) veulent souvent continuer à travailler sur une pièce car il y a toujours quelque chose qui n'est pas parfait. Mais quelle valeur a la perfection quand elle retarde indéfiniment la publication et empêche ainsi quiconque d' apprécier l'œuvre?

La chose la plus importante à réaliser est que votre code va toujours changer et qu'il y a toujours place à amélioration. Aucun code n'est jamais parfait. Plus souvent qu'autrement, une bibliothèque de classe sur laquelle vous travaillez aujourd'hui sera très différente six mois plus tard. Vous apprenez une nouvelle technique ou trouvez un modèle qui vous convient vraiment. Tant que le code est facilement maintenable et lisible, alors vous devriez être bon. Idéalement, vous auriez des tests unitaires pour faciliter la refactorisation plus tard sur la route.

Il est facile de se laisser prendre à rendre le code parfait et à suivre toutes les normes auxquelles vous pouvez penser. Cela nous arrive à tous. En regardant le code que j'ai écrit il y a quelques semaines, je pense à faire des changements. Ajoutez une propriété ici, refactorisez la méthode là-bas. Et cela semble arriver à la fin du projet. Mais si vous êtes trop absorbé par cela, vous pourriez finir par faire un bug de showstopping. Je l'ai fait plusieurs fois au début de ma carrière. Quelques séances de correction de bogues de 3 heures du matin m'ont guéri de ce problème.

Faites-le autrement.

Au lieu de "qu'est-ce qui peut être mieux fait?" chercher "qu'est-ce qui me fait chier?" jusqu'à ce que rien ne se passe.

En tant que programmeur, votre travail consiste à produire du code. Le but des meilleures pratiques est d'augmenter votre taux de production en rendant les choses plus faciles à comprendre / à faire / à retenir. Si adhérer à ces pratiques vous empêche de faire avancer les choses, vous faites quelque chose de mal. Essayez simplement de produire du code aussi rapidement que possible, et vos pratiques devraient évoluer pour vous permettre de faire exactement cela.

Faites-le fonctionner, le rendre propre, le rendre SOLIDE, le rendre performant.

Les trois premiers sont un adage que j'épouse chaque fois que quelqu'un se demande comment écrire du code SOLIDE sur une chronologie. Lorsque vous écrivez une ligne de code pour la première fois, elle doit simplement fonctionner, alors faites ce que vous avez à faire et ne soyez pas fantaisiste. La première fois que vous revisitez une ligne de code, celle-ci n'est plus ponctuelle et vous devez nettoyer le code, le rendant ainsi lisible et donc plus maintenable. La troisième fois que votre curseur va dans cette ligne, c'est probablement un gros problème maintenant, et vous devriez le refactoriser pour qu'il adhère à la méthodologie SOLID, en faisant abstraction des dépendances, en implémentant des modèles et en rendant le code plus facile à brancher ou à brancher pour une amélioration future.

L'élégance dans le code doit être obtenue lorsque le programmeur remarque une opportunité, et est généralement une fonction de simplification, de nettoyage et généralement d'amélioration de la lisibilité et de la maintenabilité du code tout en suivant les étapes précédentes. Ce n'est pas quelque chose à maximiser .

Le code performant est presque toujours le moins préoccupant dans les langages gérés en mémoire (Java, la famille .NET, la plupart des langages fonctionnels, etc.). Dans ces environnements, le but est d'écrire du code correct ("correct" ici défini comme produisant le résultat attendu dans tous les cas attendus, etétant compréhensible et bien structuré, et donc maintenable), et la performance est secondaire (elle procède généralement dans une certaine mesure à partir du code correct). Dans tous les cas, un algorithme est performant quand il est "assez bon". Rappelez-vous, "l'optimisation prématurée est la racine de tout mal"; faire des optimisations dont vous ne savez pas que vous aurez besoin ne fait que gaspiller du temps, obscurcir le code et empêcher généralement les progrès. Il doit d'abord fonctionner, puis une fois qu'il fonctionne, vous l'exécutez et voyez à quelle vitesse il fonctionne. S'il n'est pas assez rapide (tel que défini par un benchmark qui est une exigence publiée), vous l'améliorez jusqu'à ce qu'il soit, puis vous vous arrêtez .

Vous devez vraiment être pragmatique en matière de programmation. Oui, nous aimons tous bien faire les choses, mais vous êtes payé pour fournir des logiciels qui fonctionnent, pas pour les peaufiner pour le reste de votre vie.

L'approche à adopter est de "faire avancer les choses" dans votre vie professionnelle. Livrez et continuez. Enregistrez votre perfectionnisme pour des projets personnels.