Pourquoi la qualité du code n’est-elle pas populaire?

J’aime que mon code soit en ordre, c’est-à-dire correctement formaté, lisible, conçu, testé, vérifié pour les bogues, etc. En fait, je suis fan à ce sujet. ( Peut-être même plus que fanatique… ) Mais dans mon expérience, les actions aidant à la qualité du code sont à peine mises en œuvre. (Par qualité de code, je veux dire la qualité du code que vous produisez au quotidien. Le sujet de la qualité du logiciel avec les processus de développement, etc., est beaucoup plus large et non la scope de cette question.)

La qualité du code ne semble pas populaire. Quelques exemples de mon expérience incluent

  • Probablement tous les développeurs Java connaissent JUnit, presque tous les langages implémentent les frameworks xUnit, mais dans toutes les entresockets que je connais, il y avait très peu de tests unitaires appropriés (voire pas du tout). Je sais qu’il n’est pas toujours possible d’écrire des tests unitaires en raison de limitations techniques ou de délais serrés, mais dans les cas que j’ai vus, les tests unitaires auraient été une option. Si un développeur voulait écrire des tests pour son nouveau code, il pourrait le faire. Ma conclusion est que les développeurs ne veulent pas écrire de tests.

  • L’parsing de code statique est souvent utilisée dans les petits projets, mais elle n’est pas vraiment utilisée pour appliquer des conventions de codage ou détecter d’éventuelles erreurs dans les projets d’entreprise. Généralement, même les avertissements du compilateur tels que l’access potentiel au pointeur null sont ignorés.

  • Les conférenciers et les magazines parleraient beaucoup d’EJB3.1, OSGI, du Cloud et d’autres nouvelles technologies, mais guère des nouvelles technologies ou outils de test, des nouvelles approches d’parsing de code statique (résolution SAT), des processus de développement une vilaine bête du code hérité a été mise à l’épreuve, … (je n’ai pas assisté à de nombreuses conférences et cela semble probablement différent pour les conférences sur des sujets agiles, comme les tests unitaires et les CI, qui ont une valeur plus élevée.)

Alors, pourquoi la qualité du code est-elle si impopulaire / considérée comme ennuyeuse?

MODIFIER:
Merci pour vos réponses. La plupart d’entre eux concernent les tests unitaires (et ont été discutés dans une question connexe ). Mais il y a beaucoup d’autres choses qui peuvent être utilisées pour maintenir la qualité du code élevée (voir la question associée ). Même si vous ne pouvez pas utiliser les tests unitaires, vous pouvez utiliser une génération quotidienne, append une parsing de code statique à votre environnement de développement intégré ou à votre processus de développement, essayer la programmation par paires ou appliquer des révisions de code critique.

Une réponse évidente à la partie Stack Overflow est qu’il ne s’agit pas d’un forum. C’est une firebase database de questions et de réponses, ce qui signifie que les tentatives de doublons sont évitées.

Combien de questions différentes sur la qualité du code pouvez-vous penser? C’est pourquoi il n’y a pas 50 000 questions sur la “qualité du code”.

En dehors de cela, toute personne qui prétend que les conférenciers ne veulent pas parler de tests unitaires ou de qualité de code doit clairement aller à plus de conférences.

J’ai également vu plus qu’assez d’articles sur l’continuous integration.

Il y a des excuses communes pour ne pas écrire de tests, mais ce ne sont que des excuses. Si l’on veut écrire des tests pour son nouveau code, alors c’est possible

Oh vraiment? Même si votre patron dit “Je ne vous paierai pas pour perdre du temps sur les tests unitaires”? Même si vous travaillez sur une plate-forme intégrée sans structure de test unitaire? Même si vous travaillez dans un délai serré, essayez d’atteindre un objective à court terme, même au prix d’une qualité de code à long terme?

Non, il n’est pas toujours possible d’écrire des tests unitaires. Il y a beaucoup d’obstacles communs à cela. Cela ne veut pas dire que nous ne devrions pas essayer d’écrire des tests plus nombreux et de meilleure qualité. Juste que parfois, nous n’avons pas l’occasion.

