Ver la versión completa : [programación] Por qué está mal hacer esto?
akualung
12/02/2014, 22:40
Hola, lanzo una pregunta a los "cracks" de la programación que hay en este foro que sé que sois muchos y buenos, jejeje. Se trata de una cosa que leí hace ya bastantes días y, pese a que no le dí importancia, desde entoces me ha estado rondando la cabeza y al fin me he querido quitar el gusanillo de encima preguntando. El mensaje es de una noticia de menéame y dice esto:
"#8 No me sorprende nada, en la empresa en la que estoy tenemos un ERP creado por una consultora externa que es ATERRADOR. Si se hicieran una lista de todas las malas prácticas del planeta tierra y sus cercanías y se pusieran todas en una aplicación PHP sería igual a esta.
De todas las burradas que tiene hay una que me encanta: La conexión a la base de datos es una clase estatica, la cual se instancia en un archivo y luego se inyecta a toda la aplicación en variables superglobales"
El mensaje en cuestión proviene de aquí, de un tal Pablosky: http://www.meneame.net/story/merece-pena-hacer-cosas-bien-esta-profesion
Y la duda que me asalta es: por qué está mal hacer eso? A ver, si ese chico dice que es una burrada, me lo creo, pero como he hecho pocas aplicaciones "tochas" , pues como que me falta todavía rodaje en temas más de análisis y de estructurar la aplicación.
Tangencialmente: ¿conoceis y me podeis recomendar algún buen libro para aprender a estructurar bien una aplicación? Es decir, no el típico libro para aprender a programar que empieza con los ifs, los fors, sintaxis, etc, sino algo más para aprender a hacer bien una aplicación, aplicando bien los patrones de diseño, etc. Me bajé uno que se llama "UML y patrones", de Craig Larman pero, como ya estoy algo desengañado, antes de meterme a piñón con un tocho de casi 700 páginas sin tener referencias, prefiero primero peguntar (o si conoceis otro, pues bienvenido sea), que no estoy para perder el tiempo con libros que luego tengan un valor pedágógico escaso, mal escritos, farragosos y hasta con faltas de ortografía en casi cada página (me viene a la cabeza "professional PHP6" que cogí en una biblioteca de mi ciudad. Un auténtico bodrio infumable).
Como siempre, muchísimas gracias de "hantebraso" a todos los que me echeis un cable :)
Porque es mas dificil reutilizar clases/ficheros o trozos de la aplicación porque dependerán de esta variable global.
Si funciona y es lo que pide el cliente, bien está.
... además, todo es mejorable si el precio es el 'adecuado', aquí parece que la gente se ha acostumbrado a pagar poco y a obtener un servicio mediocre ( me refiero a lo que yo veo o he visto personalmente ) :lol2:
Si compila se manda al cliente XD
Te recomiendo que te compres cualquier libro del lenguaje que uses que traten de lo siguiente:
-Patrones de disenio
-TTD
Normalmente cuando programas se intenta atomizar los problemas, de forma que se puedan agrupar funcionalidades en modulos autocontenidos.
Para que algo sea legible y mantenible, es importante que se pueda seguir el flujo de la aplicación según la lees, nombres de funciones/metodos autodescriptivos, nombres de variables claros, reglas coherentes de nombrado entre los distintos ficheros, comentar las partes difíciles.
Si en mitad de un flujo al que le pasas parámetros usas una variable global, nadie se lo esperara, y mucho menos si no esta comentado.
Cualquier cambio no tendrá en cuenta dicho uso de la variable global, de forma que si cambias un atributo de un objeto global posiblemente no te puedas adelantar a todas las consecuencias, rompiendo el flujo de la aplicación.
A nivel personal, para mi es importante no hacer la vista gorda con codigo espagueti de mierda, ya que es dar una patada para delante, y la mierda tiene tendencia de disfrazarse de bumerang, al final todo vuelve, pero mas grande y pestilente.
EDITO.
PD. UML esta bien si, pero saber lo justo para leer diagramas si solo vas a programar, UML es muy extenso como para leerte un libro entero. Para mi los patrones de dise;o te aclaran mucho mas sobre como hcer cosas comunes de la mejor manera.
PD2. Si se necesita usar un modelo global, lo mejor es tenerlo bien identificado, con metodos y tal, pero nunca acceder directamente y sin comentar en ningun sitio. Cada lenguaje tiene su mejor forma de hacer esto.
A nivel personal, para mi es importante no hacer la vista gorda con codigo espagueti de mierda, ya que es dar una patada para delante, y la mierda tiene tendencia de disfrazarse de bumerang, al final todo vuelve, pero mas grande y pestilente.
Ojala te oyeran mis jefes, pero cuando se hace algo a lo guarro dicen, no importa mientras funcione ya habrá tiempo de hacerlo mejor, pasa a otra cosa que has perdido mucho tiempo en esto...
Y claro, la mierda se acumula, los tiempos de desarrollo se disparan, cada vez cuesta mas encontrar errores, tocas una cosa y se fastidia otra... y eso hace que nunca tengas tiempo "libre" para rehacer/refactorizar/mejorar algo que ya esta hecho porque según mis jefes es una perdida de tiempo, si ya esta hecho para que lo vas a tocar.
El problema es que te encuentras con librerías que no hay manera de reutilizar por depender de otras librerías, que también dependen de otras y mas y mas... esto en vez de código spaguetti es código ovillo.
PD: ¿se nota que estoy quemado?
Estopero
13/02/2014, 00:32
+1 a todo lo de otto
Es fundamental seguir las buenas prácticas si tu aplicación va a ser mantenida posteriormente, si será mantenida por ti te resultará menos trabajoso retomarla, solucionar bugs misteriosos..., y si será mantenida por otra persona le ahorrarás además parte del infierno de entender tu aplicación.
Si es una aplicación para salir del paso y que no va a ser mantenida... el camino más rápido será suficiente, aunque es bueno acostumbrarse a seguir los patrones de diseño y las buenas prácticas siempre... para no perder la costumbre :)
Siendo un poco más concretos... busca en google por el patrón MVC (Modelo Vista Controlador) para PHP si es el lenguaje que vas a utilizar, no puedo recomendarte ningún libro en concreto porque no he leído ninguno dedicado especialmente a MVC, pero es un patrón que se utiliza mucho y que hace que la arquitectura de tu aplicación tenga más sentido.
La mayoría de frameworks de PHP se apoyan sobre el patrón MVC o derivados, hablamos un poquito sobre el tema aquí: http://www.gp32spain.com/foros/showthread.php?125780-Programadores-PHP-CodeIgniter-manifestaos
Y si quieres meterte de lleno...:
http://symfony.com/
http://framework.zend.com/
Ojala te oyeran mis jefes, pero cuando se hace algo a lo guarro dicen, no importa mientras funcione ya habrá tiempo de hacerlo mejor, pasa a otra cosa que has perdido mucho tiempo en esto...
Y claro, la mierda se acumula, los tiempos de desarrollo se disparan, cada vez cuesta mas encontrar errores, tocas una cosa y se fastidia otra... y eso hace que nunca tengas tiempo "libre" para rehacer/refactorizar/mejorar algo que ya esta hecho porque según mis jefes es una perdida de tiempo, si ya esta hecho para que lo vas a tocar.
El problema es que te encuentras con librerías que no hay manera de reutilizar por depender de otras librerías, que también dependen de otras y mas y mas... esto en vez de código spaguetti es código ovillo.
PD: ¿se nota que estoy quemado?
Pan nuestro de cada dia hijo, pan nuestro de cada dia.
Yo me estoy poniendo las pilas con TTD, cuando lo domine voy a empezar a usarlo en todos mis modulos, y que no los contamine nadie por su propia salud.
Que es TTD? Por que no es el Transport Tycoon Deluxe ni Teoría de la Transición Demográfica, jaja.
Y si, yo aun no he leido a dia de hoy codigos ajenos de programas medianos/grandes (soy novato) y me da un miedo terrible porque soy un enfermo de la tabulacion y los comentarios y se que te puedes encontrar cosas que te pueden provocar infartos multiples.
Que es TTD? Por que no es el Transport Tycoon Deluxe ni Teoría de la Transición Demográfica, jaja.
Y si, yo aun no he leido a dia de hoy codigos ajenos de programas medianos/grandes (soy novato) y me da un miedo terrible porque soy un enfermo de la tabulacion y los comentarios y se que te puedes encontrar cosas que te pueden provocar infartos multiples.
Me equivoque, TDD, test driven development xD
Una metodologia de programacion muy interesante.
Me equivoque, TDD, test driven development xD
Una metodologia de programacion muy interesante.
Vale, ya se lo que es, lo lei hace tiempo en el libro de Head First Java (era el método que aconsejaban seguir) y me pareció lógico pero complicado de llevar a cabo, pero yo soy un ignorante en esto.
TDD es una metodología muy chula de aprender, es una manera efectiva de afrontar los retos de programación y obtener una visión mucho más clara y concisa sobre cómo acometer un desarrollo.
Hasta ahí todo bien pero no me volvería loco con ella, hay que sopesar muy bien que TDD usualmente requiere mayor tiempo de desarrollo (aunque la domines) y además suele caerse en el error de ponerse a aumentar la cobertura de código que funciona en producción con test unitarios que realmente no aportan ningún beneficio. No hay que perder de vista que el objetivo es que las cosas funcionen y mi consejo es aplicar TDD o nuevos patrones de diseño sólo a desarrollos nuevos y más particularmente haría TDD con aquellos procesos en el que intervengan comunicaciones con terceros (como para desarrollo de API, frameworks, etc.).
TDD es una metodología muy chula de aprender, es una manera efectiva de afrontar los retos de programación y obtener una visión mucho más clara y concisa sobre cómo acometer un desarrollo.
Hasta ahí todo bien pero no me volvería loco con ella, hay que sopesar muy bien que TDD usualmente requiere mayor tiempo de desarrollo (aunque la domines) y además suele caerse en el error de ponerse a aumentar la cobertura de código que funciona en producción con test unitarios que realmente no aportan ningún beneficio. No hay que perder de vista que el objetivo es que las cosas funcionen y mi consejo es aplicar TDD o nuevos patrones de diseño sólo a desarrollos nuevos y más particularmente haría TDD con aquellos procesos en el que intervengan comunicaciones con terceros (como para desarrollo de API, frameworks, etc.).
Esta claro que cuando algo se ha planificado mal no hay metodologia que lo arregle :)
Lo que tengo claro es que a partir de ahora acceptance test para todos los apis, automatizados y almacenando las respuestas para comparar los cambios no declarados.
Y luego TDD para desarrollos nuevos, esta claro que hay que saber que test cases hay que crear, pero los mantras estan claros, hay que entenderlos, no es crear test cases por crearlos.
Creo que a la larga ahorra tiempo, es mucho peor tener mil regression bugs porque la gente no sabe hacer merges, o programa con la minga. Con test unitarios eso no pasa, si no pasa test no subes, asi de sencillo.
Y para lo demas muerte
^MiSaTo^
13/02/2014, 16:43
En mi curro llevamos ya un par de años usando TDD y bueno, al principio parece un coñazo hacer unit tests y demás pero es util de la leche. Por ejemplo hace año y medio hicimos una app y se publicó en el market y demás. Hace cosa de 3 meses la retomamos para hacer una actualización y claro, acuérdate tú de lo que hiciste hace un año y medio! aparte, una de las cosas que había que actualizar era por ejemplo llamadas al servidor que devolvían los mismos datos (osea el método de "manager" era el mismo) pero internamente se trataban diferente. Pues nada mejor que volver a ejecutar los unit tests para ver si sigue funcionando como debería :)
Fuimos el único proyecto que empezamos a usarlo y fuimos dando el coñazo a los demás para que se sumaran al carro. Y por fin con esta actualización se han dado cuenta de la importancia de ello.
PD: otra cosa que os recomiendo, es hacer code reviews. Ahora mismo somos dos programadores, bueno pues yo reviso el código de mi compañero y él el mío. Ninguna user story está completa hasta que no están los unit tests (si son necesarios, que no siempre), el código revisado de cada uno y bueno, sin bugs que haya sacado el tester.
Ojo con lo de revisar el código que hay gente que no soporta que le anden corrigiendo, hay que hacerlo con la mente abierta. Aquí lo hacemos para aprender y cuando vemos algo que el otro piensa que se podía hacer diferente se discute entre los dos y se toma la mejor solución (que puede o no ser la que había). Todo esto se hace con la intención de mejorar. Tampoco vale corregir el código del compañero sin avisar o sin explicar ni siquiera el por qué. Y hay que tomarse las críticas a bien (que ya hemos tenido movidas en otros desarrollos por intentar hacer lo mismo con otra gente que no quiere que le toquen "su código")
En mi curro llevamos ya un par de años usando TDD y bueno, al principio parece un coñazo hacer unit tests y demás pero es util de la leche. Por ejemplo hace año y medio hicimos una app y se publicó en el market y demás. Hace cosa de 3 meses la retomamos para hacer una actualización y claro, acuérdate tú de lo que hiciste hace un año y medio! aparte, una de las cosas que había que actualizar era por ejemplo llamadas al servidor que devolvían los mismos datos (osea el método de "manager" era el mismo) pero internamente se trataban diferente. Pues nada mejor que volver a ejecutar los unit tests para ver si sigue funcionando como debería :)
Fuimos el único proyecto que empezamos a usarlo y fuimos dando el coñazo a los demás para que se sumaran al carro. Y por fin con esta actualización se han dado cuenta de la importancia de ello.
PD: otra cosa que os recomiendo, es hacer code reviews. Ahora mismo somos dos programadores, bueno pues yo reviso el código de mi compañero y él el mío. Ninguna user story está completa hasta que no están los unit tests (si son necesarios, que no siempre), el código revisado de cada uno y bueno, sin bugs que haya sacado el tester.
Ojo con lo de revisar el código que hay gente que no soporta que le anden corrigiendo, hay que hacerlo con la mente abierta. Aquí lo hacemos para aprender y cuando vemos algo que el otro piensa que se podía hacer diferente se discute entre los dos y se toma la mejor solución (que puede o no ser la que había). Todo esto se hace con la intención de mejorar. Tampoco vale corregir el código del compañero sin avisar o sin explicar ni siquiera el por qué. Y hay que tomarse las críticas a bien (que ya hemos tenido movidas en otros desarrollos por intentar hacer lo mismo con otra gente que no quiere que le toquen "su código")
Nosotros hacemos mucho en la oficina pair programming, y la verdad es que funciona muy bien.
Para las reviews de codigo pues depende, con gente de aqui tenemos un chat y vamos comentando, todo perfecto, pero con las oficinas de fuera es mas complicado, usando otro idioma si tienes la mente cerrada todo se puede tomar como un ataque, visto lo visto.
Creo que no te lo han dicho, en el caso de las variables globales estas pueden ser modificadas en cualquier parte del código, lo que significa que si una parte del programa hace lo que no debe y modifica una variable que luego se usa en otra pero no espera que haya sido modificada tu programa terminará fallando o mostrando datos erróneos, seguramente en una parte que está más o menos bien, que no es la que hace la cosa rara con la variable.
Busca ejemplos de "spaguetti code". De ahí la conveniencia de programar utilizando módulos aislados conectados por interfaces claras que por otra parte son reutilizables.
Inyectar la base de datos entera a toda la aplicación, o pasarle al cliente todos los datos de una base de datos y que luego haga subconsultas de esos datos en global es una pésima idea, primero porque estás estresando al servidor de la base de datos pidiéndole todo, en segundo lugar porque esos datoos seguramente van por red hasta el cliente y estás generando mucho más tráfico del que le hace falta y en segundo lugar estás estresando la estación de trabajo del usuario haciéndole cargar en memoria datos que no necesita.
En el caso de la historia a la que referencias en Meneamé es la del típico homo-consulting-informaticus que tiene montado su chiringuito en la típica teleco española, en una compañía de seguros o un banco, que trabajan un huevo dando soporte (o haciendo el desarrollo y dando soporte) de una aplicación interna y supersecreta, generalmente muy antigua que corre en sistemas operativos lo bastante extraños como para que alguien que no haya trabajado nunca en esto conozca (en general unix comerciales, VMS y semejantes) que tienen decenas de bugs, que son subsanables con parches o mediante scripting pero que están apoltronados en su trabajo, que curran mucho, o poco, pero que hacen horas y las cobran y mantienen a su jefe en la inopia, porque no es que le jefe o los compañeros no sepan, es que no les dejan saber. Se guardan la documentación para ellos, dicen que no hay documentación y en realidad tampoco saben mucho del sistema. Todos los días hacen los mismos chequeos a mano, se han pegado un huevo de horas haciendo un sistema de monitorización en cualqueir lenguaje exótico (o no tan exótico) que les manda decenas de eventos cada hora de cosas que necesitan solución (se está llenando un filesystem, se ha caído un proceso) en lugar de utilizar una solución de tipo cfengine o puppet que te mantiene viva la plataforma.
Y así es todo. Los programadores kobold y otras criaturas del pasado se creen que son los únicos que pueden hacer su trabajo, pero los kobols siempre miran con recelo cuando alguien nuevo llega a su mazmorra, no sea que el nuevo becario descubra que el kobol (o porgramador COBOL) en realidad no sabe tanto como los hace creer a Jefus y se descubra que hace un millón de tareas manuales al día porque es tan perro que pasa de automatizar, que con un poco de ganas se puede dejar de hacer un trabajo de robot y pasar a hacer un trabajo que aporta valor...
En fin, esto da para un libro.
^MiSaTo^
13/02/2014, 17:25
Nosotros hacemos mucho en la oficina pair programming, y la verdad es que funciona muy bien.
Para las reviews de codigo pues depende, con gente de aqui tenemos un chat y vamos comentando, todo perfecto, pero con las oficinas de fuera es mas complicado, usando otro idioma si tienes la mente cerrada todo se puede tomar como un ataque, visto lo visto.
Nosotros hacemos pair programming tb a veces (especialmente cuando es algo nuevo y complejo que queremos aprender) y la verdad que sí, es util.
Ahora, todas estas cosas no son la panacea. Tb he visto gente que aprende un nuevo patrón y ya se tiene que usar para todo y tampoco es así (no lo digo por ti, sino cosas que he visto). Las cosas hay que usarlas cuando son necesarias ^^ Esto como consejo general (me incluyo)
akualung
13/02/2014, 18:57
Muchísimas gracias a todos por vuestros comentarios. No os pongo un agradecimiento a cada uno (al principio he empezado haciéndolo pero luego he visto que quizá era demasiado) porque quedaría ridículo ver absolutamente cada comentario con "el usuario X ha agradecido este mensaje", pero me habeis ayudado todos muchísimo, en serio, gracias :)
La mejor manera de arreglar la "cagada" de la que habla el mensaje de menéame que yo copié aquí, sería tratarlo como se hace en cualquier framework, no? O sea, modularizar el acceso a BD y hacer un include o require (o como se diga) donde toque, no?
Sois unos maricas, en mi oficina no hacemos ni code review, ni pair programing ni TDD ni nada.
Cuando se acumula el trabajo yo hago ping-pong programming, esto es o bien dedicas medio día a una aplicación y otro medio a otra, o cuando corre prisa te abres varios visual studio, y mientras estas compilando o ejecutando algo que tarda un rato pues te pones a programar/depurar la otra aplicación.
Añádele el tiempo que pierdes cuando el jefe te llama para enseñarte algún error, para eso esta el bug-tracker, oh wait pero si no usamos ninguna clase de bug-tracker, o cuando te pregunta si la aplicación hace o no hace algo que se le acaba de ocurrir y que dentro de N horas te dirá que le compiles una versión con eso nuevo añadido, cuando se supone que debes de estar dedicando tu tiempo a otro proyecto.
El resultado es que tienes a los trabajadores quemados.
PD: yo en casa si que uso TDD, es muy aburrido porque acabas con muchos programas que solo sacan por la linea de comandos un "ok", pero cuando pasa algo raro descubres el error en muchísimo menos tiempo. Pair programming y el code review es mas chungo cuando estas solo, pero si que de vez en cuando voy clase por clase mirando cada método y preguntando si tiene sentido en esa clase o si le faltan métodos (útiles claro, no rellenar por rellenar), ademas de ir comentando el código o poniéndolo mas claro.
Nosotros hacemos pair programming tb a veces (especialmente cuando es algo nuevo y complejo que queremos aprender) y la verdad que sí, es util.
Ahora, todas estas cosas no son la panacea. Tb he visto gente que aprende un nuevo patrón y ya se tiene que usar para todo y tampoco es así (no lo digo por ti, sino cosas que he visto). Las cosas hay que usarlas cuando son necesarias ^^ Esto como consejo general (me incluyo)
En este mundo o tienes la mente abierta o eres carne de llevarte palos.
Yo intento estar al día para mejorar, pero obviamente no puedes forzar ninguna metodologia en un entorno compartido como un equipo, puede que no sirva, o que el equipo use otras mucho mejores, o sino mejores, mucho mas pulidas.
Sois unos maricas, en mi oficina no hacemos ni code review, ni pair programing ni TDD ni nada.
Cuando se acumula el trabajo yo hago ping-pong programming, esto es o bien dedicas medio día a una aplicación y otro medio a otra, o cuando corre prisa te abres varios visual studio, y mientras estas compilando o ejecutando algo que tarda un rato pues te pones a programar/depurar la otra aplicación.
Añádele el tiempo que pierdes cuando el jefe te llama para enseñarte algún error, para eso esta el bug-tracker, oh wait pero si no usamos ninguna clase de bug-tracker, o cuando te pregunta si la aplicación hace o no hace algo que se le acaba de ocurrir y que dentro de N horas te dirá que le compiles una versión con eso nuevo añadido, cuando se supone que debes de estar dedicando tu tiempo a otro proyecto.
El resultado es que tienes a los trabajadores quemados.
PD: yo en casa si que uso TDD, es muy aburrido porque acabas con muchos programas que solo sacan por la linea de comandos un "ok", pero cuando pasa algo raro descubres el error en muchísimo menos tiempo. Pair programming y el code review es mas chungo cuando estas solo, pero si que de vez en cuando voy clase por clase mirando cada método y preguntando si tiene sentido en esa clase o si le faltan métodos (útiles claro, no rellenar por rellenar), ademas de ir comentando el código o poniéndolo mas claro.
:lol:
Es una putada currar así.
En mi curro TDD no hacemos... si que hemos metido test unitarios en una libreria que hemos hecho. Para probar las Apps que hacemos tenemos a gente de QA que se encarga de hacernos putaditas... (te renombro, mientras subo un fichero, al tiempo que giro la pantalla, cambio de pestaña y bloqueo la pantalla durante 10 minutos y voila! el fichero no se ha subido por que ha dado un error de credenciales xD).
Luego resto de cosillas si que hacemos/usamos: SCRUM, Jira, pair programing (esto poco, suele ser cuando es un buen reto). Me ha hecho gracia leer a ^MiSaTo^decir "User Story", odio ese termino, nosotros también lo usamos para definir lo que entra en el sprint. Como queramos meter una refactorización de alguna clase o de alguna vista nos toca hacer malabares para que parezca una "User Story" y es cutrisimo xD, menos mal que nos dejan hacerlo sin problemas (si se pusieran tontos con un "es que eso no da valor de negocio" nos dejan rotos y con el código hecho mierda).
josepzin
13/02/2014, 23:07
Mucho finolis por aquí, que si TTD, MVC, testunit, pair programing... :D :D
^MiSaTo^
13/02/2014, 23:17
:lol:
Es una putada currar así.
En mi curro TDD no hacemos... si que hemos metido test unitarios en una libreria que hemos hecho. Para probar las Apps que hacemos tenemos a gente de QA que se encarga de hacernos putaditas... (te renombro, mientras subo un fichero, al tiempo que giro la pantalla, cambio de pestaña y bloqueo la pantalla durante 10 minutos y voila! el fichero no se ha subido por que ha dado un error de credenciales xD).
Luego resto de cosillas si que hacemos/usamos: SCRUM, Jira, pair programing (esto poco, suele ser cuando es un buen reto). Me ha hecho gracia leer a ^MiSaTo^decir "User Story", odio ese termino, nosotros también lo usamos para definir lo que entra en el sprint. Como queramos meter una refactorización de alguna clase o de alguna vista nos toca hacer malabares para que parezca una "User Story" y es cutrisimo xD, menos mal que nos dejan hacerlo sin problemas (si se pusieran tontos con un "es que eso no da valor de negocio" nos dejan rotos y con el código hecho mierda).
Hombre yo no se cómo se llama en Español (historias de usuario?) porque allí no lo he usado nunca. A mi se me hace raro oírlo de otra manera xD
Nosotros sí hacemos user stories de refactorizar aunque en vez de empezar la descripción como "As a user...." se empieza como "As a developer" y a la mierda xD Aquí te aseguro que se lleva todo a rajatabla, pero por suerte los que "mandamos" somos los desarrolladores. Entienden que refactorizar es algo que lleva tiempo pero que mejora la calidad de la aplicación y ese tipo de cosas. También por suerte los jefes tienen la mente muy abierta a cosas nuevas y escuchan a los demás del equipo.
...pero por suerte los que "mandamos" somos los desarrolladores
snif... que envidia...
Aqui el que manda es el jefe o el cliente, así que si un cliente pregunta por algo mis jefes les dicen que si compran la aplicación se les hace. Asi que tengo que dejar cosas a mitad, ya sea de la misma aplicación o de otra y ponerme con ello. Después a ver como leches subes el código a producción porque tienes trozos de cosas medio hechas o a medio cambiar que no debes subir...
Después acuérdate de que leches estabas haciendo XD
^MiSaTo^
13/02/2014, 23:33
snif... que envidia...
Aqui el que manda es el jefe o el cliente, así que si un cliente pregunta por algo mis jefes les dicen que si compran la aplicación se les hace. Asi que tengo que dejar cosas a mitad, ya sea de la misma aplicación o de otra y ponerme con ello. Después a ver como leches subes el código a producción porque tienes trozos de cosas medio hechas o a medio cambiar que no debes subir...
Después acuérdate de que leches estabas haciendo XD
No te preocupes he trabajado 8 años programando en España y se cómo va la cosa allí. Por suerte aquí no tiene nada que ver con eso, de verdad es otro mundo en muchos sentidos.
Ánimo ;) Y a las malas aquí seguimos necesitando gente XD
Es muy triste lo que dices, tener que irse a 3000km o más para trabajar poder hacer las cosas bien.
Creo que esta forma de trabajar es consecuencia de como funcionan aquí los negocios donde importa mas las amistades, compadreo, mamoneo, chanchullos, etc que el hacer un producto de calidad.
Hombre yo no se cómo se llama en Español (historias de usuario?) porque allí no lo he usado nunca. A mi se me hace raro oírlo de otra manera xD
Nosotros sí hacemos user stories de refactorizar aunque en vez de empezar la descripción como "As a user...." se empieza como "As a developer" y a la mierda xD Aquí te aseguro que se lleva todo a rajatabla, pero por suerte los que "mandamos" somos los desarrolladores. Entienden que refactorizar es algo que lleva tiempo pero que mejora la calidad de la aplicación y ese tipo de cosas. También por suerte los jefes tienen la mente muy abierta a cosas nuevas y escuchan a los demás del equipo.
Nosotros trabajamos en ingles por lo que también lo llamamos User Stories, alguna vez alguien ha dicho "Historias de usuario" lo cual suena un poco raro jeje.
La próxima vez que haya que hacer alguna refactorización dejare caer lo de "As a developer" a ver que dicen.
-----Actualizado-----
Es muy triste lo que dices, tener que irse a 3000km o más para trabajar poder hacer las cosas bien.
Creo que esta forma de trabajar es consecuencia de como funcionan aquí los negocios donde importa mas las amistades, compadreo, mamoneo, chanchullos, etc que el hacer un producto de calidad.
En españa hay de todo, empresas donde hay mucho mamoneo pero también tienes empresas chulas donde se hacen las cosas bien. Estoy seguro de que en Amsterdam, Berlin, Dublin... pasa igual, habra empresas donde se trabaja de pena y empresas donde se curra bien.
^MiSaTo^
14/02/2014, 09:38
Es muy triste lo que dices, tener que irse a 3000km o más para trabajar poder hacer las cosas bien.
Creo que esta forma de trabajar es consecuencia de como funcionan aquí los negocios donde importa mas las amistades, compadreo, mamoneo, chanchullos, etc que el hacer un producto de calidad.
Totalmente de acuerdo. Y sí, es triste pero es lo que hay :(
-----Actualizado-----
En españa hay de todo, empresas donde hay mucho mamoneo pero también tienes empresas chulas donde se hacen las cosas bien. Estoy seguro de que en Amsterdam, Berlin, Dublin... pasa igual, habra empresas donde se trabaja de pena y empresas donde se curra bien.
Por supuesto que hay de todo en todos lados, pero después de muchos años trabajando en muchas empresas (y siendo autónoma otros tantos años también) en general las empresas en España son unas chapuceras. Y vamos, hablando con los que están aquí de distintas regiones coinciden.
Tú habrás tenido muchísima suerte con la empresa con la que has dado, pero son las menos de verdad. En general España es lo que cuenta swapd0.
Y en general Amsterdam es lo que cuento de mi empresa. Básicamente porque para empezar los holandeses no les gusta que haya gerarquía y les gusta mucho discutir cosas. Al final eso resulta en que tu jefe no está "por encima" y tenemos 200 reuniones, y se habla de todo y se intenta llegar a una solución, etc etc. Y esque ese es su carácter (si no me crees busca sobre ello). Y eso al final tb se nota a la hora de trabajar. Habrá empresas malas, sí, pero en general aquí son las menos
Me da la sensación que swapd0 trabaja en mi misma compañía. Varios visuals abiertos es el pan de cada día, con la consecuente perdida de tiempo para acordarte que estabas haciendo en cada uno.
O parar un desarrollo nuevo por una incidencia de soporte porque no hay gente dedicada a arreglar incidencias y ZAS te jode todo el plan del día.
Creo que esta forma de trabajar es consecuencia de como funcionan aquí los negocios donde importa mas las amistades, compadreo, mamoneo, chanchullos, etc que el hacer un producto de calidad.
Cuanta verdad en tan poco espacio :) - predominan el mamoneo y los chanchullos, se intenta pagar lo mínimo, eso obliga al desarrollador a rebajar sus presupuestos, si los rebaja mucho, esto merma la calidad del producto ya que no le puede dedicar todo el tiempo y recursos que le habría tenido que dedicar en una situación más normal y justa.
Luego te tropiezas con los 'listos' que creen que les debes - de manera totalmente altruísta y gratuita - el mantenimiento, actualizaciones y parcheos de por vida... pero esa es otra histeria. :lol:
Me da la sensación que swapd0 trabaja en mi misma compañía. Varios visuals abiertos es el pan de cada día, con la consecuente perdida de tiempo para acordarte que estabas haciendo en cada uno.
O parar un desarrollo nuevo por una incidencia de soporte porque no hay gente dedicada a arreglar incidencias y ZAS te jode todo el plan del día.
Conozco esta historia, pero claro, desde el otro lado, como pringao de soporte de aplicaciones deficientes y no tan deficientes que tiene que molestar a los desarrolladores cuando soy incapaz de saber si el comportamiento de una aplicación es bueno aunque el usuario crea que no o se trata de una puñetera FENDyNS (Funcionalidad extraña no documentada y no solucionada).
Debería haber más desarrolladores dedicándose a operaciones, y alguien de operaciones con el equipo de desarrollo, para que sepáis que se ve desde el otro lado.
^MiSaTo^
14/02/2014, 11:59
Lo ves ChUKii? El mamoneo es la tónica general en España, que no es que lo diga yo, es que por desgracia es así :(
Lo ves ChUKii? El mamoneo es la tónica general en España, que no es que lo diga yo, es que por desgracia es así :(
Es un asco :(
Yo trabajo en una empresa islandesa (hasta el martes, que me cambio de curro jejeje) que es la mejor empresa en la que he trabajado hasta ahora; y por lo que veo, bastante parecida a la de Misato en cuanto a metodologías, pero muy distinta en cuanto la cultura de la gente que la dirige. La gran diferencia entre mi empresa y una empresa española es que aquí se valora mucho que tu jefe sea visible, te apoye, te de trabajo, te trate continuamente, haga caso a tus requierimientos y no te deje a la mano de dios, allí es todo lo contrario, cuanta más independencia de tu jefe tengas, mejor. Se valora mucho trabajar lo más independiente posible y esto, claro está tiene sus ventajas y sus inconvenientes.
La manera de trabajar de mi empresa en la central es buena cuando tu empresa desarrolla un producto, como hace mi empresa desde Reykjavik. Pero es horroso cuando hablamos de hacer personalización de un producto (o llamémosle por lo que es: consultoría) desde una rama separada de la empresa, como es mi caso y el resto de mis compañeros en España; la sensación general es que estamos totalmente descolgados de la compañía, y que a la misma vez ni pertenecemos a ella ni a la empresa para la que realmente trabajamos.
No se puede decir que tal forma de trabajar es mejor o peor que otra, está claro que depende muchísimo tanto de las personas que compongan un proyecto, como de la situación en general de éste. Lo digo porque en ocasiones leo maravillas de la aparente horizontalidad de empresas como Steam, Google u otras mientras a la vez también leo de la enorme rotación que sufren y cuando se cuentan los motivos se mencionan cosas cómo exceso de reuniones, tareas de poco valor, o que unos pocos sacan el trabajo que realmente da beneficio mientras que otros no hacen prácticamente nada.
Por lo demás, digo que es cierto que en españa, y en particular en el mundo del desarrollo lo mas habitual es tratar a patadas a los empleados, pero os juro que no somos únicos.
chemaris
15/02/2014, 15:17
Bahh!! tonterías, donde este la metodología ASM (A Salto de Mata) que se quite todo lo demás, es mas divertido vivir al limite, el único riesgo es que al final a alguien se le puede ir la olla y acabar asesinando a toda la oficina
Cierto, en una sala de operaciones suele haber un veterano y todos los demás novatos en cada turno, haciendo tareas de poco o ningún valor y turnos de la muerte hasta que se cambian de curro y es curioso. porque si en un nivel uno pones a unos cinturones negros de la administración de sistemas en lugar de gente que busca su primer empleo tienes a un buen equipo de automatizadores y solucionadores de mierdas, o por lo menos gente que hace scripts para subsanar bugs hasta que los devs los solucionan en el código.
En fin, a mi es que el tema de la metodología me apasiona, tanto orientada a desarrollo como como a operaciones como a todo junto. De mi carrera es lo que mas me gusta, mucho más que la parte jurídica, así que puede que el trabajo de fin de grado lo haga sobre metodologías ágiles, DevOps o alguna cosa de esas.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.