Javascript vs Coffeescript, que opinan?

[Dario Seminara]

En un proyecto (rails 3) tenemos la opcion de utilizar Javascript puro, o Coffeescript. Que opinan que seria mejor?

Algunos datos de contexto que puedo dar:

• En la empresa hay varios desarrolladores rails (mas o menos 3-4 asignados al proyecto), pero tb de otras tecnologias (por ej Java)
• En el mismo proyecto hay otras tecnologias que no se relacionan directamente con rails

Tambien en el mismo proyecto hay quienes conocen JS muy bien, desde mi punto de vista tendria que aprender algo en nuevo con cualquiera de las dos opciones (en lo personal me gusta mas la idea de aprender javascript)

[Michel Martens]

2013/7/24 Dario Seminara <dar...@gmail.com>:

> Javascript puro, o Coffeescript. Que opinan que seria mejor?

CoffeeScript es una aberración. Como ejemplo, mirá esta lista
(muy benevolente) de problemas que presenta:

http://en.wikipedia.org/wiki/CoffeeScript#Issues

[Andrés Arana]

Antes que nada, trabajo con Dario, así que estoy al tanto de la discusión que se está desarrollando en la empresa en donde trabajamos. Spoiler también, yo no estoy de un lado ni del otro, así que está genial escuchar opiniones fundamentadas al respecto para que podamos decidir mejor.

Es interesante que la mayor parte de la gente a la que se le consulta acerca de esta tecnología tiene opiniones tan marcadas... he escuchado cualquier cosa desde "es una aberración" hasta "es lo mejor que le puede pasar a client-side development" (es algo que se da mucho en tecnología... será porque nos enamoramos de las herramientas que usamos?). También es interesante que se suelen citar cuatro sources al respecto:

1. La lista de issues en wikipedia, la mayor parte de los cuales son relativamente menores, y que además termina con "The above issues are only indicative and there are many other strong arguments for and against CoffeeScript.". Prestar especial atención a la parte de  **for and against**. (Sin mockear a michel a quien considero un groso de la comunidad!).

2. http://net.tutsplus.com/articles/interviews/should-you-learn-coffeescript/, en donde se presentan opiniones de diversos grosos de javascript. Lo loco es que se presentan puntos de vista tanto a favor como en contra, y la conclusión del artículo es abierta a la discusión (la parte de loco es que se suele citar como puntos en contra de coffee, cuando es más una discusión abierta sin conclusión definida). 

3. http://ryanflorence.com/2011/case-against-coffeescript/. El título del post es "A case against coffeescript". Loco también que se cite como problemas de coffeescript, porque en el primer párrafo del artículo lee: "Update: I actually love CoffeeScript now that I've been writing it for a year. I hope to write something about my conversion soon.".

4. Nadie lo está usando. Es una de las razones que más escucho. Peeeero... On September 13, 2012, Dropbox announced that their browser-side codebase has been rewritten from JavaScript to CoffeeScript. GitHub's style guide says to "write new JS in CoffeeScript". En definitiva... hay algunas empresas relativamente grandes que lo están usando.

En fin... Propongo entonces que en vez de citar y descartar o citar y elogiar, demos ventajas y desventajas, contando nuestra propia experiencia al respecto, y discutamos cada una de estas en función de nuestras opiniones, si puede ser con una conclusión propia. Empiezo yo:

**Ventajas:**

* Sintaxis concisa para idioms de javascript. For loops, preservar el this, declaración de variables para prevenir errores por hoisting, etc. Son cosas que si sabés javascript las hacés automáticamente sin pensarlo demasiado (de la misma manera que un programador de assembler MIPS recuerda casi automáticamente guardar los valores de registros temporales, pushear argumentos al stack si corresponde y hacer un jump-and-link cuando quiere hacer una call a una función), pero que de todas formas ayuda tener abstracciones para hacer estas cosas que las hacemos todo el tiempo y que leemos todo el tiempo.

* Es un layer sintáctico encima de javascript. Lo que aprendés de coffee te sirve para extrapolar a javascript de última instancia. La transición entre los lenguajes no es (en mi caso al menos) traumática ni dolorosa. Los conceptos son relativamente equivalentes.

**Desventajas:**

* Debugging. Esto en mi experiencia es un problema real. Se que hubo avances con los sourcemaps, etc... pero la experiencia de debuguear coffeescript no es demasiado placentera que digamos, al menos hasta hace más o menos 6 meses.

* Segmentación mental y el argumento de leaky abstraction. Estás laburando en coffee, pero pensando en el javascript subyacente. Con suficiente práctica te despegás del javascript subyacente salvo contados casos. Personalmente no lo encuentro como un problema, pero se que hay gente a la que le molesta.

* Agrega un paso de compilación adicional. En rails (como es nuestro caso) esto no es un problema (viene por defecto).

* Coffeescript es sensible a los espacios. Equivalente a javascript es sensible a los punto-y-comas en mi opinión. Lo que si es un tema es que perdés la posibilidad de usar los espacios para formatear el código. Se puede argumentar sin embargo que muchos de los usos de espacios para formateo es lo que en coffreescript se convierte en sintaxis.

En mi conclusión, es javascript con mejoras sintácticas para cosas que hacemos todos los días (+) pero que trae problemas de debugging y profiling (-). ¿Qué otras opiniones tienen ustedes?

Saludos,

Andrés Arana

2013/7/24 Michel Martens <sov...@openredis.com>

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a rubysur+u...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

[Gabriel Balbuena]

He intentado acostumbrarme a coffeescript y no logro convencerme que la ventaja en una sintaxis mas clara se pague con tantas contras como son los citados por el compañero andrés.

Creo que depende del proyecto y las decisiones que tome el equipo aunque para mi yo daría mi voto negativo sobre si usarlo o no, de ultima si tengo que hacerlo que conste.

Otro punto es que rails viene con coffeejs por defecto lo que me hace llegar al pensamiento que tal vez sea una gran herramienta, esos tipos son unos fenómenos y seguro por algunas razones justificadas lo ponen como parte del framework.

En fin es mi pensamiento

Saludos

--

Gabriel Balbuena

[Angel Java Lopez]

Hola gente!

A ver si logro expresarme

Primero, y principal, y soy "hinchapelotas" pero @dseminara me conoce, espero que me entienda:

- Programar sin TDD codigo de produccion, es como alinear las sillas y las mesas en la cubierta del Titanic,

Bien, dicho esto, luego vuelvo a JavaScript:

- Si bien Arana pone que el paso de compilacion adicional lo tiene automatico con Rails (y no conozco Rails para juzgar la friccion que trae), si codifico JavaScript con TDD, trabajo directo con lo que estoy armando

- Lo que vi de CofeeScript, nunca lo necesite en anios. Siempre pude salir adelante con JavaScript

- Pero codificando con TDD: todo va saliendo, poco a poco, casi no hace falta debuggear. Los Clase.prototype.mifuncion pueden quedar tranquilamente encapsulados. Hay formas de programar con .js separados, testearlos, y luego, usarlos en el browser, incluyendo cada uno, o un simple build que arma un .js que contiene todo nuestro "namespace"

- Y como dije antes, "bite the bullit", si aprenden y trabajan en JavaScript lo van a poder aprovechar en mas contextos.

JavaScript es un gran lenguaje. Vale la pena estudiarlo y practicarlo. No se, en ningun caso de uso que me toco en estos ultimos anios, tuve necesidad de CoffeeScript.

Brego por la simplicidad, no por lo facil. Y cada vez que vuelvo al tema, veo a JavaScript mas simple que CofeeScrip, asi como veo una hamburguesa mas simple que un McDonalds. Cuando uno trabaja con algo simple, es como que tiene menos piezas moviles, y los desafios del proyecto se veran en otro lado, y no en la eleccion de un herramienta simple.

Solo adoptaria CoffeeScript si tuviera una piedra en el zapato, algo que me duela hacer en JavaScript, lo que dirian los americanos PITA (pain in the ass). Y hasta ahora, no lo he encontrado.

Jeje... en cualquier momento hago algo en TypeScript, pero solo para entrenar la neurona ;-)

Nos leemos!

Angel "Java" Lopez

2013/7/24 Andrés Arana <and2...@gmail.com>

[Hernan Fernandez]

Hola

estuve trabajando en un proyecto donde se hizo casi todo con Coffescript, y un scrapper node también en coffescript.

yo tenia experiencia en Js, nunca había usado antes Cs, fue mi primer contacto con un proyecto en Cs.

Si no tenes algo de experiencia en Js yo no te recomendaría tirarte a Cs, aprendé Js y sus yeites para luego pasar a Cs,

debugear es un parto en Cs tenes que terminar compilando a Js para ver el código generado para ver donde salta el error o

debuggear inline con por ejemplo Chrome DevTools, ahi vas a tener que leer Js puro, si no tenes experiencia ... podes tener

un problema.

Pero mi mayor problema con Cs es el mantenimiento, las empresas "grosas" que nombras usan Cs porque tienen un team comprometido

con el código y es una sola app o grupo de apps, si estas laburando en una app que en 6 meses va a ser mantenida por otro o por vos eventualmente vas a tocasr de tanto en tanto, el código se desactualiza, las librerias no enganchan empezas a hacer malabares para que todo cuadre.

Por ejemplo en mi caso scraper node fue echo inicialmente con node 0.8.10 y Cs 1.2, migrar eso a por lo menos Cs 1.6 era todo un tema

Eventualmente compilas Cs a Js y podes seguir con Js ... es una opción, pero tenes que saber/entender js.

Yo te diria, "Sacate el Gusto" hace una parte de la app en Cs y otra en Js, eventualmente migras uno al otro.

Comentario aparte, uno que pinta interesante como un avance sobre Js es TypeScript, opinión de alguien muuy lejos de ser un entendido en lenguajes de programación.

Hernan

2013/7/24 Andrés Arana <and2...@gmail.com>

[Michel Martens]

2013/7/24 Andrés Arana <and2...@gmail.com>:

> En mi conclusión, es javascript con mejoras sintácticas para cosas que
> hacemos todos los días (+) pero que trae problemas de debugging y profiling
> (-). ¿Qué otras opiniones tienen ustedes?

Una anécdota que tiene algo que ver con esto. Cuando salió golang,
no me gustó el hecho de tener que escribir con mayúscula inicial
los métodos públicos. Me parecía tan anti-estético que me costaba
prestarle atención a los demás aspectos.

Lo común en otros lenguajes es declarar qué funciones se van a
exportar, de modo que si agregás la función foo() y querés que sea
pública, tenés que moverte dentro del archivo al lugar en donde
está esa declaración y agregar 'foo' a la lista. En lua, por
ejemplo, no hace falta esa declaración, sino que el archivo que
contiene el módulo tiene que retornar un objeto, y dentro de ese
objeto puede haber funciones públicas y privadas, entonces sólo
las públicas son accessibles. Para que la función no se exponga,
hay que poner 'local ' antes.

Entonces lo que ocurre es que la solución anti-estética en
realidad es la más eficiente, porque en vez de moverse dentro del
archivo para actualizar una lista, o agregar 'local ' como prefijo
a cada definición, lo único que hay que hacer es comenzar el
identificador con mayúscula. Es una edición local (no hay que
moverse), no hay caracteres extras, y además es muy claro y
explícito.

Todo esto para decir que a veces uno juzga una herramienta por la
pinta que tiene, en vez de juzgar la lógica que la fundamenta y la
estructura interna.

En el caso de CoffeeScript, mi primera impresión fue buena, pero
me duró muy poco (hasta que lo probé, digamos). Está diseñado por
un rubista, casi tratando de escribir JavaScript con Ruby,
entonces es un lenguaje más conciso. Pero hay rubismos que no son
nada buenos, como por ejemplo el hecho de que todas las funciones
retornan la última expresión evaluada. Esto parece práctico, pero
el JavaScript que se genera es más ineficiente para los casos en
los cuales no hace falta retornar nada. También está el problema
del scoping: como en CoffeScript no hay diferencia entre declarar
una variable y asignarle un valor, es posible y tal vez frecuente
el shadowing accidental de variables o funciones globales. El
resultado es que en vez de tener un scope lexico, como JavaScript,
tiene un scope dinámico (más difícil de debuggear). Había una
discusión muy buena al respecto en Reddit, pero no la encuentro.
De todas formas, en este issue queda claro el problema y las
respuestas del autor de CoffeScript son un poco tristes:

https://github.com/jashkenas/coffee-script/issues/712#issuecomment-430673

Como hice poco con CoffeScript, no tengo mucho más para decir.
JavaScript tiene algunos problemas que son difíciles de solucionar
sin romper la compatibilidad, pero en general me parece mejor
lenguaje que CoffeeScript. Lo de la compilación y la dificultad
del debugging son complicaciones extra, que estaría dispuesto a
pagar si las ventajas fueran descomunales, pero en mi caso no le
veo ventajas.

[Bruno Aguirre]

Iba a dar una opinion pero soveran lo dijo mejor de lo que podria haberlo hecho yo.

http://bminusblogs.files.wordpress.com/2013/03/cool-runnings-slow-clap.gif?w=590

-- 

elCuervo

[Dario Seminara]

Muy buenos aportes todos, gracias!

Alguien puede compartir alguna experiencia debuggeando CoffeeScript en la utlima version que salio?, es definitivamente mas dificil que debuggear JS puro?

En mi caso particular mi concimiento de Javascript es muy basico (lo minimo para hacer cosas con jQuery y validaciones browser-side), recomiendan desarrollar con CoffeeScript solamente a quien domine Javascript?, o sea, no es como si coffeescript sea un "lenguaje de mas alto nivel" que oculta javascript bajo una capa de abstraccion ? (como programar en Ruby en lugar de C o assembler y no necesitaria conocimiento de estos ultimos para desarrollar en ruby)  

[Hernan Fernandez]

Hola

Coffescript es un compilador a Js, el browser no sabe CoffeScript, por lo tanto un problema en la línea 10 de CoffeScript termina siendo un error en la línea 15 de Js, en la mayoría de los casos es fácil pescarlo, cuando el código se complica ....

Hay una solución al problema de debugging, se llama sourcemaps, Cs soporta SourceMaps, por lo que podes debugear sobre el código Cs directamente con Chrome DevTools.