Personnellement, je me lasse des discussions sur la “qualité du code” car elles ont tendance à

  • être trop préoccupé par des exemples hypothétiques, et sont trop souvent le fruit d’une personne, qui n’a vraiment pas pris en compte son ampleur pour les projets d’autres personnes, ou les bases de code de tailles différentes de celle sur laquelle il travaille,
  • ont tendance à devenir trop émotif et à imprégner notre code de trop de traits humains (pensez au terme «odeur de code», par exemple),
  • être dominé par des gens qui écrivent un code horrible, bourré, compliqué et prolixe avec beaucoup trop de couches d’abstraction, ou qui jugeront si le code est réutilisable par “il semble que je puisse simplement prendre ce morceau de code et l’utiliser dans un futur projet “, plutôt que le plus significatif” j’ai effectivement pu prendre ce morceau de code et le réutiliser dans différents projets “.

Je suis certainement intéressé à écrire un code de haute qualité. Les gens qui parlent généralement de la qualité du code ont tendance à me désactiver.

La révision du code n’est pas une science exacte. Les mésortingques utilisées sont en quelque sorte discutables. Quelque part sur cette page: ” Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer

Supposons que vous ayez une fonction énorme de 5000 lignes avec 35 parameters. Vous pouvez le tester à votre guise, cela peut faire exactement ce qu’il est censé faire. Quelles que soient les entrées. Donc, sur la base des tests unitaires, cette fonction est “parfaite”. Outre l’exactitude, il y a des tonnes d’autres atsortingbuts de qualité que vous pourriez vouloir mesurer . Performances, évolutivité, maintenabilité, facilité d’utilisation, etc. Vous êtes-vous déjà demandé pourquoi la maintenance des logiciels est un tel cauchemar?

Le contrôle de qualité des projets logiciels réels va bien au-delà de la simple vérification de la validité du code. Si vous vérifiez le modèle V du développement logiciel , vous remarquerez que le codage n’est qu’une petite partie de l’équation.

Le contrôle qualité du logiciel peut aller jusqu’à 60% du coût total de votre projet. C’est énorme. Au lieu de cela, les gens préfèrent réduire à 0% et rentrer à la maison en pensant avoir fait le bon choix. Je pense que la vraie raison pour laquelle si peu de temps est consacré à la qualité du logiciel, c’est que la qualité du logiciel n’est pas bien comprise.

  • Qu’y a-t-il à mesurer?
  • Comment le mesurons-nous?
  • Qui va le mesurer?
  • Que vais-je gagner / perdre en mesurant?

Beaucoup de sweatshops codeurs ne réalisent pas la relation entre «moins de bugs maintenant» et «plus de profit plus tard». Au lieu de cela, tout ce qu’ils voient, c’est «le temps perdu maintenant» et «moins de profit maintenant». Même lorsque montré de jolis graphismes démontrant le contraire.

De plus, le contrôle de la qualité des logiciels et l’ ingénierie logicielle dans son ensemble constituent une discipline relativement nouvelle. Une grande partie de l’espace de programmation a jusqu’ici été prise par les cyber-cow-boys. Combien de fois avez-vous entendu que “quelqu’un” peut programmer? Tout le monde peut écrire du code c’est certain, mais ce n’est pas tout le monde qui peut être programmeur.

MODIFIER *

Je suis tombé sur cet article (PDF) qui vient du gars qui a dit “Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer”. Fondamentalement, il dit que tout contrôler n’est pas aussi souhaitable qu’il le pensait. Ce n’est pas une recette de cuisine exacte que vous pouvez appliquer aveuglément à tous les projets comme les écoles de génie logiciel veulent vous faire réfléchir. Il ajoute juste un autre paramètre à contrôler qui est “Est-ce que je veux contrôler ce projet? Sera-t-il nécessaire?”

  • Paresse / Considéré ennuyeux
  • La direction a le sentiment que ce n’est pas nécessaire – L’attitude ignorante “Just do it right”.
  • “Ce petit projet n’a pas besoin de gestion de la qualité du code” se transforme en “Maintenant, il serait trop coûteux d’implémenter la gestion de la qualité du code sur ce grand projet”

Je ne suis pas d’accord que ce soit terne si. Une conception solide des tests unitaires facilite la création de tests et leur exécution encore plus amusante.

Calculating vector flow control - PASSED Assigning stream capacitor variance level - PASSED Rerouting superconductors for faster dialing sequence - PASSED Running Firefly hull checks - PASSED Unit tests complete. 4/4 PASSED. 

