Uno_QuePasabaPorAqui escribió:Este youtuber (parece que desarrollador de profesión) comenta cosas interesantes (a partir del min. 5), pero ni entiendo ni comparto sus conclusiones (que los bugs son normales, básicamente). Al final del vídeo le echa un cable a HP, que le ha debido de dar lástima, en fin.
Pero oye, más razón que un santo con lo que dice hacia el minuto
10:30.
Bien, intentaremos explicarlo de la sencilla posible.
El código interpretado es cuando se lee 1 linea, se convierte a código máquina por el interprete, se lee la siguiente linea de código, se convierte a código máquina y así sucesivamente hasta que no queda más código por interpretar. Funcionan sí lenguajes como javaScrip (ecmaScript realmente), python o php.
El codigo compilado significa que conviertes todo el código directamente a código maquina, en vez de ir paso a paso. Eso hace que los lenguajes compilados suelan tener un mejor rendimiento que los interpretados.
De lo que habla, según él, yo no lo se porque no manejo unity (ni me he metido en desarrollo de juegos de momento), aunque si sé que se programa en C#, es que en modo editor funciona interpretando la parte que estas programando. Y ahora que lo pienso tiene sentido (no necesitas compilar todo para testear en ese momento).
La diferencia de rendimiento entre ambos es lo que puede provocar errores imprevistos que solo puedes conocer si pruebas la build, es básicamente a lo que se refiere. (Realmente C# se compila primero y luego se interpreta por una maquina virtual a código máquina como ocurre con Java, pero tampoco hace falta entrar en más detalles).
Pero ahora te digo yo, que en un desarrollo de software, sea del tipo que sea, no debe faltar una persona minimo (o más si es posible económicamente) testeando las builds y reportando fallos. Una persona dedicada a los test unitarios que todo software debe tener mientras se desarrolla. Y aquí da la sensación de que esa parte se la saltan. Solo con el hecho de presentarte con una build sin compilar ni testear ya dice mucho.
No dice que los bugs sean normales, es un hecho que van a haber bugs en todo desarrollo de software porque somos humanos y nos equivocamos, más en un que parece tener bastantes junior sin experiencia previa. Es completamente inevitable. Lo que no es normal es que si has sido programador, no sepas esto. No pares de dar fechas y no pares de meterte en problemas que no necesitas. Metiendo presión al equipo, metiendote tu presión, y encima meterte a redes a contestar en vez de tratar de salvar el barco. Eso no es lo normal en un desarrollo de software. ¿Ves a la gente de Team Cherry dando fechas de Silksong? Ni falta que hace. Si tienes algo lo muestras y sino te callas hasta que tengas algo que mostrar. Esa es la parte que no entiendo, ¿que necesidad hay de dar fechas y fechas y fechas para incumplirlas? Forzar a tu equipo a trabajar bajo presión, haciendo con ello que puedan cometer más fallos de los que tendrían normalmente. Es un sin sentido.
Cuando dice que mucho del tiempo de desarrollo se dedica a corregir bugs, dice toda la verdad. Y no en este, pasa en todos los proyectos de software y seguirá pasando. además cuanto más complejos son más probabilidades de que surgan bugs. Lo que no es normal es toda la pantomima de fechas en las que se ha metido y meterte a redes sociales a contestar a todo dios porque tu solo te has puesto en el punto de mira. Que presentes buidls sin testear a la prensa y toda esta gestion que el solito se ha buscado. Y lo peor, sin necesidad, porque de haber tomado el camino de la honestidad en vez de emperrarse que el juego estaba acabado hace meses, la gente lo habría comprendido, porque es así. Los retrasos por bugs en el desarrollo de software son comunes y cuanta menos experiencia tiene el equipo de desarrollo más probables son.