Barrapunto

Dicen que soy quisquilloso y "especialito" por que estoy todo el dia intentando convencerles sobre todos los problemas inherentes a hacer las cosas asi

En mi opinión el problema no es de ellos, lo tienes tú. Debes buscar trabajo en empresas con mayor madurez en los procesos productivos.

Respetuosamente: puede que seas tú el que estás equivocado.

Te cuento por qué... [...] con un diseño orientado a objetos que cumpla [...]

¡Vaya! Parece que damos por sentado que hay que utilizar un diseño orientado a objetos.

Los "novatos" (es broma) tenéis que saber que también se puede utilizar una buena programación estructurada y procedural, y no utilizar un diseño orientado a objetos. Incluso aunque utilices un lenguaje orientado a objetos (Java, C++, etc.), no es necesario que utilices un diseño orientado a objetos, puedes utilizar un diseño estructurado y procedural.

no utilizan herencia ni interfaces

¡Esto es el colmo! Y aquí sí que me pongo serio. ¿Acaso es obligatorio utilizar interfaces? Esta moda de ahora de utilizar interfaces, por ejemplo "por si cambiamos la base de datos por otra cosa" es típica de alguien que se ha leído muchos documentos "modernos" de los que circulan por Internet pero tiene poca experiencia en una empresa real. Enterémonos: NADIE cambia la base de datos por otra cosa, y, si se cambia, te aseguro que el menor de los problemas será el haber usado o no interfaces. Es realmente absurda la costumbre de hacer siempre dos fuentes: uno con el interface y otro con la implementación. Los interfaces están bien cuando necesitas herencia múltiple (que no existe en Java), pero es absurdo usarlos "por si nos cambian la base de datos por otra cosa y tenemos que modificar la implementación".

Akbar tiene un mensaje [blogspot.com] para ti.

Ahora en serio, si la situación es como la pintas, lo mejor es que salgas corriendo de allí, porque lo más probable es que te peguen a ti los malos vicios y la cultura que ha generado ese tipo de desarrollos.

Si por la razón que imagino, no puedes permitirte salir de allí, trata de ponerte en cuarentena y realizar bien tu trabajo. Eso implica que tu seas el único responsable de tus desarrollos y que si alguien más tiene que tocarlos o colaborar contigo, lo haga baja tus reglas. De esta manera minimizas el contagio y quizá consigas un converso o dos a la larga. Pero ya te adelanto que ese camino es duro y muy largo, y requiere de aptitudes que van más allá de las aptitudes técnicas.

Solo dos cosas: 1.- Una AK-47, también llamado cuerno de chivo. 2.- Mucho C4. No falla. Es broma ... claro. ======================= http://e-scientia.co.uk/ [e-scientia.co.uk]

Es una situación difícil, pero una forma de hacerles ver poco a poco que hay formas mejores de hacer las cosas es, cuando haya un problema, explicar cómo se podría haber evitado de hacer las cosas bien. Sin echar las culpas a nadie, ojo, que eso pone a la gente a la defensiva, aquí hay que ser asertivo y, más que decir "ha petado porque tú lo has hecho mal", hay que intentar decir "si a partir de ahora lo hacemos así esto no volverá a pasar".

Y, por supuesto, practica con el ejemplo. Que los demás hagan lo que quieran, pero tu código hazlo bien. A lo mejor el día que un cambio en alguna cosa a los demás les implique una semana de trabajo y a ti sólo modificar dos líneas, se van dando cuenta de que haces las cosas por algo.

Saludos y suerte

No sabía que trabajásemos juntos :-D

Si puedes encontrar una empresa de la competencia con mejor posicionamiento en el mercado y mejores prácticas que la tuya, intenta

1. Pedir trabajo allí. Si no funciona,
2. Déjales bien clarito a tus compañeros que el éxito de la competencia esta basado precisamente en sus mejores prácticas de desarrollo. Que lo que ellos hacen es pan para hoy y hambre para mañana.

Los nuevos empleados en una empresa, por definicion de "nuevo", no tienen experiencia. Y tu eres el nuevo allí. A mi me ocurrió lo mismo en mi lugar de trabajo. Cuando entré tuve varioas discusiones con mi jefe e incluso con el jefe de mi jefe con la forma de programar que había. En este lugar, las "buenas practicas de programacion" consisten en a) copiar y pegar código. b) tener mucho codigo por duplicado o triplicado explicitamente. c) usar variables globales en grandes cantidades. Mi consejo es que no te calles ni te guardes tus opiniones, pero no dejes que esas discusiones afecten tu trabajo ni el de otros. Un compañero de trabajo que perturba el trabajo de otros y realiza comentarios negativos constantes es mucho peor a usar un par de variables globales.

sali corriendo de ahi lo mas rapido que puedas!!!!

Si no te gusta lo que decide el responsable te vas de la empresa y haces como hice yo y te montas la tuya propia. No estas para darle clases a nadie, ni decirle a nadie como tiene que hacer su trabajo. Entre otras cosas porque hay muchas formas posibles, viables y rentables de hacerlo. Si no estas de acuerdo con las decisiones de tu jefe. Puerta. No eres dios, ni tu criterio es el único valido. No tengamos tanto ego. Ademas, no se le puede enseñar a alguien que piensa de una forma, el pensar de otra, por tanto ellos no te van a enseñar a ti a ver el lado positivo de su forma de trabajo y tu esta claro que no tienes el interés aprender nada sobre ese equipo de gente. Sois incompatibles, y tu eres el que sobra. A la calle. Macho. A creerte superior a otro sitio porque a ti también te queda mucho por aprender...

Compra un par de rifles y munición, enciérrate en la empresa tomando de rehenes a tus compañeros. Pide como exigencia que te todos programen como profesionales. No pidas el helicóptero, mola mucho pero siempre te la meten con él.

Si tienes que matar a alguien, ya sabes, los jefes primero.

Si te dice algo la poli, al final les explicas que era un bromón.

Las palabras mueven, el ejemplo arrastra.

Por lo que me dices son unos mantas. Ahora, tampoco estoy de acuerdo en que todas las "Best Practices" que mencionas sean realmente tan buenas prácticas (aunque algunas cosas son un mal necesario en lenguajes como Java).

Si el jefe está de acuerdo con ellos me temo que no puedes hacer mucho más que irte y buscarte a un equipo más serio, o hacer un trabajo a largo plazo de educación, que es lo que necesitan, haciéndoles ver lo que pierden trabajando a la chapuza.

Existe un problema de educación muy importante en esta profesión, y es que en pocos sitios se aprende a trabajar bien y formalmente, y en muy pocos sitios te pagan por así hacerlo. Muchos jefes no saben ver estas cosas (muchos jefes no distinguirían un ordenador de una farola, tampoco).

Al jefe tienes que hablarle del coste del software mal escrito. Esto es lo único que le va a medio convencer para preguntarse si quizá tengas razón y darte una oportunidad de demostrarlo.

Pero yo me iría pensando muy mucho lo que te han dicho casi todos: lárgate de ahí en cuanto puedas.

Hay dos tipos de programadores... qué digo, hay dos tipos de personas: las que quieren mejorar día tras día y las que piensan que ya saben todo lo que necesitan saber. Tú pareces estar rodeado de gente del segundo tipo, por lo que no creo que tengas ninguna esperanza.

No se puede enseñar a alguien que no quiere aprender.

Es recurrir a la neurociencia. Todos hacemos algo según la recompensa que obtendremos. Así, hay que ofrecerles a los especímenes una recompensa concreta al esfuerzo de hacer la codificación con estándares. Alli es donde era otro punto de apoyo: la gestión. El sistema de indicadores que premia con bonos o calificaciones de rendimiendo. Los indicadores con más peso suelen(deberían) ser los que representen la salud del proyecto. Ahi pasa que los estándares de programación no pesan como indicador por lo tanto nadie se esfuerza por implementarlos cumplirlos. Es más importante terminar en fecha. El tema es bastante profundo.

Aunque probablemente no sea el caso, me ha recordado a un párrafo de the Tao of programming:

  A novice asked the Master: ``Here is a programmer that never designs, documents or tests his programs. Yet all who know him consider him one of the best programmers in the world. Why is this?''

The Master replies: ``That programmer has mastered the Tao. He has gone beyond the need for design; he does not become angry when the system crashes, but accepts the universe without concern. He has gone beyond the need for documentation; he no longer cares if anyone else sees his code. He has gone beyond the need for testing; each of his programs are perfect within themselves, serene and elegant, their purpose self-evident. Truly, he has entered the mystery of Tao.''

a menudo uno entra en la diyuntiva de escribir codigo optimizado o codigo reutilizable el codigo optimizado termina siendo espartano y dificil de leer por otros en el codigo reutilizable a menudo existe codigo duplicado para evitar dependencias al escribir codigo en muy corto periodo de tiempo, luego al leerlo uno se encuentra que hay codigo duplicado, nombres de variables poco significativas, nombres de funcion que solo el que las hizo sabe para que sirven es muy dificil cuando hay varios programadores con diferente coding style(estlo de codigo) y ni hablar cuando hay dogs of code y me gusta mas como suena en castellano "Perros del código" que solo hacen destrozos.

Bienvenido al mundo real. Salvo que llegues a entrar en una empresa consolidada, la mayoría de las veces te vas a encontrar eso. Y si nos metemos en el tema de documentación... mejor ni hablar xD Y si añadimos el análisis de requisitos... en su mayor parte inexistente...
Yo también me encontré con eso en mi primer trabajo. Todo funcionaba parche sobre parche, cuando tenias que modificar algo tenias que recorrerte prácticamente toda la aplicación fichero por fichero para ver que no estuviese en más sitios. Huelga comentar, que la documentación era inexistente.
Como ya te han dicho algunos:
1 - Tampoco tiene que ser todo orientado a objetos (depende del lenguaje en que programes). También hay otro métodos de organizar el código, no necesariamente POO.
2 - Haz tu código lo mejor que puedas. Cuando alguien tenga que modificar algo y se tire una semana para hacerlo... y tu si lo has hecho bien solo tengas que cambiar un par de lineas... lo normal sería que se diesen cuenta... el problema de esto es que como tardas poquito, le dan menos importancia aún, ya que por lo general el mandamás suele no tener ni idea de nada...
3 - Esto es un consejo, no vayas de "listillo" y trates de cambiar todo el funcionamiento de la empresa de la noche a la mañana... El clavo que sobresale es el primero en llevarse el martillazo...

Programar en un entorno hostil es un reto. Armado con el arsenal de las buenas prácticas de programación puedes extraer un orden del caos. Como te han dicho, predica con el ejemplo, si eres capaz. No muestres apatía, y premia el buen código que hagan tus compañeros. En un sitio así, aprenderás mucho más de por qué las buenas prácticas de programación lo son. El reto consiste en programar al mismo ritmo que tus compañeros, pero mejor. Si lo consigues, no habrá nada que se te resista...

Es bastante complicado y es lo normal en la mayoría de los sitios. Decirte que cambiarlo no vas a poder y que te lo vas a tener que currar si quieres que a partir de ahora se hagan las cosas bien, que es lo suyo, de cara sobre todo a mantenimientos y evolutivos y otros futuros grupos de trabajo. Ten preparado un método de trabajo y la capacidad de concienciar y ayudar a los más torpes digamos, y en el siguiente proyecto hazles la propuesta con algo práctico y rápido, algo que puedan ver las ventajas que principalmente son menos esfuerzo y más sencillez y organización a la hora de escribir líneas de código. //Suerte

Me parece que lo estáis planteando mal, no se puede llegar a un sitio y decir a los que llevan tiempo trabajando de una manera que lo están haciendo mal y que tú eres el único que sabe hacerlo bien, el recién llegado.
Las cosas hay que plantearlas de otra forma, con más psicología y mucha mano izquierda para hacer que ellos mismos se convenzan y no lo vean como una imposición sin sentido del novato listillo.
Las buenas prácticas de negociación también son muy importantes.

Yo encontré la misma situación, me asignaron agregar algunas funciones al sistema pero estaba tan mal programado que no se le encontraba ni pies ni cabeza, al cabo de un par de días logre aplicarle los cambios y me pareció buena idea normalizar al menos la parte que agregue, Para sorpresa mía el jefe me dijo que era mal programador y que hacia demasiadas vueltas, entonces le confronte ademas le recomendé que leyese de normalizan y administración de proyecto al final renuncie

eso es lo que les gustaria a los que quieren crear un colegio... como si ellos tuviesen el don divino de decidir como se hacen las cosas...

Quizá el que deba aceptar que tiene errores y que no es dios eres tu... Yo tenia uno de esos quisquillosos en mi curro y el pobre no tenia ni idea de la vida, ni de programar, ni de nada... Cuando obtengas experiencia ya veras que la mayoría de cosas son una completa perdida de tiempo inútil y sobresaturacion de recursos con ningún beneficio.

o quiza tienen la experiencia para saber que muchas de esas cosas son chorradas inutiles que jamas van a utilizar pero como vienen en un libro y un tio te ha dicho que lo tienes que hacer asi porque en las maquinas de 1979 funcionaba bien, pues eso... asi va la informatica en España. Os lo tragais todo y encima os creeis unos maquinas.

Osea que el nuevo y sin experiencia sabe mas que los que llevan años haciendo su trabajo. Mas o menos es lo que os creéis todos... Luego salen cosas como las NoSQL y os lleváis las manos a la cabeza. Normal con una mente tan cuadriculada, atrasada y sin experiencia.

Cuánta razón tienes. Con lo fácil que lo ponen a día de hoy los navegadores y que todavía sigamos así...

No lo pillo...

¿Esperas que los coja uno a uno y les dé por el culo si resulta que no hacen caso?. Seguramente se resistirán, y hasta es posible que el que no oponga mucha resistencia acabe "devolviéndole" la jugada a él. xD