Ingenieros Informáticos que repiten codificación (Valoración de 5.00 sobre 5, resultante de 1 votos)

Aplicaciones y herramientas informáticas, internet y otros sucedáneos informáticos
por
#238651
Pues no sé si os sorprenderá o no, o incluso alguno de vosotros estais titulados en ingeniería informática y también lo haceis.

Trabajo para una consultora multinacional en un proyecto en el que trabajamos esencialmente con Shell Scripts y PL/SQL. Trabajo en la parte de desarrollo, pero alguna vez me ha tocado mantener algún proceso o me he ojeado procesos que han hecho otros de mis compañeros, algunos de ellos ingenier@s informátic@s, según ellos. Pues resulta que multitud y multitud de veces me he encontrado que hasta es un mismo proceso(no digamos ya en procesos separados), en varias partes, había grupos de lineas que si no hacían lo mismo, que a veces si que lo hacían, sólo cambiaban en una o dos cosas, os pongo un ejemplo muy básico en pseudocódigo.

if X = 3
a = 1
b = 2
c = 3
d = 4
e = 5
f = 6

end if;


en otra parte del código pero así como os lo digo me vuelvo a encontrar:

if X = 3
a = 1
b = 2
c = 3
d = 4
e = 5
f = 6

end if;


en otra parte me encuentro algó así como:

if X = 5
a = 1
b = 2
c = 3
d = 8
e = 5
f = 4

end if;


etc ...
etc ...

osea que perfectamente esas líneas que tanto se repetían en todo el proceso, se podrian haber metido en un Procedure parametrizado ¿No es cierto?. Esto también lo aplico a las queries que muchas de ellas podrían ser perfectamente parametrizables, sin tener porque perjudicar en su rendimiento y así conseguir que en diferentes procesos no se vea una y otra y otra vez la misma select. También me he encontrado multitud de procesos que no disponen de ningún control para evitar hacer miles y miles (os aseguro que no os exagero) de selects iguales, algunas bastante pesadas contra la BD, durante la ejecución de un proceso, y os aseguro que esas selects tan repetitivas no se realizan por el hecho de que se piense en que los datos puedan cambiar inmediatemente y se quiera coger el dato más actualizado. En general, en la programación que se hace en mi proyecto, no se lleva una tendencia de que ni siquiera cuando se hacen desarrollos nuevos, se tengan en cuenta comandos nuevos (que sean compatibles con el entorno por supuesto), en absoluto, muchos lo hacen siempre por la vía tradicional, como os comentaba sin poner ningún esmero en repetir el menos código posible, es decir centralizar lo máximo posible, ni que el proceso tarde lo menos posible, no. Esto es algo que a mi personalmente me desquicia, porque no ha hecho ese proceso un cualquiera, no, lo ha hecho un ingeniero informático que debería de saber mucho en cuanto a optimización ¿No es así?

Cuando he hablado con algunos de esos ingenieros sobre esto, algunos me dicen, más o menos, que no se paran mucho a pensar en eso por falta de tiempos otros me dicen que hacer el código repetitivo es una manera de "atar" al cliente. Pero os aseguro que tener que cambiar en toda una base de datos algun detalle común a muchos procesos, y tener que tocar alomejor más de 30 procesos(packages, pls), alomejor en cada uno de ellos que salga más de 3 veces, es un auténtico suplicio.

Comentaros que simplemente soy Técnico Superior(Desarrollo de Aplicaciones Informaticas), pero si que siempre me esmero, en que el código sea claro, esté optimizado, los procesos tarden lo menos posible, y la verdad es que aunque algunos me digan que no centralizan el código por falta de tiempo, yo considero que lo hago rápido, pero ¿sabeis porque? Porque me he acostumbrado a eso.

¿Creeis que lo que se hace en mi proyecto es una mala práctica de la ingeniería?
¿Porque creeis que gente titulada universitaria hace eso, por dinero, porque no le gusta su trabajo..? ... Porque eso del tiempo y de sujetar al cliente para mi son simplemente excusas...

¿En la ingeniería informática en algún momento el catedrático dice que repetir código asi porque si es algo bueno?

