User Tag List

Página 2 de 3 PrimerPrimer 123 ÚltimoÚltimo
Resultados 16 al 30 de 36

Tema: [programación] Por qué está mal hacer esto?

  1. #16

    Fecha de ingreso
    Dec 2005
    Mensajes
    8,005
    Mencionado
    43 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    643
    Agradecer Thanks Received 
    635
    Thanked in
    Agradecido 410 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    52
    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.
    A veces hago cosas

  2. #17

    Fecha de ingreso
    Feb 2004
    Ubicación
    Madrid
    Mensajes
    22,749
    Mencionado
    226 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    2,240
    Agradecer Thanks Received 
    1,902
    Thanked in
    Agradecido 1,185 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por otto_xd Ver mensaje
    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)

  3. #18

    Fecha de ingreso
    Jun 2006
    Mensajes
    4,574
    Mencionado
    41 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,259
    Agradecer Thanks Received 
    700
    Thanked in
    Agradecido 427 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    6
    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?
    _
    .▲ ALABADO SEA EL TRI-FORCEPS!

    Nunca me he considerado de clase media. Soy más bien de clase calcetín roñoso.

  4. #19

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    7,561
    Mencionado
    47 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,668
    Agradecer Thanks Received 
    1,922
    Thanked in
    Agradecido 1,289 veces en [ARG:2 UNDEFINED] posts
    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.

  5. #20

    Fecha de ingreso
    Oct 2003
    Mensajes
    17,905
    Mencionado
    42 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    214
    Agradecer Thanks Received 
    160
    Thanked in
    Agradecido 109 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por ^MiSaTo^ Ver mensaje
    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.

  6. #21

    Fecha de ingreso
    May 2009
    Mensajes
    3,037
    Mencionado
    12 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    226
    Agradecer Thanks Received 
    173
    Thanked in
    Agradecido 112 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    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.


    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).

  7. #22

    Fecha de ingreso
    Nov 2005
    Ubicación
    Excartagenero
    Mensajes
    23,651
    Mencionado
    276 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    5,994
    Agradecer Thanks Received 
    5,821
    Thanked in
    Agradecido 3,794 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    1
    Mucho finolis por aquí, que si TTD, MVC, testunit, pair programing...

  8. #23

    Fecha de ingreso
    Feb 2004
    Ubicación
    Madrid
    Mensajes
    22,749
    Mencionado
    226 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    2,240
    Agradecer Thanks Received 
    1,902
    Thanked in
    Agradecido 1,185 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por ChUKii Ver mensaje


    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.

  9. #24

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    7,561
    Mencionado
    47 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,668
    Agradecer Thanks Received 
    1,922
    Thanked in
    Agradecido 1,289 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por ^MiSaTo^ Ver mensaje
    ...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

  10. #25

    Fecha de ingreso
    Feb 2004
    Ubicación
    Madrid
    Mensajes
    22,749
    Mencionado
    226 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    2,240
    Agradecer Thanks Received 
    1,902
    Thanked in
    Agradecido 1,185 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    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

  11. #26

    Fecha de ingreso
    Sep 2006
    Ubicación
    Malaga
    Mensajes
    7,561
    Mencionado
    47 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    1,668
    Agradecer Thanks Received 
    1,922
    Thanked in
    Agradecido 1,289 veces en [ARG:2 UNDEFINED] posts
    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.

  12. #27

    Fecha de ingreso
    May 2009
    Mensajes
    3,037
    Mencionado
    12 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    226
    Agradecer Thanks Received 
    173
    Thanked in
    Agradecido 112 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por ^MiSaTo^ Ver mensaje
    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-----

    Cita Iniciado por swapd0 Ver mensaje
    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.

  13. #28

    Fecha de ingreso
    Feb 2004
    Ubicación
    Madrid
    Mensajes
    22,749
    Mencionado
    226 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    2,240
    Agradecer Thanks Received 
    1,902
    Thanked in
    Agradecido 1,185 veces en [ARG:2 UNDEFINED] posts
    Cita Iniciado por swapd0 Ver mensaje
    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-----

    Cita Iniciado por ChUKii Ver mensaje
    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

  14. #29

    Fecha de ingreso
    Jan 2006
    Ubicación
    Madrid2X
    Mensajes
    947
    Mencionado
    2 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    39
    Agradecer Thanks Received 
    15
    Thanked in
    Agradecido 12 veces en [ARG:2 UNDEFINED] posts
    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.

  15. #30
    Yeti Sports 2 Champion!
    Fecha de ingreso
    Jun 2006
    Ubicación
    Texas, España
    Mensajes
    14,543
    Mencionado
    86 Post(s)
    Tagged
    0 Tema(s)
    Agradecer Thanks Given 
    833
    Agradecer Thanks Received 
    292
    Thanked in
    Agradecido 216 veces en [ARG:2 UNDEFINED] posts
    Entradas de blog
    1096
    Cita Iniciado por swapd0 Ver mensaje
    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.

Página 2 de 3 PrimerPrimer 123 ÚltimoÚltimo

Etiquetas para este tema

Permisos de publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •