Un code de qualité médiocre peut représenter un coût supplémentaire pour le développement du site et, pire encore, pour l’ensemble des activités. De nombreux entrepreneurs n’ont aucune idée de la programmation ou ne peuvent pas obtenir l’aide d’un technicien dans ce domaine non plus. Heureusement, vous pouvez vérifier vous-même la qualité du code. Vous vous demandez comment? Suivez simplement les instructions spécifiées dans cet article!
Table des matières
Premièrement – prévention
Avant de commencer une coopération avec un programmeur, il est utile de vérifier la qualité du code créé par un employé potentiel. Comment faire? Il est préférable de demander à fournir un exemple de code en privé ou via un service de type Github. Vérifiez le code avec la clé obtenue ou demandez à un programmeur expérimenté de vous donner une première évaluation.
Qu’est-ce qui affecte la mauvaise qualité du code?
Plusieurs éléments affectent la qualité du code incorrect. Et en fait, la négligence du programmeur n’est pas toujours la principale. En tant que commissaire, vous pouvez également contribuer à réduire la qualité du code en:
- délai de livraison trop court,
- projet mal planifié, spécification préparée à la hâte, </ li> <li> mauvaise estimation de la portée et du budget du projet, de sorte que le programmeur ajoute des modifications supplémentaires dans le même budget,
- où il y a six programmeurs, il y a aussi …. code odor – essayez de garder une équipe bien connue et permanente,
- le projet / la coopération avec vous est unique, ce qui réduit l’engagement, </ li> <li> apprenez les bases du langage de programmation dans lequel votre projet est exécuté.
Pourquoi le code médiocre est-il si mauvais?
Il y a plusieurs raisons et toutes ont un impact négatif sur les entreprises:
- le développement et la maintenance du code sont coûteux,
- il peut être nécessaire de réécrire le projet à partir de zéro,
- il est difficile de trouver des programmeurs prêts à travailler avec du code de mauvaise qualité,
- peut cesser ou ralentir le développement de l’entreprise,
- sécurité réduite,
- génère des bogues difficiles à identifier et à corriger.
Clutter dans le code
Ouvrez quelques fichiers et regardez attentivement le code. Si, au lieu d’un beau texte régulièrement mis en forme que vous ne comprenez pas du tout… vous voyez un gâchis que vous ne pouvez même pas lire, comprendre, interpréter du tout ni voir aucune logique – alors informer le contractant de vos préoccupations.
Noms et convention d’appellation
Si vous avez en quelque sorte traité avec la programmation, vous savez quelles sont les fonctions et les variables. Si vous n’êtes pas familier avec cela, 5 minutes de lecture de ce guide vous permettront de reconnaître les fonctions, les classes et les variables dans le code testé. Qu’est-ce qui devrait vous alarmer:
- Les entrées non en anglais,
- noms incompréhensibles, par exemple xyz () au lieu de addUser (),
- incohérence dans le formatage, par exemple nom de fonction, nom_fonction, nom_fonction.
<!- Trop de commentaires ->
Il peut sembler que / * les commentaires dans le code décrivant la procédure de tout * / semblent être une bonne pratique. Eh bien, pas exactement, surtout si le contractant avait des problèmes dans le paragraphe précédent et essayait de rattraper son retard en utilisant des commentaires. En fin de compte, le code devrait être compréhensible sans description supplémentaire. Les commentaires ne doivent être utilisés que lorsque ce n’est pas possible.
Assez de frameworks suffit
Le contractant recommande l’utilisation de nombreux cadres différents? Si tel est le cas, il convient de se demander si elles sont toutes nécessaires. La duplication de frameworks qui exécutent les mêmes tâches est le moyen le plus simple de créer du code compliqué. En conséquence, le site sera plus lourd et plus susceptible d’échouer.
Nouvelles technologies ou oldies, mais goldies
Il est très facile de vérifier si le contractant utilisera le cadre qu’il a appris il y a X ans (et il essaie toujours de le pousser vers les clients), ou tente de nous convaincre d’innover. Dans les deux cas, cela peut nous amener à des problèmes de maintenance concernant notre site Web.
Vérifiez le mode d’exécution du référentiel
Dans le cas de la création de sites Web, je n’exigerais pas de référentiel, mais si vous en avez accès, cela vous permettra de suivre l’avancement des travaux. Également après les «commits» et leur description, vous pouvez évaluer le déroulement du projet. Si la description du «commit» n’a pas de sens et ne fournit aucune information, il peut être difficile à trouver à l’avenir.
Demander des tests
Dans le cas d’applications, les tests unitaires doivent être écrits en même temps. Leur tâche consiste à accélérer les contrôles de code. En outre, ils imposent en outre une plus grande attention à la qualité du code même.
Si je viens d’encadrer votre programmeur ….
parce que je vous ai motivé à inspecter la qualité du code, je m’excuse pour le problème. En fonction de vos contrats et obligations, vous devez indiquer les sources d’odeur du code, définir un plan de reprise et ce qui est important, le mettre en œuvre dès que possible, pour ne pas continuer dans l’impasse.
Et enfin, je vous souhaite des projets réussis avec un code de haute qualité. 🙂