Bueno espero que no os hayais aburrido con este ladrillo je je...
Saludos,
por
#239296
Pues no, todo lo contrario. Además es uno de los principios básicos que se enseña en ingeniería del software en ingeniería en informática: un buen programa o sistema ha de ser modular (es preferible muchos módulos sencillos a pocos módulos complicados), ha de ser lo más desacoplado posible (cada módulo ha de poder modificarse afectando en nada o poco a los demás) y coherente (cada módulo habrá de hacer algo con significado funcional). Esto cualquier ingeniero en informática debe llevar grabado a fuego, claro que también hay buenos, regulares y pésimos ingenieros, como en todas las profesiones.

No repetir código que se parece y centralizarlo es lo mejor para tener un mantenimiento fácil; vale, pero esto es la teoría que todos sabemos, en la práctica las prisas de desarrollo fomentan el copy&paste porque muy pocos clientes valorarán (=pagarán más) un buen desarrollo informático, auqnue es bueno que te fijes en estas cosas. Y una de las cosas que a mí más me costó entender como consultor de ingeniería y que nunca te enseñan en la universidad es que hay que educar al cliente: si un cliente es un pesetero que espera un Porsche a precio de Seat Panda está prohibido darle un producto excelente, lo estás acostumbrando mal y te tomará por el pito del sereno, simplemente le puedes ofrecer un software que corra y nada más.
por
#239453
Mendinho,

Sobre lo que comentas de la manera de modularizar estoy deacuerdo, pero hay módulos que perfectamente para obtener ciertos datos se podrían alimentar de procedimientos o funciones genericas comunes a todos los que las requieran utilizar...

Creo que el cliente no suele mirar la codificación ¿No es así?, es más no suelen entender de código, por lo que al cliente le da igual que por debajo la aplicación que le genera la información este ordenada y sea la caña de optimizada y sofisticada o sea la ley de la jungla que es como me he encontrado, muchísimos "módulos" de esos que tu mencionas en mi proyecto.

Lo de los tiempos, te puedo decir por mi experiencia que si te acostumbras la optimización del código, el pensar en que no se hagan búsquedas repetitivas, etc sale sólo, y si me sale a mi, que soy sólo técnico superior ¿Como no les va a salir a gente que en una carrera de 3 o 5 años se ha exprimido el cerebro en resolver complejas ecuaciones matemáticas, en optimizar, en resolver problemas de física, complejos programas ...? Normalmente, les saldrá 20 veces mejor que a mí y lo harán 20 veces más rápido que yo ¿No?

Yo concibo el repetir código en un módulo, como perjudicar a mis compañeros de mantenimiento, porque es que es verdad, yo lo veo absolutamente absurdo y puede dar lugar a confusiones....

¿Es que porque no pague demasiado el cliente hay que obviar principios fundamentales de la ingeniería, como que los procedimientos y las funciones están para algo?
Al menos en mi proyecto, parece que mucha peña es reacía a utilizar, cosas que están un poco más por encima de las típicas variables "planas", como son records, tablas de memorias, compuestas por records, rowtypes ... etc, etc, yo creo que hay muchos que no saben por ejemplo que dentro de un procedimiento en pl, te puedes declarar un procedimiento o una función auxiliar que tire de las variables que te hayas podido declarar en ese procedure o en la cabecera del package... Se tiende siempre a ir a lo tradicional ...uff, nos vamos a quedar estancados ...
¿Eso es lo que dicen los catedráticos en la carrera de ingeniería? ¿que no hay que investigar nuevas formas de hacer las cosas y siempre hay que agarrarse a lo que funciona y a lo tradicional?

Saludos,


mendinho escribió:Pues no, todo lo contrario. Además es uno de los principios básicos que se enseña en ingeniería del software en ingeniería en informática: un buen programa o sistema ha de ser modular (es preferible muchos módulos sencillos a pocos módulos complicados), ha de ser lo más desacoplado posible (cada módulo ha de poder modificarse afectando en nada o poco a los demás) y coherente (cada módulo habrá de hacer algo con significado funcional). Esto cualquier ingeniero en informática debe llevar grabado a fuego, claro que también hay buenos, regulares y pésimos ingenieros, como en todas las profesiones.