Comme tout ce qui peut devenir ennuyeux si vous en faites trop, mais passer 10 ou 20 minutes à écrire des tests aléatoires pour des fonctions complexes après plusieurs heures de codage ne va pas aspirer la vie créative de votre part.

Pourquoi la qualité du code est-elle si impopulaire?

Parce que notre profession n’est pas professionnelle.

Cependant, certaines personnes se soucient de la qualité du code. Vous pouvez par exemple trouver des personnes intéressées dans le groupe de discussion du mouvement Software Craftsmanship . Mais malheureusement, la majorité des gens travaillant dans le secteur des logiciels ne comprennent pas la valeur de la qualité du code ou ne savent même pas ce qui constitue un bon code.

Je suppose que la réponse est la même que pour la question «Pourquoi la qualité du code n’est-elle pas populaire?

Je crois que les principales raisons sont les suivantes:

  • La paresse des développeurs. Pourquoi investir du temps dans la préparation des tests unitaires, revoir la solution, si elle est déjà mise en œuvre?
  • Mauvaise gestion Pourquoi demander aux développeurs de gérer la qualité du code, s’il y a des milliers de nouvelles demandes de fonctionnalités et que les programmeurs pourraient simplement implémenter quelque chose au lieu de prendre en charge la qualité de quelque chose déjà implémenté.

Réponse courte: C’est l’un de ces actifs incorporels que seuls les développeurs et ingénieurs principalement expérimentés peuvent apprécier, à moins que quelque chose ne se passe mal. À quel point les gestionnaires et les clients sont dans un tumulte et demandent pourquoi les processus formels n’étaient pas en place.

Réponse plus longue: Cette approche à courte vue ne se limite pas au développement de logiciels. L’indussortinge automobile américaine (ou ce qu’il en rest) en est probablement le meilleur exemple.

Il est également plus difficile de justifier des processus d’ingénierie formels lorsque les projets commencent leur vie de manière ponctuelle ou jetable. Bien sûr, longtemps après que le projet est terminé, il prend sa propre vie (et prend de l’importance) au fur et à mesure que les différentes unités commerciales commencent à en dépendre pour leur propre processus commercial.

À quel point une nouvelle solution doit être conçue. mais sans pratique dans l’utilisation de ces outils et bonnes pratiques, ces outils sont loin d’être inutiles. Ils deviennent un obstacle chronophage. Je vois trop souvent cette situation dans les entresockets où les équipes informatiques sont un support pour l’entreprise, où le développement est souvent réactionnaire plutôt que proactif.

Edit: Bien sûr, ces mauvaises habitudes et bien d’autres sont la véritable raison pour laquelle des sociétés de conseil telles que Thought Works peuvent continuer à prospérer aussi bien qu’elles.

Un grand facteur que je n’ai pas encore vu est que toute amélioration des processus (tests unitaires, continuous integration, revues de code, etc.) doit avoir un défenseur au sein de l’organisation engagé dans la technologie, disposant de l’influence appropriée au sein de l’organisation. , et est prêt à faire le travail pour convaincre les autres de la valeur.

Par exemple, j’ai vu exactement une organisation d’ingénierie où l’examen du code était vraiment pris au sérieux. Cette société avait un vice-président du logiciel qui croyait sincèrement, et il assistait à des revues de code pour s’assurer qu’elles se déroulaient correctement. Ils ont d’ailleurs eu la meilleure productivité et qualité de toutes les équipes avec lesquelles j’ai travaillé.

Un autre exemple est celui où j’ai implémenté une solution de test unitaire dans une autre entreprise. Au début, personne ne l’a utilisé, malgré l’insistance de la direction. Mais plusieurs d’entre nous ont fait un réel effort pour parler des tests unitaires et fournir le plus d’aide possible à quiconque souhaitait commencer les tests unitaires. Finalement, deux des développeurs les plus respectés ont signé, une fois qu’ils ont commencé à voir les avantages des tests unitaires. Après cela, notre couverture de test s’est considérablement améliorée.

Je viens de penser à un autre facteur – certains outils prennent beaucoup de temps pour démarrer, et ce temps de démarrage peut être difficile à trouver. Les outils d’parsing statique peuvent être terribles de cette façon: vous exécutez l’outil et vous signalez 2 000 «problèmes», dont la plupart sont inoffensifs. Une fois que vous avez configuré l’outil correctement, le problème de faux positif est considérablement réduit, mais quelqu’un doit prendre ce temps et s’engager à maintenir la configuration de l’outil au fil du temps.

