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

[akualung]

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

[swapd0]

Porque es mas dificil reutilizar clases/ficheros o trozos de la aplicación porque dependerán de esta variable global.

[X-Code]

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 )

[swapd0]

Si compila se manda al cliente XD

[otto_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.

[swapd0]

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]

+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/showt...er-manifestaos

Y si quieres meterte de lleno...:
http://symfony.com/
http://framework.zend.com/

[otto_xd]

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.

[aitorpc]

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.

[otto_xd]

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.

[aitorpc]

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.

[amkam]

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

[otto_xd]

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^]

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

[otto_xd]

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.