03 marzo 2005

Herramientas imprescindibles reloaded

Ya publiqué hace tiempo un post del MSDN con las diez herramientas imprescindibles que todo programador serio de .NET debe tener instaladas (además del VS o de SharpDevelop, claro). El artículo ha sido renovado.

Editado.- Examinemos un poco más las herramientas en cuestión, que repasados los últimos artículos parezco autista, leñe.


  • NUnit.- El desarrollo orientado al testeo es una de las piedras angulares de uno de los paradigmas de programación que más adeptos está ganando, el Extreme Programming, o XP. Se puede o no estar de acuerdo con este enfoque, se puede convencer al jefazo de turno de la conveniencia de adoptar este paradigma (esto último puede ser algo más complicado); pero desde luego el ciclo vital constante de codificación, testeo, modificaciones y refactorización promete producir código mucho más compacto y robusto que el que se hacía hasta ahora. NUnit nos permite realizar testeos unitarios a nuestras clases .NET y desde luego es una herramienta imprescindible para los adeptos al XP,... entre los que tendré que incluirme poco a poco. Que un cambio de paradigma no es moco de pavo.

  • NDoc.- Mediante NDoc generaremos documentación HTML y CHM de nuestras clases. Es muy útil pero precisamente para eso, para generar documentación de las clases. Absolutamente inútil para generar ayuda al usuario final, claro.

  • NAnt.- Apenas lo he probado, pues para el tipo de soluciones que desarrollo por el momento no lo necesito. Mediante NAnte podremos automatizar el proceso de construcción de una solución mediante plantillas en XML.

  • CodeSmith.- Otro generador de código mediante plantillas. Personalmente, para generar código desde base de datos prefiero el D4Modelizer, pero CodeSmith tiene la ventaja de no estar limitado a un sólo lenguaje y de generar código en base a nuestras propias plantillas para cualquier tarea que podamos parametrizar, no sólo para clases de datos.

  • FxCop.- Aunque es un poco paranoico en el nivel de warnings que proporciona, una pasada de FxCop por nuestro EXE o DLL y nos daremos cuenta de un montón de cuellos de botella, malpractices y demás cosas que podemos arreglar. Nuestros programas funcionan, cómo no, pero siempre pueden funcionar mejor; y si tenemos el tiempo de hacer los cambios sugeridos por FxCop, debemos hacerlo. Altamente recomendado.

  • Snippet Compiler.- Una auténtica maravilla. El poder probar pequeños trozos de código sin tener que construir toda una solución de pruebas para ello vale su peso en oro.

  • Herramientas de cambio.- El artículo menciona el ASP .NET Version Switcher y el Visual Studio .NET Project Converter. Como de momento no trabajo en ASP .NET no he usado el primero. Para convertir proyectos desde la versión 2002 de VS utilizo el propio VS 2003 que nunca me ha dado ningún problema al respecto.

  • Regulator.- Las expresiones regulares, lejos de ser una panacea bajo la cual deba hacerse cualquier cosa si que son una herramienta extremadamente útil en nuestro código. Regulator es una buena herramienta para construir y probar expresiones regulares, pero personalmente prefiero Expresso. Por cierto, a los que os interese el tema echadle un vistazo a RegEx Library.

  • .NET Reflector.- Esta interesante herramienta de Lutz Roeder nos puede venir muy bien para examinar código de otros, incluyendo clases del mismísimo .NET framework. En esta misma página podéis encontrar otra herramienta muy interesante, el Resourcer, para manejar ficheros .resx.

2 Comments:

  • Pues luego me dirás, pero:

    · NUnit to write unit tests
    · NDoc to create code documentation
    · NAnt to build your solutions

    es calcadito del mundo java...
    :p

    By Anonymous Will, at 2:51 p. m.  

  • Evidentemente: os estamos quitando lo mejor que tenéis para quedárnoslo nosotros. :P

    Por suerte ni mencionan el NHibernate, que existe, pero no pienso tocar en la vida... bastante asco le tengo al Hibernate.

    Ya se ha mencionado por aquí que alguien dijo que C# era Java bien hecho, y estoy completamente de acuerdo con él, claro. Porque lo de java.sql.Date y java.util.Date no tiene nombre...

    By Blogger CodeCruncher, at 8:35 p. m.  

Publicar un comentario

<< Home