Pourquoi la qualité du code n'est pas populaire?

Question

J'aime mon code dans l'ordre, c'est à dire correctement formaté, lisible, conçu, testé, vérifié pour les bugs, etc. En fait, je suis fanatique de ce sujet. (Peut-être même plus que fanatique...), Mais dans mon expérience, les actions contribuant à la qualité du code sont à peine mis en œuvre. (Par la qualité du code, je veux dire de la qualité du code que vous produisez au jour le jour. L'ensemble du sujet de la qualité des logiciels avec les processus de développement et est beaucoup plus large et de ne pas la portée de cette question.)

Code de la qualité ne semble pas populaire. Quelques exemples de mon expérience

• Probablement chaque développeur Java sait JUnit, presque toutes les langues de mettre en œuvre frameworks xUnit, mais dans toutes les sociétés que je connais, que très peu de bon tests unitaires existé (le cas échéant). Je sais que ce n'est pas toujours possible d'écrire des tests unitaires en raison de limitations techniques ou en appuyant sur les délais, mais dans les cas que j'ai vu, tests unitaires aurait été une option. Si un développeur a voulu écrire quelques tests de son nouveau code, il/elle pourrait le faire. Ma conclusion est que les développeurs ne veulent pas écrire des tests.

• L'analyse statique de code est souvent joué dans les petits projets, mais pas vraiment utilisé pour appliquer les conventions de codage ou trouver d'éventuelles erreurs dans des projets d'entreprise. Généralement, même les avertissements du compilateur comme potentiel de pointeur null accès sont ignorés.

