Bucle Infinito

Me encanta programar "a la antigua usanza", con un editor dotado de pocas opciones más que un Notepad avanzado, sin librerías y creando todo el código desde 0; es divertido, pero no eficiente. Hoy en día, en lenguajes modernos como .Net, tenemos unos entornos de desarrollo fantásticos ,como Visual Studio,  y la posibilidad de usar Plugins y herramientas que nos faciliten y automaticen gran parte del trabajo.

Uno de las prácticas que nos facilita todo esto, es la refactorización, este término se utiliza para describir la modificación del código fuente, de forma que no afectemos al funcionamiento. El objetivo es hacer más legible el código sin arriesgarnos a "cargarnos" nada (ni añadir funcionalidades que no existiesen anteriormente).

Hace poco me he tenido que enfrentar a un código C# bastante "denso", que me planteaba el reto de limpiarlo, por lo que pensé que una refactorización en profundidad era el camino a seguir antes de hacer nada. En el IDE de Visual Studio 2005 ya encontramos algunas opciones de refactorización, cosa que no existía en 2003, pero si queremos más opciones debemos acudir a complementos externos.

Tras indagar cuales podían ser las mejores herramientas me quedé con 2 posibilidades: DevExpress Refactor!, que era el que más me llamó la atención de entrada, y Jetbrains ReSharper(Este es un Add-in con muchas más posibilidades aparte de la refactorización).  Ambas de pago y no especialmente baratas, unos 99$ el primero y 170€ el segundo. No estoy en contra de comprar una licencia para una herramienta que me facilite mucho el trabajo… pero tengo que estar bastante convencido.

Una licencia de un mes de uso ha sido la culpable de que finalmente esté probando en profundidad ReSharper, aunque he de decir, que estoy encontrando más útiles el resto de sus opciones que las especificas de refactorización… creo que voy a tener que darle una oportunidad a Refactor!… e investigar un poco más antes de decidirme …

desarrollo, c#, .net

Me he llevado una agradable sorpresa, cuando me he enterado de que Scott Hanselman, uno de mis bloggers favoritos, ha co-escrito un libro sobre MVC, un tema que me gustaría estudiar en profundidad. Los otros autores del libro son Rob Conery, Phil Haack y el también bastante popular en la blogosfera Scott Guthrie(más conocido como  ScottGu)

MVC son las siglas de Modelo Vista controlador, Un patrón de arquitectura que separa los datos, la interfaz y la logica de control en componentes distintos. Este patrón no es nuevo,  ni mucho menos, pero sí lo es la implementación por parte de Microsoft para su plataforma .Net. En los últimos tiempos el MVC ha dado bastante de que hablar, en gran parte debido a su uso en aplicaciones web escritas en Ruby On Rails, y viene, a dar un poco de luz a las aplicaciones asp.net, que necesitan seguir unos patrones rígidos debido a su tendencia natural al caos… ¿o será tendencia de sus programadores?

De momento el libro esta entrando en Producción, lo que quiere decir que aunque aun no está publicado debe faltarle poco, para abrir boca han distribuido de forma gratuita el primer capitulo del libro(185 páginas) y la aplicación que construyen de ejemplo durante este. Los links para descargar el pdf se puede encontrar en cualquiera de sus blogs y la aplicación, llamada Nerd Dinner ,  junto con su código fuente, en codeplex.

Estoy deseando hincarle el diente…

desarrollo, libros, mvc

Los principios S.O.L.I.D. (SOLID principles) es un juego de palabras que contiene el acrónimo de un conjunto de "buenas practicas" para la programación orientada a objetos.

El autor que primero recopiló estos principios es el llamado "Tio Bob", su primer articulo sobre ellos tiene más de década y estaban pensados con C++ en mente, aun así hoy en día con los modernos Lenguajes y Frameworks que se usan en programación, nos podemos encontrar gran cantidad de código que mejoraría tremendamente aplicando solo parte de ellos, aunque no sean más que el sentido común aplicado a la POO.

A veces tenemos herramientas tan complejas que nos olvidamos de lo básico.

Estos principios son:

SRP – The Single Responsibility Principle (Principio de Responsabilidad Única)

"Una clase debería tener solo una razón para cambiar"

OCP – The Open/Closed Principle (Principio Abierto / Cerrado)

"Una clase debería poder ser extendida, sin ser modificada"

LSP – The Liskov Substitution Principle (Principio de Sustitución de Liskov)

"Clases derivadas deben ser sustituibles por sus clases bases"

ISP - Interface Segregation Principle (Principio de Segregación de Interfaces)

"Muchas interfaces muy especializadas son preferibles a una interfaz general en la que se agrupen todas las interfaces"

DIP – The Dependency Inversion Principle (Principio de Inversión de Dependencias)

"Las abstracciones no deben depender de los detalles, los detalles deben depender de las abstracciones"

En  próximos post profundizaré más sobre, la aplicación, las ventajas (y posibles inconvenientes) de cada uno de ellos, ya que no deben ser tomados como dogmas y en ciertos casos puede ser recomendable utilizar un enfoque diferente.

En la web del Uncle Joe podemos encontrar más detalles sobre estos principios(en inglés) de su puño y letra

solid, desarrollo, poo

Leyendo un post de Joel Spolsky sobre como lidiar con los bugs en nuestros desarrollos, me topé con el termino "bug database" o "Bug Tracking System", desde el momento que lo leí me resulto bastante interesante. Se trata de tener una aplicación para gestionar los bugs, saber que bugs tenemos actualmente, cuales han sido solucionados, asignar a alguien su resolución, guardar un registro de cara a futuro...

Navegando por la red he encontrado varias aplicaciones que se mueven en este sentido: Bugzilla, FogBuz (de la compañía del propio Joel), BugTrack, Bugaware... prácticamente todas basadas en una interfaz web, lo cual me parece absolutamente acertado y tras probar un par de ellas veo que son bastante similares en su planteamiento.

¿Cual es el problema con este tipo de software? El problema es que los resultados que obtengamos dependerá de como se use y de que se use.

• A veces nos encontraremos con un pequeño bug que pensamos que podemos resolver en un momento y que nos va a llevar más tiempo introducir en la aplicación que arreglarlo así que simplemente no lo introducimos, fallo
• Resolvemos el bug e introducimos una vaga descripción de la resolución por que nos resulta demasiado complicado explicarlo, fallo
• No detallamos los pasos para reproducir el error ya que nos parecen triviales o por el contrario son demasiado enrevesados, fallo

Y así mil ejemplos más, me llaman fuertemente la atención  este tipo de aplicaciones ya que soy de los que olvidan fácilmente las cosas, habituarse a mantener un riguroso control de bugs y mantenerlo  puede ser tedioso pero es una inversión de cara a futuro cuyos frutos recogeremos a no muy largo plazo.

Desarrollo desarrollo, bugs