Tous les développeurs Java connaissent probablement JUnit …

Bien que je pense que la plupart ou de nombreux développeurs ont entendu parler de JUnit / nUnit / d’autres frameworks de test, peu d’entre eux savent comment écrire un test en utilisant un tel framework. Et parmi ceux-ci, très peu ont une bonne compréhension de la manière de tester une partie de la solution.

Je connais les tests unitaires et les frameworks de test unitaire depuis au moins 7 ans. J’ai essayé de l’utiliser dans un petit projet il y a 5 ou 6 ans, mais ce n’est que ces dernières années que j’ai appris à le faire correctement. (c.-à-d. trouvé un moyen qui fonctionne pour moi et mon équipe …)

Pour moi, certaines de ces choses étaient:

  • Trouver un workflow adapté aux tests unitaires.
  • Intégrer les tests unitaires dans mon IDE et disposer de raccourcis pour exécuter / déboguer les tests.
  • Apprendre à tester quoi. (Comme comment tester la connexion ou accéder à des fichiers. Comment vous extraire de la firebase database. Comment faire de la moquerie et utiliser un cadre moqueur. Apprendre des techniques et des modèles qui augmentent la testabilité.)
  • Avoir des tests est mieux que de ne pas avoir de test du tout.
  • Plus de tests peuvent être écrits plus tard lorsqu’un bogue est découvert. Écrivez le test qui prouve le bogue, puis corrigez le bogue.
  • Tu devras t’entraîner pour t’améliorer.

Donc, jusqu’à trouver le bon chemin oui, c’est ennuyeux, non gratifiant, difficile à faire, prend du temps, etc.

EDIT: Dans cet article de blog, je vais approfondir certaines des raisons invoquées ici contre les tests unitaires.

La qualité du code est impopulaire? Laissez-moi contester ce fait.

Des conférences telles que Agile 2009 ont une pléthore de présentations sur l’continuous integration et les techniques et outils de test. Des conférences techniques telles que Devoxx et Jazoon ont également leur juste part de ces sujets. Il existe même une conférence dédiée à l’continuous integration et aux tests ( CITCON , qui se déroule 3 fois par an sur 3 continents). En fait, mon sentiment personnel est que ces discussions sont si fréquentes qu’elles sont sur le point d’être totalement ennuyeuses pour moi.

Et selon mon expérience en tant que consultant, la consultation sur les techniques et les outils de qualité de code est en fait assez facile à vendre (mais pas très bien payée).

Cela dit, même si je pense que Code Quality est un sujet de discussion populaire, je suis plutôt d’accord avec le fait que les développeurs ne font pas (en général) de bons tests, ou assez. J’ai une explication assez simple à ce fait.

Essentiellement, cela se résume au fait que ces techniques sont encore relativement nouvelles (TDD a 15 ans, IC moins de 10) et elles doivent rivaliser avec 1) les gestionnaires, 2) les développeurs dont les méthodes ont “bien fonctionné jusqu’à présent” (peu importe ce que cela signifie). Selon les mots de Geoffrey Moore, les techniques modernes de qualité du code sont encore au début de la courbe d’adoption. Il faudra du temps pour que l’ensemble de l’indussortinge les adopte.

La bonne nouvelle, cependant, est que je rencontre maintenant des développeurs nouvellement universitaires qui ont appris TDD et qui s’y intéressent vraiment. C’est un développement récent. Une fois que ceux-ci sont arrivés sur le marché, l’indussortinge n’aura d’autre choix que de changer.

C’est assez simple quand on considère l’adage d’ingénierie “bon, rapide, pas cher: choisir deux”. Dans mon expérience, 98% du temps, c’est rapide et bon marché, et par nécessité, l’autre doit souffrir.

C’est la psychologie de base de la douleur. Lorsque vous courez pour respecter un délai, la qualité du code prend la dernière place. Nous détestons parce que c’est terne et ennuyeux.

Cela me rappelle ce sketch de Monty Python :

“Excitant? Non ce n’est pas. C’est ennuyeux. Terne. Terne. Mon dieu, c’est terne, c’est désespérément terne et fastidieux, étouffant et ennuyeux et désemparé.”

