Java vs .Net

[Daniel Molina Wegener]

On 13/06/12 22:14, Felipe wrote:
> La verdad Javier, estoy en profundo desacuerdo contigo. Me refiero
> especificamente a la frase:
>
> "permiten enfocarse de mejor manera en la lógica de negocio del sistema,
> en lugar de estarse preocupando por el código en si".

   No estoy de acuerdo al 100% con tus ejemplos, pero si en varios
aspectos. Eso viene del mito nacido con Visual Basic 5/6  de que
"cualquiera puede programar y /este lenguaje/ es la panacea".
Creo que no existe mito mas falso... ;)

>
> La verdad, ambos aspectos son importantes, y el desarrollo se vuelve mas
> colaborativo, escalable y ameno con buenas practicas de desarrollo que
> son transversales a todos los lenguajes de programacion y stacks
> tecnologicos.
>
> Algunos ejemplos de porque si hay que "preocuparse del codigo en si":
>
> Ejemplo #1:
> Tienes un servicio critico en una nube en Windows Azure y de pronto se
> cae. Tienes 0 segundos para arreglarlo y cada segundo que pasa significa
> una perdida significativa.
>
> Ves los logs, pero no hay nada. Solo hay "OLAA AQUI ESTOY PASANDO!!" y
> tonteras similares. Abres Visual Studio, y por no preocuparte del codigo
> en si, terminas revisando miles de lineas de codigo, donde posiblemente
> algunas de ellas no estan en uso, y ocupas mucho tiempo en proporcionar
> una solucion. Para cuando terminas, el downtime total genero nuevos
> problemas con consecuencias graves para "el negocio".
>
>
> Ejemplo #2:
> Tu jefe contrata mas gente, los hace trabajar contigo, pero por no
> preocuparte del codigo en si, nadie se siente capaz de agregar nuevas
> funcionalidades o corregir un defecto.
> Despues de mucho tiempo invertido, la persona hace un commit y todo se
> rompe.
>
>
> Ejemplo #3:
> 2 personas intentan trabajar, pero todo esta en una clase gigante. Elige
> el desenlace:
> a) Para evitar hacer un merge gigante, una de las personas se va a tomar
> un cafe y a leer el diario. La empresa cambia dinero y cafe a cambio de
> nada.
> b) Hacen un merge gigante, se demoran 20 minutos y meten un bug nuevo.
> El log de control de versiones tiene un merge por commit.
>
>
> Ejemplo #4:
> Quieren agregar pruebas de unidad. Tarde en el desarrollo, como siempre
> ocurre cuando no te preocupas del codigo en si. Pero como esta todo
> acoplado. Implementar una prueba a nivel unitario se vuelve imposible y
> tu prueba se vuelve equivalente a correr el programa completo.
> Hacer un deployment a produccion se vuelve un juego de azar. La
> integracion continua se vuelve imposible o pierde sus ventajas.
>
>
> Ejemplo #5:
> Te llega un reporte de bug. Arreglas la porcion de codigo afectada pero
> por no reutilizar codigo (pues para que preocuparse del codigo en si),
> hay codigo que resuelve el mismo problema en secciones distintas del
> proyecto. De pronto, tienes un bug fix parcial y alargaste el QA una semana.
>
>
> Asi que, en mi opinion, el codigo siempre es importante. No es lo mas
> importante, y no es lo unico importante, pero es importante.
>
> Gracias,

Atte.
-- 
Daniel Molina Wegener <dmw [at] coder [dot] cl>
System Programmer & Web Developer
Phone: +56 (2) 979-0278 | Blog: http://coder.cl/