Portada
mis comunidades
otras secciones
#2:
Es una pena que no actualice el blog mas a menudo.
Cuando lo descubrí me lo leí entero de un tirón.
Cuando lo descubrí me lo leí entero de un tirón.
#15:
Suma dos variables globales y devuelve el resultado. Qué grande 
Me ha recordado una cosa que me encontré queITdeu otra $Superempresaweb había hecho para cierto $Banco, y que me tocó mantener porque se había hecho infumable. Tampoco me quiero preguntar cuánto le cobraron en su momento al banco por la aberración y cuánto cobró el becario.
El caso es que era una aplicación web que gestionaba media docena de restaurantes y te mostraba lo que había de comer en cada uno, pasado, presente y futuro. Con la comida venían las cifras nutricionales pero no era mucho más complicado, vamos, tenía alguna otra pijadita pero era una web bastante tonta.
El problema que le daba al banco es que iba lento, pero lento de tirarse 1 minuto en cargar tras cada click, y si se acercaba la hora de la comida, varios minutos o incluso timeouts.
El primer mosqueo, que estaba hecho en JRE y con un JBoss sobredimensionado de la ostia, que tardaba varios minutos en arrancar. Supongo que por el JBoss cobrarían mucho.
Pero bueno, luego me encontré el motivo definitivo de la cutrez, después de un rato intentando desentrañar la base de datos: habían metido todos los datos que gestionaba el programa en la misma tabla SQL. ¿La contraseña del admin? En la tabla. ¿El plato que hay hoy de primero en el restaurante de cocina italiana? También. ¿Las proteínas que tiene ese plato? Igual. Se pone un campo "tipo" y dependiendo de ese "tipo" pues se interpreta de una manera o de otra, y mientras tanto cientos de miles de entradas en una sola tabla abarcando toda la aplicación.
Eso sí, como habían partes que eran compiladas y no teníamos ni fuentes ni nada (ni casi nada de presupuesto) al final la solución fue poco espectacular: borrar los datos de restaurantes de años acumulados y a tirar, porque no querían pagar una aplicación nueva.
Me ha recordado una cosa que me encontré que
El caso es que era una aplicación web que gestionaba media docena de restaurantes y te mostraba lo que había de comer en cada uno, pasado, presente y futuro. Con la comida venían las cifras nutricionales pero no era mucho más complicado, vamos, tenía alguna otra pijadita pero era una web bastante tonta.
El problema que le daba al banco es que iba lento, pero lento de tirarse 1 minuto en cargar tras cada click, y si se acercaba la hora de la comida, varios minutos o incluso timeouts.
El primer mosqueo, que estaba hecho en JRE y con un JBoss sobredimensionado de la ostia, que tardaba varios minutos en arrancar. Supongo que por el JBoss cobrarían mucho.
Pero bueno, luego me encontré el motivo definitivo de la cutrez, después de un rato intentando desentrañar la base de datos: habían metido todos los datos que gestionaba el programa en la misma tabla SQL. ¿La contraseña del admin? En la tabla. ¿El plato que hay hoy de primero en el restaurante de cocina italiana? También. ¿Las proteínas que tiene ese plato? Igual. Se pone un campo "tipo" y dependiendo de ese "tipo" pues se interpreta de una manera o de otra, y mientras tanto cientos de miles de entradas en una sola tabla abarcando toda la aplicación.
Eso sí, como habían partes que eran compiladas y no teníamos ni fuentes ni nada (ni casi nada de presupuesto) al final la solución fue poco espectacular: borrar los datos de restaurantes de años acumulados y a tirar, porque no querían pagar una aplicación nueva.
#34:
#20 El buen código es aquel que no necesita ser comentado.
Si eres buen programador, sigues las convenciones, buenas prácticas, haces un código modular, desacoplado y con nombres coherentes, tu código se vuelve infinitamente más legible que si haces una mierda de funcion enorme de 200 lineas con un comentario de 10 lineas que te explica la biblia y más.
Es más, no soporto ver el típico código de becario mal enseñado en la facultad, en el que a cada linea de código le acompaña un comentario inútil de cabecera. Por ejemplo
// Oculto la vista
view.hidden = true;
Esas mierdas complican más la lectura del código y lo peor es que el que lo hace se sentirá hasta un hacha...
Si eres buen programador, sigues las convenciones, buenas prácticas, haces un código modular, desacoplado y con nombres coherentes, tu código se vuelve infinitamente más legible que si haces una mierda de funcion enorme de 200 lineas con un comentario de 10 lineas que te explica la biblia y más.
Es más, no soporto ver el típico código de becario mal enseñado en la facultad, en el que a cada linea de código le acompaña un comentario inútil de cabecera. Por ejemplo
// Oculto la vista
view.hidden = true;
Esas mierdas complican más la lectura del código y lo peor es que el que lo hace se sentirá hasta un hacha...
#3:
Grandioso. Fiel reflejo de lo que puede haber detrás de una "empresa de software muy conocida" de las que abundan en el panorama cárnico egpañol.
#5:
Aún me estoy riendo con lo de "Un pitufo epiléptico ha estado practicando sexo tántrico con doce sapos encantados sobre los portales RFID me parece una causa razonable."
#42:
#40 no estoy de acuerdo. Tienes montones de buenas opciones para evitar comentarios innecesarios. Y ese tipo de comentarios son, por regla general innecesarios. El problema es que los comentarios a veces son una excusa para no nombrar a los métodos adecuadamente.
Programar es como escribir. El primer nivel es poner palabras juntas para expresar algo. El segundo es intentar no repetirse y clarificar las cosas. El tercero es aplicar un estilo de redacción y el último es que además puedas transmitir lo que quieres de una forma concisa y clara.
Code is poetry no es sólo una frase bonita. Es una manera de hacer las cosas
Programar es como escribir. El primer nivel es poner palabras juntas para expresar algo. El segundo es intentar no repetirse y clarificar las cosas. El tercero es aplicar un estilo de redacción y el último es que además puedas transmitir lo que quieres de una forma concisa y clara.
Code is poetry no es sólo una frase bonita. Es una manera de hacer las cosas
#48:
#46 WTF? ¿Me lo estás diciendo en serio?
Miras la función y ves que objeto espera la función que le pases y miras el retorno y ves que tipo de objeto te devuelve. Para eso no te hace falta ningún comentario. Obviamente ni #34, #35, #40 ni yo ni Neo puede mirar al nombre de una función o un método y saber que va a devolver sin saber el resto.
Pero vamos, para muestra un botón:
public User getUser (Object id)
No se trata de no comentar, se trata de no ser redundante. Y un código bien hecho en el 99% de los casos se autoexplica sólo.
BTW: ¿Lo de no utilizar camel case ha sido aposta o iba relacionado con la pregunta? La respuesta a esta pregunta quizás explicaría algunas cosas
Miras la función y ves que objeto espera la función que le pases y miras el retorno y ves que tipo de objeto te devuelve. Para eso no te hace falta ningún comentario. Obviamente ni #34, #35, #40 ni yo ni Neo puede mirar al nombre de una función o un método y saber que va a devolver sin saber el resto.
Pero vamos, para muestra un botón:
public User getUser (Object id)
No se trata de no comentar, se trata de no ser redundante. Y un código bien hecho en el 99% de los casos se autoexplica sólo.
BTW: ¿Lo de no utilizar camel case ha sido aposta o iba relacionado con la pregunta? La respuesta a esta pregunta quizás explicaría algunas cosas
Comentarios
Es una pena que no actualice el blog mas a menudo.
Cuando lo descubrí me lo leí entero de un tirón.
#2 Yo es que oigo "Sistemas?" y ya es que me parto
#2 Joder, y yo. He llegao hasta a comprarme el libro y me lo estoy releyendo otra vez. Las batallas contra el antiguo Boss son épicas.
Suma dos variables globales y devuelve el resultado. Qué grande
Me ha recordado una cosa que me encontré que
ITdeuotra $Superempresaweb había hecho para cierto $Banco, y que me tocó mantener porque se había hecho infumable. Tampoco me quiero preguntar cuánto le cobraron en su momento al banco por la aberración y cuánto cobró el becario.El caso es que era una aplicación web que gestionaba media docena de restaurantes y te mostraba lo que había de comer en cada uno, pasado, presente y futuro. Con la comida venían las cifras nutricionales pero no era mucho más complicado, vamos, tenía alguna otra pijadita pero era una web bastante tonta.
El problema que le daba al banco es que iba lento, pero lento de tirarse 1 minuto en cargar tras cada click, y si se acercaba la hora de la comida, varios minutos o incluso timeouts.
El primer mosqueo, que estaba hecho en JRE y con un JBoss sobredimensionado de la ostia, que tardaba varios minutos en arrancar. Supongo que por el JBoss cobrarían mucho.
Pero bueno, luego me encontré el motivo definitivo de la cutrez, después de un rato intentando desentrañar la base de datos: habían metido todos los datos que gestionaba el programa en la misma tabla SQL. ¿La contraseña del admin? En la tabla. ¿El plato que hay hoy de primero en el restaurante de cocina italiana? También. ¿Las proteínas que tiene ese plato? Igual. Se pone un campo "tipo" y dependiendo de ese "tipo" pues se interpreta de una manera o de otra, y mientras tanto cientos de miles de entradas en una sola tabla abarcando toda la aplicación.
Eso sí, como habían partes que eran compiladas y no teníamos ni fuentes ni nada (ni casi nada de presupuesto) al final la solución fue poco espectacular: borrar los datos de restaurantes de años acumulados y a tirar, porque no querían pagar una aplicación nueva.
#15 por el servidor JBoss no creo que cobraran nada, ya que es software libre. Y aunque el diseño de una aplicación en una única tabla es una cutrez, no tendría que ralentizar si ésta tiene los índices necesarios y se accede de forma correcta.
Yo también me he encontrado código con selects sin ningún where en el que se recorrían los registros hasta obtener un elemento tuviera el id Y, efectivamente, en fase de pruebas funciona perfectamente...
#15 http://3.bp.blogspot.com/-ZLixDboMRlw/UYZpgmQDrNI/AAAAAAAABTM/4kjGmi7kPqI/s320/mother-of-god-template_foro.jpg
#20 El buen código es aquel que no necesita ser comentado.
Si eres buen programador, sigues las convenciones, buenas prácticas, haces un código modular, desacoplado y con nombres coherentes, tu código se vuelve infinitamente más legible que si haces una mierda de funcion enorme de 200 lineas con un comentario de 10 lineas que te explica la biblia y más.
Es más, no soporto ver el típico código de becario mal enseñado en la facultad, en el que a cada linea de código le acompaña un comentario inútil de cabecera. Por ejemplo
// Oculto la vista
view.hidden = true;
Esas mierdas complican más la lectura del código y lo peor es que el que lo hace se sentirá hasta un hacha...
#34 y #35 Típica excusa para no comentar. Estaría bien lo que decís (y en un mundo en el que todo el mundo es un hacha programando sería posible) pero no es incompatible con comentar el código, por lo menos hay que escribir una breve descripción al inicio de la función para saber qué hace sin necesidad de leerla.
#40 Para eso está el nombre de la función. El 95% no necesitan ninguna explicación si les pones un nombre descriptivo. Si de verdad necesitas poner un comentario en todas tus funciones para saber qué hacen, algo estás haciendo mal.
#41 y #42 ¿Si os encontrais la función get_user qué os va a devolver?
#43 ¿Que parámetros le pasas? ¿Que parámetros esperas que te devuelva?
#45 ¿Que parámetros le pasas? No sé, mira los comentarios de la cabecera
¿Que parámetros esperas que te devuelva? Eso es lo que estoy preguntando.
#46 WTF? ¿Me lo estás diciendo en serio?
Miras la función y ves que objeto espera la función que le pases y miras el retorno y ves que tipo de objeto te devuelve. Para eso no te hace falta ningún comentario. Obviamente ni #34, #35, #40 ni yo ni Neo puede mirar al nombre de una función o un método y saber que va a devolver sin saber el resto.
Pero vamos, para muestra un botón:
public User getUser (Object id)
No se trata de no comentar, se trata de no ser redundante. Y un código bien hecho en el 99% de los casos se autoexplica sólo.
BTW: ¿Lo de no utilizar camel case ha sido aposta o iba relacionado con la pregunta? La respuesta a esta pregunta quizás explicaría algunas cosas
#40 no estoy de acuerdo. Tienes montones de buenas opciones para evitar comentarios innecesarios. Y ese tipo de comentarios son, por regla general innecesarios. El problema es que los comentarios a veces son una excusa para no nombrar a los métodos adecuadamente.
Programar es como escribir. El primer nivel es poner palabras juntas para expresar algo. El segundo es intentar no repetirse y clarificar las cosas. El tercero es aplicar un estilo de redacción y el último es que además puedas transmitir lo que quieres de una forma concisa y clara.
Code is poetry no es sólo una frase bonita. Es una manera de hacer las cosas
#40 #70 Para mi poner una cabecera al inicio de los metodos o clases (tipo javadoc) explicando lo que hace, sus parametros y lo que devuelve lo considero mas documentar que comentar y lo hago siempre (excepto con casos muy triviales como los setters and getters) y siempre de una forma estandar.
A lo que me refería es que el ideal es que el código sea autodescrito, aunque se que dependiendo del lenguaje y de la necesidad de optimizar otros aspectos en vez de la legibilidad sea difícil de conseguir, pero debería ser una de las principales reglas a seguir.
#72 Si estoy de acuerdo con que el código debe ser significativo, tampoco creo que sea precisamente un ideal, y el mayor problema de fiarse del código es que el código puede estar mal y, no nos engañemos, seguramente lo estará antes o después. También hay más cosas como que suele reflejar demasiado la forma de pensar de quién lo escribió, una forma de pensar que para otra persona no puede ser tan evidente.
Por cierto, al menos yo no me refería a la documentación. Por eso me refería a esas preguntas, no es lo mismo qué se quiere hacer, a cómo se quiere hacer y que es lo que realmente se está haciendo. En un algoritmo suele haber pasos bastante diferenciados que pueden estar reflejados en un comentario si es pertinente, a eso me refería, no a la documentación.
#34 El comentario es necesario porque conecta el código con lo que funcionalmente hace.
#36 a diferencia de lo que se dice en el artículo, son eficientes. Pero son inmanejables. No hay forma de seguir el código si se utilizan variables locales. Cantas más se usen, más difícil de seguir.
Hay una técnica de tortura más fina que consiste en, además de poner muchas, reutilizarlas.
#37 Es que lo que tú ves como un gran inconveniente se supone que era la ventaja por la que se hacía, es decir, tú declaras una serie de variables globales que todos los métodos, procedimientos, funciones o lo que sean las usarán como parámetros de entrada, así si cambian los requerimientos con cambiar las variables globales no tienes que ir buscándolas función por función, con el riesgo de colarte alguna. Será que no pillo lo que dices y me gustaría entenderte.
#55 ¿dices que las variables globales son inmanejables y al mismo tiempo que no hay forma de seguir el código si se utilizan variables locales?
#56 arg, sorry, una errata. Debe ser >
Se entiende que es cuando son muchas/todas.
De todas formas no está de más recordar que hay quien no es capaz de seguir el código, solo entiende sus propios programas y no siempre.
#56 Precisamente vengo yo de programar una monstruosidad gigantesca durante los últimos 18 meses usando Symfony 2, se que no es demasiado comparable por que PHP no usa declaracion de variables, pero casualmente Symfony 2 (que va en modo estricto por defecto) si lo hace y tienes que declararlas todas antes de usarlas.
Bien, pues puedo confirmar que no hemos usado el concepto "variable global" (Globals en php) ni nada que se le parezca ni de lejos. Se han creado algunas interfaces, hay algunas clases estáticas, varios servicios (clases estáticas de una manera muy curiosa que usa Symfony 2) y se usa un único objeto para devolver las respuestas al Ajax, pero variables globales ni una. Simplemente no son necesarias cuando se hacen las cosas bien programando en POO.
#56 cuando cambian los requerimientos lo normal es que cambies el código no el valor de las variables, por lo tanto mejor tener el acceso a través de una interfaz y no arriesgarse a estropearlo todo tocando en un solo sitio. Es una cuestión de fe y de ver lo bien que funciona
#34 #35 En realidad yo iba a comentarle casi lo mismo a #20 en un tono muy similar al tuyo, pero es que creo que te has pasado. Si tu código no necesita ningún comentario simplemente significa que realmente tu código hace más bien poco. Lo ideal no es que tenga comentarios o que no los tenga, lo ideal es que esté bien comentado.
A mi me fastidia ver comentarios simples sobre cosas que ya se ven en el código y que no aportan nada. Ahora mismo me acordé de unos compañeros con los que hice un proyecto que no distinguían entre cuando les preguntaba sobre algún algoritmo qué querían hacer, que hacían, y cómo lo hacían, aparentemente para ellos esas preguntas se contestaban diciendo diciéndome lo que querían hacer y a veces de forma tan absurda y genérica como "resolver la consulta/pedido/operación/etc". .
A veces es muy importante contestar a algunas de esas preguntas en el código. Y una cosa, tampoco puedes limitar tus comentarios al código porque el código puede estar mal.
#68 A mi me ha dado la impresión de alguien no sabe de que habla cuando se refiere a requerimientos y que de lo que de verdad quiere hablar es de parámetros globales.... pero no me gusta señalar a la gente.
#70 Ah, que él hablaba de parametrización y no de requerimientos del software. No lo leí, sólo la parte de requerimientos.
Aún mejor. Cuando hagas una nueva release haces una versión personalizada para cada cliente con su parametrización particular en variable globales.
A mi me ha dado la impresión de alguien no sabe de que habla cuando se refiere a requerimientos y que de lo que de verdad quiere hablar es de parámetros globales.... pero no me gusta señalar a la gente.
Con respecto a esto, leyendo tu comentario en #69 ya veo que eres todo un experto y sabes de que hablas. El ejemplo de barajarCartas es un ejemplo de buenas prácticas de desarrollo de software en estado puro.
#62
), toca tu un módulo de SAP lleno de Z que no has visto en tu vida y que no está muy claro, porque falta la documentación a que se dedica y porqué hace lo que hace y cual es la funcionalidad entera del mismo, que fue creado hace 5 años atras por vaya usted a saber quien para a saber que oscuro proyecto de ampliacion por una pequeña modificacion del workflow de un documento que ya ni se utiliza, pero hay algo ahí que toca un dato que ni entiendes bien que es pero jode a otro departamento que tampoco sabes bien que hace (trabajar para el sector público, que las funcionalidades de sus erp os van a desvelar un sinfin de departamentos mágicos que hacen cosas extrañas 
).
#47
#34 Aqui es donde igual cabe explicar que soy de ABAP fui durante 2 años parte del mantenimiento correctivo y evolutivo de empresa gorda (ahora gracias a dios abandone ese infierno y trabajo desde hace algun tiempo en proyectos de implantacion desde 0, pero aun me levanto empapado en sudor pensando en el cabron del Remedy
Y entonces descubres que el majo del programador tampoco ha comentado nada y te fascinas ante la lluvia de saltos y calculos sobre datos de tablas que nisiquiera sabes bien que son (si, un integer, pero que es esto, un porcentaje de algo que pone zimp_may_min_progresivo ahhh muy bien y que quiere hacer con eso?).
Y descubre que si intentas googlear informacion solo la encuentrtas en tu pauperrimo alemán y pobremente explicada lo que debería hacer (que no lo que hace la modificación en cuestión)
Puedo entender vustro punto de vista sobre piezas de códgo pequeño, bien documentado o en las que dominais cual es la funcionalidad requerida, pero creeme igual yo soy el unico programador lelo que le cuesta entender bien las cosas cuando se salen un poco de madre y de lo habitual, tampoco me considero tan bueno, pero, igual detras de vosotros pensad que puede llega alguien tan lerdo como yo y no comentar le hace la vida imposible
Y lo de las select... si lo se a mi tb me parece una aberracion y se intenta evitar.... pero los caminos del estandard SAP y los analisis funcionales que te llegan son inescrutables
#63 Ah, entonces utilizas ORACLE (dicho al revés es "el caro"). Ahora, al menos en Cantabria, está de moda pedir tu perfil para cobrar un máximo de 18.000€ brutos al año, y siendo discapacitado. Hace unos años se cobraba más por esto (más del doble), así que supongo que el sector se habrá llenado de "becarios" y "terroristas" como los que indicas
En fin, si algo de eso te toca la moral, contraataca: http://thc.org/root/phun/unmaintain.html
#64 Si bueno el sector yo ya lo pille tocado y ahora es un cachondeo
pero en la defensa de los chavales diré que en el fondo hasta los entiendes, curso de 15 días de introducción a abap y ale a subir paridas a productivo pal consultor técnico y el funcional con 1 mesecillo de curso más de lo mismo y hacen lo que pueden, es un problema de como estan planteados los proyectos de desarrollo en este país que se han tirado los precios a base de recortar la calidad de software tirando de mano de obra barata (y no porque sean malos si no porque los lanzan a los leones sin formación)
Y si Oracle, pero desde sap es digamos bastante transparente para nosotros, tiene implementado un opensql ultracurte y muy limitado para invocarlo que apenas te permite jugar con el a modo de capa en el compilador y de ahí los problemones
a veces (lo han mejorado bastante pero amos sigue siendo un mojon, y como te encuentras código heredado de igual hace 7 años con una version vieja que no dejaba segun que cosas... pos un cristo de programa)
#65 Esperemos que el software "a medida" en general vaya tomando poco a poco el camino de la normalidad y ganando en calidad. Yo soy de los que creen (y pueden demostrar) que una persona experta (con una buena base y experiencia) es capaz de desarrollar lo que 3 o 4 de estos "chavales", en el mismo tiempo (o menos) y con mucha más calidad.
"Un experto es una persona que ha cometido todos los errores posibles en su campo del conocimiento."
Niels Bohr
Tarde o temprano las empresas tienen que ver estas cosas. Casos como el que relata Wardog son reales en más sitios de los que nos imaginamos
Me parto siempre con este tío!!
jajajajaja
Grandioso. Fiel reflejo de lo que puede haber detrás de una "empresa de software muy conocida" de las que abundan en el panorama cárnico egpañol.
Aún me estoy riendo con lo de "Un pitufo epiléptico ha estado practicando sexo tántrico con doce sapos encantados sobre los portales RFID me parece una causa razonable."
#36 Una variable global no suele tener nada de malo. Pero 6 scrolls de pantalla de variables globales debería ser ilegal, penado con varias cadenas perpetuas consecutivas.
Atention SPOILER es na recopilaciond e cagadas del código.
Programas monoliticos, GOTO, varibles globales, voids...... creo que no se han dejado nada del manual del chapuzas, incluso se han inventao nuevos, como semaforos cutres y paso de parametros por ciencia infusa. En pleno agosto me ha puesto los pelos de punta.
#4 así programaba yo creo que en mi primera práctica de la carrera... empiezo a dudar de que eso lo hicieran becarios...
#8 Así programaba yo antes de entrar en la carrera, cuando ni siquiera tenía internet para consultar sino que iba a prueba y error con un libro mal traducido... Y yo creo que ni así cometía tantos gambazos...
Madre mía, tengo los pelos como escarpias.
#11 #4 Pues que queréis que os diga, yo puedo perdonar todo lo que se dice en el texto y más, lo único que me jode hasta ponerme de mala ostia y que es el más claro síntoma de que el que lo hizo no tiene ni puta idea es encontrarse el código sin comentarios explicativos.
Es el más claro indicativo de que el que lo hizo no tiene experiencia, la horrible experiencia de coger algo sin documentar e intentar saber que mierda es. Los loops anidados X10 a veces son necesarios, hay selects que no puedes evitar traerte un porron de datos porque los criterios de búsqueda que tienes no son campos clave, los goto hay veces que incluso tienen lógica (pocas pero las hay), el usar globales a cascoporro a veces es más cómodo cuando el rendimiento no es una limitación.... o incluso puedo pasar cagadas gordas y sin justificación porque coño todos tenemos un mal día y se te pueden cruzar los cables.... pero no comentar...
#9 No tiene porqué, yo he programado aplicaciones que manejan muchísimos datos en VB6 y va de pm y ya lleva 7 años de funcionamiento.
#20 hay selects que no puedes evitar traerte un porron de datos porque los criterios de búsqueda que tienes no son campos clave ¿Qué tendrá que ver?
#22 Pos que hay veces que no puedes optimizar las llamadas a base de datos ni haciendo mil join y no queda otra que traerse casi todo a local y recorrerselo en loops, la vida es dura y antes que joder el servidor de la bbdd con mil llamadas se jode al usuario que espere ad infinitum por su consulta.
)
Lo digo porque en el texto hace referencia a un select sin wheres muy jocosamente descojonandose de que no acote la búsqueda y es que a veces no se puede, y amos yo sin sin, admito que nunca pero con 2 tristes wheres que te traen un tablón interno de tropecientosmil registros me lo he encontrado muchísimas más veces de las que me gustaría y a veces no hay solución.
Resumiendo, casi todas las cosas que te dicen en la uni que no hagas en un entorno profesional acabarás teniendo que hacerlas alguna vez por exigencias del programa, o las cometerás porque estas empanado pensando en las tetas de la de enfrente y se te va la olla, o tienes un mal día, y todas todas son comprensibles, desde llamar a variables Var9/indx12/cnt7 (que tiene delito y se ve muchísimo más de lo que debería) a fallos gordos de rendimiento, pero sigo diciendo que lo que más me cabrea e indigna cuando heredo un código es cuando vienen sin comentarios, es que es algo que cuesta taaaaan poco, que no tienes que estar ni despierto ni pensar en na simplemente explicar lo que estas haciendo y demuestra tanta dejadez y poca idea (porque da igual lo bueno que sea tu kung fu, alguien en un futuro en algún momento tendrá que leerlo ya sea actualizando, corrigiendo o simplemente auditando y creeme ... SE VA A CAGAR EN TU PUTA MADRE
#28 Me cuesta creer que sea necesario llevar "todo" a cliente antes que hacerlo en una consulta... ¿Qué servidor de BBDD usas? Porque por mi experiencia, usando los índices adecuados (hay que tener las estadísticas de los mismos actualizadas), haciendo subconsultas, vistas indexadas, funciones y procedimientos almacenados, todo funciona mucho más eficientemente que llevarse tropecientos mil datos a cliente (uso de disco en servidor y tráfico de red).
De hecho, para mi el "*" en una consulta es el equivalente de poner un GOTO en un código
#c-9" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/1992120/order/9">#9 Coincido con #22, he realizado (por exigencias del guión) una aplicación en VB6 (desde el 2001) dirigida a un entorno multiusuario (> 150 usuarios concurrentes), con más de 400 tablas y algunas con más de 15 millones de registros, procedimientos almacenados, vistas indexadas, etc... e iba como un tiro. Claro que en la parte SQL tienes que saber "tunear" y depurar mucho con trazas y demás. Pero partes del mismo programa rehechas en C#, con su LINQ y la madre que lo parió, en comparación iban como el culo (hasta que no "pulías" ciertos detalles). Y consumían muchos más recursos aún estando bien hechas. Muchas veces la "facilidad" de algunos lenguajes a la hora de acceso a datos, como con LINQ, dejan mucho que desear frente a una consulta T-SQL pura y dura o a un procedimiento almacenado.
Y con esto no digo que C# sea una mierda, que a la hora de apoyarse en web services, por ejemplo, está muy bien (por escalabilidad y rendimiento), sino que en VB6 se pueden hacer cosas muy majas y funcionales para una PYME necesitando muy pocos recursos en cliente.
#20 Pues lo ideal es precisamente un codigo que no necesite ningun comentario, o lo que es lo mismo que viendo los nombre de metodos, variables y la estructura puedas entender lo que hace el programa. Los comentarios se podrian exclusivamente cuando se haga algo raro o dificil de entender.
El select con where siempre va a ser mas rapido que traerte toda la tabla y luego filtrar en el código, aunque los campos que filtres no tengan indice (que seria lo ideal),
lo de la variable trileana es buenísimo jeje.
Lo de vender programas con código de mierda y luego cobrar por una "bolsa de horas" de mantenimiento es el negocio del siglo, cojonudo, cuanto peor mejor. Lo malo de la historia es que el cliente es el que dedica tiempo de sus empleados para arreglar desastres de otros, mu bien: ¿cuando necesiten un nuevo software que harán?, ¿encargarselo a sus propios empleados y montar un equipo que dirijan los que supieron arreglar la barbarie anterior?, ¿volver a contratar a pollasoft consulting inc?. Las carnicas entregan porquerías a punta pala, pero muchos clientes lo piden a gritos.
#20 como dice el tio bob: "Every time you write a comment, you should grimace and feel the failure of your ability of expression.".
#20 >
No, no creo. Es mejor dejar a la base de datos que filtre. Sobre todo si es remota.
Y sobre el general, tampoco. Un programa que tenga bucles anidados más de dos o tres veces es que está mal diseñado. Etc.
#8 ¿ qué te hace suponer que los becarios han estudiado una carrera o informática ?
#4 ¿Que tienen de malos las variables globales? Lo pregunto en serio.
#36 que si una variable global es usada por mas de un método, creas dependencia entre ellos, así a la hora de mantener tendrás que tocar en cuatro, cinco o cien sitios distintos si quieres cambiar el código o refactorizarlo. Si además le añades que el código no lo has hecho tú (aunque a veces que lo hayas hecho tu es incluso peor) pues tienes un bonito cacao en el que cuando tocas una cosa revienta otra que no tiene nada que ver. Y todo gracias a las variables globales. Y a esta bonita descripción se le llama encapsulamiento, que se da el primer día de POO en cualquier facultad del mundo.
#36 Que siempre están ahí
#36 Algunas cuestiones que se mencionan aquí son "buenas prácticas", no porque lo contrario sea una malo en sí mismo, simplemente porque se usa sin tener ni idea de qué se hace porque parece más fácil. Alguien que sepa lo que hace debe saber barajar cuando una variable necesita ser global entendiendo los riesgos y beneficios.
Bien, el problema es que si yo tengo un procedimiento al que le paso ciertos parámetros por lo general en cualquier lenguaje de programación la cabecera/firma de dicho procedimiento ya me dice que está tocando. Y eso simplifica mucho las cosas porque ya sé 1) de qué depende y 2) sé que podría cambiar después de su ejecución.
Si yo tengo mi procedimiento barajarCartas y le paso como parámetro un mazo de cartas, yo sé que mi procedimiento solo trabajará con esas cartas, no va a tocar ningún otro. Y cuando lo use sé que no estaré fastidiando a los jugadores que usen otra baraja.
Además, si las cartas que yo le paso son "correctas" (no son defectuosas, ni faltan cartas) sé que la función debería funcionar. Es decir limitamos los posibles problemas a un error en los parámetros o a un error interno de la función. Sé que mi procedimiento no va a dejar de funcionar porque haya parámetros ocultos pasados como variables globales, así sé que no va a depender de que a lo mejor las cartas de otra mesa no estén. Ni tengo que preocuparme que a lo mejor alguien las haya utilizado y me fastidie a mi.
Al final de todo lo importante es usarlas cuando sea necesario, teniendo muy claro ese concepto de "necesario".
He llorado del descojone, sobretodo cuando averiguan el motivo de la lentitud.
¡Grandioso!
y yo he visto un progrmaa escrito por uno de Eve.., perdon, por uno de $Megaconsulting que hacia lo mismo. En desarrollo iba bien, pero en produccion con una base de datos de unos millones de registros...
Yo llevo unos meses trabajando en una aplicación web enorme hecha en Java que básicamente hace lo mismo que esa, al iniciarse precarga decenas de variables globales pillando todo a tropel de la base de datos (aunque incluye wheres) y luego se dedica a filtrar o tratar los datos a través de métodos especialmente diseñados para tal fin. De hecho no es la primera vez que la base de datos de producción se queda K.O. por sobrecarga. Claro que al menos está bastante mejor hecha que esa (por suerte para mi y mi compañero).
#29 No creo que estuviera configurado para que guarde un log de todos los select que se hacen en la base de datos, como mucho de queries lentas y ya explica que lo habían optimizado y que volaba.
Los GOTO en si no son malos y llegan a ser lógicos y útiles en muchos casos (sobre todo en C). Podría daros ejemplos pero no hay mejor ejemplo que el Kernel de linux y muchos de sus módulos.
ok, lee la tabla entera y luego filtra. Pero entonces tendrian que haber visto que al menos uno de los cores estaba al 100%
#12 No necesariamente, depende primero de cómo leas los registros y segundo de en qué momento mires el core. A lo mejor estaban mirándolo cuando todavía estaba trayéndose giga y pico por la red, o cuando la base de datos estaba todavía calculando todo lo que tenía que devolver accediendo a disco.
Y luego que cuando hay muchos cores, a veces la tarea se reparte entre todos ellos, no poniendo ninguno al 100% porque al ser una tarea secuencial, no puedes ponerlos todos a trabajar a la vez.
En cualquier caso, depende.
#13 Pero hombre, no se trata de "mirar el procesador" en un instante concreto.
Lo que se analiza son los registros de monitoreo de rendimiento. Cualquier motor de BBDD con cara y ojos mismo ya provee tales herramientas.
#12 Según explica el filtro de los datos lo hace el equipo cliente no el servidor.
#12 Lo que tendrían que haber visto es el log de la consulta SQL en la base de datos, pero bueno... está divertido igualmente.
#12 ¿ No cantaría más bien el acceso a disco ?
#12 en el log de sql. Quizás no en el de consultas lentas, ya que parece que la lentitud se producía al recorrer los datos de esa consulta en memoria del cliente, pero si en el log por consultas más repetidas por distintos usuarios ya que era algo generalizado.
#39
Wardog: el gato más famoso de Menéame.
Genial, como siempre.
PD.: yo no aseguraría que fuesen becarios, a no ser que fuesen becarios de los 80
¿En que idioma está escrita la noticia? ¿Javascript?
#27 PHP. Por los $.
Está ocurriendo ahora mismo en nuestras Facultades. Nadie enseña a programar para que otros puedan luego revisar y/o mejorar lo hecho. Y la Programación Orientada a Objetos, aun muchos profesores la consideran una molesta exigencia curricular. Aunque por fortuna no todos, muchos docentes han dejado la labor de enseñar a programar de verdad, a las ofertas de certificación profesional de las grandes casas de software.
http://webcache.googleusercontent.com/search?q=cache%3Amundowdg.com%2Fblog%2F2013%2F08%2F14%2Fel-codigo%2F&oq=cache%3Amundowdg.com%2Fblog%2F2013%2F08%2F14%2Fel-codigo%2F&sugexp=chrome,mod=3&ie=UTF-8
No sé qué me asusta más, que el filtrado de queries se haga DESDE LA RUTINA y no desde una clausula where en la consulta, o que se ataque a la BDA desde el cliente y no sea el servidor que haga de puente (a no ser que tenga una copia en local para escenarios offline).
Yo reconozco que no programo bien por falta de algunos conocimientos y por que programo con muchos descansos entre medias. Pero por favor... es pensar un poco...
+10
Impresionante!
El envío es ligeramente personal con todos esos motecitos, me siento como si empezase a ver Dinastía en la última temporada.
TLDR;
Grande Wardog. Inconmensurable. Lo del presidente lo usare la próxima vez que me vengan con la tontería!
Joder, me ha recordado a cualquier programa hecho en VB, lentitud pura y dura a partir de X datos por muy bueno o malo que esté programado.
#9 Creo que te confundes con Java
slow query log
Aún así.. Se ha superado a sí mismo con la redacción