Je dirais pour plusieurs raisons.

Tout d’abord, si l’application / le projet est petit ou ne contient pas de données vraiment importantes à grande échelle, le temps nécessaire pour écrire les tests est mieux utilisé pour écrire l’application réelle.

Il existe un seuil où les exigences de qualité sont telles que les tests unitaires sont requirejs.

Il y a aussi le problème de nombreuses méthodes qui ne sont pas facilement testables. Ils peuvent s’appuyer sur des données dans une firebase database ou similaire, ce qui crée le problème de la configuration des données de maquette à transmettre aux méthodes. Même si vous configurez des données de maquette, pouvez-vous être certain que la firebase database se comporterait de la même manière?

Les tests unitaires sont également faibles pour trouver des problèmes qui n’ont pas été pris en compte. C’est-à-dire que les tests unitaires sont mauvais pour simuler l’inattendu. Si vous n’avez pas envisagé ce qui pourrait se produire lors d’une panne de courant, si le lien réseau envoie des données incorrectes qui sont toujours correctes. Écrire des tests pour cela est inutile.

Je suis tout à fait en faveur des inspections de code car elles permettent aux programmeurs de partager leur expérience et leur style de code avec d’autres programmeurs.

“Il y a des excuses communes pour ne pas écrire des tests, mais ce ne sont que des excuses.”

Sont-ils? Réunissez huit programmeurs dans une pièce, posez-leur une question sur la meilleure façon de maintenir la qualité du code et vous obtiendrez neuf réponses différentes, en fonction de leur âge, de leurs études et de leurs préférences. Les années 1970, les informaticiens se seraient moqués de la notion de test unitaire; Je ne suis pas sûr qu’ils se seraient trompés.

La direction doit être vendue sur la valeur de passer plus de temps maintenant pour gagner du temps sur la route. Comme ils ne peuvent pas réellement mesurer les “bogues non corrigés”, ils sont souvent plus soucieux de respecter les délais et la date de livraison immédiats que la qualité à long terme du projet.

La qualité du code est subjective. Les sujets subjectifs sont toujours fastidieux.

Le but étant simplement de faire quelque chose qui fonctionne, la qualité du code vient toujours en second. Cela ajoute du temps et des coûts. (Je ne dis pas que cela ne devrait pas être considéré comme une bonne chose cependant.)

99% du temps, il n’y a pas de conséquences de tiers pour une qualité de code médiocre (à moins que vous ne créiez un logiciel de navette spatiale ou de changement de train).

  • Est-ce que ça marche? = Béton
  • Est-ce joli? = Dans l’oeil du spectateur.

Lisez le mois de l’homme mythique de Fred Brooks. Il n’y a pas de solution miracle.

Le test unitaire nécessite un travail supplémentaire. Si un programmeur voit que son produit “fonctionne” (par exemple, pas de test unitaire), pourquoi faire quoi que ce soit? Surtout quand ce n’est pas aussi intéressant que l’implémentation de la prochaine fonctionnalité du programme, etc. La plupart des gens ont tendance à être paresseux, ce qui n’est pas une bonne chose …

La qualité du code est spécifique au contexte et difficile à généraliser, quels que soient les efforts déployés par les personnes pour y parvenir.

C’est similaire à la différence entre la théorie et l’application.

Je n’ai pas non plus vu de tests unitaires écrits régulièrement. La raison en est que le code a été trop largement modifié au début du projet, donc tout le monde a abandonné les tests d’écriture jusqu’à ce que tout soit stabilisé. Après cela, tout le monde était content et n’avait pas besoin de tests unitaires. Nous avons donc quelques tests en tant qu’historique mais ils ne sont pas utilisés et ne sont probablement pas compatibles avec le code actuel.

Personnellement, je considère que les tests unitaires d’écriture pour les grands projets ne sont pas réalisables, même si je reconnais que je ne les ai pas essayés ni parlé à des personnes qui l’ont fait. Il y a tellement de règles dans la logique métier que si vous changez quelque chose un peu quelque part, vous n’avez aucun moyen de savoir quels tests mettre à jour au-delà de ceux qui planteront. Qui sait, les anciens tests peuvent maintenant ne pas couvrir toutes les possibilités et il faut du temps pour se rappeler ce qui a été écrit il y a cinq ans.

