Design a site like this with WordPress.com
Get started

GTD y OneNote

Y as铆 damas y caballeros es como llevo un tiempo aplicando GTD con OneNote, usando un OneNote que est谩 siempre en la nube 馃檪

OneNote y GTD

Secciones:

  • Entrada: voy poniendo todas las cosas que van surgiendo que tengo que hacer.
  • Siguiente: Pongo las tareas que he decidido que voy a hacer en el d铆a.
  • Proyectos: Los diferentes proyectos que tengo a la vista y de los que quiero ir cerrando tareas. Esta secci贸n tiene p谩ginas, una por聽proyecto.
  • Alg煤n d铆a: Al igual que la secci贸n de proyectos, en esta secci贸n creo una p谩gina por proyecto que alg煤n d铆a me gustar铆a hacer.

驴Tambi茅n usas OneNote para gestionar tus tareas? 驴C贸mo lo haces?

Juan Mar铆a La贸 Ramos

StyleCop, TFS y Nuget

StyleCop聽es una herramienta que analiza nuestro c贸digo para ver si se cumplen un conjunto de reglas y estilos de codificaci贸n.

Por resumir un poco, el equipo que lleva el proyecto de StyleCop ha identificado un estilo y conjunto de reglas para la聽programaci贸n en C#. En esas reglas se define, por ejemplo, que todo m茅todo debe tener una secci贸n de documentaci贸n, toda variable de clase debe estar documentada, etc … Si quer茅is ver cuales son esas reglas por defecto no dej茅is de pasaros por la secci贸n de la documentaci贸n dedicada a ello.聽No voy a entrar en la discusi贸n de si esas secciones son necesarias o no para documentar el c贸digo ;). El objetivo que se busca con este proyecto es que todo el c贸digo est茅 escrito de manera homog茅nea, evitando de un plumazo las discusiones entre los miembros del equipo del tipo: “Has vuelto a poner el { en la misma l铆nea del if …”

StyleCop en NuGet

Para integrarlo en nuestros proyectos, simplemente con NuGet, buscamos StyleCop:

StyleCop En Nuget

Una vez que lo instalemos los paquetes StyleCop y StyleCop.MSBuild en nuestro proyecto, si queremos que los errores que nos marca StyleCop sean errores de compilaci贸n en lugar de warnings tan solo tenemos que editar el .csproj y a帽adir la l铆nea:

<StyleCopTreatErrorsAsWarnings>false</StyleCopTreatErrorsAsWarnings>

En la secci贸n que queramos que esto ocurra, por ejemplo, si queremos que esto s贸lo salte cuando compilemos en debug, buscaremos la secci贸n de configuraci贸n para ello, y la a帽adiremos al property group:

&lt;PropertyGroup&gt;
    &lt;Configuration Condition=&quot; '$(Configuration)' == '' &quot;&gt;Debug&lt;/Configuration&gt;
    &lt;Platform Condition=&quot; '$(Platform)' == '' &quot;&gt;AnyCPU&lt;/Platform&gt;
    &lt;ProjectGuid&gt;{471ADD54-6DE1-42F2-8ECD-A41C5C05029E}&lt;/ProjectGuid&gt;
    &lt;OutputType&gt;Library&lt;/OutputType&gt;
    &lt;AppDesignerFolder&gt;Properties&lt;/AppDesignerFolder&gt;
    &lt;RootNamespace&gt;ClassLibrary1&lt;/RootNamespace&gt;
    &lt;AssemblyName&gt;ClassLibrary1&lt;/AssemblyName&gt;
    &lt;TargetFrameworkVersion&gt;v4.5&lt;/TargetFrameworkVersion&gt;
    &lt;FileAlignment&gt;512&lt;/FileAlignment&gt;
    &lt;SccProjectName&gt;SAK&lt;/SccProjectName&gt;
    &lt;SccLocalPath&gt;SAK&lt;/SccLocalPath&gt;
    &lt;SccAuxPath&gt;SAK&lt;/SccAuxPath&gt;
    &lt;SccProvider&gt;SAK&lt;/SccProvider&gt;
    &lt;StyleCopTreatErrorsAsWarnings&gt;false&lt;/StyleCopTreatErrorsAsWarnings&gt;
    &lt;SolutionDir Condition=&quot;$(SolutionDir) == '' Or $(SolutionDir) == '<em>Undefined</em>'&quot;&gt;..&lt;/SolutionDir&gt;
    &lt;RestorePackages&gt;true&lt;/RestorePackages&gt;
  &lt;/PropertyGroup&gt;

