Complejidad Ciclómática de McCabe

[agilenature]

Quiero pasarles un truco muy rápido que uso para rapidamente darme una
idea de cuán "cochino" es un código legado, en cualquier lenguaje de
programación. Sirve en cualquier lenguaje porque está basado en el
número de circuitos linearmente interdependientes en el grafo de
control de un módulo.

Si encuentro consistentemente que hay métodos con una complejidad
ciclómática de más de 10, me preparo a enfrentar a un código que tiene
una deuda técnica muy alta (a veces tan alta que merece una
declaración de "banca rota") que requiere diferentes técnicas de
refactoring. Es como un smell de smells.

[Si tiene un proveedor de servicios de software que afirma hacer
desarrollo de software ágil, pidale los la complejidad ciclomática de
los proyectos de desarrollo que ha realizado, y de paso exija una
complejidad ciclomática de 10 o menos, si el proveedor no sabe qué es
CC, huya! ]

Una muy buena noticia es que se puede establecer un servidor de
continuous integration (ese que cuando alguien hace check-in, se
dispara el build automáticamente, se corren todos los Unit Tests, se
confirma que que los Unit Tests pasen y logren una cobertura de código
de al menos 95% [por ejemplo] y luego haga deployment) que permiten
chequeos de la complejidad ciclómática de los métodos agregados, de
manera que si por ejemplo se pasan de CC 10 entonces falle el build.

Referencias:
What's your/a good limit for cyclomatic complexity? http://bit.ly/dAmcjB
How to compute McCabe's Cyclomatic Complexity in Java methods
http://bit.ly/cvN1st
Structured Testing: A Testing Methodology Using the Cyclomatic
Complexity Metric http://www.mccabe.com/pdf/nist235r.pdf

[Franz Pereira]

Sobre el tema de complejidad ciclomática:

Para los que estén trabajando en Ruby y/o Rails hay una herramienta muy buena llamada metric_fu.

http://metric-fu.rubyforge.org/

Da reportes (en gráficos) de:

1. Complejidad ciclómatica
2. Code smells
3. Duplicaciones de código
4. Churns
5. Problemas de diseño
6. Porcentaje de código cubierto por pruebas
7. Entre otros

Como mencionó David, a esto se lo pegan a CI server (como http://cruisecontrolrb.thoughtworks.com/ ) y están listo para el camino a mejor código!

Saludos!

2010/9/8 agilenature <alfaro...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "cragile" group.
To post to this group, send email to cra...@googlegroups.com.
To unsubscribe from this group, send email to cragile+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cragile?hl=en.

[agilenature]

Buenísimo Franz!

Acá otra combinación para Java, también Open Source:

Maven (http://maven.apache.org/) para hacer el build.
Hudson (http://hudson-ci.org/) para el servidor de Continuous
Integration
Sonar (http://www.sonarsource.org/) para el análisis de calidad de
código (Complejidad Ciclomática por ejemplo)

Bienvenidas sean otras combinaciones!!!

On Sep 8, 8:15 pm, Franz Pereira <franzpere...@gmail.com> wrote:
> Sobre el tema de complejidad ciclomática:
>
> Para los que estén trabajando en Ruby y/o Rails hay una herramienta muy
> buena llamada metric_fu.
>
> http://metric-fu.rubyforge.org/
>
> Da reportes (en gráficos) de:
>

>    1. Complejidad ciclómatica
>    2. Code smells
>    3. Duplicaciones de código
>    4. Churns
>    5. Problemas de diseño
>    6. Porcentaje de código cubierto por pruebas
>    7. Entre otros
>
> Como mencionó David, a esto se lo pegan a CI server (comohttp://cruisecontrolrb.thoughtworks.com/) y están listo para el camino a
> mejor código!
>
> Saludos!
>
> 2010/9/8 agilenature <alfaro.da...@gmail.com>

>
> > Quiero pasarles un truco muy rápido que uso para rapidamente darme una
> > idea de cuán "cochino" es un código legado, en cualquier lenguaje de
> > programación. Sirve en cualquier lenguaje porque está basado en el
> > número de circuitos linearmente interdependientes en el grafo de
> > control de un módulo.
>
> > Si encuentro consistentemente que hay métodos con una complejidad
> > ciclómática de más de 10, me preparo a enfrentar a un código que tiene
> > una deuda técnica muy alta (a veces tan alta que merece una
> > declaración de "banca rota") que requiere diferentes técnicas de
> > refactoring. Es como un smell de smells.
>
> > [Si tiene un proveedor de servicios de software que afirma hacer
> > desarrollo de software ágil, pidale los la complejidad ciclomática de
> > los proyectos de desarrollo que ha realizado, y de paso exija una
> > complejidad ciclomática de 10 o menos, si el proveedor no sabe qué es
> > CC, huya! ]
>
> > Una muy buena noticia es que se puede establecer un servidor de
> > continuous integration (ese que cuando alguien hace check-in, se
> > dispara el build automáticamente, se corren todos los Unit Tests, se
> > confirma que que los Unit Tests pasen y logren una cobertura de código
> > de al menos 95% [por ejemplo] y luego haga deployment) que permiten
> > chequeos de la complejidad ciclómática de los métodos agregados, de
> > manera que si por ejemplo se pasan de CC 10 entonces falle el build.
>
> > Referencias:

> > What's your/a good limit for cyclomatic complexity?http://bit.ly/dAmcjB

> > How to compute McCabe's Cyclomatic Complexity in Java methods
> >http://bit.ly/cvN1st
> > Structured Testing: A Testing Methodology Using the Cyclomatic

> > Complexity Metrichttp://www.mccabe.com/pdf/nist235r.pdf

>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "cragile" group.
> > To post to this group, send email to cra...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > cragile+u...@googlegroups.com<cragile%2Bunsu...@googlegroups.com>
> > .