Ahora, todo esto bien en development, que pasa en production? vas a mandar los archivos de sourcemap a prod para poder debuggear esos elusivos problemas que "anda en mi pc" ?.

http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

http://tarantsov.com/WorkflowThu/source-maps-with-coffeescript-and-uglify-js/

Una de las partes con problemas para mi humilde entender de Cs es http://coffeescript.org/#fat-arrow

una de los "problemas" de Js es el scoping, si miras el código generado por Cs en el link anterior 

esta resolviendo el problema del scoping de "this" de la manera tradicional, peeero eso te resuleve el problema

para algunos de los casos nomas

ej

<a href="#" class=".shoping_cart" data-confirm="true">Comprar</a>

Account = (customer, cart) ->
  @customer = customer
  @cart = cart

  $('.shopping_cart').bind 'click', (event) =>
    if $(@).data('confirm')
      alert 'confirmar compra'

    else
      @customer.purchase @cart

eso falla miserablemente porque cambiaste el scope de this con fatarrow

deberias reemplazar 

if $(@).data('confirm')  por   if $(this).data('confirm')

para no usar el this the Cs (@) que tiene el scope cambiado.

Si vas a usar Cs para hacer "cositas" con jquery, por ahi no valga la pena, si vas a hacer una app

client side por ahi valga la pena.

Hernan

2013/7/24 Dario Seminara <dar...@gmail.com>

[banafederico]

Aca hay uno fresquito, de hoy.

http://donatstudios.com/CoffeeScript-Madness

Enjoy :P

2013/7/24 Hernan Fernandez <hern...@gmail.com>

--

Federico Baña - Software Engineer

banafederico.com
+598 95 279 173

[Bruno Bonamin]

Hola, hace 6 meses empezamos a usar CoffeeScript + AngularJS en una aplicación Rails que tiene poco más de un año. Mi consejo es que si conocés muy bien la sintaxis de Javascript, Coffescript sirve para agilizar la escritura de código, escribiendo menos boilerplate, y en mi opinión, cuando te acostumbrás, es más fácil de leer.

Con AngularJS + Coffee no tuvimos ningún problema más que los primeros días, mientras nos acostumbrábamos a la sintaxis. Sin embargo, como dije al principio, es fundamental poder entender el código que se genera, ya que al debuggear obviamente trabajás con el código javascript generado.

En resumen, por más que se alcen en armas en contra de Coffeescript, creo que es una cuestión de gustos y de lo cómodo que está uno en el lenguaje. Por lo mismo que usamos HAML, que es: escribir menos, que el lenguaje mismo te organice el código (por la tab sensitivity a la Python), sirve mucho para facilitar la lectura y escritura rápida, pero no quita que uno tenga que conocer el lenguaje que se genera por debajo.

My two cents.

Bruno.

--
Bruno Bonamin.

[Bruno Bonamin]

Es verdad lo que decís que el último código fallaría, pero en este caso me parece que es buscarle el pelo al huevo porque en Javascript tendrías que guardar el this de Account dentro de otra variable para poder referenciarla desde dentro del bind.

Probablemente en este caso, el código en Javascript sería más explícito, ya que verías la diferencia entre that.customer y $(this), pero la fat arrow es una excepción, para poder escribir menos y zafar de var that = this.

Bruno Bonamin.

[Michel Martens]

2013/7/25 banafederico <m...@banafederico.com>:
> http://donatstudios.com/CoffeeScript-Madness

El tema del scope y el shaddowing involuntario acaba de cobrarse otra
víctima: el propio compilador de coffee-script:

https://github.com/jashkenas/coffee-script/commit/7f1088054c91f5ab3bf1ea1098b6ebffaa29a5a9

[banafederico]

OH GOD IT'S EVERYWHEREEE

2013/7/26 Michel Martens <sov...@openredis.com>

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a rubysur+u...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

[Dario Seminara]

Que Ironia!

[Dario Seminara]

[banafederico]

jjajaja muy bueno!

2013/7/27 Dario Seminara <dar...@gmail.com>

--

Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a rubysur+u...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Rodrigo Martín]

jauajauajuaj

[Dario Seminara]

Volviendo al debate serio de esto, por ahi lei como argumento a favor de CoffeeScript, el tema de la abstraccion

Entonces, es natural que para responder a las necesidades del desarrollo de software surjan nuevos lenguajes que abstraen a otros (como por ejemplo C o C++ para no tener que programar en Assembler, o Assembler para no tener que programar directamente con los codigos binarios)

En este caso, CoffeeScript al ser de "mas alto nivel" nos estaria librando de las complejidades de Javascript, asi como Ruby nos abstrae de C y es mas sencillo programar cosas en ruby

Entonces la cuestion para mi se reduce a dos cosas:

• Si esa abstraccion es del todo necesaria (o sea, Javascript tiene demasiadas complejidades por ser un lenguaje "de bajo nivel" y se necesita otro lenguaje para abstraernos, como con el caso de Assembler)
  
• Si CoffeeScript en particular abstrae correctamente a Javascript, es decir, a tal punto que podamos olvidarnos del todo que Javascript existe y preocuparnos solamente por el codigo CoffeeScript

No conozco suficiente Javascript como para juzgar si tiene complejidad innecesaria o no, si es necesario otro lenguaje que lo substituya, pero mas o menos me estoy dando una idea de que tan buena es la abstraccion que aporta CoffeeScript 

Segun como lo veo, programar con CoffeeScript para no programar en Javascript NO es lo mismo que programar en ruby para abstraerse de C, 

El interprete de Ruby no funciona conviertiendo el codigo en Ruby a C, esta mucho mas aceitado (parsea el AST y lo recorre, en muchos casos usa una VM como YARV, otros interpretes usan LLVM, por ahi JRuby usando bytecode de java, etc...)

Mientras que el compilador de CoffeeScript lo que hace es convertir codigo de CoffeeScript a JavaScript, y segun mi parecer de ahi vienen las complicaciones, CoffeeScript esta adaptado muy especificamente para poder "compilarse" a Javascript, por lo que el disenio de ese lenguaje esta condicionado por eso, por ahi hay dando vueltas compiladores y/o interpretes de ruby a javascript (por ej: Opal) que por ahi se ajusta mas al camino de lo que buscarian Rubystas que les da "cosa" tocar codigo javascript. No obstante, cualquier "compilador" de ruby a javascript creo q sacrificaria performance, y como ruby no es justamente reconocido por la performance, una version de ruby con menos performance es como q no le gustaria a muchos (y supongo es la razon por la que existe CoffeeScript)

[Hernan Fernandez]

Hola

tecnicamente Coffeescript es un transpiler, toma código fuente y devuelve código fuente.

No le des tantas vueltas, usalo, sacate las dudas con código real, podes volver tranquilamente a js.

Hernan

2013/7/30 Dario Seminara <dar...@gmail.com>

[Dario Seminara]

No es cuestion de nada mas usarlo y ver como anda, sino de reflexionar cuales son las implicancias de usar una cosa o lo otra

Por ahi vi comentarios de gente que se maravillo usando CoffeeScript y tras meses de usarlo se encontraron con las complicaciones

[geronimo diaz]

El 30 de julio de 2013 16:53, Dario Seminara <dar...@gmail.com> escribió:

No es cuestion de nada mas usarlo y ver como anda, sino de reflexionar cuales son las implicancias de usar una cosa o lo otra

Por ahi vi comentarios de gente que se maravillo usando CoffeeScript y tras meses de usarlo se encontraron con las complicaciones

tambien hay que tener en cuenta que cualquier research que hagas para dar solucion a algun problema lo vas a encontrar en la mayoria de los casos en javascript y no en coffee, esto puede o no influir tambien en tu desicion.    

Saludos.

 

--
Geronimo Diaz
Ruby/RoR Developer

t: @gerondimodiaz

g+: gero...@gmail.com

in: http://ar.linkedin.com/in/geronimod

gh: http://github.com/geronimod

[Bruno Bonamin]

Por ahí hay otra gente que lo usa hace meses y sigue maravillado ;-)

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a rubysur+u...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Bruno Bonamin.

[Angel Java Lopez]

Bien, leo a @dseminara:

" Por ahi vi comentarios de gente que se maravillo usando CoffeeScript y tras meses de usarlo se encontraron con las complicaciones"

Cambien "CoffeeScript" por "RubyOnRails", "Hibernate", "NHibernate", "EntityFramework", "SpringFramework", o cualquier otra cosa que parece "facil", y es lo mismo.

De ahi mi postura:

1- Empiecen por lo mas simple, JavaScript

2- Desarrollen con TDD

Si el punto 1 les resulta en un tiempo equivocado, el haber seguido el punto 2 les facilitara el cambio.

A veces, el punto 1 no es que resulta equivocado, sino que llegan a un lugar donde el precio de seguir por lo simple es mas caro que cambiar a algo menos simple. Por ejemplo:

1- Empiezo persistiendo en NoSQL

2- Desarrollo en TDD

en algun momento, necesito la fuerza de una base relacional:

3- Cambiamos a SQL, TDD nos ayuda en el cambio

O sino, otro workflow que he seguido:

1- Empiezo con el modelo en memoria

2- Desarrollo en TDD

3- Los casos de uso salen como arvejas de la chaucha ;-)

4- Cuando ya si o si me piden persistencia cambio a NoSQL o SQL

Otro workflow:

1- Empiezo con persistencia, SQL comandos puros

2- Desarrollo con TDD
3- Cuando ya tengo muchas tablas para seguir con el punto 1, cambiamos a un micro ORM

4- etc....

Si eligen lo simple, y no siguen TDD, no va andar, porque cuando quieran cambiar a algo menos simple, les va a costar, no tienen toda la bateria de tests para ayudarlos en el courage de refactor/redisenio.

Si eligen lo facil (tipo Ruby on Rails), en algun momento se complica, e hicieron una decision temprana, que no sale de ningun test planteado por TDD casi con seguridad

En el caso de @dseminara seria:

1- Empiezo con JavaScript

2- Desarrollo con TDD

3- Cuando alguna vez JavaScript me quede chico (lo dudo) o sea un "pain in the ass", pasamos a CoffeeScript (en anios, jamas he llegado a ese punto)

Pero sera cuestion de probar.

Nos leemos!

Angel "ElHinchaPelotasDeTDDYLoSimpleAntesQueLoFacil" Lopez

@ajlopez

2013/7/30 Dario Seminara <dar...@gmail.com>

[Michel Martens]

2013/7/30 Angel Java Lopez <ajlop...@gmail.com>:
> 2- Desarrollen con TDD

Perdón por abrir esta caja de pandora. Podemos cambiar eso por "Usen tests"?

Yo no hago TDD, pero sí uso tests.

[Dario Seminara]

TDD es una caja de pandora que solo tiene que ver con el inicio y el fin del mundo

Talvez el tema tests, y el tema TDD (una tecnica de disenio que involucra tests), al final resulta ser mas importante de lo que creia (mas importante que Javascript vs CoffeeScript)

@ajlopez esta promoviendo TDD, (y no simplemente "tests"), porque TDD es una herramienta que facilita el cambio interno, mientras podes confiar en que lo externo sigue andando. 

Sin tests, el codigo practicamente no se toca a no ser que se implemente alguna funcionalidad nueva, es el miedo a romper algo si se cambia el codigo, entonces los cambios aparecen solo si se justifican para agregar algun valor funcional (ej: hacer que el proyecto haga X funcionalidad nueva requerida por el negocio) y es poco probable algun cambio del tipo "refactoreo esto para eliminar complejidad", o "cambio esto para aplicar X patron", o "reemplazo tal funcionalidad por tal otra gema que es mejor", etc..

Con tests, la cosa va mejor, ahora sabemos que si tocamos tal parte del codigo, habia tests que la testeaban (!?!?!?!), tenemos tests que testean algunas funcionalidades del sistema que sabemos q no se van a romper (sabemos?) , por lo que tendriamos que testear manualmente solo aquellas funcionalidades que no estan cubiertas por los tests (cuales son?). En definitiva, algunas partes del codigo son receptivas al cambio y se pueden mejorar

Con TDD es optimo, si esta bien hecho, sabemos que TODO esta testeado, por lo que podemos hacer cualquier clase de cambio y tendriamos la seguridad de que nada se rompe si todos los tests pasan, aunque reconozco que incluso con el TDD mas perfecto todavia existira la prueba manual, aunque seria minima.

Ademas, como bonus, TDD te permite diseniar el sistema a travez de los tests, separas el "contrato" que es lo que el sistema, o las partes del sistema tienen que hacer, de la implementacion, que es como lo hace, que es lo que puede variar (para refactorear, para implementar cosas nuevas) siempre y cuando cumpla con ese contrato.

Pero TDD no es gratuito, para implementarlo bien es fundamental que los tests se escriban siempre antes de la implementacion, o para decirlo de otra manera, nunca implementar algo que no sea con el fin de hacer que pase un test, y ademas, actuar a conciencia de que el sistema solo hara lo que se describe en los tests (siempre y cuando todos los tests pasen, claro), ni mas ni menos, cualquier funcionalidad que creamos que existe, por mas que este escrita en la implementacion, si no esta en los test no se garantiza que funcione (o talvez, en lugar de usar el concepto de "funcionalidad" , debamos hablar de "casos")

En la practica (proyectos tipicos que nos tocan a Rubystas y tambien a otros desarrolladores en un laburo), veo que es extremadamente dificil lograr esto, porque?, a mi entender es porque TDD te pide revertir el orden de prioridades

Segun el dia a dia, en un proyecto con requerimientos que vienen constantemente, TDD es solo una herramienta mas (realmente se le debe considerar una herramienta mas) que representa a mi entender algo totalmente NO-funcional (me refiero, a que no hay forma, o es muy dificil de vender como una ventaja mas "nosotros hacemos TDD") y por lo tanto queda relegado a segundo plano, esto significa que cuando se presentan las cosas para hacer: primero se hace lo prioritario segun este contexto, que es que el software funcione como debe hacerlo, y despues, si queda tiempo, viene lo secundario, que son los tests, la mentalidad requerida para aplicar TDD bien, te pide que lo hagas al revez, que hagas primero los tests, que son "accesorios" y que despues hagas lo que "realmente importa" que es la implementacion. Opino que incluso los que saben bien de TDD les costaria mucho trabajo aplicarlo en un contexto asi