Personalizar las reglas

Una vez que hayamos instalado StyleCop, podemos configurarlo haciendo clic derecho en el proyecto y veremos las聽reglas y opciones que podemos configurar:

StyleCop SettingsEsto va a generar un archivo en la ra铆z del proyecto llamado “Settings.Stylecop” que tenedremos que a帽adir al proyecto y al TFS

No es mala idea usar siempre el mismo archivo de configuraci贸n para todos nuestros proyectos, as铆 que una vez que tengamos un archivo de este tipo podemos ponerlo en un directorio dentro del聽TFS y enlazarlo al archivo de nuestro proyecto en la secci贸n de configuraci贸n de聽StyleCop, en la pesta帽a “Settings Files”聽de esta manera:

StyleCop Custom Rules

Esto generar谩 un “Settings.stylecop” tan s贸lo con la ruta que le hemos indicado. Este archivo tambi茅n tenemos que a帽adirlo al TFS para que se ejecute StyleCop en la nube.

Juan Mar铆a La贸 Ramos

Una experiencia ALM ++

En estos 煤ltimos tres meses he tenido la oportunidad de aplicar Scrum y TDD de manera estricta.

Ha sido una experiencia muy enriquecedora y la voy a compartir con todos.

En el proyecto hemos usado Team Foundation Service y Visual Studio 2012 como soluci贸n ALM con la plantilla por defecto de Scrum. Con esto solventamos varias cosas de un plumazo:

  • Gesti贸n del Backlog
  • Definici贸n de Sprints
  • Gesti贸n de Tareas.
  • Gesti贸n de Bugs.

La interacci贸n con el cliente tambi茅n la hac铆amos a trav茅s de la web del proyecto.

Lo que m谩s me llam贸 la atenci贸n fu茅 lo f谩cil que es la gesti贸n de bugs. Cuando el cliente encontraba un bug, lo abr铆a y le pon铆a la prioridad, el scrum Master lo comunicaba en el daily scrum y nos organiz谩bamos para ver qui茅n lo correg铆a

ALM

  • Ten铆amos definidas varias Builds para cada parte del sistema que lanzaba una compilaci贸n y ejecuci贸n de los Test Unitarios que hab铆a para asegurar que no se hab铆a roto nada.
  • Tambi茅n hab铆a otra serie de Builds manuales necesarias para generar una versi贸n para desplegar en los distintos entornos Desarrollo, Pre-producci贸n y Producci贸n.

La verdad que esto de no salir de Visual Studio para crear un sistema es una bendici贸n. En su d铆a integr茅 Jenkis, Trac y Subversion en un proyecto en .NET, me maravillaba lo que se podia hacer con estas herramientas. La verdad es que me cost贸 un tiempo montarlo y despu茅s mantenerlo.

Y en una conversaci贸n con el Scrum Master me solt贸 esto:

鈥淟uego te llegan los empalmados que si Subversion, Jenkins, Jira, Trac, Bugcilla, que es gratis. Si est谩s desarrollando en .NET, el intentar integrar todo eso para que funcione con .NET es posible, pero es cuesti贸n de tiempo y dinero鈥

Y en estos tres meses de trabajo, le habremos dedicado 40 horas a estos temas (daily scrums incluidos) y todo sin salir de Visual Studio.

Knock, knock … Buenos d铆as developer, venimos a hablarle de TDD

Aviso: Este es un post que te va a vender TDD.

En otras publicaciones han resumido las bonanzas de TDD, como el libro de @carlosbleDise帽o 谩gil con TDD“. Os lo recomiendo desde ya.

