Contar Líneas de Código

Nasa Contar líneas de código fuente es una práctica que se viene realizando desde tiempos inmemoriales… vamos desde antes de 1970 más o menos. Por ejemplo, de acuerdo con el Centro Tecnológico de Calidad de Software (Software Assurance Technology Center – SATC) de la NASA:

“El tamaño es una de las formas más antiguas y comunes de medición de software. El tamaño de los módulos es en sí misma un indicador de calidad. El tamaño puede ser medido a través del total de líneas de código, contando todas las líneas; que no correspondan a comentarios y que no esté en blanco, disminuyendo las líneas totales, por el número de espacios en blanco y comentarios, y todas aquellas sentencias ejecutables que se definen por un delimitador dependiente del lenguaje de programación.”

Sin embargo, con el paso del tiempo y medida que nuestra disciplina evolucionaba y maduraba, se determinó que por sí sólo el número de líneas de código en un proyecto de software no es un indicador de la calidad del mismo, o la productividad del trabajo realizado por los desarrolladores, si se podría afirmar que es una métrica confiable del tamaño real del proyecto. Habitualmente es una métrica que combinamos con índices como la Complejidad Ciclomática o el número de clases.

En el mundo de Visual Studio contamos con una funcionalidad denominada Code Metrics la cual nos muestra una serie de estadísticas muy útiles sobre nuestra solución y sus proyectos. Entre estas métricas está la cuenta de líneas de código.

Metrics

Ahora, esta cuenta no es exactamente todas las líneas de código de nuestra solución (o proyecto), sino una cuenta aproximada basada en el código IL generado por la compilación (vamos, más o menos lo que hace la NASA). Éste índice como tal es bastante útil en determinar si un método está haciendo más de lo que debe, pues aún cuando un método tenga cientos de líneas de código físico, la compilación puede hacer que el número de líneas sea radicalmente menos, y si el mismo no baja, puede indicar una pobre o inapropiada mantenibilidad del método.

