Estoy forzado a escribir código incorrecto. ¿Cómo me salvo la cara? [cerrado]

70

Solo soy un desarrollador junior, pero mi trabajo me obliga a trabajar con un código PHP realmente terrible (piense en el peor código PHP que haya visto; luego piense en el código dos veces más mal). Por lo general, trato de corregir errores y luchar con el código base para agregar nuevas funciones. A veces me ordenan que las cosas funcionen lo antes posible, lo que a menudo implica trucos sucios.

Anteriormente, el producto era de código abierto y me preocupa que pueda ser de código abierto en el futuro. Me avergonzaría si alguien (especialmente los posibles empleadores) pudiera encontrar mi nombre junto a algunos de los conjuntos de cambios. ¿Qué puedo hacer para proteger mi buen nombre?

No estoy seguro de si esto es relevante, pero agregaré que ni mi jefe ni mis colegas quieren admitir que el código es malo, pero no estoy seguro de que pueda culparlos por eso, muchos de ellos Este es su primer trabajo.

    
pregunta Ashamed One 06.07.2011 - 02:24

10 respuestas

132

Roma no se construyó en un día, pero puedes ser un buen 'Boy Scout'. Cada vez que toque el código, déjelo mejor de lo que era antes. No toma una cantidad extraordinaria de tiempo usar nombres de funciones razonables, buenos estándares de codificación y comentarios decentes cuando trabaja.

Creo que el peligro es pensar que es todo o nada. El hecho de que no pueda pasar el tiempo que desea para escribir código elegante, no significa que tenga que darse por vencido y escribir basura.

    
respondido por el Amy Anuszewski 06.07.2011 - 02:38
60

De acuerdo con S.Lott de los comentarios * (por una vez :) nadie te obliga a escribir código incorrecto. La cosa es, dev menor. a menudo (este sitio también es el culpable de eso) perderse en las mejores prácticas, "código hermoso", ... como quiera que lo llamemos ... y no hacen mucho; O lo logran pero pierden mucho tiempo. Al decirles que escriban un código incorrecto (que es un código que también funciona) se obtiene que "a través de eso", solo hace que entreguen algo. A medida que pasa el tiempo, resulta que a (ahora no más :) el desarrollador junior aparece muy rápidamente con una solución rápida y sucia, pero pasa el resto del tiempo mejorándolo. Y a medida que pasa el tiempo, aprendes más y, en algún momento, empiezas a ofrecer soluciones rápidas y sucias que en realidad son un buen código.

Pero, si sigues tu camino e intentaste escribir el código perfecto desde el principio, lo más probable es que hayas pasado mucho tiempo y no hayas hecho casi nada.

Entonces ... escribe un código incorrecto, ... un montón ... código que apenas funciona, y luego ITERATE. ¡Cada iteración un poco mejor!

Nadie escribió la solución perfecta la primera vez.

* esto, si fuera más corto hubiera sido un comentario.

    
respondido por el Rook 06.07.2011 - 02:55
40

Los comentarios de código son tus amigos aquí.

Cuando sientas que tienes que escribir un hack barato debido a la presión, solo di algo como "Este código hace X debido a limitaciones de tiempo. Idealmente, haría Y en su lugar. - Ashamed One, 5 de julio de 2011"

Luego, si los posibles empleadores lo ven, se darán cuenta de que prefiere escribir un buen código, pero también está dispuesto a ajustar su estilo de codificación a las necesidades comerciales. La mayoría de los empleadores verán a ambos como cosas buenas.

    
respondido por el Bob Murphy 06.07.2011 - 03:14
10

Depende de cómo te obliguen.

En mi experiencia, hay dos posibilidades:

Se siente forzado por una agenda apretada, código legado, etc.

En este caso, como la mayoría de las otras respuestas ya lo dicen, depende de usted "optimizar para la tranquilidad". Es posible que no tenga tiempo para volver a escribir el código base en MVC, pero como primer paso, por ejemplo, puede dejar de pegar su SQL a mano y escribir un bonito execute_sql($query, $params) , que sienta las bases para las abstracciones como fetch_customer($filter_params) , etc. Recuerde que todas las mejores prácticas son, en última instancia, que su jefe recibe un producto antes, por lo que solo existe un conflicto en cuanto a cuánto tiempo invertir en el futuro frente al presente.