No repetir código que se parece y centralizarlo es lo mejor para tener un mantenimiento fácil; vale, pero esto es la teoría que todos sabemos, en la práctica las prisas de desarrollo fomentan el copy&paste porque muy pocos clientes valorarán (=pagarán más) un buen desarrollo informático, auqnue es bueno que te fijes en estas cosas. Y una de las cosas que a mí más me costó entender como consultor de ingeniería y que nunca te enseñan en la universidad es que hay que educar al cliente: si un cliente es un pesetero que espera un Porsche a precio de Seat Panda está prohibido darle un producto excelente, lo estás acostumbrando mal y te tomará por el pito del sereno, simplemente le puedes ofrecer un software que corra y nada más.
por
#239538
SolidEinyel escribió:Mendinho,
Sobre lo que comentas de la manera de modularizar estoy de acuerdo, pero hay módulos que perfectamente para obtener ciertos datos se podrían alimentar de procedimientos o funciones genericas comunes a todos los que las requieran utilizar...


Que sí, que estamos de acuerdo: no hay por qué repetir código y si dos cosas hacen lo mismo o casi lo mismo se podrán combinar en una función única más facil de mantener. Módulos suficientemente cortos, sencillos e independientes que no repitan código parecido al que ya se ha programado es la filosofía adecuada si lo que se busca es manetener. Ahora aunque el código bonito de leer es el fácil de mantener no necesariamente es el más rápido a la hora de correr. Cada invocación a un módulo lleva más tiempo de ejecución que correr un spaghetti code plano y, por ejemplo, los programas de ingeniería civil o de física suelen tener un código feo y muy malo de mantener. Todo depende de cual sea el objetivo: mantenimiento (lo normal) o rapidez a la hora de correr.

SolidEinyel escribió:¿Es que porque no pague demasiado el cliente hay que obviar principios fundamentales de la ingeniería, como que los procedimientos y las funciones están para algo?


En el mundo real se trabaja para ganar salario y no por amor al arte. No justifico una mala praxis de tus compañeros pero tienes que ser consciente de que no se puede ofrecer la misma calidad y esmero en un producto a quien te lo paga bien y a quien te lo paga mal :D

SolidEinyel escribió:yo creo que hay muchos que no saben por ejemplo que dentro de un procedimiento en pl, te puedes declarar un procedimiento o una función auxiliar que tire de las variables que te hayas podido declarar en ese procedure o en la cabecera del package...

Cada lenguaje tiene sus historias y no sé cuanto se parece PL/SQL a Java-JDBC-MySQL que es lo que conozco. Pasar las variables de manera global o por referencia al interior de una función, salvo que lo que se busque sea eficacia en lugar de mantenimiento sencillo, hay que pensárselo dos veces. A mí me parece más sencillo de entender por cualquiera el que las variables se pasen por valor de manera explícita a través de las interfaces de las funciones y que no haya demasiadas funciones anidadas.

SolidEinyel escribió:¿Eso es lo que dicen los catedráticos en la carrera de ingeniería? ¿que no hay que investigar nuevas formas de hacer las cosas y siempre hay que agarrarse a lo que funciona y a lo tradicional?


Siempre está bien repensar si las cosas se pueden hacer mejor lo diga quien lo diga.
por
#239774
mendinho escribió:Que sí, que estamos de acuerdo: no hay por qué repetir código y si dos cosas hacen lo mismo o casi lo mismo se podrán combinar en una función única más facil de mantener. Módulos suficientemente cortos, sencillos e independientes que no repitan código parecido al que ya se ha programado es la filosofía adecuada si lo que se busca es manetener.

Me alegra que estemos deacuerdo :)

mendinho escribió: Ahora aunque el código bonito de leer es el fácil de mantener no necesariamente es el más rápido a la hora de correr. Cada invocación a un módulo lleva más tiempo de ejecución que correr un spaghetti code plano y, por ejemplo, los programas de ingeniería civil o de física suelen tener un código feo y muy malo de mantener. Todo depende de cual sea el objetivo: mantenimiento (lo normal) o rapidez a la hora de correr.

A mi modo de verlo, más que de los objetivos, depende del potencial de las máquinas, de la BD y de los lenguajes de programación con los que trabajemos. En mi proyecto he realizado muchas pruebas con las que he podido comprobar que para nada es necesario utilizar ese "spaghetti code plano" que tu mencionas para conseguir unos resultados de alta velocidad, para nada. Lo que demora es realizar miles y miles (no te exagero) de querys repetitivas(Debido a la jerarquía y la forma en la que están relacionados los datos que intervienen en el proceso) durante la ejecución de un proceso, ya que no se piensa mucho en hacer controles o en realizar ordenaciones estratégicas en las selects que contribuyan a saber que si ya he encontrado un dato para algo muy concreto para que lo voy a buscar otra vez ejecutando exactamente la misma query si estoy seguro de que no va a cambiar ¿Es absurdo no? ... Se emplean cursores con selects enormes(muchas montadas por ingenier@s informátic@s) que vete a saber cuantas miles y miles y miles de querys pesadas innecesarias no realizarán internamente y que encima no tienen claúsulas que podrían facilitar la búsqueda más inmediata(porque espíritu de investigación escaso escaso), y así algunos procesos se les van en más de 8 horas. También muchas veces los procesos se demoran en muchísmo tiempo porque las tablas(muchas de esas tablas diseñadas por ingenier@s informátic@s) sobre las que se hacen selecciones de datos no tienen los índices por los campos correctos, no tienen un tamaño adecuado o simplemente ni los tienen. Muchas veces también han reventado las tablas por no tener espacio suficiente como para albergar todos los datos que se querían albergar en ella.

mendinho escribió: En el mundo real se trabaja para ganar salario y no por amor al arte. No justifico una mala praxis de tus compañeros pero tienes que ser consciente de que no se puede ofrecer la misma calidad y esmero en un producto a quien te lo paga bien y a quien te lo paga mal :D

Sabes que sucede mendinho, que para mí lo que pague el cliente para que le realicemos el proceso es transparante, yo ya he cogido unos hábitos y a mi siempre me sale esa inpiración de trabajar igual. De todas formas porque el producto no haya sido muy bien pagado, ¿Dejamos vendidos a l@s chic@s de mantenimiento? Porque esos productos que se hacen con menos pasta necesitarán mantenimiento también digo yo.
De todos modos aunque en mi proyecto el cliente pagase una cantidad alta y dando mucho tiempo, yo creo que se seguierían viendo barbaridades y burradas en la misma línea, ya que trabajar así parece que se ha convertido en un hábito.

mendinho escribió:Cada lenguaje tiene sus historias y no sé cuanto se parece PL/SQL a Java-JDBC-MySQL que es lo que conozco. Pasar las variables de manera global o por referencia al interior de una función, salvo que lo que se busque sea eficacia en lugar de mantenimiento sencillo, hay que pensárselo dos veces. A mí me parece más sencillo de entender por cualquiera el que las variables se pasen por valor de manera explícita a través de las interfaces de las funciones y que no haya demasiadas funciones anidadas.

Eso va un poco en gustos, yo soy partidarío de usar las tan temidas variables declaradas a nivel de cabecera de package(pero no me refiero solo a variables planas, sino records, tablas, etc...), que tanto detestan much@s ingenier@s informátic@s ya que hay que pensar mucho en como realizar su correcta administración y limpieza en el momento adecuado a lo largo de una aplicación. Considero que son muy útiles, por ejemplo, para evitar procesar innecesariamente. También soy partidario de declarar procedimientos dentro de otros que se alimentan de las variables declaradas a nivel del procedimiento superior... Todo esto depende de la estrategía que quiera definir cada uno.

Y en mi proyecto, observando estas barbaridades y burradas que he comentado, observando nuevos desarrollos con aspecto tradicional y poco innovador, me pregunto ¿De que les ha servido a es@s compañer@s ingenier@s informátic@s estudiar una carrera, aparte de para encontrar un puesto de trabajo?

Estoy seguro de que en otros proyectos en España se tendrá una mayor calidad en el desarrollo de software, bueno y si ya me pongo a pensar en empresas japonesas o estadounidenses de desarrollo de Software estoy seguro de que la gran mayoría llevaran una gran calidad en sus desarrollos de software, porque en esos países tienen un mayor interés por el progreso y las nuevas tecnologías, a ver porque por ejemplo consiguen altas velocidades en el software, en conexiones a internet, dudo que se trate únicamente de que eso sea debido a que utilizan un hardware potente sino más que nada al factor puramente intelectual... me quito el sombrero con la tecnología informática tan poderosa de esos 2 paises, Igualitos que nosotros ¿no? ...

Saludos,
por
#239815
SolidEinyel escribió:... y si ya me pongo a pensar en empresas japonesas o estadounidenses de desarrollo de Software estoy seguro de que la gran mayoría llevaran una gran calidad en sus desarrollos de software, porque en esos países tienen un mayor interés por el progreso y las nuevas tecnologías, a ver porque por ejemplo consiguen altas velocidades en el software, en conexiones a internet, dudo que se trate únicamente de que eso sea debido a que utilizan un hardware potente sino más que nada al factor puramente intelectual... me quito el sombrero con la tecnología informática tan poderosa de esos 2 paises, Igualitos que nosotros ¿no? ...

No te confíes, que en todos lados cuecen habas.
por
#240104
SolidEinyel escribió:
mendinho escribió:Cada lenguaje tiene sus historias y no sé cuanto se parece PL/SQL a Java-JDBC-MySQL que es lo que conozco. Pasar las variables de manera global o por referencia al interior de una función, salvo que lo que se busque sea eficacia en lugar de mantenimiento sencillo, hay que pensárselo dos veces. A mí me parece más sencillo de entender por cualquiera el que las variables se pasen por valor de manera explícita a través de las interfaces de las funciones y que no haya demasiadas funciones anidadas.

Eso va un poco en gustos, yo soy partidarío de usar las tan temidas variables declaradas a nivel de cabecera de package(pero no me refiero solo a variables planas, sino records, tablas, etc...), que tanto detestan much@s ingenier@s informátic@s ya que hay que pensar mucho en como realizar su correcta administración y limpieza en el momento adecuado a lo largo de una aplicación. Considero que son muy útiles, por ejemplo, para evitar procesar innecesariamente. También soy partidario de declarar procedimientos dentro de otros que se alimentan de las variables declaradas a nivel del procedimiento superior... Todo esto depende de la estrategía que quiera definir cada uno.


En esto no puedo estar de acuerdo contigo, no es una cuestión de gustos, la gracia del código es hacerlo tan simple, independiente y modular que cualquiera pueda transplantarlo como quien copia y pega un texto sin preocuparse de entender todos los entresijos internos. Las variables globales y el paso por referencia hacen más difícil de entender el código (porque te lo tienes que lleer todo) e impiden copiar y pegar código (porque hay cosas declaradas fuera). Explicit is better than implicit dice el zen de Python y muchos años de programación avalan esta idea en general salvo que, como he dicho antes, se tengan que hacer guarrerías para que el código vaya rápido. Claro, esto es la teoría.

SolidEinyel escribió:¿De que les ha servido a es@s compañer@s ingenier@s informátic@s estudiar una carrera, aparte de para encontrar un puesto de trabajo?


En general alguien que ha seguido unos estudios superiores en un área de la tecnología algo debería haber aprendido. Unos habrán aprovechado la oportunidad mejor y otros peor, unos habrán seguido un camino más técnico y otros un camino más comercial.

SolidEinyel escribió:Estoy seguro de que en otros proyectos en España se tendrá una mayor calidad en el desarrollo de software, bueno y si ya me pongo a pensar en empresas japonesas o estadounidenses de desarrollo de Software estoy seguro de que la gran mayoría llevaran una gran calidad en sus desarrollos de software


Pues no sé que decirte. Buena parte del software libre y abierto se ha desarrollado en Europa y con una calidad excepcional.
por
#240980
mendinho escribió: En esto no puedo estar de acuerdo contigo, no es una cuestión de gustos,
la gracia del código es hacerlo tan simple, independiente y modular que cualquiera pueda transplantarlo como quien copia y pega un texto sin preocuparse de entender todos los entresijos internos.


¿Entonces tiramos por la borda la idea de que un procedimiento llame a una función, de que una función llame a un procedimiento, de que un procedimiento llame a otro, de que una función llame a otra (compilados en el mismo package o en otros packages que pueden estar asociados perfectamente a un mismo módulo) ... simplemente por la comodidad y ponemos siempre el "code spagueti plano"?
En el momento que, por ejemplo una función llame a un procedimiento, que encima está compilado en otro package, el código ya no es transportable ¿No?, y como el copy - paste en ese caso nos falla, ¿eso sería un mal código según tu?
¿En eso se basa el ingenio aprendido en la carrera de ingeniería informática?
¿Es que las ecuaciones que se resuelven en las asignaturas relacionadas con matemáticas y álgebra en la carrera son simplonas y faciles, hasta el punto que un estudiante de bachiller las sabe resolver?
¿Para eso se rompe tanto la cabeza un estudiante en la carrera de ingeniería informática, para luego realizar el código con el propósito de que sea fácil aplicar la transportación mediante el copy - paste y no hacer nada del otro mundo? ... Sinceramente no me encaja

mendinho escribió:Explicit is better than implicit dice el zen de Python y muchos años de programación avalan esta idea en general salvo que, como he dicho antes, se tengan que hacer guarrerías para que el código vaya rápido. Claro, esto es la teoría.


Bueno esas "guarrerías" perfectamente controladas, (te podría poner ejemplos de que si se quiere conseguir un objetivo son inevitables hacerlas), no tienen porque requerir ni mucho menos el estudio de todo el código del package del módulo, y suelen contribuir, entre otras cosas, a que el proceso no sólo vaya más rápido, sino que durante la ejecución no se realicen acciones absurdas. Para entender "esas guarrerías", están los comentarios en el código, los nombres perfectamente definidos de las variables o incluso su documentación. Supongo que en la ingeniería informática se aprenderárá que el código de un programa no debe de hacer acciones innecesarias y absurdas ¿No?...¿Pero que sucede? que para conseguir ese objetivo, en aplicaciones que, por la jerarquía lógica de los datos que procesan, lo requieren, se considera que hay que pensar demasiado y claro se acaba deshechando la idea y nada, si la aplicación tarda 2 horas que tarde, si lo hago en 200 lineas en vez de hacerlo en 100, que más dá, ya pensé demasiado y derroché talento en la carrera ...

Para mi es más guarrería es repetir código por todos los lados, hacer selects gigantescas repitiéndolas por muchos lados, hacer escasísimos módulos con código reutilizable, en definitiva, no aplicar la ingeniería...

Saludos,
por
#241111
SolidEinyel escribió:¿Entonces tiramos por la borda la idea de que un procedimiento llame a una función, de que una función llame a un procedimiento, de que un procedimiento llame a otro, de que una función llame a otra (compilados en el mismo package o en otros packages que pueden estar asociados perfectamente a un mismo módulo) ... simplemente por la comodidad y ponemos siempre el "code spagueti plano"?
En el momento que, por ejemplo una función llame a un procedimiento, que encima está compilado en otro package, el código ya no es transportable ¿No?, y como el copy - paste en ese caso nos falla, ¿eso sería un mal código según tu?
¿En eso se basa el ingenio aprendido en la carrera de ingeniería informática?
¿Es que las ecuaciones que se resuelven en las asignaturas relacionadas con matemáticas y álgebra en la carrera son simplonas y faciles, hasta el punto que un estudiante de bachiller las sabe resolver?
¿Para eso se rompe tanto la cabeza un estudiante en la carrera de ingeniería informática, para luego realizar el código con el propósito de que sea fácil aplicar la transportación mediante el copy - paste y no hacer nada del otro mundo? ... Sinceramente no me encaja