Cuando necesito conocer las líneas reales de código fuente, su tipo (código, comentario o línea en blanco) y su distribución (SQL, XML, ASP.NET o C#) empleo y recomiendo un pequeño programa llamado CLOC, el cual no requiere instalacieon, es súper fácil de usar y soporta cientos de tecnologías y lenguajes de programación, incluyendo C#, ASP.NET, VB.NET y muchos más.

Count

Entre sus características básicas, me es muy útil que es capaz de reconocer el número de líneas blancas dentro de código, y aquellas que se corresponden a texto de documentación y comentarios, con lo cual se puede obtener métricas, ahora si de la calidad del código, sobre cuanto documentado este puede estar. Por ejemplo, imaginen un código fuente sin ninguna documentación. A través de una aplicación como CLOC podríamos determinar esto y así levantar la correspondiente incidencia.

Otras característica interesante es que se puede obtener un reporte de líneas de código por archivo o por lenguaje.

El reporte puede exportarse a un archivo separado por comas, a XML e incluso en sentencias de SQL que pueden ser útiles para inyectar en una base de datos de reportes de estado y salud del proyecto.

Profesionalmente, al realizar auditorias técnicas complemento el resultado del Code Metrics del Visual Studio con los resultados de CLOC. De esa forma puedo ofrecer una fotografía completa de la mantenibilidad del código versus cuanto está escrito, cuanto es espacio vacío y que tanta documentación podríamos encontrar.

Tautología III

Tautologia III

Tu trabajo no es importante.

Importante es el trabajo de los demás.

Si lo piensas, y todos actúaran de esta forma, te darías cuenta entonces que los demás considerarán tu trabajo importante.

Programador Ninja o Programador Zen

Hoy día las empresas se han vuelto adictas a implementar una u otra forma de “desarrollo ágil” de software, que en la gran mayoría de las veces termina convirtiéndose o traduciéndose en una forma degenerada y poco saludable de proceso de “construye-y-despliega”.

Esta deformación de los procesos ágiles de desarrollo de software en las empresas ha hecho que muchos desarrolladores de alta profesionalidad hayan adquirido características más propias de guerreros míticos.

Y de todos los guerreros, no se les ocurrió ninguno mejor que el Ninja. ¿Pero qué es exactamente un programador Ninja?

El Programador Ninja

Ninja Básicamente son programadores con un nivel de experiencia y una pasión efervescente, siempre encendida por nuestra disciplina. No sólo son ágiles, sino también disciplinados y centrados en su trabajo.

Paradójicamente, una de las primeras características que resalta en un programador Ninja no es su agilidad, disciplina o conocimientos, sino su confianza en sus habilidades y el resultado de su trabajo. No sueles escuchar que digan “Yo se hacer esto o lo otro…” sino más bien “Yo puedo hacerlo y se como lograrlo…”

Los programadores Ninja tienen movimientos secretos, fuentes Open Source y oscuros blogs con conocimientos prohibidos que utilizan para llevar con éxito su tarea. Y por ello parte de las características propias de un programador Ninja es que está constantemente buscando fuentes de información, el programador Ninja sabe como ser un buen estudiante.

El conocimiento de los programadores Ninja no sólo reside en los aspectos técnicos que dominan, sino también en las particularidades de sus enemigos (los requisitos con tiempos de entrega muy estrechos) y sus aliados (los clientes y usuarios). Los programadores Ninja saben como romper con los requisitos para satisfacer a sus clientes.

Los programadores Ninja participan activamente en dojos de programación y en hackatomes de todo tipo. Sin embargo son cerrados y sólo interactúan con reducidos grupos sociales, tanto en las oficinas como en los eventos.

Sin embargo, los programadores Ninja (contrario a lo que ellos mismos puedan pensar) no están orientados a la calidad, al detalle fino o a los acabados pulidos. Una organización sólo puede esperar del programador Ninja que entregue un producto con calidades good enough en el corto tiempo que se tiene para obtenerlo. Ahora, no se mal interprete, el producto de software entregado no tendrá errores ni defectos, pero será un FIAT comparado a un FERRARI. Por ejemplo, es muy común ver código de programador Ninja con ninguna documentación o arquitectura de software definida.

Por otro lado, aunque los programadores Ninja son muy buenos estudiantes, son pésimos profesores. No tienen dotes pedagógicas, carecen de los soft skills que les permiten convencer a otros de que lo que hacen es lo mejor, o simplemente no desean comunicar sus secretos.

Y entonces… ¿son los programadores Ninja la única alternativa en una organización?

Introduciendo al Programador Zen

zenEl programador Zen comparte algunas características con el programador Ninja, pero su principal diferencia es que, aunque son ágiles, no están orientados a entregar software de forma rápida. Se toman su tiempo, meditan y vuelven a meditar antes de tomar alguna acción.

El programador Zen sólo sabe y sólo domina la tecnología base a la cual está orientado, es su dogma y su filosofía; la base de su ciencia y religión que es la programación. Y difícilmente se moverá de esta tecnología. Mientras un programador Ninja no tiene problemas en pasarse de .NET a Java a Rails a PHP… el programador Zen permanecerá inalterable fiel a la tecnología que a elegido para si.

Mientras el programador Ninja lo sabe todo, el programador Zen no sabe nada. Su mente está vacía, con lo cual cada nuevo reto y cada nuevo proyecto es un lienzo blanco sobre el cual diseñar el mandala de su solución de software. El programador Zen no tiene el conocimiento, pero si la sabiduría para encontrarlo y reconocer dicha solución dentro del kōan de los requerimientos.

Para el programador Zen, los requerimientos no son enemigos, y los usuarios no son aliados; ambos son elementos del camino como las piedras sobre el suelo o las flores a los lados. No los dividen ni los categorizan, simplemente los aprecian como parte de su meditación.

Un programador Zen es un excelente estudiante, y aun más un excelente maestro. Siempre esta dispuesto a compartir lo que sabe para vaciarse y así llenarse de nuevas experiencias y de nuevas tecnologías. Busca constantemente que otros sepan lo que él o ella saben para poder dedicarse a cultivar nuevos frutos.

Finalemente, debido a que no están motivados a entregar de forma acelerada el producto de software, están muy orientados a la calidad y a la belleza del mismo. Su software está exquisitamente documentado, diseñado e integrado a un todo. Y ese es su secreto… no vuelven a hacer una cosa dos veces porque no tiene sentido, con lo cual al presentar productos apropiadamente arquitecturados, integrados y construidos son capaces de crear cosas nuevas sobre éstos reduciendo tiempos (sobre todo si hay que cambiar funcionalidades) y esfuerzos.

Pero entonces… ¿qué es mejor, Ninja o Zen?

Ni lo uno ni lo otro. Ambos son necesarios. El Ninja puede sacar de un aprieto a su señor feudal, pero el Zen es el que al final le dará la paz y la sabiduría para el éxito.

Quizás algún día veamos el punto intermedio, el Ninja que abraza el Zen, o el Zen que despierta para actuar como el Ninja. Quizás se escriba el bushido de la programación, y empecemos a hablar de programadores Samurai.

Humor: Técnica Infalible para la Estimación de Proyectos

Nada es más difícil en la disciplina de la Ingeniería de Software que realizar una estimación apropiada (y lo más precisa posible) de los requerimientos para su diseño y eventual desarrollo (incluyendo pruebas por supuesto).

Pero en estos días, Daniel Cialdella (@dcialdella) me mostró su mejor metodología. Tras probarla un tiempo he encontrado que es simplemente la mejor.

Les dejo una imágen de como aplicarla efectivamente: