Mostrando entradas con la etiqueta buenas prácticas. Mostrar todas las entradas
Mostrando entradas con la etiqueta buenas prácticas. Mostrar todas las entradas
domingo, abril 06, 2008
Semanas atrás publicaba el post "101 citas célebres del mundo de la informática", la traducción del post original de Timm Martin en Devtopics, "101 Great computer quotes". El tema me pareció tan divertivo e interesante que he realizado una nueva recopilación de otras tantas frases relacionadas con el mundo de la informática, y con especial énfasis en el desarrollo de software.
Informática
1. "No temo a los ordenadores; lo que temo es quedarme sin ellos"-- Isaac Asimov
2. "Una vez un ordenador me venció jugando al ajedrez, pero no me opuso resistencia cuando pasamos al kick boxing"
-- Emo Philips
3. "La informática tiene que ver con los ordenadores lo mismo que la astronomía con los telescopios"
-- Edsger W. Dijkstra
4. "El ordenador nació para resolver problemas que antes no existían"
-- Bill Gates
5. "El software es como la entropía: difícil de atrapar, no pesa, y cumple la Segunda Ley de la Termodinámica, es decir, tiende a incrementarse"
-- Norman Augustine
6. "El software es un gas: se expande hasta llenar su contenedor"
-- Nathan Myhrvold
7. "Todas las piezas deben unirse sin ser forzadas. Debe recordar que los componentes que está reensamblando fueron desmontados por usted, por lo que si no puede unirlos debe existir una razón. Pero sobre todo, no use un martillo"
-- Manual de mantenimiento de IBM, año 1925
8. "Los estándares son siempre obsoletos. Eso es lo que los hace estándares"
-- Alan Bennett
9. "La física es el sistema operativo del Universo"
-- Steven R Garman
10. "El hardware es lo que hace a una máquina rápida; el software es lo que hace que una máquina rápida se vuelva lenta"
-- Craig Bruce
Conocimiento
11. "La imaginación es más importante que el conocimiento. El conocimiento es limitado, mientras que la imaginación no"-- Albert Einstein
12. "El mayor enemigo del conocimiento no es la ignorancia, sino la ilusión del conocimiento"
-- Stephen Hawking
13. "Cuanto más sabes, más te das cuenta de que no sabes nada"
-- Sócrates
14. "Dime y lo olvido, enséñame y lo recuerdo, involúcrame y lo aprendo"
-- Benjamín Franklin
15. "El auténtico conocimiento es conocer la extensión de la propia ignorancia"
-- Confucio
16. "Si la gente no hiciera cosas estúpidas, nunca se podría haber hecho nada inteligente"
-- Ludwig Wittgenstein
17. "Obtener información de internet es como intentar beber agua de una boca de incendios"
-- Mitchell Kapor
Usuarios
18. "Si piensas que los usuarios de tus programas son idiotas, sólo los idiotas usarán tus programas"-- Linus Torvalds
19. "Desde el punto de vista de un programador, el usuario no es más que un periférico que teclea cuando se le envía una petición de lectura"
-- P. Williams
20. "¿Dónde está la tecla 'ANY'?"
-- Homer Simpson, frente a un mensaje "press any key"
21. "Los ordenadores son buenos siguiendo instrucciones, no leyendo tu mente"
-- Donald Knuth
22. "Sólo hay un problema con el sentido común: que no es demasiado común"
-- Milt Bryce
23. "Tus clientes más descontentos son tu mayor fuente de aprendizaje"
-- Bill Gates
24. "Tenemos que cambiar la tradicional actitud ante la construcción de software. En vez de pensar que nuestra principal tarea es indicar a un ordenador qué hacer, concentrémonos en explicar a las personas lo que queremos que el ordenador haga"
-- Donald E. Knuth
Internet
25. "¿Internet? No estamos interesados en eso"-- Bill Gates
26. "La mejor forma de obtener información correcta de los foros de Usenet es enviar algo incorrecto y esperar las correcciones"
-- Matthew Austern
Profesionales
27. "La mayoría de expertos está de acuerdo en que la causa más probable de destrucción del mundo sería por accidente; y aquí es donde entramos nosotros: somos profesionales de la informática, causamos accidentes"-- Nathaniel Borenstein
28. "Dicen que los pesimistas ven el vaso medio vacío; los optimistas, en cambio, lo ven medio lleno. Los ingenieros, por supuesto, ven que el vaso es el doble de grande de lo que sería necesario"
-- Bob Lewis
29. "Si en una sala llena de diseñadores de software dos de ellos están de acuerdo, eso es una mayoría"
-- Bill Curtis
30. "Es importante destacar que ningún ingeniero software con ética consentiría escribir un procedimiento llamado DestruirBaghdad. Su ética le obligaría a escribir un procedimiento DestruirCiudad, al que se pasaría el parámetro Baghdad"
-- Nathaniel S. Borenstein
31. "Una de las cosas más fascinantes de los programadores es que no puedes saber si están trabajando o no sólo con mirarlos. A menudo están sentados aparentemente tomando café, chismorreando o mirando a las nubes. Sin embargo, es posible que estén poniendo en orden todas las ideas individuales y sin relación que pululan por su mente"
-- Charles M. Strauss
32. "Si piensas que vales lo que sabes, estás muy equivocado. Tus conocimientos de hoy no tienen mucho valor más allá de un par de años. Lo que vales es lo que puedes llegar a aprender, la facilidad con la que te adaptas a los cambios que esta profesión nos regala tan frecuentemente"
-- José M. Aguilar, en cómo tu blog te ayuda a encontrar empleo
Programación
33. "Los programas deben ser escritos para que los lean las personas, y sólo incidentalmente, para que lo ejecuten las máquinas"-- Abelson and Sussman
34. "Comentar el código es como limpiar el cuarto de baño; nadie quiere hacerlo, pero el resultado es siempre una experiencia más agradable para uno mismo y sus invitados"
-- Ryan Campbell
35. "Tenemos que dejar de optimizar para programadores y comenzar a optimizar para usuarios"
-- Jeff Atwood
36. "La programación en bajo nivel es buena para el alma del programador"
-- John Carmack
37. "Está bien investigar y resolver misteriosos asesinatos, pero no deberías necesitar hacerlo con el código. Simplemente deberías poder leerlo"
-- Steve McConnell
38. "Si queremos contar líneas de código, no deberíamos referirnos a ellas como líneas producidas, sino como líneas consumidas"
-- Edsger Dijkstra
39. "La programación puede ser divertida, al igual que la criptografía; sin embargo, ambas no deberían combinarse"
-- Kreitzberg and Shneiderman
40. "Antes de que un software sea reutilizable debería ser utilizable"
-- Ralph Johnson
41. "Si automatizas un procedimiento desastroso, obtienes un procedimiento desastroso automatizado"
-- Rod Michael
42. "Ley de Alzheimer de la programación: si lees un código que escribiste hace más de dos semanas es como si lo vieras por primera vez"
-- Via Dan Hurvitz
43. "Es más fácil cambiar las especificaciones para que encajen con el software que hacerlo al revés"
-- Alan Perlis
44. "Menos del 10% del código tienen que ver directamente con el propósito del sistema; el resto tiene que ver con la entrada y salida, validación de datos, mantenimiento de estructuras de datos y otras labores domésticas"
-- Mary Shaw
45. "Si tienes una función o procedimiento con diez parámetros, probablemente hayas olvidado uno"
-- Alan Perlis
46. "Es raro que mantener el código de otro desarrollador sea como entrar en un edificio de gran diseño que admiras mientras paseas por él y planeas cómo añadirle un ala o algún elemento decorativo. Lo más frecuente es que sea como tirarse de cabeza a un gran montón de basura maloliente"
-- Bill Venners
47. "La generación de código, como beber alcohol, es bueno si se hace con moderación"
-- Alex Lowe
Desarrollo
48. "La simplicidad llevada al extremo se convierte en elegancia"-- Jon Franklin
49. "Un programa nunca está completo por debajo del 90% ni por encima del 95%"
-- Terry Baker
50. "Cuando estás en un atasco de tráfico con un Porsche, todo lo que puedes hacer es consumir más combustible que el resto estando parado. La escalabilidad va de construir carreteras más anchas, no coches más rápidos"
-- Steve Swartz
51. "Todo el mundo sabe el peligro de la optimización prematura. Pienso que deberíamos estar igualmente preocupados con el diseño prematuro, es decir, el hecho de diseñar demasiado pronto lo que un programa debería hacer"
-- Paul Graham
52. "Programar sin una arquitectura o diseño en mente es como explorar una gruta sólo con una linterna: no sabes dónde estás, dónde has estado ni hacia dónde vas"
-- Danny Thorpe
53. "La mejor forma de predecir el futuro es implementarlo"
-- David Heinemeier Hansson
54. "Lo realmente necesario es saberlo todo sobre los cambios en la información. Nadie quiere o necesita que le recuerden 16 horas al día que tiene sus zapatos puestos"
-- David Hubel
55. "En dos ocasiones me han preguntado: 'si pone datos incorrectos en la máquina, ¿saldrán las respuestas correctas?'. Soy absolutamente incapaz de hacerme una idea del tipo de confusión de ideas que pueden provocar que alguien haga una pregunta así"
-- Charles Babbage
56. "Hazlo todo tan simple como sea posible, pero no más simple"
-- Albert Einstein
57. "Hoy en día la mayoría del software existe no para resolver un problema, sino para actuar de interfaz con otro software"
-- I. O. Angell
58. "Unas buenas especificaciones incrementará la productividad del programador mucho más de lo que puede hacerlo cualquier herramienta o técnica"
-- Milt Bryce
59. "La diferencia entre la teoría y la práctica es que, en teoría, no hay diferencia entre la teoría y la práctica"
-- Richard Moore, desarrollador de KDE
Errores y depuración
60. "No documentes el problema; arréglalo"-- Atli Björgvin Oddsson
61. "Por norma, los sistemas software no funcionan bien hasta que han sido utilizados y han fallado repetidamente en entornos reales"
-- Dave Parnas
62. "Si el código y los comentarios no coinciden, posiblemente ambos sean erróneos"
-- Norm Schryer
63. "Creo que es una nueva característica. No le cuentes a nadie que fue un accidente"
-- Larry Wall
64. "Si no las capturas y procesas, cerramos tu aplicación. Esto incrementa enormemente la fiabilidad de tu sistema"
-- Anders Hejlsberg, sobre las excepciones en .Net
65. "Cuando se está depurando, el programador novato introduce código correctivo; el experto elimina el código defectuoso"
-- Richard Pattis
66. "En un proyecto software con diez personas, probablemente tres de ellas introducen tantos errores que podríamos considerar su productividad como negativa"
-- Gordon Schulmeyer
67. "Es inevitable que la gente programe mal, y la formación no mejorará sustancialmente las cosas. Tenemos que aprender a vivir con ello"
-- Alan Perlis
68. "El testing de componentes puede ser muy efectivo para mostrar la presencia de errores, pero absolutamente inadecuado para demostrar su ausencia"
-- Edsger Dijkstra
Lenguajes y tecnologías
69. "La gestión manual de bloques de memoria en C es como hacer malabarismos con pastillas de jabón en la ducha de la prisión: todo diversión hasta que cometes un fallo"-- Un usuario anónimo de un foro Usenet
70. "No pueden existir concursos de Perl ofuscado; no tendría sentido"
-- Jeff Polk (Nota: ¡sí que los hay!)
71. "Java es lo más penoso que le ha ocurrido a la informática desde MS-DOS"
-- Alan Kay
72. "Sólo hay dos cosas malas en C++: el concepto inicial y la implementación"
-- Bertrand Meyer
73. "Era una broma, ¿vale? Si hubiéramos pensado que iba a usarse no la habríamos escrito"
-- Mark Andreesen, hablando de la etiqueta BLINK de HTML
74. "Los Servicios Web son como el sexo entre los adolescentes. Todos hablan de hacerlo, pero aquellos que realmente lo hacen, lo hacen muy mal"
-- Michelle Bustamante
75. "Perl: el único lenguaje cuyo código es prácticamente igual antes y después de someterlo a una encriptación RSA"
-- Keith Bostic
76. "No trabajé duro para hacer Ruby perfecto para todo el mundo, porque todos somos diferentes. Intenté hacer Ruby perfecto para mí, así que puede que a tí no te lo parezca; probablemente, el mejor lenguaje para Guido van Rossum es Python"
-- Yukihiro Matsumoto, aka "Matz", creador de Ruby
77. "XML no es más lenguaje de programación que unas notas sobre una servilleta de papel"
-- Charles Simonyi
78. "BASIC es a la programación lo que QWERTY a la mecanografía"
-- Seymour Papert
79. "Se ha descubierto que C++ dispone de una gran facilidad para ocultar los detalles triviales de un programa... así como dónde están sus bugs"
-- David Keppel
80. "UNIX es simple. Sólo necesita un genio para entender su simplicidad"
-- Dennis Ritchie
81. "Algunos desarrolladores cuando se enfrentan a un problema piensan que la solución es usar expresiones regulares. En este momento, ya tienen dos problemas"
-- Jamie Zawinski
Seguridad
82. "Pienso que los virus informáticos muestran la naturaleza humana: la única forma de vida que hemos creado hasta el momento es puramente destructiva"-- Stephen Hawking
83. "El único sistema seguro es aquél que está apagado en el interior de un bloque de hormigón protegido en una habitación sellada rodeada por guardias armados"
-- Gene Spafford
84. "Saber romper medidas de seguridad no hacen que seas hacker, al igual que saber hacer un puente en un coche no te convierte en un ingeniero de automoción"
-- Eric Raymond
85. "Las organizaciones gastan millones de dólares en firewalls y dispositivos de seguridad, pero tiran el dinero porque ninguna de estas medidas cubre el eslabón más débil de la cadena de seguridad: la gente que usa y administra los ordenadores"
-- Kevin Mitnick
86. "Si piensas que la tecnología puede solucionar tus problemas de seguridad, está claro que ni entiendes los problemas ni entiendes la tecnología"
-- Bruce Schneier
87. "Los bulos (hoaxes) que circulan por internet usan la debilidad del ser humano para asegurar su replicación y distribución. En otras palabras, utilizan los resquicios del Sistema Operativo Humano"
-- Stewart Kirkpatrick
88. "Las contraseñas son como la ropa interor. No puedes dejar que nadie la vea, debes cambiarla regularmente y no debes compartirla con extraños"
-- Chris Pirillo
Empresa
89. "En realidad no trato de destruir a Microsoft: eso será sólo un efecto colateral no intencionado"-- Linus Torvalds
90. "Sí, tenemos unas reglas de vestuario en la empresa. Tienes que vestirte"
-- Scott McNealy, co-fundador de Sun Microsystems
91. "En el mundo del software, los activos más importantes de la compañía se van a casa todas las noches. Si no se les trata bien, pueden no volver al día siguiente"
-- Peter Chang
92. "Es mejor esperar a que un desarrollador productivo esté disponible que esperar a que el primer desarrollador disponible sea productivo"
-- Steve C McConnell
93. "No soy de los que piensan que Bill Gates es el diablo. Simplemente sospecho que si Microsoft alguna vez se encontrara con el diablo, no necesitarían un intérprete"
-- Nicholas Petreley
Predicciones
94. “En dos años el problema del spam se habrá resuelto”-- Bill Gates, 2004
95. "El problema de los virus es pasajero. En un par de años estará resuelto"
-- John McAfee, 1988
96. “Los virus informáticos son una leyenda urbana”
-- Peter Norton, 1988
97. "En 2031, los abogados serán componentes habituales de la mayoría de los equipos de desarrollo"
-- Grady Booch
98. “No sé cómo será el lenguaje del año 2000, pero sé que se llamará Fortran”
-- C. A. Hoare, 1982
99. "En el futuro es posible que los ordenadores no pesen más de 1,5 toneladas"
-- Popular mechanics, 1949
100. “Veo poco potencial comercial en Internet, al menos durante diez años”
-- Bill Gates, 1994
101. "Antes de que el hombre alcance la luna, el correo será enviado en unas horas desde Nueva York a California, Inglaterra, India o Australia con misiles guiados. Estamos en la era del misil-correo"
-- Arthur Summerfield, 1959, Correos de los Estados Unidos
Más citas en: 101 citas célebres del mundo de la informática
Publicado originalmente en: http://www.variablenotfound.com.
miércoles, febrero 27, 2008
Sabemos que los patrones son plantillas reutilizables que podemos usar para solucionar problemas habituales en el proceso de desarrollo de software. Así, permiten utilizar soluciones fiables y bien conocidas a problemas concretos, aprovechando experiencias previas como base para la consecución de mejores resultados en los nuevos desarrollos.
Pues bien, justo en el lado opuesto se encuentran los antipatrones, que definen situaciones y comportamientos que, según experiencias anteriores, nos conducen al fracaso en proyectos de desarrollo de software, es decir, son soluciones o planteamientos que se han demostrado incorrectos.
Y es ahí donde radica su interés: la observación y conocimiento de los mismos puede evitarnos resultados desastrosos, o actuar como alertas tempranas ante decisiones o dinámicas incorrectas, permitiéndonos prevenir, evitar o recuperarnos de estos problemas.
Al igual que en los patrones, su descripción está relativamente formalizada y suele recoger los siguientes aspectos:
- nombre del antipatrón, así como su "alias"
- su tipología: organizacional, de análisis, desarrollo... (veremos esto más tarde)
- contexto y entorno en el que se aplica
- descripción del problema concreto
- síntomas, y consecuencias de la aplicación del antipatrón
- causas típicas y raíces del problema
- refactorización a aplicar, es decir, una descripción de cómo podríamos replantear el problema y conseguir una solución positiva.
- ejemplos y escenarios para su comprensión.
- soluciones relacionadas con la propuesta.
Por ejemplo, un resumen del clásico antipatrón que reconoceréis muy rápidamente, el llamado spaghetti code:
| Nombre: | Spaghetti Code |
| Tipología: | Desarrollo |
| Problema: | Existencia de una pieza de código compleja y sin apenas estructura que dificulta enormemente su mantenimiento posterior |
| Síntomas y consecuencias: |
|
| Causas: |
|
| Solución positiva: |
|
Según según la Wikipedia, los antipatrones se clasifican en los siguientes grupos, atendiendo a las áreas a las que afectan:
- Antipatrones Organizacionales, que incluyen prácticas nocivas a este nivel, como pueden ser, entre otros:
- Gestión de champiñones (Mushroom management), o mantener al equipo en la oscuridad, desinformado, y cubierto de porquería.
- Parálisis en análisis (Analysis paralysis), o quedar inmovilizado debido a un análisis o precaución excesiva, en contraposición a la siguiente:
- Extinción por intuición (Extint by instinct), llegar a la muerte por adelantarse demasiado y usar la intuición para la toma de decisiones.
- Antipatrones de Gestión de proyectos, describiendo problemas en la gestión de proyectos, como los célebres:
- Marcha de la muerte (Death march), que describe el avance de determinados proyectos hacia el fracaso aunque todo el personal, excepto los gerentes, saben que al final se darán el castañazo.
- Humo y espejos (Smoke and mirrors), o la demostración de funcionalidades o características no implementadas como si fueran reales, lo que siempre he llamado "enseñar cartón piedra".
- Antipatrones de Gestión de equipos, que recoge problemas relacionados con la relación con y de equipos de trabajo, como:
- Doble diabólico (traducción libre del término Doppelganger), personas que dependiendo del día pueden ser magníficos colaboradores o auténticos demonios.
- Gestor ausente (Absentee manager), describiendo situaciones en las que el director está invisible periodos prolongados
- Antipatrones de Análisis, categoría que engloba antipatrones relacionados con la fase analítica de los proyectos software, entre otros:
- Retroespecificación (Retro-specification), o lo que viene a ser la realización del análisis una vez implementada la solución.
- Especificación de servilleta (Napkin specification), también muy socorrida, que consiste en pasar al equipo de desarrollo las especificaciones del producto a crear descritas con muy poco detalle o informalmente.
- Antipatrones de Diseño, que incluye malas prácticas de diseño de software que dan lugar a aplicaciones y componentes estructuralmente incorrectos:
- Gran bola de lodo (Big ball of mud), realización de aplicaciones sin estructura reconocible.
- Factoría de gas (Gas factory), diseños innecesariamente complejos.
- Botón mágico (Magic Pushbutton), o implementación de funcionalidades directamente en los manejadores de evento (p.e., click) del interfaz.
- Antipatrones en Orientación a objetos, como una especialización del anterior, describe problemas frecuentes en los diseños creados bajo este paradigma, como:
- Llamar al super (Call super), obligar a las subclases a llamar a la clase de la que heredan.
- Singletonitis, abuso del patrón singleton.
- Orgía de objetos (Object orgy), o encapsulación incorrecta en clases que permite el acceso incontrolado a sus métodos y propiedades internas.
- Otra jodida capa más (YAFL, Yet another fucking layer), o la inclusión excesiva de capas en un sistema.
- Antipatrones de Programación, con un gran número de errores frecuentes a evitar, como:
- Spaghetti code, comentando anteriormente.
- Ravioli code, que consiste en la existencia de un gran número de objetos desconectados o débilmente acoplados entre sí.
- Ocultación de errores (Error hiding), o capturar errores antes de que lleguen usuario, mostrando mensajes incomprensibles o simplemente no mostrar nada.
- Números mágicos (Magic numbers), incluir números inexplicables en el código.
- Antipatrones Metodológicos, o formas de desarrollar que se han demostrado incorrectas a lo largo del tiempo, como pueden ser:
- Programación copy & paste, también llamada herencia de editor, consiste en copiar, pegar y modificar, en contraposición a la estritura de software reutilizable.
- Factor de improbabilidad (Improbability factor), asumir que un error conocido es improbable que ocurra.
- Optimización prematura (Premature optimization), según algunos la raíz de todos los males, consiste en sacrificar el buen diseño y mantebilidad de un software en benecificio de la eficiencia.
- Programación por permutación (Programming by permutation), o intentar dar con una solución modificando sucesivamente el código para ver si funciona.
- Antipatrones de Gestión de configuración, hace referencia a antipatrones relacionados con la gestión de los entornos de desarrollo y explotación del software, como las variantes del infierno de las dependencias (Dependency hell), o problemas de versionado de librerías y componentes:
- DLL's Hell, el conocido y traumático mundo de las librerías dinámicas en Windows.
- JAR's Hell, idem, pero relativo a las librerías Java.
Por no hacer el post eterno sólo he recogido unos cuantos, aunque existen cientos de ellos, y con una gran variedad temática: antipatrones para el desarrollo guiado por pruebas (TDD), antipatrones de manejo de excepciones, para el uso de arquitecturas orientadas al servicio (SOA), de rendimiento, de seguridad, centrados en tecnologías (p.e., J2EE antipatterns) o según el tipo de software (sistemas de gestión, tiempo real, videojuegos, etc.).
Y como conclusión personal, decir que me he visto reconocido en multitud de ellos, lo cual significa que muy descaminados no andan. Es más, si hiciera una lista con patrones y otra con los antipatrones que utilizo o he utilizado, la segunda tendría más elementos que la primera... ¿quizás es momento de reflexionar un poco?
Publicado en: http://www.variablenotfound.com/.
domingo, febrero 10, 2008
Existen muchos consejos para crear código mantenible, como los que ya cité cuando hablaba sobre comentar el código fuente, pero ninguno iguala a este:
"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live"
(Codifica siempre como si la persona que fuera a mantener tu código fuera un asesino en serie maníaco que sabe donde vives)
Al parecer se trata de un leyenda urbana sobre Visual C++ 6.0, pero no deja de tener su razón...
Imagen: My Confined Space
Publicado en: http://www.variablenotfound.com/.
domingo, enero 20, 2008
FxCop es una herramienta que nos ayuda a mejorar la calidad de nuestras aplicaciones y librerías desarrolladas en cualquier versión de .Net, analizando de forma automática nuestros ensamblados desde distintas perspectivas y sugiriéndonos mejoras cuando detecta algún problema o incumplimiento de las pautas de diseño para desarrolladores de librerías para .Net Framework (Design Guidelines for Class Library Developers).
La versión actual (1.35) se puede descargar desde esta dirección, aunque ya existe una beta de la v1.36 en la web de Microsoft. Todos los comentarios que siguen se refieren a esta última versión, la 1.36 (beta), osado que es uno ;-), pero la mayor parte son válidos para la última revisión estable, la 1.35.
Una vez instalado tendremos a nuestra disposición dos aplicaciones: FxCop, que facilita el análisis y consulta de resultados a través de su propia GUI, y FxCopCmd, ideada para su utilización desde línea de comandos e integrarlo en otros sistemas, como Visual Studio, como parte del proceso de construcción (build) automatizado.
En cualquiera de los dos casos, el análisis de los ensamblados se realiza sometiéndolos a la comprobación de una serie de reglas basadas en buenas prácticas y consejos para asegurar la robustez y mantenibilidad de código. Del resultado del mismo obtendremos un informe con advertencias agrupadas en las siguientes categorías:
- Advertencias de diseño, recoge avisos de incumplimientos de buenas prácticas de diseño para .Net Framework, como pueden uso de constructores públicos en tipos abstractos, interfaces o namespaces vacíos, uso de parámetros out, capturas de excepciones genéricas y un largo etcétera.
- Advertencias de globalización, que avisan de problemas relacionados con la globalización de aplicaciones y librerías, como pueden ser el uso de aceleradores de teclado duplicados, inclusión de rutas a carpetas de sistema dependientes del idioma ("archivos de programa"), etc.
- Advertencias de interoperabilidad, que analizan problemas relativos al soporte de interacción con clientes COM, como el uso de tipos auto layout visibles a COM, utilización de
System.Int64en argumentos (que no pueden ser usados por clientes VB6), o la sobrecarga de métodos. - Advertencias de movilidad, cuestionando el soporte eficiente de características de ahorro de energía, como uso de procesos con prioridad
ProcessPriorityClass.Idle., o inclusión deTimersque se repitan más de una vez por segundo. - Advertencias de nombrado, que detectan las faltas de cumplimiento de las guías y prácticas recomendadas en cuanto al nombrado de elementos (clases, métodos, variables, etc.), como uso de nombres de parámetros que coinciden con nombres de tipo, y más con los propios de un lenguaje concreto, mayúsculas y minúsculas no utilizadas correctamente, eventos que comiencen por "Before" o "After", puesto que deben nombrarse conjugando verbos en función del momento que se producen (p.e., Closing y Closed en lugar de BeforeClose y AfterClose), y un largo conjunto de comprobaciones.
- Advertencias de rendimiento, que ayudan a detectar problemas en el rendimiento de la aplicación o librería, comprobando puntos como el número de variables locales usadas, la existencia de miembros privados o internos (a nivel de ensamblado) no usados, creación de cadenas (strings) innecesarias, por llamadas múltiples a
ToLower()oToUpper()sobre la misma instancia, realización de conversiones (castings) innecesarios, concatenaciones de cadenas en bucles, etc. - Advertencias de portabilidad, que recoge observaciones interesantes para la portabilidad a distintas plataformas, como el uso de declaraciones PInvoke.
- Advertencias de seguridad, que se centran en analizar aspectos que podrían dar lugar a aplicaciones o librerías inseguras, avisando de problemas potenciales como la ausencia de directivas de seguridad, punteros visibles, o uso de arrays de sólo lectura, entre otros.
- Advertencias de uso, que analizan el uso apropiado del framework .Net realizando multitud de chequeos sobre el código, detectando aspectos como ausencia la liberación (dispose) explícita de tipos
IDisposable, resultados de métodos no usados, uso incorrecto de NaN, etc.
(Puedes ver la lista completa de comprobaciones, en inglés, aquí)
Realizar un análisis de un ensamblado con FxCop resulta de lo más sencillo. Basta con crear un proyecto (al iniciar la aplicación aparecerá uno creado por defecto), añadir los ensamblados a analizar y pulsar el botón que iniciará el proceso.El tiempo dependerá del número y complejidad de los ensamblados a analizar, así como del conjunto de reglas (pestaña "rules") a aplicar, que por defecto serán todas. En cualquier caso, el proceso es rápido y finalizará con la presentación de una lista con el resumen de las anomalías detectadas, sobre la que podremos navegar y ampliar información.
Por cada anomalía, además, podremos acceder a una descripción completa de sus causas, origen en el código fuente, posibles soluciones, una URL para ampliar información, grado de certeza de existencia del problema, su gravedad y la categoría a la que pertenece. Con estos datos, sólo nos quedará acudir a nuestro código y corregir o mejorar los aspectos indicados.
En conclusión, se trata de una interesante herramienta que puede ayudarnos a mejorar la calidad del código que creamos. Aunque existen los "falsos positivos" y a veces no es todo lo precisa que debiera, la gran cantidad de comprobaciones que realiza, la posibilidad de añadir reglas personalizadas, así como el detalle de los informes de resultados hacen de ella una utilidad casi imprescindible para los desarrolladores .Net.
Publicado originalmente en: http://www.variablenotfound.com/.
martes, diciembre 11, 2007
He encontrado un post muy interesante sobre hábitos comunes en personas altamente innovadoras y creativas, extraídos del libro de Scott Berkun, "The myths of innovation", que me permito interpretar y recoger a continuación.
1. Trabajar duro
La innovación implica algo más que tener grandes ideas. Hay que tener fe, trabajar duro y luchar en contra de la marea para conseguir nuestros objetivos. Como dijo Thomas Alba Edison:"La invención es un 1% de inspiración y un 99% de transpiración"
2. Evitar inhibiciones
Estas inhibiciones nos hacen sentirnos limitados y bloqueados, necesitamos abrir la mente eliminando asunciones y restricciones, abrirnos a nuevas ideas y soluciones sin limitaciones mentales de ningún tipo. La innovación tiene más que ver con la psicología que con el intelecto.3. Asumir riesgos, cometer errores
El miedo al fracaso es uno de los causantes de que fabriquemos nuestras propias limitaciones. Está claro que algunas ideas fallarán durante el aprendizaje, por lo que es conveniente construir prototipos frecuentemente, probarlos, someterlos a discusión, usar el feedback y realizar cambios de forma incremental.En lugar de tratar los errores como fracasos, es conveniente pensar en ellos como experimentos. En palabras de Scott Berkun,
"Los experimentos son los errores previstos para aprender algo deliberadamente"Así, no debemos flagelarnos con los fallos, aceptémoslos y utilicemos la lección aprendida para encontrar nuevas y mejores soluciones. Los errores forman parte del camino hacia el éxito, positivémoslos; como decía Edison,
"No me he equivocado. Simplemente he encontrado 10.000 soluciones que no funcionaban"
4. Escapar
Cuando más relajados estamos internamente, más receptivos somos respecto a nuestra creatividad. Este es el motivo por el que frecuentemente tenemos grandes ideas en el cuarto de baño, en la cama o estando solos.Cada uno de nosotros contacta con "su lado más creativo" de una forma diferente, sólo es cuestión de averiguar cómo. Los hay que caminan, que hacen footing, otros escuchan música... ¿cuál es tu método?
5. Anotar las ideas
Muchos creativos y personas innovadoras tienen siempre a mano algo donde apuntar ideas y pensamientos: libretas, post-it, papel, o algo más tecnológico. Da igual el soporte, lo importante es disponer de una forma de capturar sus pensamientos, pensar sobre el papel, romper con las inhibiciones y comenzar el proceso creativo.El famoso manuscrito de Leonardo Da Vinci fue comprado por Bill Gates por más de 30 millones de dólares.
6. Encontrar patrones y combinarlos
Las ideas aparecen partiendo de otras ideas. Por ejemplo, Edison no fue el inventor de las bombillas, pero hizo que pudieran durar más tiempo creando un filamento de carbono e introduciéndolo en el interior de un cristal.Ábrete a nuevas ideas, estúdialas y piensa en combinarlas para mejorar soluciones existentes.
7. Ser curioso
Muchos innovadores son simplemente personas curiosas a los que les gusta resolver problemas. Es una buena costumbre observar soluciones existentes y preguntarse si hay otras vías para hacerlo, cuestionarse las normas y métodos existentes.Publicado en: Variable Not Found.
lunes, diciembre 10, 2007
Hasta la versión 3.0 de C#, la declaración de una variable se debía realizar indicando su tipo de datos antes del identificador elegido para la misma. También era muy frecuente definir en ese mismo momento su valor inicial, siguiendo un patrón similar al siguiente:
string s = "cadena";Las variables locales implícitamente tipadas permiten obviar en su declaración el tipo que tendrán, dejando al compilador la tarea de averiguar cuál será en función de las variables o constantes que se usen al inicializarlo. Por tanto, será posible escribir código como:
var x = XmlDateTimeSerializationMode.Local;
XmlDateTimeSerializationMode x = XmlDateTimeSerializationMode.Local;Creo que no hace falta decir cuál de ellas es más cómoda a la hora de programar, ¿no? Simplemente hemos indicado con la palabra var que preferimos que sea el compilador el que haga el trabajo sucio.
Otro contexto donde este tipo de variables pueden facilitarnos la vida de forma frecuente es en los bucles for, foreach y bloques using:
// Un ejemplo de bucle...
var chars = "Saludicos".ToCharArray();
foreach (var ch in chars)
{
Console.Write(ch); // ch es char
}
// Y ahora un bloque using...
using (var ctx = new AppContext())
{
// usamos ctx, que es de tipo AppContext
}
También es importante la existencia de esta nueva forma de declaración para posibilitar la creación de objetos de tipo anónimo, es decir, aquellos cuya especificación de clase se crea en el mismo momento de su definición. Por tanto, una declaración como la siguiente será válida:
var x = new { Nombre = "Juan", Edad = 23 };
class __Anonymous1
{
private string nombre ;
private int edad ;
public string Nombre { get { return nombre ; } }
public int Edad { get { return edad ; } }
public __Anonymous1(string nombre, int edad)
{
this.nombre = nombre;
this.edad = edad;
}
}
...
__Anonymous1 x = new __Anonymous1("Juan", 23);
Existen ciertas reglas de obligado cumplimiento para usar variables locales implícitamente tipadas:
- La declaración debe incluir un valor de inicialización. En otras palabras, no será posible usar en una línea
var i;, puesto que el compilador no podría inferir el tipo en este momento. - El valor de inicialización debe ser una expresión evaluable como clase en tiempo de compilación. Expresamente prohibido el valor null, es decir, nada de
var n = null;, puesto que el compilador no sabría de qué tipo se trata; eso sí, si fuera necesario, podría forzarse un castingvar str = null as string;. - La declaración no puede incluir más de una variable. Una línea como
var i = 1, s = "hola";generará un error en compilación. - El inicializador no puede referirse a la propia variable declarada, obviamente.
- Sólo pueden utilizarse como variables locales en bloques de código, en bucles for y foreach y como recurso de un bloque using.
Por último, me gustaría añadir un par de detalles que considero interesantes.
Primero, el hecho de utilizar la palabra "var" y no indicar de forma explícita el tipo puede hacernos pensar que estamos utilizando tipado dinámico en tiempo de ejecución, como lo hacemos con Javascript, sin embargo esto no es así. Como he comentado anteriormente, el compilador toma el tipo del lado derecho de la asignación de inicialización, por lo que si la variable no es inicializada se produce un error de compilación:Implicitly-typed local variables must be initializedPor ello, un entorno como Visual Studio sabe en todo momento el tipo exacto de que se trata, y nos puede ofrecer las ayudas en la codificación, detección de errores sintáticos e intellisense, como se puede observar en la imagen.
(Las variables locales implícitamente tipadas deben ser inicializadas)
Segundo, y muy interesante. Como ya comenté en su momento, la nueva versión de Visual Studio permite la generación de ensamblados para versiones anteriores de la plataforma, es decir, que es posible escribir código C# 3.0 y generar un ensamblado para el framework 2.0. Esto, a efectos prácticos, implica que una vez demos el salto definitivo a VS2008 podremos usar las variables locales de tipo implícito, así como otras novedades del lenguaje, incluso en aplicaciones diseñadas para .NET 2.0.
Publicado en: Variable Not Found.
lunes, diciembre 03, 2007
Hace unos días publicaba una entrada donde hablaba de los problemas que generan la inclusión y el mantenimiento de comentarios en el código fuente de nuestras aplicaciones, aunque para no extenderme mucho sólo cité brevemente algunos aspectos a tener en cuenta a la hora de afrontar estos inconvenientes.
Ahora, partiendo de estos consejos, la abundante literatura que hay sobre el tema y mi propia experiencia, he creado los 13 consejos para comentar tu código, que contribuirán a hacerlo más inteligible y por tanto a incrementar su mantenibilidad a lo largo del tiempo.
1. Comenta a varios niveles
Comenta los distintos bloques de los que se compone tu código, aplicando un criterio uniforme y distinto para cada nivel. Puedes, por ejemplo, seguir un modelo como:- En cada clase, incluir una breve descripción, su autor y fecha de última modificación
- Por cada método, una descripción de su objeto y funcionalidades, así como de los parámetros y resultados obtenidos
Obviamente, una solución bastante aceptable e incluso aconsejable es utilizar las convenciones y herramientas (como XML en C# ó Javadoc para el mundo Java) que ayudan y facilitan esta tarea.
2. Usa párrafos comentados
Como complemento al punto anterior, es recomendable dividir un bloque de código extenso en "párrafos" que realicen una tarea simple, e introducir un comentario al principio de forma que se guíe al lector, precediéndolos, además, de una línea en blanco que ayude a separar cada uno del anterior. ...
// Comprobamos si todos los datos
// son correctos
foreach (Record record in records)
{
if (rec.checkStatus()==Status.OK)
{
...
}
}
// Ahora pasamos a realizar las
// transacciones
Context ctx = new ApplicationContext();
ctx.BeginTransaction();
...3. Tabula por igual los comentarios de líneas consecutivas
Si tenemos un bloque de líneas de código donde existe por cada una de ellas un comentario, es buena costumbre tabularlos todos a la misma posición, de forma que quedarán alineados y serán más sencillos de leer, sobre todo si forman parte de la misma frase. const MAX_ITEMS = 10; // Número máximo de paquetes
const MASK = 0x1F; // Máscara de bits TCP
Ojo a las tabulaciones. Hay editores que usan el carácter ASCII (9) y otros, en cambio, lo sustituyen por un número determinado de espacios, que suelen variar según las preferencias personales del desarrollador. Lo mejor es usar espacios simples o asegurarse de que esto es lo que hace el IDE correspondiente.
4. No insultes la inteligencia del lector
Debemos evitar comentarios absurdos como: if (a == 5) // Si a vale cinco, ...
counter = 0; // ... ponemos el contador a cero
...
Este exceso necesita mucho tiempo a la hora de su creación, lo necesitará para su mantenimiento y, además, la mayoría de las veces distraerá al lector con detalles que no es necesario conocer o que pueden ser deducidos echando un vistazo al código.
5. Sé correcto
Evita comentarios del tipo "ahora compruebo que el estúpido usuario no haya introducido un número negativo", o "este parche corrije el efecto colateral producido por la patética implementación del inepto desarrollador inicial".El uso de este tipo de comentarios no dice nada a favor de su creador, y, además, nunca se sabe quién los va a leer en el futuro. Emarts, en "Sapos, culebras y código fuente" muestra ejemplos de comentarios de este tipo.
Otro tema relacionado y, a mi entender, igualmente importante: cuida la ortografía. El hecho de que los comentarios no se vean desde el exterior no implican que puedas descuidarlos. Una ortografía correcta mejora la calidad de la expresión escrita y, por tanto, de la comunicación, que es de lo que se trata.
6. No pierdas el tiempo
No comentes si no es necesario, no escribas nada más que lo que necesites para transmitir la idea. Nada de diseños realizados a base de caracteres ASCII, ni florituras, ni chistes, ni poesías, ni chascarrillos.En resumen, mantén los comentarios simples y directos, pues de lo contrario harás perder tiempo a tu sucesor. Para entender el efecto negativo de una verborrea excesiva, no hay como echar un vistazo a Hyperverbosity, publicado en Worse Than Failure hace unos días.
7. Utiliza un estilo consistente
Hay quien opina que los comentarios deberían ser escritos para que los entendieran no programadores. Otros, en cambio, piensan que debe servir de ayuda para desarrolladores exclusivamente.En cualquier caso, coincidiendo con Ryan Campbell en su post Successful Strategies for Commenting Code, lo que importa es que siempre sea de la misma forma, orientados al mismo destinatario. Personalmente, dudo mucho que alguien de un perfil alejado a la programación vaya a acercarse al código, por lo que, para mi gusto, bastaría con cubrir el segundo caso de los expuestos anteriormente.
8. Para los comentarios internos usa marcas especiales
Y sobre todo, aunque no únicamente, cuando se trabaja en un equipo de programación en el que varias personas pueden estar tocando las mismas porciones de código. El ejemplo típico es el comentario TODO (to-do, por hacer), que describe funciones pendientes de implementar:
int calcula(int x, int y)
{
// TODO: implementar los cálculos
return 0;
}En este caso los comentarios no se usan para explicar una porción de código, sino para realizar anotaciones sobre el mismo a las que hay que prestar especial atención. Eso sí, si usas esta técnica, recuerda que debes actualizarlos conforme las anotaciones dejen de tener sentido.
9. Comenta mientras programas
Ve introduciendo los comentarios conforme vas codificando. No lo dejes para el final, puesto que entonces te costará más de el doble de tiempo, si es que llegas a hacerlo. Olvida las posturas "no tengo tiempo de comentar, voy muy apurado", "el proyecto va muy retrasado"... son simplemente excusas. Si tu intención es comentar el código, no te engañes y ¡hazlo!Hay incluso quien opina que los comentarios que describen un bloque deberían escribirse antes de codificarlo, de forma que, en primer lugar, sirvan como referencia para saber qué es lo que hay que hacer y, segundo, que una vez codificado éstos queden como comentarios para la posteridad. Un ejemplo:
public void ProcesaPedido()
{
// Comprobar que hay material
// Comprobar que el cliente es válido
// Enviar la orden a almacén
// Generar factura
}La codificación de cada una de las tareas descritas en el lenguaje correspondiente se realizaría justo debajo del comentario, quedando éste como encabezado de párrafo (como se describe en el consejo 2).
10. Comenta como si fuera para tí mismo. De hecho, lo es.
A la hora de comentar no pienses sólo en mantenimiento posterior, ni creas que es un regalo que dejas para la posteridad del que sólo obtendrá beneficios el desarrollador que en el futuro sea designado para corregir o mantener tu código.En palabras del genial Phil Haack,
"tan pronto como una línea de código sale de la pantalla y volvemos a ella, estamos en modo mantenimiento de la misma"
Como consecuencia, nosotros mismos seremos los primeros beneficiaros (o víctimas) de nuestro buen (o mal) hacer.
11. Actualiza los comentarios a la vez que el código
De nada sirve comentar correctamente una porción de código si en cuanto éste es modificado no se actualizan también los comentarios. Ambos deben evolucionar paralelamente, pues de lo contrario estaremos haciendo más difícil la vida del desarrollador que tenga que mantener el software, al facilitarle pistas incorrectas para comprenderlo.Atención especial a las refactorizaciones automáticas, que suelen introducir cambios en distintos puntos del código de un proyecto, dejando los comentarios obsoletos en ese mismo instante.
12. La regla de oro del código legible
He dejado para el final uno de los principios básicos para muchos desarrolladores: deja que tu código hable por sí mismo. Aunque se sospecha que este movimiento está liderado por programadores a los que no les gusta comentar su código ;-), es totalmente cierto que una codificación limpia puede hacer innecesaria la introducción de textos explicativos adicionales.Recordemos, por ejemplo, el código introducido en el post "Interfaces fluidos (fluent interfaces)", donde se muestra lo que esta técnica puede aportar a la claridad y autoexplicación en un desarrollo:
Console.WriteLine("Resultado: " +
new Calculator()
.Set(0)
.Add(10)
.Multiply(2)
.Substract(4)
.Get()
);A la vista del ejemplo, ¿es necesario añadir algú