Cuando configura el contexto correcto ('dentro de 6 meses, sin tener tiempo extra, he refactorizado el código monolítico a MVC'), debe dejar su nombre en el código e intentar estar orgulloso como un terapeuta, que enseña una acariciar a la víctima para que vuelva a decir palabras sueltas.

Se le ha ordenado explícitamente que lo implemente de la manera que considere inadecuada

El intento de separar la vista del modelo no sobrevive a la revisión, porque "es demasiado complicado, ¿por qué no haces simplemente consultas de sql simple?". Tu execute_sql se conserva porque "un programador con disciplina no necesita eso".

Este caso es malo. En mi experiencia, generalmente viene con microgestión y líderes de equipo que fueron promovidos allí por razones políticas, no por sus éxitos. El problema real es que te ponen a cargo de algo (el código) que no puedes controlar (tienes que hacerlo a su manera). La mejor solución sería resolver la causa raíz (es decir, que eres tratado como un gruñido). La segunda mejor solución (y en mi experiencia, la habitual) es dejar de fumar.

La ventaja es que, en este escenario, es probable que su nombre no se publique de todos modos, porque el líder del equipo se lleva el crédito por todo el éxito.

    
respondido por el keppla 06.07.2011 - 14:16
8

Estoy bastante seguro de que tu jefe te exige que entregues algo rápido, pero no es que tomes ningún esfuerzo extra para hacerlo deliberadamente malo. Lo que significa que siempre que tenga la opción de elegir entre un código realmente malo y un código un poco menos malo, y ambas opciones le tomarán el mismo tiempo de implementación, opte por la opción un poco menos mala. Esa es la solución a corto plazo, y no requiere ningún esfuerzo en absoluto.

A largo plazo, habla con tu jefe. Explique cómo invertir 15 minutos aquí puede ahorrar horas allí. Asegúrese de tener ejemplos convincentes, no del tipo "si hice esto y lo otro aquí, espero que pueda hacer esta otra cosa el próximo año", sino más bien, "mire, aquí hice esto y porque de eso, me tomó tres horas encontrar el problema allí; si lo hubiera hecho así, el error habría sido aparente de inmediato ". Una advertencia aquí: mientras que el código elegante y mantenible se siente mucho mejor y más eficiente, a veces no lo es. Hay situaciones en las que una solución rápida descuidada está perfectamente justificada: a veces escribes código de un solo uso, a veces mantienes con vida una pieza de chatarra obsoleta, esperando lo real; a veces, el beneficio de una solución adecuada no justifica el esfuerzo (en términos de dinero, que es todo lo que le interesa a su jefe).

Si todo lo demás falla, ve a buscar otro trabajo.

    
respondido por el tdammers 06.07.2011 - 08:12
3

Nadie te obliga a escribir código malo. Puedes cambiar esta situación y convertirla en algo positivo. Cambio pionero para políticas y procedimientos. Y tampoco siempre puedes ser el "sí" hombre / mujer. Si dicen que necesitan funcionalidad x antes del final del día, dígales que no es factible, pero que justifiquen por qué no lo es. Donde haya un problema, ofrezca soluciones. No solo un ojo ciego, o peor aún ... añadiéndolo.

Tu tienda de desarrolladores no es la primera en tener fechas límite estrictas, aunque sigue teniendo el deseo de mantener un código bien diseñado.

    
respondido por el user29981 06.07.2011 - 02:33
3

Cualquier compañía necesita encontrar un equilibrio entre escribir código brillante, con documentación extensa y pruebas de unidad y obtener productos en el mercado en un presupuesto y espacio de tiempo razonables.

El mejor código del mundo no importa si está obsoleto antes de su lanzamiento.

Ser pragmático es tratar de encontrar ese equilibrio. Conseguir que las características se solucionen rápidamente puede ser comercialmente esencial en este momento, no significa que siempre lo será.

Se necesita mucha experiencia (más de lo que la mayoría de los codificadores tienen), para lograr este equilibrio correcto. Es muy fácil ir por cualquiera de los dos extremos. Encontrar un camino intermedio es más difícil.

No estoy diciendo que tu jefe tenga razón. Como programador, existe la tentación de intentar crear constantemente un código hermoso que no sea comercialmente viable. Ser consciente de esta tentación puede ayudarlo a darse cuenta de que algunos de estos trucos no son tan malos.

La mayoría de los códigos después de un tiempo suficiente contendrán hacks para situaciones específicas que fueron demasiado costosos para refactorizar en un marco general.

    
respondido por el Jeremy French 06.07.2011 - 13:46
2

Me gustaría agregar que no debería continuar como lo está haciendo ahora, sin decir nada y solo pirateando y pirateando.

Necesitas pararte y señalar el código concreto y decirles qué apesta. Sea específico y use las métricas de código para respaldar sus reclamos. Nada es más embarazoso que afirmar que un código es malo cuando en realidad no lo es, simplemente no entendiste lo que se estaba haciendo.

Estoy seguro de que hay muchas herramientas disponibles de uso gratuito para el análisis de código PHP enlace

También, por supuesto esto enlace

Léalo, resuma lo que puede encontrar en su aplicación y, por supuesto, enumere alternativas . Es una mala práctica levantarse y gritar "No me gusta cómo se hace esto" sin presentar una forma alternativa (preferiblemente) mejor de hacerlo.

Los hacks rápidos cuestan dinero. Y no lo veas como algo totalmente negativo: puedes aprender mucho de este trabajo ahora y aprovechar las experiencias que obtengas en el próximo.

hth

    
respondido por el UrbanEsc 06.07.2011 - 12:03
0

Antes de cualquier otra cosa, si usas control de código fuente de algún tipo, ¿verdad? Si no, empieza desde allí. Primero le ayudará y será adoptado rápidamente por el resto del equipo.

Si tiene control de código fuente, no debe poner su nombre en el código, solo debe poner el nombre de su compañía. Es común que en un código incorrecto colocar un historial de revisión en los comentarios en la parte superior de los archivos, esto se delegue mejor al control de fuente.

Ahora, con respecto a la calidad del código, no podrá cambiarlo como un enfoque de Big Bang. Lentamente, uno por uno, agregue nuevos enfoques a diferentes temas. Si lo haces bien, te AHORRARÁ un tiempo y lo utilizarás para mejorar la calidad general.

Para darte un ejemplo mío, una vez llegué en medio de un proyecto con una aplicación Perl / CGI donde todo el HTML estaba en el código. Toda la aplicación estaba en un solo archivo sin una estructura clara. Nada fue versionado. Comencé configurando un repositorio de CVS (no hay SVN disponible en ese momento), puse una interfaz web para el cliente. Al principio, yo mismo estaba manejando los compromisos de mis colegas. Luego, divido todos los métodos en diferentes módulos (archivos). En ese momento, los colegas comenzaron a adoptar CVS. Luego, moví el HTML fuera del código. Luego, cada vez que tenía que hacer un cambio en alguna parte del código, me tomaba un poco de tiempo para refactorizarlo. Al final, la velocidad de desarrollo había aumentado tanto que el cliente estaba extremadamente contento. Solicitarían un cambio estético y en lugar de decirles "tomará 2 días", lo cambié sobre la marcha en el entorno de desarrollo.

Sin embargo, este enfoque solo funcionará si dominas el código general lo suficientemente bien. Si no entiende el panorama general, si algunas partes de la aplicación siguen siendo ininteligibles, hará su trabajo realmente difícil.

Una última cosa, una reescritura completa es a veces la única solución, pero generalmente es muy difícil justificar su costo para la administración.

    
respondido por el Eric Darchis 06.07.2011 - 18:49
0

Ya que eres un desarrollador junior, esto es realmente algo bueno. Si te lanzan en medio de un gran desorden de códigos, aprenderás mucho más sobre qué no hacer que solo trabajar con un código perfectamente "limpio". Aproveche la situación y aprenda a refactorizar el código incorrecto y conviértalo lentamente en algo más manejable. Y no te quejes de tener que ser lo antes posible. Ese es el punto: aprenda a refactorizar y limpiar el código mientras hace las cosas en un plazo ajustado. Después de todo, cualquiera puede escribir código perfecto si tiene un tiempo infinito disponible.

    
respondido por el GrandmasterB 06.07.2011 - 20:41

Lea otras preguntas en las etiquetas