Pero he encontrado聽una presentaci贸n de Francesco Carucci, antiguo desarrollador de Crytek聽que actualmente trabaja en Apple, en la que聽muestra/vende TDD desde el punto de vista del desarrollo de聽video juegos.

Me ha parecido聽muy bien聽estructurada y c贸mo vende聽TDD, as铆 que lo pongo aqu铆 para escribirlo, compartirlo y de manera ego铆sta, como un ejercicio para que me ayude a no olvidar algunas cosas.

La estructura consiste en聽poner las diferentes聽razones y excusas聽que聽solemos dar para聽no聽escribir tests o por qu茅 no hacer TDD y las respuestas que deber铆amos grabarnos como mantras. As铆 que all谩 vamos:

No hago Tests por que …

… el tiempo que gasto en escribir test es tiempo que pod铆a estar escribiendo c贸digo.

  • Al final gastamos m谩s tiempo en debugear y mantener c贸digo que escribi茅ndolo.
  • Si escribimos primero los聽test y el c贸digo que los pasa, el c贸digo que los pasa es c贸digo de producci贸n. La consecuencia es que tardamos menos tiempo en tener c贸digo que funciona, esto es: c贸digo de producci贸n.
  • La modificaci贸n del c贸digo es m谩s confiable. Cuando modificamos c贸digo lo hacemos “m谩s tranquilos” ya que sabemos que vamos a romper pocas cosas, y si se rompen, nos vamos a dar cuenta r谩pido.
  • Se evitan bugs de regresi贸n. Al detectar un bug, escribimos un test que lo reproduzca y ese bug no volver谩 a aparecer.
  • Se detectan antes los bugs,聽como ya vimos en聽el post anterior

… los test no lo pueden probar todo

  • Un test es mejor que ninguno.
  • El c贸digo legacy o de terceros聽no聽hay que聽testearlo a menos que tengamos que modificarlo.
  • Roma no se construy贸 en un d铆a, pero se construy贸 (y conquisto el mundo conocido)

… este c贸digo es temporal y lo cambiar茅 despu茅s, no necesito testearlo

  • Todo el c贸digo se modifica tarde o temprano. Hacer c贸digo que sea f谩cil de cambiar es la raz贸n聽fundamental de TDD: elimina la sobre-ingenier铆a (KISS, Keep It Simple, Stupid!)
  • Los requisitos cambian:聽entonces hay que modificar los tests afectados y el c贸digo de producci贸n. Pero como聽est谩 testeado unitariamente, el c贸digo est谩 m谩s desacoplado, es m谩s f谩cil de modificar y los cambios tendr谩n menos efectos secundarios.

En el mundo del desarrollo de juegos

El desarrollo de juegos es diferente: los test automatizados pueden no funcionar.

  • En general el desarrollo de juegos es totalmente diferente 鈥
  • 鈥 pero escribir c贸digo es lo mismo, incluso m谩s simple.
  • El c贸digo de un juego es m谩s algoritmia y matem谩ticas, eso es incluso m谩s f谩cil de testear que un proceso de negocio.
  • Un c贸digo de sobresaliente es lo mismo tanto en un juego como en una web.
  • El c贸digo de un juego cambia a menudo: m谩s cambios es un motivo m谩s para tener test que comprueben que no se ha roto nada.

Los juegos son para divertirse, un test no puede comprobar que un juego sea divertido.

  • Pero s铆 puedes capturar bugs, y menos tiempo debugando errores significa m谩s tiempo para implementar la parte divertida.
  • Crear un test para un bug te asegura que ese bug no volver谩 a aparecer (El 30% de las correcciones de bugs crean nuevos bugs debido a efectos colaterales)

Esto es un juego AAA, es muy arriesgado hacer test automatizados sobre 茅l.

  • Los juegos AAA son muy complejos, muy tecnol贸gicos y muy divertidos. Para conseguir un juego AAA, se deben usar herramientas adecuadas, y los test automatizados son una de esas herramientas.
  • Lo arriesgado es NO hacer test en un juego AAA