L’autre raison étant le manque de temps. Lorsque vous avez une tâche assignée où il est indiqué “Temps d’achèvement: O, 5 hommes / jours”, vous n’avez que le temps de l’implémenter et de la tester peu, de ne pas penser à tous les cas et relations possibles tests nécessaires. Cela peut prendre réellement 0,5 jour pour mettre en œuvre quelque chose et quelques semaines pour écrire les tests. À moins que l’on vous ait donné l’ordre de créer les tests, personne ne comprendra cette perte de temps considérable, ce qui entraînera des critiques négatives. Et non, pour notre application d’entreprise complexe, je ne peux penser à une bonne couverture de test pour une tâche en cinq minutes. Cela prendra du temps et probablement une connaissance très approfondie de la plupart des modules d’application.

Donc, les raisons pour lesquelles je les vois sont une perte de temps qui ne donne aucune fonctionnalité utile et le cauchemar de maintenir / mettre à jour les anciens tests pour refléter les nouvelles règles métier. Même si quelqu’un le souhaitait, seuls les collègues expérimentés pouvaient écrire ces tests – une implication au moins une année dans le projet, mais deux ou trois sont vraiment nécessaires. Les nouveaux collègues ne gèrent donc pas les tests appropriés. Et il ne sert à rien de créer de mauvais tests.

Il est “ennuyeux” d’attraper une “caractéristique” aléatoire d’une importance extrême pendant plus d’une journée dans un code mystérieux écrit par quelqu’un d’autre, il y a des années, sans aucune idée de ce qui ne va pas, quand il était censé se terminer dans quelques heures. Et quand cela sera fait, personne ne sera satisfait du retard énorme.

Été là – vu ça.

Un grand nombre de concepts qui sont mis en évidence dans l’écriture moderne sur la qualité du code négligent la mésortingque primaire de la qualité du code: le code doit être fonctionnel avant tout. Tout le rest n’est qu’un moyen d’y parvenir.

Certaines personnes n’ont pas l’impression d’avoir le temps d’apprendre les dernières tendances en matière de génie logiciel et d’écrire du code de haute qualité. Je ne suis pas en mesure de les juger, mais à mon avis, il est très difficile d’utiliser votre code sur de longues périodes si les gens ne peuvent pas le lire, le comprendre et le modifier.

L’absence de «qualité de code» ne coûte pas à l’utilisateur, au vendeur, à l’architecte ni au développeur du code; cela ralentit la prochaine itération, mais je peux penser à plusieurs produits qui semblent être faits de cheveux et de boue.

Je trouve que les tests unitaires me rendent plus productif, mais j’ai vu beaucoup de codes mal conçus et illisibles, mal conçus, qui ont réussi tous leurs tests (généralement du code long-in-the-tooth corrigé à plusieurs resockets). En passant des tests, vous obtenez un Skoda digne de la route, pas le savoir-faire d’un Bristol . Mais si vous avez une «qualité de code faible» et que vous réussissez vos tests et que vous répondez toujours aux exigences de l’utilisateur, alors c’est un modèle commercial valide.

Ma conclusion est que les développeurs ne veulent pas écrire de tests.

Je ne suis pas sûr. En partie, tout le processus éducatif dans le logiciel n’est pas piloté par les tests et devrait probablement l’être – au lieu de demander qu’un exercice soit remis, donnez les tests unitaires aux étudiants. C’est normal en maths de faire une vérification, pourquoi pas en génie logiciel?

L’autre chose est que les tests unitaires nécessitent des unités. Some developers find modularisation and encapsulation difficult to do well. A good technical lead will create a modular architecture which localizes the scope of a unit, so making it easy to test in isolation; many systems don’t have good architects who facilitate testability, or aren’t refactored regularly enough to reduce inter-unit coupling.

It’s also hard to test dissortingbuted or GUI driven applications, due to inherent coupling. I’ve only been in one team that did that well, and that had as large a test department as a development department.

Static code analysis is often played around in small projects, but not really used to enforce coding conventions or find possible errors in enterprise projects.

Every set of coding conventions I’ve seen which hasn’t been automated has been logically inconsistent, sometimes to the point of being unusable – even ones claimed to have been used ‘successfully’ in several projects. Non-automatic coding standards seem to be political rather than technical documents.

Usually even comstackr warnings like potential null pointer access are ignored.

