Est-ce bitrot ont des dimensions acceptées?

Question

Chaque système de contrôle de source moderne peut couper et dés l'histoire d'un programme. Il existe de nombreux outils pour analyser statiquement et dynamiquement le code. Quel genre de formule mathématique me permettrait d'intégrer la quantité d'activité dans un fichier ainsi que le nombre de déploiements de ce logiciel? Nous constatons que même si un programme se termine tous ses tests unitaires, il faut plus de travail que nous attendre au moment de mise à niveau. Une mesure de ce type devrait être possible, mais assis et penser à même ses unités m'a déconcerté.

Mise à jour: Si quelque chose est envoyé à une machine de test, je pouvais voir marquer moins pourrie. Si quelque chose est envoyé à toutes les boîtes de test que je pouvais le voir obtenir un marqueur frais. Si quelque chose va à la production que je pourrais lui donner un signe de tête et de réduire son bitrot score. S'il y a beaucoup d'activité dans ses dossiers et il n'est envoyé nulle part je voudrais ding la merde hors de celui-ci. Ne vous concentrez pas sur le code suppose que les données dont j'ai besoin est à portée de main.

Qu'est-ce commettre type d'analyse (validation des commentaires (mentionnés ci-dessous) ou le temps entre les commits) sont des données justes à appliquer?

Mise à jour: Je pense que l'analyse dimensionnelle pourrait probablement être juste, fondée sur l'âge. Par rapport à ce qui est un peu plus difficile. Ancien code est pourri. L'âge moyen de chaque ligne de code est toujours simplement une mesure du temps. Est-ce un module source plus pourrir plus vite qu'un plus petit, plus complexe?

Mise à jour couverture de code est mesurée en lignes. Code exécuté doit souvent, par définition, être moins pourrie que le code n'a jamais été exécuté. Pour mesurer avec précision bitrot vous auriez besoin d'analyse de couverture pour agir comme un amortisseur.

Answer 1

La réponse évidente est non. Bitrot n'a pas de dimensions acceptées.

Answer 2

Train très intéressant de la pensée!

Tout d'abord, ce que est bitrot? L'article Software Pourriture de sur wikipedia recueille quelques points:

• changement d'environnement: changements dans le moteur d'exécution
• Code non utilisé: les changements dans les habitudes d'utilisation
• Code rarement mis à jour: modifications par l'entretien
• Refonte: un moyen d'endiguer bitrot

loi de Moore , delta(CPU)/delta(t) est un facteur constant de deux tous les 18 à 24 mois . Étant donné que l'environnement contient plus que la CPU, je suppose que cette forme ne borne inférieure une très faible sur le changement réel dans l'environnement. Unité: OPS / $ / s, le changement dans les opérations par seconde par dollar au fil du temps

