El caso es:¿por que no 10 en vez de 20? Y sólo 5? llevar la ídea al extremo y
pensar en métodos de una línea nos puede ayudar a aprender algo que luego
podamos aplicar en nuestros métodos de 100+ líneas.
Y por supuesto no estamos hablando de "concentrar" el código en una sóla
línea que haga muchas cosas (tipo cosas Perl o C++)
Ejemplos
En las pruebas unitarias de la EnterpriseLibrary hay métodos de una línea:
[TearDown]
public void CleanOutDatabase()
{
backingStore.Flush();
}
[Test]
public void CanGetCountOfItems()
{
Assert.AreEqual(0, backingStore.Count);
}
Y una clase de código de producción de entlib con métodos de una sóla línea
namespace Microsoft.Practices.EnterpriseLibrary.Caching
{
internal class StartScavengingMsg : IQueueMessage
{
private BackgroundScheduler callback;
public StartScavengingMsg(BackgroundScheduler callback)
{
this.callback = callback;
}
public void Run()
{
callback.DoStartScavenging();
}
}
}
El otro día viendo el código de BTSUnit nos encontramos con la clase.
public class StreamFromString : MemoryStream
{
public StreamFromString(string input) : base(Encoding.UTF8.GetBytes(input))
{
}
}
Que no tiene más métodos que el constructor con una sóla línea.
Mi conclusión personal, es que siempre que me encuentro con métodos de
pocas líneas suelen representar un buen diseño.
Por otro lado, pensar en que la recomendación "muchos métodos cortos mejor
que pocos métodos largos" no creo que haga daño a nadie y es el primer paso
para realizar la transición entre programación estructurada y OO.
Normalmente no es fácil preveer a priori el número de clases que vamos a
necesitar para implementar una determinada funcionalidad, siempre se puede
empezar con una clase a la que añadir una gran método, después partirlo más
métodos y cuando tenga muchos agruparlos en clases, después de unos pocos
Refactorings se puede ir "moldeando" el diseño, con el número de clases por
assembly, métodos por clase, y líneas por método justos y necesarios para
expresar el dominio del problema con código que funcione
Clean code that works !!
Una parte del artículo nos informa sobre las empresas que han optado por desplazar sus centros de trabajo a provincias como Murcia, Badajoz, o Lerida. Me parece muy interesante, ya que se normalmente se gana en calidad de vida, y eso mejora en los resultados obtenidos.
Personalmente me encantaria la posibilidad de poder trabajar fuera de Madrid, pero lamentablemente, mi profesión de consultor me exige estar en Madrid y disponibilidad para viajar al cliente.
]]> El articulo continua con comentarios de algunos responsables de las empresas más importantes del pais que estan apostando por "Fábricas de Software". Y me sorprendió la forma de afirmar que el diseño y la construcción son actividades separadas.Es cierto que hoy por hoy los resultados obtenidos para desarrolar software dejan mucho que desear en comparación con otras ingenierias, pero eso no significa que la unica solución consiste en seguir apoyando a las metodologías clásicas en las que se acaba suponiendo que el desarrollo es una cadena de actividades que se puede realizar de forma sistemática como si se tratase de una cadena de producción.
El enfoque clásico de dividir las fases del proyecto en 1)Análisis 2)Diseño 3)Código 4)Pruebas no suele ser todo lo efectivo que parece a primera vista, cuanto más tiempo se dedique al análisis, con la esperanza de no haberse dejado en el camino, y con más detalle se quiera realizar el diseño para intentar minimizar los errores en el código, menos tiempo se dispone para poner una primera versión (incompleta por supuesto) a funcionar. El resultado es que se entrega el producto cuando ya no queda tiempo para rectificar, y acertar a la primera es una tarea imposible, debido al conflicto de intereses entre el proveedor y el cliente.
Las metodologías ágiles son una alternativa para mejorar la industria del desarrollo de aplicaciones, para evitar los conocidos males del sector en cuanto a efectividad de proyectos realizados con éxito.
Estas metodologías hacen incapié en una serie de procesos iterativos e interconectados que dan lugar a software de gran calidad. En cada una de las iteraciones se realizan tareas relacionadas con las cuatro fases comentadas anteriormente. Asi es común empezar con las pruebas, a partir de ese punto mejorar el diseño, y todo mientras escribimos código. Pero también se puede empezar diseñando, implementando y probando. Cada escenario nos ira pidiendo las tareas según avanzamos.
El argumento es sencillo, si el resultado más importante de un proyecto de software son los ejecutables que lo hacen funcionar, las fuentes con las se crean estos ejecutables son el activo de más valor, y por eso tenemos que cuidarlo.
Las fuentes, el código, tiene que cumplir una doble misión, transmitir a la máquina como comportarse y transmitir a los programadores lo que la máquina va a entender, para poder asi comprenderlo y mejorarlo, extenderlo o simplemente mantener los posibles errores que pudiesen aparecer. Esta dualidad es muy dificil de conseguir, y debido a la dinámica de los proyectos el código se da por terminado cuando ha cumplido solo una parte de su misión.
La situación más habitual nos la encontramos al observar la reacción de los jefes de proyecto, o los clientes, al plantearles la necesidad de mejorar el diseño sin añadir funcionalidad. Esta técnica se denomina Refactoring, y no suele gustar a la gente NoTécnica
Es muy dificil, y practicamente imposible, craer una solución aceptable a la primera, es necesario dos o tres intentos hasta que se llega a una situación de équilibrio máquina/hombre. Esta forma de dividir los esfuerzos entre añadir código nuevo o modificar el existente es una de las claves para conseguir nuestro doble objetivo, código que funcione en una máquina a la vez que es entendible por personas. El diseño es una actividad que realizaremos continuamente, al escribir documentos, diagramas o código, y diseñaremos hasta el último día del proyecto.
Por todo esto no creo en la visión que se plantea de las "Fábricas de Software", en las que unos pocos realizan el diseño y se lo pasan a los programadores para que lo implementen.
Me gustaria oir hablar de centros de desarrollo, pero no de fábricas, el término fábrica transmite algo más que el mero hecho de fabricar, implicitamente se refiere a realizar tareas repetitivas que van a dar lugar a un programa.
En un centro de desarrollo se pueden concentrar muchos programadores, y eso puede ser muy bueno para la mayoria de los proyectos, en terminos de reducción de costes, asi como de mejora del clima laboral, pero para poder beneficiarse de estas mejoras hay que combatir los efectos negativos de la centralización, en concreo reducir la distancia entre el cliente y los técnicos.
]]>El contenido no se actualiza frecuentemente pero lo que hay es de calidad.
]]>"... El paso más eficaz que puede dar para protegerse
de los hipervínculos maliciosos es no hacer clic en ellos.
Lo que debe hacer es escribir personalmente en la barra de
dirección la dirección URL del destino al que pretende llegar."
http://support.microsoft.com/default.aspx?scid=kb;es;833786
]]> Pienso que como esto siga asi nos vamos a cargar la red en poco tiempo.Los hipervinculos han sido uno de esos inventos que han impulsado la informática y
han hecho posible que miles de usuarios puedan emepezar a usar la red sin necesidad
de grandes conocimientos. Si nos cargamos esto, estamos poniendo en peligro Internet
tal y como lo conocemos hoy.
¿Cómo le explico yo a alguien no técnico la diferencia entre una "URL Maliciosa"
y una URL Benéfica?
He leido que otros navegadores
no sufren este problema, pero ¿durante cuanto tiempo?
Definitivamente la seguridad informática sólo se va a poder conseguir
desconectándose de la red.
Windows no cuenta con esta utilidad (que yo sepa),
y es muy útil cuando empezamos a tener
problemas de disco y queremos encontrar esas esas
carpetas que ocupan demasiado...
Hoy he encontrado una herramienta para
Windows (esta con GUI ;.) DX Hog Hunt muy recomendable.
Asi que he conseguido abrir un Blog en MSDN http://blogs.msdn.com/rido
pero ahora me he encontrado con el problema del idioma, resulta que todos los blogs de este sitio están en inglés,
pero yo quiero escribir el mio en castellano.
Asi que de momento, estoy esperando a ver que pasa con la iniciativa de MSDN Spain para abrir un sitio de blogs en
castellano.
Mientras seguiremos escribiendo en los dos.
]]>http://workspaces.gotdotnet.com/RidoCode
Esta dirección redirige a http://www.gotdotnet.com/community/workspaces/workspace.aspx?ID=54FB9F3F-7093-43D1-9608-5642AA6F189D
Como siempre si alguien quiere que le incluya que me lo pida !! estoy esperando que los miembros actuales aporten algo, aunque solo sea feedback
]]>En la versión 0.8.4 de NAnt y NAnt.Contrib tenemos las tareas:
version que actualiza un fichero "build.number" y
asminfo que crea un fichero AssemblyInfo.cs basándonse en la información parametrizable.
Sin embargo, no he encontrado la manera de :
Mi primera aproximación fue escribir unas tareas de NAnt que mediante
script lee la versión actual, y usando
exec llamaba a UpdateVersion.exe.
Como creo que estas tareas son necesarias, las he empaquetado en el Assembly: NAnt.Versioning.Tasks
Que teneis disponible en RidoCode Workspace (buscar el Releases)
]]>