Y supongo que es por eso que Michel Martens aclara que solo hace tests, pero no aplica TDD

Aunque para mi es bueno debatir de las dos cosas "hacer test" y TDD

[Angel Java Lopez]

Perdon que insista, pero hay algo que veo que no se entiende. Escribe @dseminara

" primero se hace lo prioritario segun este contexto, que es que el software funcione como debe hacerlo, y despues, si queda tiempo, viene lo secundario, que son los tests, la mentalidad requerida para aplicar TDD bien, te pide que lo hagas al revez, que hagas primero los tests, que son "accesorios" y que despues hagas lo que "realmente importa" que es la implementacion."

Pues justamente: TDD te ayuda a armar el software que funcione como debe hacerlo. No es TDD escribir los test primero, sino ir escribiendo el codigo de a poco, con el minimo codigo que cumpla los ejemplos de uso que le planteamos (llamenlos tests). Codigo de produccion que no se puede tracear hacia atras habiendo nacido de un test, no deberia aparecer.

Sin TDD, no hay forma de asegurar que el software funcione como debe hacerlo CUANDO CODIFICAMOS (luego tendremos que pasar por QA, test manuales, etc). Pero yo veo, y tengo evidencia recogida de seis anios (temo que proyectos privados) que TDD nos da eso: la seguridad (a la etapa de codificar) de que el software funcione como debe hacerlo (estoy hablando de logica, no de pruebas de carga, stressing, etc...)

Cuando refactorizo, o extiendo, o redisenio, y los tests de TDD pasan a verde, tengo una alta confianza que todos los test manuales, de QA, luego van a pasar (de nuevo, tengo evidencia, pero privada). Sin eso, puedo cambiar algo, tener test (no TDD) en verde, y sin embargo, el sistema explota (tengo evidencia).

Con respecto a:

"Opino que incluso los que saben bien de TDD les costaria mucho trabajo aplicarlo en un contexto asi"

El contexto de cambio es uno de los mejores para armar TDD. Yo lo aplico desde hace anios, y no me cuestra trabajo aplicarlo en un contexto asi. Ahora estoy en la cuarta iteracion semanal de un proyecto, y tengo cambios y el sistema sobrevive. He hecho refactor quirurjico y sobrevive. Hemos descubierto abstracciones e implementaciones alternativas, que agregaron valor al negocio, que no estaban en los planes iniciales, se agregaron y sobrevive.

(en realidad, cada nuevo test es un cambio en los requerimientos, si quieren verlo asi. Por eso tambien digo que TDD esta hecho para el cambio)

Por otro lado, tengo proyectos sin TDD, escritos por gente brillante, y son inmantenibles (tambien habra alguno mantenible, pero es raro), y tienen mucha inercia al cambio. La gente sin TDD se "mambea" como se dice aca en Argentina. TDD permite el crecimiento organico (disculpen de nuevo, no tengo evidencia mostrable negativa, son todos proyectos privados).

Espero que Martens (que juega al Go) aprecie lo que quise poner en:

http://msmvps.com/blogs/lopez/archive/2013/01/22/tdd-y-el-juego-del-go.aspx

TDD es un workflow que permite el crecimiento organico de lo que estamos haciendo, porque hacemos crecer al "organismo" que es el software en construccion, desafiandolo de a poquito: "bueno, ahora hace esto" y el software lo hace. "Bueno, ahora necesitamos esto", y el software lo hace. 

Claro, TDD no es todo. Como puse en algun lado, es TDD y cabeza. Hay que poner cabeza en los elementos iniciales. Hay que poner cabeza en el refactor. Hay que hacer code review. Pero, para mi, escribir codigo de produccion sin TDD deberia estar prohibido ;-)

Que nadie se quede con la idea: TDD es dificil de aplicar "en un proyecto con requerimientos que vienen constantemente".

Justamente, cada test (yo los agrego de a uno) es un nuevo requerimiento.

Angel "TDD" Lopez

@ajlopez

2013/7/31 Dario Seminara <dar...@gmail.com>

--

[Dario Seminara]

Esto me hace cambiar un poco de opinion

Ahora pienso que TDD si es aplicable, pero segun coo lo veo siempre y cuando sea un valor adicional que se vende en el proceso de desarrollar software, como algo que agrega valor al servicio

"Desarrollo tu software para que haga lo que requeris, pero ademas hago TDD con lo que se vuelve mucho mas mantenible y con una calidad mejor"

Entonces, asi se justifica:

Cliente: "necesito X funcionalidad para maniana"

Desarrollador: "no se puede hacer para maniana, porque requerimos tiempo para escribir primero los tests"

Cliente: "es verdad, es mejor siempre tener tests primero"

Para pensar: a que clase de clientes de software a medida, se le puede convencer facilmente de las ventajas de TDD?

[Angel Java Lopez]

Jaja! @dseminara, me das trabajo para una tesis! ;-)

Aca tengo un cliente, con dos sistemas, A y B.

A fue escrito sin TDD.

B fue escrito con TDD.

El cliente no pidio TDD, y tampoco se puso a ver los detalles.

Cuando quiere algo para B, un nuevo requerimiento, a veces lo hicimos/implementamos en 2 horas. Ya tenemos toda la red de contencion de TDD, las clases de soporte, modelos en memoria, todos los anteriores casos de uso cubiertos, etc...

Cuando quiere algo nuevo para A, ahora es dificil de convencer que no lo podemos hacer en 2 horas, se malacostumbro con B ;-) Hemos tardado dias (y hasta semanas en un caso) arreglar algo en A.

Cuando se paso el presupuesto de tiempo para A, no se penso en TDD. Yo lo impuse en el medio del desarrollo. Y salio con TDD, en tiempo y forma (yo diria que antes del tiempo acordado, tuvimos tiempo para otros overdelivery).

TDD no cuesta. TDD pays ;-)

Angel "MasQueHinchaPelotasYaConTDDMePuedenMandarAPasearCuandoQuieran" Lopez ;-)

2013/7/31 Dario Seminara <dar...@gmail.com>

[Michel Martens]

Aclaro que uso TDD, pero no todo el tiempo. También hay que tener
en cuenta que el código que escribo está testeado, no es que meto
en producción código sin tests automatizados.

Creo que TDD es útil cuando la API está definida, pero cuando el
problema es diseñar una API es muy difícil encarar el problema sin
la libertad de explorar primero. En ese caso, TDD nos impone mucho
trabajo mental sin la ayuda de código exploratorio.

(Cuando digo API no me refiero a HTTP + JSON, sino a la interfaz de
cualquier componente de software, desde algo grande como un
webserver hasta algo chico como una función.)

Lo que sí me parece importante es tener tests (sin importar el
origen), y sobre todo que el código sea testeable. Acá hay algunos
datos sobre cómo diseñar para que el código sea testeable, hay
mucha bibliografía sobre esto:

http://en.wikipedia.org/wiki/Test-driven_development#TDD_for_complex_systems

Yendo a la analogía del go: uno puede imaginar una secuencia de
jugadas y actuar en consecuencia. Si uno pudiera ayudarse con un
tablero, pensar en esa secuencia de jugadas sería más simple
porque uno tiene la posibilidad de probar en vez de imaginar.
Cuando se trata de una secuencia conocida, donde ya no es tanto
"imaginar" sino más bien "recordar", entonces el tablero no brinda
tanta ayuda. Esto equivaldría a diseñar una API (imaginar) versus
usar una API (recordar). El código exploratorio hace las veces de
tablero.

Dentro de XP, lo del código exploratorio está contemplado en
cierta medida en el concepto de spike:

http://c2.com/cgi/wiki?SpikeSolution

> Por otro lado, tengo proyectos sin TDD, escritos por gente
> brillante, y son inmantenibles (tambien habra alguno mantenible,
> pero es raro), y tienen mucha inercia al cambio. La gente sin
> TDD se "mambea" como se dice aca en Argentina. TDD permite el
> crecimiento organico (disculpen de nuevo, no tengo evidencia
> mostrable negativa, son todos proyectos privados).

Sin TDD o sin tests?

Hay de todo: proyectos inmantenibles (con o sin tests) y proyectos
mantenibles (con o sin tests). Hay proyectos hechos con TDD que
son inmantenibles.

Mantenible, sin tests:

https://github.com/soveran/sc

Mantenible, con tests:

https://github.com/cyx/armor

Inmantenible, con tests:

https://github.com/rails/rails

Inmantenible, sin tests:

http://www.procmail.org/procmail-3.22/src/procmail.c

Si uno ve este commit, por ejemplo:

https://github.com/cyx/armor/commit/4aaa375ba617bfe0eb5bdf51466e7e5a837b4d44

Es difícil saber si se usó TDD o no, al punto que resulta
irrelevante. Una vez que la API de Armor quedó definida, agregar
tests (y hacer TDD) resulta natural.

A lo que iba con mi planteo original tiene que ver con que me
parece que poner la metodología por delante no es lo mejor en
todos los casos. Mirá esta entrevista laboral:

Empleador: --Dígame, señor Norvig, ¿usted hace TDD?
Peter Norvig: --Casi nunca.
Empleador: --Lo siento mucho, no podemos contratarlo.

Media hora después se presenta Juan Carlos Tededé, alumno de
primer año en la UTN, y queda contratado.

Un poco de esto está pasando, y ni Kent Beck ni Ron Jeffries hacen
todo el tiempo TDD como para pasar esa entrevista. Entonces el
riesgo es que el énfasis queda puesto en un aspecto que por sí
solo no determina la calidad del código.

[Angel Java Lopez]

Si, por eso digo que TDD no asegura nada. Es TDD y cabeza:

http://msmvps.com/blogs/lopez/archive/2013/03/08/tdd-y-dise-241-o-de-implementaci-243-n-1.aspx

TDD no ayuda solito a dar una solucion de implementacion. Por eso se necesita cabeza.

Pero yo tambien tengo casos de API cambiable. Y con TDD voy explorando. En otro thread, le recomende a @dseminara el caso de spikes, cuando tiene que probar algo NO ESCRITO POR EL. O para practicar algo como aprender como dibujar en el canvas de HTML5. Pero lo que escribimos nosotros, tranquilamente podemos tambien adoptar TDD. Ejemplo cambiable de API, lo tengo todo el tiempo en proyectos personales (al fin algo publico para mostrar!), dos en JavaScript (para volver al tema inicial de este thread):

https://github.com/ajlopez/SimpleProlog

https://github.com/ajlopez/SimpleGrammar

Pueden ver la historia de commits por test (algo alguna vez sugerido por @dseminara en un almuerzo hace unos anios, aunque yo lo adopte de casi a un test; el creo que prefiere escribir 10 o mas test y despues ir volteando muniecos ;-), para dar evidencia de "put money where mouth is"

Ni idea de todos los requerimientos del interprete Prolog en el primer caso. Estoy explorando la implementacion. Lo mismo con el generador de parsers del segundo caso. Y asi en otros proyectos personales, en otros lenguajes y tecnologias. Lo mismo trato de hacer en los privados.

Hmmm... con respecto al ejemplo de Go, mi idea era mostrar que no hace falta pensar las jugadas para adelante en muchas situaciones. Con TDD "estoy bien": no pregunto cuantos son, sino que vengan de a uno (los nuevos requerimientos ;-)

Angel "Java" Lopez

@ajlopez

2013/7/31 Michel Martens <sov...@openredis.com>

[Michel Martens]

> Pero yo tambien tengo casos de API cambiable. Y con TDD voy
> explorando.

Con tests, los tests no son potestad de TDD. Con tests podés
mandarte a cambiar una API, no hace falta que sea TDD.

> Con TDD "estoy bien": no pregunto cuantos son, sino que vengan
> de a uno (los nuevos requerimientos ;-)

Con tests estás bien.

[Dario Seminara]

Ese argumento ya lo lei

"TDD no consume mas tiempo, sino que ahorra tiempo" 

Pero en el arranque consume mas

Mi cuestion es como se justificaria el tiempo extra (eso, cuando hay tiempo extra) que requeris para hacer TDD, como se hace para explicar que si al principio se tarda mas, eso sirve para ahorrar mucho tiempo en el futuro?

[Angel Java Lopez]

Concuerdo con

"Con tests podés
mandarte a cambiar una API, no hace falta que sea TDD."

Pero he visto que TDD ayuda a ir avanzando en el codigo de implementacion sin poner algo demas, o algo demasiado grande. Eso es lo que destaco de TDD en el dia a dia de desarrollo.

Trabajando en equipo, en proyectos privados, sin TDD, sin ese gusto por "poner lo minimo que anda", veo que se tiende a poner codigo de mas y romper YAGNI. Hay que tener mucha disciplina para que todos se coordinen para no poner codigo de mas. Con el sombrero TDD puesto, eso se consigue mas facil (por supuesto, tienen que haber "comprado TDD" y poner cabeza, sino tambien, ponen codigo de mas y rompen YAGNI).

Tengo aca un caso del anio pasado: un simple requerimiento que, aplicando TDD, se resolvia con 10 lineas de codigo. Sin TDD, el equipo lo implemento, puso los test, etc. Pero la implementacion supuso poner una rule engine, un inyector de dependencias, y como digamos 5 clases adicionales. Eso es lo que evita el flujo de TDD.

Tengo aca otro caso: un requerimiento no tan simple, el equipo escribiendo sin TDD se mando a adoptar una tecnologia que aparentemente resolvia el problema. Un anio mas tarde, esa tecnologia sigue siendo un "pain in the ass". Borrar elementos no usados en el dominio, la ultima vez tardo 23 horas, por la influencia directa e indirecta de esa tecnologia. Programando con TDD, poniendo el minimo codigo, se pudo alcanzar el mismo set de requerimientos, y el proceso de ese requerimiento de horas, ahora se podria hacer en menos de 10 minutos. Pero el sistema original ya esta en produccion... snif... snif ;-)

Angel "Java" Lopez

@ajlopez

2013/7/31 Michel Martens <sov...@openredis.com>

> Pero yo tambien tengo casos de API cambiable. Y con TDD voy
> explorando.

[Dario Seminara]

Los tests automatizados sirven un monton, pero segun mi forma de ver usar TDD es mucho mejor que solo conformarse con tests

Si estas diseniando un API, seria buen comienzo escribir primero los tests para darte la idea de que metodos tiene esa api y que esperas que devuelva, y despues vas implementando el api para que pasen los tests (y asi empiezan los ciclos de TDD)

Con tests, podes mandarte a cambiar el API, pero los tests que son producto de haber aplicado TDD seran mucho mejores porque te garantizan que testean todo lo que mas importa (porque sabes que todo lo que escribiste esta funcionalmente cubierto por esos tests)

Con esto no digo que hay q usar TDD si o si para todo, como dije antes hay casos en que por H o por B usar TDD se vuelve engorroso, pero para mi es clara la ventaja de usar TDD sobre simplemente usar "tests"

[Angel Java Lopez]

Ah! @dseminara! Me estas llevando a escribir un libro ;-) ;-)

Como sabes que "al arranque consume mas"?

Yo tengo aca dos casos:

- Un proyecto privado, con algun requerimiento no simple. Se encaro el requermiento mas importante, con TDD. TDD nos llevo a armar una solucion, que siguiendo el minimo codigo, no necesitaba ni base de datos. Empezo un lunes, el viernes teniamos el caso de uso implementando, listo para mostrar en la iteration review, con el cliente pudiendo apreciar si era lo que necesitaba o no. Sin TDD, sin ese gusto por "implementar lo minimo" mucho de la implementacion no hubiera surgido de la manera que surgio (tengo otros proyectos, misma gente, mismo cliente, y no aparece un caso de uso implementado hasta la tercer semana, digamos)

- Otro proyecto, privado tambien. Sin TDD, el equipo tardaba 4 semanas en implementar un requerimiento. Con TDD, pensando en el minimo codigo, se pudo implementar en 1 semana. Y luego tenemos mas feedback del cliente, y podemos refactorizar con courage, y agregar lo que haya que agregar, etc.

- El proyecto B que mencionaba en otro email. En una semana, el cliente tuvo un caso de uso principal en el aire, y pudiendo entregarse a otro equipo, para que lo fuera consumiendo. Jeje... de hecho, el otro equipo se confio que no le ibamos a entregar algo hasta dentro de dos meses, y los sorprendimos offside ;-)

Angel "Java" Lopez

@ajlopez

2013/7/31 Dario Seminara <dar...@gmail.com>

Ese argumento ya lo lei

[Michel Martens]

2013/7/31 Angel Java Lopez <ajlop...@gmail.com>:

> Tengo aca un caso del anio pasado: un simple requerimiento que, aplicando
> TDD, se resolvia con 10 lineas de codigo. Sin TDD, el equipo lo implemento,
> puso los test, etc. Pero la implementacion supuso poner una rule engine, un
> inyector de dependencias, y como digamos 5 clases adicionales. Eso es lo que
> evita el flujo de TDD.

Eso no tiene nada que ver con la metodología que uses, es
programar bien versus programar mal.

[Lorenzo Jorquera]

Ese argumento ya lo lei

"TDD no consume mas tiempo, sino que ahorra tiempo" 

Pero en el arranque consume mas

Mi cuestion es como se justificaria el tiempo extra (eso, cuando hay tiempo extra) que requeris para hacer TDD, como se hace para explicar que si al principio se tarda mas, eso sirve para ahorrar mucho tiempo en el futuro?

 
Tu cuestión no es sobre TDD, es sobre tests o no tests (porque el tiempo para escribir los tests tendrías que tomarlo en cuenta independientemente de si es antes o despues).

La respuesta creo que tiene varias partes, entre ellas:
         1. manual o automaticamente, vas a tener que probar tu código antes de decidir que ya está listo. Escribir tests es una manera de reutilizar el tiempo que usarías para probar manual.

         2. escribir un poco más de código (los tests) en realidad no lleva mucho más tiempo. Uno se pasa mucho más tiempo leyendo/entendiendo/debuggeando código que escribiendo. Los tests bajan los tiempos de estas actividades, en particular, los de una actividad que lleva muchísimo tiempo que es determinar que fue lo que causo un error en base a un reporte de usuario o de QA.

Una cosa que me llama la atención es que hay otras actividades que llevan tiempo y que no tienen que ver con el desarrollo puro y duro de una feature. Por ejemplo refactoring, elegir nuevos nombres, etc. Porque no se cuestionan estas actividades y si los tests?

[Jano González]

2013/7/31 Michel Martens <sov...@openredis.com>

Estoy de acuerdo con Michel en este debate, las metodologías son ayudas y no un fin en si mismas. Por ej. uno no usa agilidad para "ser ágil" sino para ayudarse a "producir software de calidad en un tiempo razonable respondiendo a requerimientos cambiantes".

En mi caso, TDD me ayuda bastante, pero no creo que sea una práctica obligatoria para cada tipo de proyecto. 

--
Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a rubysur+u...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

--

Jano González

http://janogonzalez.com

[Lorenzo Jorquera]

Eso no tiene nada que ver con la metodología que uses, es
programar bien versus programar mal.

A mi TDD me ayuda a

  escribir codigo testeado

  escribir código en micro iteraciones

  ejecutar mucho los tests

  obtener feedback rápido de mis APIs

  escribir código fácil de testear (lo cual en general implica mejor código)

  etc.

No significa que no pueda obtener estos beneficios sin TDD pero a mi particularmente la metodología me hace más fácil lograrlos.

No es ninguna bala de plata, un mal programador escribiendo codigo TDD no va a programar bien.

Yo lo tomo como una herramienta que potencia mi capacidad y entiendo perfectamente que a alguien no le sume, pero probablemente sea porque ya estaba obteniendo de otra manera todas las cosas que TDD tiende a facilitar.

[emanuelF]

El 31 de julio de 2013 13:06, Michel Martens <sov...@openredis.com> escribió:

Creo que TDD es útil cuando la API está definida, pero cuando el
problema es diseñar una API es muy difícil encarar el problema sin
la libertad de explorar primero. En ese caso, TDD nos impone mucho
trabajo mental sin la ayuda de código exploratorio.

(Cuando digo API no me refiero a HTTP + JSON, sino a la interfaz de
cualquier componente de software, desde algo grande como un
webserver hasta algo chico como una función.)

bellisimo.

--

Emanuel Friedrich - Casi licenciado en Sistemas... :)
Cel: 3754-495887

Haya paz

[Dario Seminara]

Para mi la cuestion tambien es si TDD o no TDD, los tests producto de la practica de TDD para mi siempre seran mas utiles que simplemente "hacer tests", otra cuestion sera si conviene usar o no TDD segun el contexto

[Andrés Arana]

En ese aspecto me parece que depende a la escala que lo estés usando. Yo argumentaría que cuando estás diseñando algo chico (como una función o incluso una clase), TDD te ayuda a explorar, justamente porque podés pensar en cómo funciona desde el lado de cliente, explorando las alternativas de cómo se podría invocar la función, qué esperaría el cliente como resultado, etc.