• Les conférenciers et les magazines parlent beaucoup sur EJB3.1, OSGI, le Cloud et d'autres nouvelles technologies, mais à peine sur les nouvelles technologies de test ou d'outils, de nouvelles analyse de code statique approches (p. ex. SAT de problèmes), les processus de développement en aidant à maintenir la meilleure qualité, comment une méchante bête de code legacy a été intentée en vertu de test, ... (je n'ai pas assister à de nombreuses conférences et il ressemble probablement différents pour les conférences sur agile sujets, comme les tests unitaires et les CI et a une valeur plus élevée.)

Alors, pourquoi est la qualité du code si impopulaire/considéré comme ennuyeux?

EDIT:
Merci beaucoup pour vos réponses. La plupart d'entre eux concernent l'unité de test (ce qui a été évoqué lors d'une question connexe). Mais il y a beaucoup d'autres choses qui peuvent être utilisés pour maintenir la qualité du code (voir question connexe). Même si vous n'êtes pas en mesure d'utiliser les tests unitaires, vous pouvez utiliser une compilation quotidienne, ajouter un peu d'analyse de code statique pour votre IDE ou le processus de développement, essayez paire de programmation ou de faire appliquer des examens de code critique.

Answer 1

Une réponse évidente pour le Dépassement de Pile, c'est qu'elle n'est pas un forum. C'est une base de données de questions et de réponses, ce qui signifie que les doublons de questions sont tenté d'éviter.

Combien de différentes questions au sujet de la qualité du code pouvez-vous penser? C'est pourquoi il n'y a pas de 50 000 questions sur le code de "qualité".

En dehors de cela, quelqu'un qui prétend que les orateurs de la conférence ne veux pas parler des tests unitaires ou de la qualité du code a clairement besoin d'aller à des conférences.

J'ai aussi vu plus de suffisamment d'articles sur l'intégration continue.

Il y a le commun des excuses pour ne pas l'écriture de tests, mais ils ne sont des excuses. Si l'on veut écrire quelques les tests de son nouveau code, alors il est possible

Oh vraiment? Même si votre patron vous dit "je ne vous paie pas pour perdre du temps sur les tests unitaires"? Même si vous travaillez sur quelque plate-forme embarquée avec pas de tests unitaires cadres? Même si vous travaillez sous un délai serré, en essayant d'atteindre certains objectifs à court terme, même au prix de long terme de la qualité du code?

Pas de. Il n'est pas "toujours possible" d'écrire des tests unitaires. Il existe de nombreux de nombreux obstacles communs. Cela ne veut pas dire que nous ne devrions pas essayer d'écrire plus et de meilleurs tests. Juste que parfois, nous n'avons pas l'occasion.

Personnellement, je suis fatigué de "code" de la qualité des discussions, car ils ont tendance à

• être trop préoccupé par exemples hypothétiques, et sont trop souvent le fruit de l'imagination de certains, qui n'a pas vraiment réfléchi à la manière de applicable pour les autres projets, ou des bases de codes de différentes tailles que celui sur lequel il travaille,
• ont tendance à devenir trop émotif, et insuffler dans notre code avec de trop nombreux traits de l'homme (pensez à l'expression "odeur de code", pour un bon exemple),
• être dominé par des gens qui écrivent horrible gonflé, trop compliqué et commenté code de trop nombreuses couches d'abstraction, ou qui juge si le code est réutilisable par "il semble que je peux prendre ce bout de code et l'utiliser dans un projet d'avenir", plutôt que de la beaucoup plus de sens "j'ai effectivement été en mesure de prendre ce morceau de code et de le réutiliser dans différents projets".

Je suis certainement intéressé à l'écriture de haute qualité de code. J'ai juste tendance à être éteint par les gens qui ont l'habitude de parler de la qualité du code.

Answer 2

La révision du Code n'est pas une science exacte. Les métriques utilisées sont quelque peu discutable. Quelque part sur la page : "Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer"

Supposons que vous avez un énorme fonction de 5000 lignes avec 35 paramètres. Vous pouvez unité de tester combien vous voulez, il peut faire exactement ce qu'il est censé faire. Quelles que soient les entrées sont. Sur la base de tests unitaires, cette fonction est "parfait". En plus d'exactitude, il y a des tonnes d'autres attributs de qualité, vous pouvez vouloir mesurer. Les performances, l'évolutivité, de la maintenabilité, de la convivialité et de la de telles. Avez-vous jamais demandé pourquoi les logiciels de maintenance est un tel cauchemar?

Real software, projets de contrôle de la qualité va bien au-delà de simplement vérifier si le code est correct. Si vous cochez la V-Modèle de développement de logiciels, vous remarquerez que le codage n'est qu'une petite partie de l'ensemble de l'équation.

Logiciel de contrôle de la qualité peut aller jusqu'à 60% de la totalité du coût de votre projet. C'est énorme. Au lieu de cela, les gens préfèrent couper à 0% et rentrer à la maison en pensant qu'ils ont fait le bon choix. Je pense que la vraie raison pour laquelle si peu de temps est consacré à la qualité des logiciels est en raison de la qualité des logiciels n'est pas bien compris.

• Que doit-on mesurer?
• Comment pouvons-nous mesurer?
• Qui va le mesurer?
• Que vais-je gagner/perdre de mesure?

Beaucoup de coder les ateliers clandestins ne se rendent pas compte de la relation entre les "moins de bugs maintenant" et "plus de profit plus tard". Au lieu de cela, tout ce qu'ils voient est "temps perdu" et "moins de profit que maintenant". Même lorsqu'ils sont présentés jolis graphiques démontrant le contraire.

De plus, les logiciels de contrôle de la qualité et de l'ingénierie du logiciel dans son ensemble est une discipline relativement nouvelle. Beaucoup de la programmation de l'espace jusqu'à présent, a été pris par les cow-boys. Combien de fois avez-vous entendu dire que "n'importe qui" peut programme? N'importe qui peut écrire du code, c'est certain, mais ce n'est pas tout le monde qui peut être un programmeur.

MODIFIER *

Je suis venu à travers ce document (PDF) qui est du gars qui dit "Vous ne pouvez pas contrôler ce que vous ne pouvez pas le mesurer". Fondamentalement, il est dit que le contrôle de tout ce qui n'est pas souhaitable qu'il a d'abord pensé qu'il serait. Il n'est pas exact, recette de cuisine que vous pouvez appliquer aveuglément à tous les projets, comme le génie logiciel écoles veulent vous faire croire. Il ajoute un autre paramètre de contrôle qui est "je veux contrôler ce projet? Sera-ce nécessaire?"

Answer 3

• La paresse / Considéré comme ennuyeux
• Gestion de la sensation que c'est inutile Ignorant "Just do it right" attitude.
• "Ce petit projet n'a pas besoin de code gestion de la qualité" se transforme en "Maintenant il serait trop coûteux à mettre en œuvre le code de gestion de la qualité sur ce grand projet"

Je suis en désaccord que c'est triste. Une unité solide tests de design, la création de tests et une brise de course encore plus amusant.

Calculating vector flow control - PASSED
Assigning flux 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 qu'il peut devenir ennuyeux si vous en faites trop, mais des dépenses de 10 ou 20 minutes de l'écriture des essais au hasard pour certaines fonctions complexes, après plusieurs heures de codage n'est pas va sucer la vie créative de vous.

Answer 4

Pourquoi la qualité du code si impopulaire?

Parce que notre métier est un manque de professionnalisme.

Cependant, il y sont des gens qui se soucient de la qualité du code. Vous pouvez trouver ces gens qui pensent par exemple à partir du Logiciel de l'Artisanat du mouvement de la discussion de groupe. Mais, malheureusement, la majorité des gens dans les logiciels d'entreprise ne comprennent pas la valeur de la qualité du code, ou ne savent même pas de quoi est fait un bon code.

Answer 5

Je suppose que la réponse est la même que pour la question " Pourquoi est la qualité du code pas populaire?'

Je crois que les principales raisons sont:

• La paresse des développeurs. Pourquoi investir du temps dans la préparation des tests unitaires, d'examiner la solution, si elle est déjà mis en œuvre?
• Une mauvaise gestion. Pourquoi demander aux développeurs de faire face avec la qualité du code, si il y a des milliers de nouvelles demandes de fonctionnalités, et les programmeurs pourrait simplement mettre en place quelque chose au lieu de prendre soin de la qualité de quelque chose de déjà mis en œuvre.