Creo que no me entiendes: para que el código sea fácilmente transportable, (rehusable, en terminología de ingeniería del software) no se trata de que no haya invocaciones a otras funciones del mismo o de otro paquete, se trata de que el paso de variables se haga preferiblemente de manera explícita, es decir, a través de la interfaz de la función.
Repetir código innecesariamente está mal (es el pecado del programador perezoso) y también está mal programar cosas más complicadas de lo que un programador junior pueda entender (es el pecado de la vanidad del programador listillo).
No sé exactamente lo que hacen tus compañeros porque desconozco los detalles, aunque seguramente tengas tu parte de razón. En todo caso esto no es un foro de lamentaciones al estilo Barrapunto, así que si quieres saber de primera mano que tan buena o mala es la formación en ingeniería en informática no tienes más que matricularte en la UNED como hice yo y ver que tal te va.
por
#241275
mendinho escribió:En todo caso esto no es un foro de lamentaciones al estilo Barrapunto, así que si quieres saber de primera mano que tan buena o mala es la formación en ingeniería en informática no tienes más que matricularte en la UNED como hice yo y ver que tal te va.


Antes de nada, que me disculpen los lectores del hilo, si en algún momento han interpretado que yo estoy diciendo que en las universidades se imparte una mala formación en la carrera de ingeniería informática, en absoluto cuestiono la formación, además se que siempre se promueve el trabajar con inteligencia y el progresar en tu calidad como profesional-investigador-ingeniero, lo que si que digo y me parece lamentable es que algunas personas tituladas en esta carrera, lleguen a su puesto de trabajo y parezca que los conocimientos que aprendieron en la carrera(a nivel de diseño de un software, de elmentos de BD), los aplican, poco, muy poco o nada, hasta el punto de que parece que saben poquísimo de lo que significa programar, da la sensación de que se les han fundido las luces que bien fuertes les brillaron durante sus estudios de carrera. Afortunadamente no les sucederá lo mismo a muchos arquitectos, ingenieros de obras públicas, físicos, químicos ... porque sino que sería de nosotros.

mendinho escribió:Creo que no me entiendes: para que el código sea fácilmente transportable, (rehusable, en terminología de ingeniería del software) no se trata de que no haya invocaciones a otras funciones del mismo o de otro paquete, se trata de que el paso de variables se haga preferiblemente de manera explícita, es decir, a través de la interfaz de la función.


Admito que puedo ser un cabezota con la idea de pasar variables de manera implicita y que sin duda lo ideal sería hacerlo como tu comentas porque queda totalmente claro, pero eso no vale en todos los casos, porque a veces es imprescindible que el proceso no se demore demasiado y es inevitable su uso si te planteas que tu procedimiento o función sea capaz de conseguir ese objetivo y no quieres pasar por interfaz(por In , Out o por In Out) variables o estructuras de variables que realmente no le hacen falta pasar de manera explícita al procedimiento o la función para realizar las acciones "explícitas" que se quieren realizar y además a nivel de sesión tienes que guardar los valores en algún sitio.

mendinho escribió:No sé exactamente lo que hacen tus compañeros porque desconozco los detalles, aunque seguramente tengas tu parte de razón.


No toda mi perspectiva de los titulados en ingeniería informática es mala ni mucho menos, antes de entrar al proyecto en el que estoy ahora, realicé las prácticas del ciclo formativo de desarrollo de aplicaciones informáticas, en una empresa formada en su mayoría por becarios que acababan de terminar en la universidad de la ciudad, y ahí si que pude ver y palpar que se apostaba muchísimo por utilizar funciones, procedimientos y librerías, por la centralización de la codificación ... eso sí la empresa trataba proyectos bastantes más pequeños...

mendinho escribió: está mal programar cosas más complicadas de lo que un programador junior pueda entender (es el pecado de la vanidad del programador listillo).


Si ponemos siempre el code spagueti plano un programdor junior siempre entenderá lo que hace la aplicación ¿No? y así tiramos por la borda la ingeniería..

Si muchos titulados en ingeniería se hiciesen los listillos, la calidad del Sotfware desarrollado crecería muchísimo, lamentablemente en mi proyecto hay escasos profesionales que nos lanzamos por esa vía "listilla".

Saludos,
Palabras clave
Temas similares

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 7 invitados

Permisos de mensaje

No puede abrir nuevos temas en este Foro
No puede responder a temas en este Foro
No puede editar sus mensajes en este Foro
No puede borrar sus mensajes en este Foro
No puede enviar adjuntos en este Foro