Ahora, cuando hablás de cosas más grandes (colaboraciones entre componentes, páginas, flujos completos de interacción, cosas que requieren validación estadística como usabilidad, conversión, etc...), estoy de acuerdo con vos, TDD se mete mucho en el medio para esos casos y no aporta demasiado me parece.

En definitiva, como bien decís, todo depende del contexto de lo que estés haciendo y de pesar los pros y los contras en tu situación particular. Y hacer TDD todo el tiempo es ignorar el contexto, algo tan malo como no hacerlo nunca IMHO.

Con respecto al comentario que había dando vueltas de que "es agregar un poco de código, no te lleva tanto tiempo". Por un lado, no te lleva tanto tiempo es como cuando hay que discutir con un PM de que "es cambiar un color, por qué te lleva tres días?". Todo depende de lo que estés analizando, de la implementación de lo que ya tengas y de los requisitos y constraints particulares con los que estás laburando. Te desafío a que encuentres, por ejemplo, una manera limpia, con poco código y que no lleve tanto tiempo de probar UI de aplicaciones mobile multiplataforma. Fuera de eso, también puedo agregar las pruebas después de que terminé mi fase exploratoria (para escalas en donde TDD no ayuda con la fase exploratoria).

Andrés Arana

2013/7/31 emanuelF <aemanuel...@gmail.com>

[Leandro Marcucci]

TDD es una técnica más dentro de nuestro oficio, pero no da convertirlo en un dogma tan inflexible como plantean.

Coffeescript es una herramienta más. A mi me parece mala idea, y no la eligiría. Nunca.

[Dario Seminara]

Para mi TDD al decidir aplicarlo tiene que ser como un dogma, es una tecnica que se basa en absolutos: es acerca de testear absolutamente TODO, de no implementar absolutamente NADA sin haber escrito un caso de prueba primero, de otro modo, de no aplicarlo como un "dogma inflexible", lo que se estaria haciendo no es TDD, sino otra cosa distinta (no digo que no sirva, solo que no seria TDD)

Otra cuestion aparte es la aplicabilidad, no tiene sentido caer en el "dogma" de usar TDD en absolutamente todo, pero cuando se usa, hay que usarlo siguiendo los preceptos absolutos que plantea la herramienta

[Alejandro Paciotti]

Dario: ¿dónde se pueden leer los "preceptos absolutos que plantea la herramienta"?

Gracias!

--

Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a rubysur+u...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Alejandro...@gmail.com

[Porta]

2013/8/1 Dario Seminara <dar...@gmail.com>

--

Has recibido este mensaje porque estás suscrito al grupo "rubysur" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a rubysur+u...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Nicolás Berger]

Yo creo que usar TDD de una forma dogmática e inflexible, es
contraproducente. O imposible. En general es muy costoso testear
absolutamente todo. Ya sea en que es costoso escribir los tests para
testear "absolutamente todo", o porque los tests terminan siendo muy
inflexibles y ante cada cambio en la aplicación se propagan demasiados
cambios en la suite de test.

Igualmente hay que ver a qué te referís con testear "absolutamente
todo". Tal vez quisiste decir "testear casi todo"?

Uso mucho TDD, a mi manera. Me gusta pensar que principalmente es una
red de contención (ya nombraron antes ese punto de vista, creo que
ajlopez). En cada caso, evaluo qué tipo de contención me parece
necesaria. Ante determinada complejidad o riesgo, uso tests unitarios.
En otros casos considero que es suficiente con la red de contención
que brindan los tests de aceptación que corren el stack completo.

También cambia mucho según el tipo de proyecto.


2013/8/1 Dario Seminara <dar...@gmail.com>:

[Guillermo Iguaran]

On Thursday, August 1, 2013 at 9:27 AM, Dario Seminara wrote:

Para mi TDD al decidir aplicarlo tiene que ser como un dogma, es una tecnica que se basa en absolutos: es acerca de testear absolutamente TODO, de no implementar absolutamente NADA sin haber escrito un caso de prueba primero, de otro modo, de no aplicarlo como un "dogma inflexible", lo que se estaria haciendo no es TDD, sino otra cosa distinta (no digo que no sirva, solo que no seria TDD)

Otra cuestion aparte es la aplicabilidad, no tiene sentido caer en el "dogma" de usar TDD en absolutamente todo, pero cuando se usa, hay que usarlo siguiendo los preceptos absolutos que plantea la herramienta

Creo que te equivocas Dario, TDD no fue pensado ni para ser un dogma, ni para basarse en absolutos, TDD fue pensado para ser usado de esta manera:

http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565

Saludos

--

Guille

[Dario Seminara]

De lo contrario es preferible no usar TDD, lo que no significa que no se hagan tests y que estos puedan servir de algo

Segun como lo veo, TDD no es una herramienta pensada para ser flexible, sino mas bien lo contrario: solo sirve si te ajustas rigidamente a todos los "dogmas"

Lo que si es flexible, y esto pasa con casi todas las herramientas, es el ambito de aplicacion. Por ejemplo, si estoy desarrollando rails podria optar por usar TDD para el modelo y no para la vista ni para los controllers, entonces puedo confiar en el codigo del modelo y la logica, y pensare otras alternativas para desarrollar, diseniar y testear la vista y los controllers

O por ejemplo una gema que parsea XML, eso va con TDD como piña

[Dario Seminara]

El mensaje se envio a la mitad :S

Lo que decia

Para mi TDD se tiene que usar solo siguiendo las reglas sin excepcion:

• No se cambia/implementa nada si no es con el proposito de que pase un test
• Al hacer que pasen los test, seguramente la complejidad del codigo aumentara, es necesario mantenerla al minimo necesario para que pasen los test (por ej: si el unico test pide que un determinado metodo devuelva 1, entonces eso es todo lo que el metodo tiene que hacer)
• Al hacer refactor, la complejidad del codigo nunca deberia aumentar, si es posible tiene que simplificarse, porque haciendo refactor esencialmente no se implementara nada nuevo

De lo contrario es preferible no usar TDD, lo que no significa que no se hagan tests y que estos puedan servir de algo

Segun como lo veo, TDD no es una herramienta pensada para ser flexible, sino mas bien lo contrario: solo sirve si te ajustas rigidamente a todos los "dogmas"

Lo que si es flexible, y esto pasa con casi todas las herramientas, es el ambito de aplicacion. Por ejemplo, si estoy desarrollando rails podria optar por usar TDD para el modelo y no para la vista ni para los controllers, entonces puedo confiar en el codigo del modelo y la logica, y pensare otras alternativas para desarrollar, diseniar y testear la vista y los controllers

O por ejemplo una gema que parsea XML, eso va con TDD como piña

[Matias Mascazzini]

TDD es una practica dentro de las Metodologías Ágiles, no se olviden de ese detalle.

Un grande Angel en evangelizar sobre esto =)

Saludos
Matías

2013/8/1 Dario Seminara <dar...@gmail.com>

--

[Dario Seminara]

Para volver al tema de coffeescript y los memes :)

Consideran que Coffeescript es un lenguaje peligroso, o es spiderman proclive a enfermar de cancer por cualquier cosa?