驴Cu谩ndo TDD no es apropiado?

  • Prototipos. Mientras buscamos/probamos posibles soluciones a un problema.
    • La soluci贸n final S脥 debe estar hecha con TDD.
  • En el c贸digo de wrappers de librer铆as existentes.
  • En la capa GUI, eso no es testing unitario, es testing de integraci贸n.
  • En c贸digo de bajo nivel, el que est谩 muy cerca del hardware

Objetivo: Producir m谩s funcionalidades en menos tiempo.

No perdamos de vista el objetivo, producir lo antes posible c贸digo que vaya a producci贸n, esto es c贸digo que funciona, libre de bugs y聽mantenible

驴Y tu porqu茅 no haces Test o TDD?

TDD: Mentirosos el ciclo no es Red – Green -Refactor

Nos han enga帽ado estos del TDD, son unos malditos mentirosos, el verdadero ciclo es:

Think – RedGreen – Refactor

Y no te lo dicen, aunque para algunos iluminados sea algo impl铆cito, el primer paso es pensar (Think) el algoritmo/l贸gica que quieres implementar, y es聽ese primer paso el que siempre me saltaba. Soy una persona visceral y suelo actuar por impulsos, y a la hora de programar … pues me pasa un poco que me dejo llevar.

Por eso voy a desglosaros c贸mo veo yo el ciclo de TDD:

Think

  1. Piensa y reflexiona la l贸gica que tienes que implementar.
  2. Identifica las diferentes responsabilidades que hay
  3. Por cada responsabilidad habr谩 una clase. (隆Quieto!, aparta las manos del teclado, no es el momento de escribir las clases. Dib煤jalas en un PDA (Papel de Apuntar))
  4. Elige un buen nombre para cada una de ellas. Nombres descriptivos, limpios, claros,聽afeitaditos. Evita las聽terminaciones de LoQueSeaObject, LoQueSeaManajer, etc… Si no dice nada sobre la funcionalidad de la clase qu铆talo. Si a煤n as铆 est谩s tentado a ponerlo, es que esa clase hace m谩s de una cosa (Principio KISS), as铆 que vuelve al paso 1.
  5. En el PDA dibuja las relaciones entre las diferentes clases

Foreach (responsabilidad in PDA)

  • Crea una clase de Test por cada una (ejemplo: responsabilidad1Test)
  • Y ahora s铆, en cada clase de test haz todos los RedGreen – Refactor necesarios para probar la funcionalidad que la clase testeada debe tener.

Mis conclusiones

Escribe tu c贸digo como si un asesino esquizofr茅nico que tiene tu direcci贸n fuese a mantenerlo

Esta es una frase muy conocida en el mundo Agile, no recuerdo si era exactamente as铆, pero lo que viene a resumir es que al final pasamos m谩s tiempo leyendo, debugeando y manteniendo c贸digo que escribi茅ndolo. Por eso es muy importante pensar muy bien el nombre que les vamos a dar a las clases, variables, m茅todos, propiedades, etc. En definitiva haz lo que sea necesario para que tu聽c贸digo sea legible.

La formaci贸n no es importante, es IMPRESCINDIBLE

Aprender la teor铆a est谩 bien, pero si聽viene acompa帽ada de una pr谩ctica con alguien que te gu铆e te va a ayudar mucho m谩s, s铆, es algo obvio, pero que no se suele hacer.

Las herramientas de refactoring son nuestras amigas

S贸lo hablo del “generate method” y “generate class” de Visual Studio, no me han hecho falta m谩s. Cuando聽empiezas a escribir el test, y haciendo clic derecho y buscar esa opci贸n en el desplegable nos permite crear r谩pidamente las clases y m茅todos聽que nos vayan haciendo falta, pero no te olvides聽del asesino esquizofr茅nico.

El Nirvana del TDD

El Nirvana del TDD es no tener que debugear para detectar un bug, s贸lo crear un test que lo reproduzca y corregirlo. Si consigues llegar a este punto ya eres un TDD Master.

驴C贸mo ampliar铆as este post?