Algunas reflexiones sobre el trabajo distribuido. Estaba pensando como mejorar la problemática del trabajo distribuido. Supongamos el hipotético caso de dos grupos trabajando en diferentes países en un gran proyecto que engloba un desarrollo Core y una extensión para el país.
Llamaremos a los grupos Core y País. Core tiene que desarrollar la funcionalidad general de tal manera que sea extensible, customizable en cada país y dentro de cada país en cada desarrollo particular. Les recuerdo que éste es un caso hipotético que no tiene ningún basamento en la realidad, sólo nos sirve para ver distintas implicancias del trabajo distribuido.
El equipo Core desarrolla tres tipos de tareas principalmente: agregar funcionalidad Core nueva, eliminar bugs y prestar soporte al equipo País, dado que puede tener menor conocimiento técnico y metodológico.
El equipo Pais por su parte realiza las siguientes tareas: extiende la capa país, corrige bugs en su capa, carga solicitudes de solución de bugs en la capa Core, implementa su producto.
Ahora visitemos un poco lo técnico, el equipo Core cada vez que agrega nueva funcionalidad compila, integra, corre tests, realiza pruebas automatizadas y publica una versión al equipo País, el cual toma las DLL del producto y pisa en su librería Core y continúa su extensión. Cada vez que el equipo País, agrega cierta funcionalidad realiza un proceso análogo.
Con los bugs es algo similiar, con la diferencia que cuando se resuelven un grupos de bugs y los mismos integran una versión, la misma puede ser sólo de solución de bugs, el número de versión sólo cambia el build y no el minor como cuando se publica nueva funcionalidad.
Hasta aquí un mundo bastante ideal.
Compliquemos las cosas
Ahora supongamos, siguiendo en el campo de la irrealidad, que el equipo Core (que es el que tiene el conocimiento técnico) se ve diezmado por temas de actualidad laboral.
Entonces la delgada línea que separaba los equipos se disuelve. Todos pueden tocar cualquiera de los dos proyectos.(Primer error se pierde administración y governance)
Compliquemos un poco más. El equipo País decide que dado que pueden tocar el Core, entonces porqué esperar una versión de Core, si podemos actualizarnos las DLL cada vez que modificamos algo en Core? (Segundo error se pierde traza, se genera inestabilidad)
Siguiendo la línea del caos (no el creativo o interesante y ágil), el equipo País realiza modificaciones en Core que les son suficientes para su capa País, pero se despreocupan por el estado de Core (compila, pero no necesariamente pasa test, se integra o simplemente sigue funcionando, se rompen interfaces) (Tercer error se piede la integración, consistencia y producto)
Conclusión
Siguiendo en ésta línea se podría continuar, pero creo que es ejemplo suficiente. A partir de éste momento hay que tomar muchas decisiones. ¿Que harías vos con éste hipotético caso? Me gustaría tener opiniones.
Disclaimer
Todo surge de una febril imaginación del autor, ningún personaje o situación tiene relación con la realidad. No fueron dañados animales en la realización del post.
Pensaba hacer un post sobre los podcast tecnológicos que escucho. 
Sin embargo viendo ésta pregunta en Stackoverflow, creo que responde en forma más amplia.
Mis top six son:
- .Net Rocks!
- Hanselminutes
- Herding Code
- Alt.Net podcast
- Agile Tolkit Podcast
- Deep Fried Bytes
Update! Scott Hanselman se inspiró en mi y puso esté post de Podcast para programadores.
Estaba escuchando un podcast de HerdingCode (esto me da pie para un próximo post sobre los podcast que escucho, thanks to commute!) donde Phil Haack habla sobre Asp.Net MVC. Y aprovechando la salida del RC (Release Candidate) podemos discutir algunos temas. (Más info sobre el patrón MVC)
Ante la pregunta de cual es el elevator speech que Phil utilizaría para describir Asp.Net MVC para alguien que utiliza Asp.Net webforms, Phil contesta:
Si utilizás Webforms y estás felíz, entonces ignorá MVC. Si sos muy productivo con Webforms, MVC no va a reemplazar Webforms. Pero los beneficios de utilizar MVC son varios: nos pone nuevamente en control de nuestra aplicación (por ejemplo los controles de Webforms generan mucho markup que si no hacen lo que deseamos puede ser complicado), otro beneficio es que el patrón arquitectónico de MVC es muy bueno en lo que respecta a la separación de conceptos, lo que permite aplicaciones más mantenibles y testeables (valgan los neologismos). Temas que no estaban tan en boga en la creación de Webforms.
Un ejemplo
Una pequeña aplicación que me permite almacenar los gastos diarios (me agarró la paranoia).
El modelo lo forman categorías y gastos.
La persistencia del mismo es a través de Entity Framework (del cual no voy a empezar una discusión, porque Gus tiene muchos argumentos en contra)
Una parte del ExpenseController de ejemplo:
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(FormCollection collection)
{
try
{
var expenseToCreate = new Expense();
Category category = new Category();
UpdateModel(expenseToCreate, new[]{"Date", "Amount", "Description"});
UpdateModel(category, new[]{"CategoryId"});
expenseToCreate.Category = _db.Category
.Where(cate => cate.CategoryId == category
.CategoryId).First();
_db.AddToExpense(expenseToCreate);
_db.SaveChanges();
return RedirectToAction("Index", "Home");
}
catch (Exception exep)
{
return RedirectToAction("Error");
}
}
Esta es la acción de crear un nuevo gasto. Acá y por culpa de no poder utilizar el SelecList.SelectedValue, tuve que hacer algo más rebuscado.
Por último, una parte de la View que representa el Create:
<fieldset>
<legend>Fields</legend>
<p>
<label for="Date">
Date:</label>
<%= Html.TextBox("Date") %>
<%= Html.ValidationMessage("Date", "*") %>
</p>
<p>
<label for="Amount">
Amount:</label>
<%= Html.TextBox("Amount") %>
<%= Html.ValidationMessage("Amount", "*") %>
</p>
<p>
<label for="Description">
Description:</label>
<%= Html.TextBox("Description") %>
<%= Html.ValidationMessage("Description", "*") %>
</p>
<p>
<select size="5" name="CategoryId" id="CategoryId">
<option value="0" selected="selected">Sin seleccionar categoría</option>
<% foreach (Category category in (IList)ViewData["Categories"])
{ %>
<%= "<option value='" + category.CategoryId + "'>" +
category.SmallDescription + "</option>" %>
<%} %>
</select>
<br />
<%= Html.ActionLink("Crear Categoria nueva", "Create", "Categories") %>
</p>
<p>
<input type="submit" value="Create" />
</p>
</fieldset>
En la misma se ve como resolví el tema de no poder utilizar un Helper Method de la entidad Html (como Html.ListBox o Html.DropDownList) debido al problema del SelectList.
Es un pequeño ejemplo. Se encuentran muchos en internet, no intento hacer un tutorial, pero si les interesa el código no tienen más que pedirlo.
Felicidad
Siguiendo con el concepto de Phil Haack, aquellos que no éramos felices con Asp.Net Webforms, nos encontramos con la chance de encontrar la felicidad en éste camino de desarrollo.
Como seguir
El RC tiene todavía algunos problemas, por ejemplo tuve muchos problemas queriendo utilizar un SelectList (lista para Views) y obtener el SelectedValue. Nunca lo logré y tuve que utilizar otras formas. Tal vez sea problemas que se solucionen en la versión definitiva, hay que tener en cuenta que es un proyecto (MVC) con mucho tiempo y mucha gente muy interesante y capaz atrás. Seguimos atentos.
Entradas