delta(users)/delta(t) est plus difficile à quantifier, mais la preuve de la fréquence des occurrences des mots « L'âge de la connaissance » dans les nouvelles, je dirais que les attentes des utilisateurs croître de façon exponentielle aussi. En regardant le développement de l'économie de base $/flops nous dit que l'offre augmente plus rapidement que la demande, ce qui donne la loi de Moore comme limite supérieure du changement d'utilisateur. Je vais utiliser points de fonction ( « quantité de fonctionnalités d'entreprise d'un système d'information permet à un utilisateur » ) en tant que mesure des besoins. Unité: FP / s, changement de points de fonction nécessaires au fil du temps

delta(maintenance)/delta(t) dépend totalement de l'organisation et est généralement assez élevé immédiatement avant une libération, lorsque des solutions rapides sont poussés à travers et lors de l'intégration de grands changements. Les modifications apportées à diverses mesures comme SLOC ,

Je suis en désaccord avec Charlie: refactoring mineur du code source peut entraîner très grand distances de Hamming et ne fournit pas une bonne mesure du degré auquel le code a été logiquement modifié.

Je considérerais regarder la longueur de commettre des commentaires. Pour un programmeur donné, un engagement relativement long commentaire indique généralement qu'ils ont fait un changement important au code.

Que diriez-vous de la réponse la plus simple possible?

foreach (file in source control){
  file.RotLevel = (Time.Now - file.LastTestedOrDeployed)
}

Si un fichier n'a pas été déployé (soit à la production ou à une machine de test) pendant une longue période, il peut être synchronisé avec la « réalité ». L'environnement a changé, et même si le fichier n'a pas été modifié, il peut ne plus fonctionner. Alors, qui me semble être une formule simple et précise. Pourquoi le rendre plus complexe que cela? Impliquant plusieurs changements semble ajouter que l'incertitude. Si un fichier a été modifié récemment, est-ce que cela signifie qu'il a été mis à jour pour refléter un changement dans l'environnement (ce qui le rend « moins pourrie »), ou ont de nouvelles fonctionnalités été ajoutées (qui augmente le risque d'erreurs, et ainsi rendre " plus pourri »)? Les modifications apportées à un fichier pourrait signifier quoi que ce soit.

Le seul facteur sans ambiguïté que je peux penser est « combien de temps qu'il fait depuis notre dernière vérifié que le fichier travaillé ? »

Je me rappelle planification fondée sur des preuves . Venez avec un ensemble de mesures raisonnables pour indiquer bitrot (à la fois sa valeur réelle et combien il a été réduit par un changement particulier). Déterminez ensuite le degré de précision, ils sont basés sur le temps passé plus tard. Venir avec les chiffres et les règles de c'est probablement compliqué.

proportion inverse du nombre de tests unitaires aux lignes totales de code?

Pensez à deux mesures possibles: différences de modifier, comme Hamming ou de distance Wagner; et de l'entropie de l'information-théorétique.

Si vous êtes vraiment intéressé à creuser dans cela, il y a des recherches là-bas. Je regardais dans les concepts d'un article qui a examiné l'effet de Structure organisationnelle sur la qualité des logiciels il y a un certain temps. J'ai fini par déposer les idées loin dans le dos de ma tête, mais vous pourriez le trouver instructif.

Étant donné que nous ne nous soucions pas de code qui fonctionne, je regarde le nombre de modifications apportées à un fichier (pas la taille des changements ont été, à quelle fréquence un fichier est modifié) et le nombre de bugs ont été corrigés par ces changements ainsi que le nombre de bogues ouverts qui sont enregistrés sur le fichier. Le résultat devrait être un nombre qui grossit plus un fichier est pourri.

Les fichiers qui changent souvent (config, etc.) tout en ne fixant pas un grand ne sera pas affiché parce que la partie de bug de l'équation sera faible. Fichier avec beaucoup de bugs ouverts apparaîtra tout comme les fichiers où les changements conduisent souvent à de nouveaux bugs. Les changements * bugfixes nombre devrait éroder au fil du temps (parce que nous ne se soucient pas de vieux points chauds).

Mon seul problème avec les tests de couverture de code et l'unité est que les tests unitaires ne testent que ce qu'ils étaient à l'origine conçus pour tester, et ils, par définition, sont le code et sujettes au même logiciel pourriture fonctionnelle qui empoisonne le code régulier. (Ils ne sont bonnes que pour ce qu'ils sont écrits pour, et après un certain temps, cela ne suffit pas)

Mais les tests unitaires de haute qualité sera évidemment fournir une certaine protection.

Ce sont mes facteurs importants pour la pourriture du logiciel:

1. Nombre de points d'interface de données externes (extDataIntfPts)
   • Qualité de traitement des données / d'erreur, les tests unitaires (codeQuality)
   • La dépendance sur les implémentations sous-jacentes telles que OS / VM. (OsDep)
   • Nombre de point d'interface de mise en œuvre externe comme plug-ins. (ExtIntfPts)
   • La complexité du code / volume de code simple (linesOfCode)

En tant que système vit dans la production, il est exposé à une plus grande variété d'entrées de données que l'ensemble de données qu'il a recueillies grandit. Cette définition expose par le code de base à un plus grand nombre de cas de pointe et des séquences.

Ceci peut être atténué par la qualité du traitement des données, la gestion des erreurs et des tests unitaires.

Il y a aussi les cibles mobiles de l'environnement sous-jacent que le système fonctionne. Une façon de modérer est de mettre l'application dans une machine virtuelle.

Si le système met en œuvre des plugins, je pouvais voir la face codebase une plus grande chance d'échec que plus plugins sont développés.

code complexe! = Code élégant. Si c'est élégant, il est probablement simple. Je vais avec le simple point ici que le code plus il y a, moins il est probable qu'il est bien testé, mais je suppose que cela pourrait être fait demi-tour.

Alors, voici mon équation:

bitrot=((linesofcode/codeQuality)*(extDataInfPts+(osDep/change)+extIntfPts)*numberOfSecondsDeployed)

D'après codeQuality comporterait probablement la mesure de ce que la couverture du code dans les tests unitaires est. Vous pouvez exécuter un programme d'analyse statique contre pour déterminer les bugs potentiels et ce serait probablement une aide aussi bien. Je veux dire, à un moment donné, il est vraiment difficile de marquer parce que le code multi-threading doit être pondéré beaucoup plus lourd qu'un POJO. Et oui, refactoring doit être compris, mais seulement là où il y a des preuves de pourriture du logiciel.

En fin de compte, c'est une pseudo-science. Voici ma contribution à la pseudo-science.

A bitrot (pas la pourriture du logiciel) a des dimensions du volume physique de stockage * temps.

bitrot est causée par la désintégration radioactive des impuretés dans le support de stockage.

Answer 3

Answer 4

Answer 5

Answer 6

Answer 7

Je suis en désaccord avec Charlie: refactoring mineur du code source peut entraîner très grand

Answer 8

Que diriez-vous de la réponse la plus simple possible?

foreach (file in source control){
  file.RotLevel = (Time.Now - file.LastTestedOrDeployed)
}

Si un fichier n'a pas été déployé (soit à la production ou à une machine de test) pendant une longue période, il peut être synchronisé avec la « réalité ». L'environnement a changé, et même si le fichier n'a pas été modifié, il peut ne plus fonctionner. Alors, qui me semble être une formule simple et précise. Pourquoi le rendre plus complexe que cela? Impliquant plusieurs changements semble ajouter que l'incertitude. Si un fichier a été modifié récemment, est-ce que cela signifie qu'il a été mis à jour pour refléter un changement dans l'environnement (ce qui le rend « moins pourrie »), ou ont de nouvelles fonctionnalités été ajoutées (qui augmente le risque d'erreurs, et ainsi rendre " plus pourri »)? Les modifications apportées à un fichier pourrait signifier quoi que ce soit.

Le seul facteur sans ambiguïté que je peux penser est « combien de temps qu'il fait depuis notre dernière vérifié que le fichier travaillé ? »

Answer 9

Je me rappelle planification fondée sur des preuves . Venez avec un ensemble de mesures raisonnables pour indiquer bitrot (à la fois sa valeur réelle et combien il a été réduit par un changement particulier). Déterminez ensuite le degré de précision, ils sont basés sur le temps passé plus tard. Venir avec les chiffres et les règles de c'est probablement compliqué.

Answer 10

proportion inverse du nombre de tests unitaires aux lignes totales de code?

Answer 11

Pensez à deux mesures possibles: différences de modifier, comme Hamming ou de distance Wagner; et de l'entropie de l'information-théorétique.

Answer 12

Si vous êtes vraiment intéressé à creuser dans cela, il y a des recherches là-bas. Je regardais dans les concepts d'un article qui a examiné l'effet de Structure organisationnelle sur la qualité des logiciels il y a un certain temps. J'ai fini par déposer les idées loin dans le dos de ma tête, mais vous pourriez le trouver instructif.

Answer 13

Étant donné que nous ne nous soucions pas de code qui fonctionne, je regarde le nombre de modifications apportées à un fichier (pas la taille des changements ont été, à quelle fréquence un fichier est modifié) et le nombre de bugs ont été corrigés par ces changements ainsi que le nombre de bogues ouverts qui sont enregistrés sur le fichier. Le résultat devrait être un nombre qui grossit plus un fichier est pourri.

Les fichiers qui changent souvent (config, etc.) tout en ne fixant pas un grand ne sera pas affiché parce que la partie de bug de l'équation sera faible. Fichier avec beaucoup de bugs ouverts apparaîtra tout comme les fichiers où les changements conduisent souvent à de nouveaux bugs. Les changements * bugfixes nombre devrait éroder au fil du temps (parce que nous ne se soucient pas de vieux points chauds).

Answer 14

Mon seul problème avec les tests de couverture de code et l'unité est que les tests unitaires ne testent que ce qu'ils étaient à l'origine conçus pour tester, et ils, par définition, sont le code et sujettes au même logiciel pourriture fonctionnelle qui empoisonne le code régulier. (Ils ne sont bonnes que pour ce qu'ils sont écrits pour, et après un certain temps, cela ne suffit pas)

Mais les tests unitaires de haute qualité sera évidemment fournir une certaine protection.

Ce sont mes facteurs importants pour la pourriture du logiciel:

1. Nombre de points d'interface de données externes (extDataIntfPts)
   • Qualité de traitement des données / d'erreur, les tests unitaires (codeQuality)
   • La dépendance sur les implémentations sous-jacentes telles que OS / VM. (OsDep)
   • Nombre de point d'interface de mise en œuvre externe comme plug-ins. (ExtIntfPts)
   • La complexité du code / volume de code simple (linesOfCode)

En tant que système vit dans la production, il est exposé à une plus grande variété d'entrées de données que l'ensemble de données qu'il a recueillies grandit. Cette définition expose par le code de base à un plus grand nombre de cas de pointe et des séquences.

Ceci peut être atténué par la qualité du traitement des données, la gestion des erreurs et des tests unitaires.

Il y a aussi les cibles mobiles de l'environnement sous-jacent que le système fonctionne. Une façon de modérer est de mettre l'application dans une machine virtuelle.

Si le système met en œuvre des plugins, je pouvais voir la face codebase une plus grande chance d'échec que plus plugins sont développés.

code complexe! = Code élégant. Si c'est élégant, il est probablement simple. Je vais avec le simple point ici que le code plus il y a, moins il est probable qu'il est bien testé, mais je suppose que cela pourrait être fait demi-tour.

Alors, voici mon équation:

bitrot=((linesofcode/codeQuality)*(extDataInfPts+(osDep/change)+extIntfPts)*numberOfSecondsDeployed)

D'après codeQuality comporterait probablement la mesure de ce que la couverture du code dans les tests unitaires est. Vous pouvez exécuter un programme d'analyse statique contre pour déterminer les bugs potentiels et ce serait probablement une aide aussi bien. Je veux dire, à un moment donné, il est vraiment difficile de marquer parce que le code multi-threading doit être pondéré beaucoup plus lourd qu'un POJO. Et oui, refactoring doit être compris, mais seulement là où il y a des preuves de pourriture du logiciel.

En fin de compte, c'est une pseudo-science. Voici ma contribution à la pseudo-science.

Answer 15

A bitrot (pas la pourriture du logiciel) a des dimensions du volume physique de stockage * temps.

bitrot est causée par la désintégration radioactive des impuretés dans le support de stockage.