I’ve never worked in a shop where comstackr warnings were tolerated.

One attitude that I have met rather often (but never from programmers that were already quality-addicts) is that writing unit tests just forces you to write more code without getting any extra functionality for the effort. And they think that that time would be better spent adding functionality to the product instead of just creating “meta code”.

That attitude usually wears off as unit tests catch more and more bugs that you realize would be serious and hard to locate in a production environment.

A lot of it arises when programmers forget, or are naive, and act like their code won’t be viewed by somebody else at a later date (or themselves months/years down the line).

Also, commenting isn’t near as “cool” as actually writing a slick piece of code.

Another thing that several people have touched on is that most development engineers are terrible testers. They don’t have the expertise or mind-set to effectively test their own code. This means that unit testing doesn’t seem very valuable to them – since all of their code always passes unit tests, why bother writing them?

Education and mentoring can help with that, as can test-driven development. If you write the tests first, you’re at least thinking primarily about testing, rather than trying to get the tests done, so you can commit the code…

The likelyhood of you being replaced by a cheaper fresh out of college student or outsource worker is directly proportional to the readability of your code.

People don’t have a common sense of what “good” means for code. A lot of people will drop to the level of “I ran it” or even “I wrote it.”

We need to have some kind of a shared sense of what good code is, and whether it matters. For the first part of that,I have written up some thoughts:

http://agileinaflash.blogspot.com/2010/02/seven-code-virtues.html

As for whether it matters, that’s been covered plenty of times. It matters quite a lot if your code is to live very long. If it really won’t ever sell or won’t be deployed, then it clearly doesn’t. If it’s not worth doing, it’s not worth doing well.

But if you don’t practice writing virtuous code, then you can’t do it when it matters. I think people have practiced doing poor work, and don’t know anything else.

I think code quality is over-rated. the more I do it the less it means to me. Code quality frameworks prefer over-complicated code. You never see errors like “this code is too abstract, no one will understand it.”, but for example PMD says that I have too many methods in my class. So I should cut the class into abstract class/classes (the best way since PMD doesn’t care what I do) or cut the classes based on functionality (worst way since it might still have too many methods – been there).

Static Analysis is really cool, however it’s just warnings. For example FindBugs has problem with casting and you should use instaceof to make warning go away. I don’t do that just to make FindBugs happy.

I think too complicated code is not when method has 500 lines of code, but when method is using 500 other methods and many abstractions just for fun. I think code quality masters should really work on finding when code is too complicated and don’t care so much about little things (you can refactor them with the right tools really quickly.).

I don’t like idea of code coverage since it’s really useless and makes unit-test boring. I always test code with complicated functionality, but only that code. I worked in a place with 100% code coverage and it was a real nightmare to change anything. Because when you change anything you had to worry about broken (poorly written) unit-tests and you never know what to do with them, many times we just comment them out and add todo to fix them later.

I think unit-testing has its place and for example I did a lot of unit-testing in my webpage parser, because all the time I found diffrent bugs or not supported tags. Testing Database programs is really hard if you want to also test database logic, DbUnit is really painful to work with.

Je ne sais pas. Have you seen Sonar ? Sure it is Maven specific, but point it at your build and boom, lots of mesortingcs. That’s the kind of project that will facilitate these code quality mesortingcs going mainstream.

I think that real problem with code quality or testing is that you have to put a lot of work into it and YOU get nothing back. less bugs == less work? no, there’s always something to do. less bugs == more money? no, you have to change job to get more money. unit-testing is heroic , you only do it to feel better about yourself.

I work at place where management is encouraging unit-testing, however I am the only person that writes tests(i want to get better at it, its the only reason I do it). I understand that for others writing tests is just more work and you get nothing in return . surfing the web sounds cooler than writing tests.

someone might break your tests and say he doesn’t know how to fix or comment it out(if you use maven).

Frameworks are not there for real web-app integration testing(unit test might pass, but it might not work on a web page), so even if you write test you still have to test it manually.

You could use framework like HtmlUnit , but its really painful to use. Selenium breaks with every change on a webpage. SQL testing is almost impossible(You can do it with DbUnit , but first you have to provide test data for it. test data for 5 joins is a lot of work and there is no easy way to generate it). I dont know about your web-framework , but the one we are using really likes static methods , so you really have to work to test the code.