Il debito tecnico può essere rilevato dall'analisi del codice?

Can technical debt be detected by code analysis?

È come chiedere se un tachimetro ti rende un autista più sicuro.

However, I would normally think of technical debt as "A piece of code which doesn't follow the overall architectural pattern."

Il debito tecnico ha molte più facce. La metafora riguarda il prendere in prestito tempo dal tuo sé futuro. Proprio come guidare, ci sono molti modi per mettersi nei guai che lo strumento semplicemente non ti aiuterà. Ma ciò non significa che lo strumento sia inutile. Prestare attenzione ad esso può aiutare. Non è tutto.

Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

Technical debt is commonly associated with extreme programming, especially in the context of refactoring. That is, it implies that restructuring existing code (refactoring) is required as part of the development process. Under this line of thinking refactoring is not only a result of poorly written code, but is also done based on an evolving understanding of a problem and the best way to solve that problem.

Technical debt may also be known as design debt.

techopedia.com

Uncle Bob ti dirà che i guadagni rapidi ottieni procrastinando il design non è una scusa per fare casino.

Fowler sosterranno che un certo debito è prudente, un po 'imprudente e un po' accidentale.

Cunningham sembra soddisfatto finché si paga il debito per fare spazio a una nuova funzione prima di aggiungere quella funzione.

Tutto ciò che mi interessa è se stai rendendo infelici i tuoi compagni programmatori. Sono stato in ambienti di sviluppo in cui il cambiamento è stato facile e veloce. Altri dove era atroce e glaciale. La grande differenza non era avere uno strumento che agitasse il dito contro di te quando il tuo progetto era strano.

La cosa più importante che manca a questo strumento è l'abilità di chiamare brutti nomi. Dai nomi brutti e ti trovi in un mondo di debito tecnico. I cattivi nomi sono strozzini che caricano interessi sconcertanti e vogliono che paghiate ogni volta che li guardate. Come lo vedrà uno strumento? La cosa migliore per questo è chiedere a un altro sviluppatore se il nome ha un senso.

Am I wrong or right? Do some objective rules or some class of rules make a good definition of technical debt or at least a type of technical debt?

L'obbedienza al limite di velocità mi rende un buon guidatore? Vorresti che smettessi di fare ciambelle sul tuo prato a 25 miglia all'ora?

O come spiegato da un bambino di 5 anni: "Questo ti infastidisce? Non ti sto toccando."

Questa cosa potrebbe aiutarti, ma non se pensi che si occupi di tutto.

Puoi usare CppDepend per creare facilmente le tue regole usando CQLinq, le regole possono riguardare l'architettura, il design e l'implementazione. Compreso l'accoppiamento tra progetti, tipi e metodi. E puoi specificare il tuo debito tecnico per ogni regola come descritto qui link

warnif count > 0 
from m in Methods
where m.CyclomaticComplexity > 10
select new { 
   m,
   m.CyclomaticComplexity,
   Debt = (3*(m.CyclomaticComplexity -10)).ToMinutes().ToDebt(),
   AnnualInterest = (m.PercentageCoverage == 100 ? 10 : 120).ToMinutes().ToAnnualInterest()
}