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". 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, -- Felipe On 06/13/2012 06:35 PM, Javier Garay wrote: > Un amigo que trabaja como jefe de proyectos con .Net me dijo que Mono > es un proyecto que esta algo ¿abandonado? Por otra parte, .Net hace > las cosas mucho mas fáciles a los desarrolladores, con sus asistentes > y templates de código para miles de funciones, un ide mucho mas > completo e integrado, permiten enfocarse de mejor manera en la lógica > de negocio del sistema, en lugar de estarse preocupando por el código > en si, y java no es una plataforma muy "fácil" para cualquier tipo de > proyecto. Todo eso sin mencionar las posibilidades que brinda C#. > > Yo al menos creo que ambas plataformas tienen lo suyo, pero que .Net > tiene sin dudas un mejor progreso que Java, gracias al trabajo de MS. > No veo que Oracle este muy "in" con Java. > > > Cordialmente, > Javier Garay G. > Ingeniero en Informática. >
