¿Cuál es el / Hay una manera correcta de decirle a la administración que nuestro código apesta?

70

Nuestro código es malo. Puede que no siempre se haya considerado malo, pero es malo y solo va cuesta abajo. Empecé recién salido de la universidad hace menos de un año, y muchas de las cosas en nuestro código me desconciertan. Al principio pensé que, como el nuevo chico, debía mantener la boca cerrada hasta que aprendiera un poco más sobre nuestra base de códigos, pero he visto muchas cosas para saber que es malo.

Algunos de los aspectos más destacados:

  • Todavía usamos marcos (intente sacar algo de una cadena de consulta, casi imposible)
  • VBScript
  • Fuente segura
  • 'Usamos' .NET; con eso quiero decir que tenemos envoltorios .NET que llaman a COM DLL, por lo que es casi imposible depurar fácilmente
  • Todo es básicamente una función gigante.
  • El código no es mantenible. Cada página tiene varios archivos que se crean cada vez que se crea una nueva página. Básicamente, la página principal hace Response.Write () varias veces para representar el HTML (runat = "server"? De ninguna manera). Después de eso, puede haber mucha lógica en el lado del cliente (VBScript), y finalmente la página se envía a sí misma (a menudo almacena muchas cosas en campos ocultos) donde luego se publica en una página de procesamiento que puede hacer cosas como guardar el datos a la base de datos.
  • Las especificaciones que obtenemos son ridículas. Muchas veces requieren cosas como "rellenar automáticamente el campo X con el campo Y o el campo Z" sin indicación de cuándo elegir el campo Y o el campo Z.

Estoy seguro de que parte de esto es el resultado de no estar empleado en una compañía de software, pero siento que las personas que escriben software deberían al menos preocuparse por la calidad de su código. Ni siquiera puedo imaginar que si mencionara algo, cualquier cosa se haría pronto, ya que se acerca un gran plazo, pero seguimos escribiendo códigos incorrectos y usando malas prácticas.

¿Que puedo hacer? ¿Cómo puedo plantear estos problemas? El 75% de mi equipo está de acuerdo conmigo y ha mencionado estos problemas en el pasado, pero nada cambia.

sdm350
fuente
27
acostumbrarse a él. El 90% del código escrito es código de lectura.
77
nada cambia por la misma razón que es un código incorrecto en primer lugar. Dejaron de pagar booku $$$$ para que cualquiera le importara hace mucho tiempo.
11
Esto está fuera de tema. Pero la respuesta corta es: economía. ¿Cuántos meses de desarrollador costará ordenar la base de código y cuántos meses de desarrollador ahorrará una base de código ordenada?
Oliver Charlesworth
89
La mejor manera es en una entrevista de salida.
kylben
32
No importa cómo le hables a los ciegos sobre el color. No te entenderán.
ThomasX

Respuestas:

68

Asegúrate de no estar exagerando. Usted es fresco, probablemente no ha trabajado en muchos otros lugares (y ¿no?), Por lo que no está preparado para el mundo del "código de la vida real". El código de la vida real es algo horrible. Es como su código de escuela agradable y su código de proyecto personal obsesivamente ajustado tuvo relaciones sexuales en el sótano de un reactor nuclear y el bebé creció en una alcantarilla de desechos tóxicos; Es un mutante horrible.

Pero suponiendo que tenga razón, y que el código es tan malo como usted dice (es decir, peor que el código típicamente malo), entonces tiene razón en preocuparse. Hable con su equipo y determine si todos los demás están de acuerdo. Se necesitará trabajo para mejorar la situación: si el resto del equipo reconoce el problema pero no le importa, está perdiendo el tiempo.

Siendo junior, probablemente no estés en condiciones de liderar. Si va a la administración usted mismo, como nuevo empleado que también es un junior, su opinión probablemente será ignorada. Consiga a su desarrollador principal o uno de los más importantes involucrados. Nuevamente, si ninguna de las personas mayores está interesada, entonces está perdiendo el tiempo.

Suponiendo que pueda interesar a algunas personas técnicas de alto nivel, trabajaría para identificar las áreas problemáticas y las posibles soluciones. Por ejemplo, si "todo es básicamente una función gigante", entonces la próxima vez que trabaje en esa 'función gigante' tal vez debería refactorizar un poco. Una vez más, necesitas poner a todos de pie. Si elimina pequeños pedazos de su problema y mejora pieza por pieza, eventualmente se volverán mucho menos problemáticos. Cada vez que toque un fragmento de código, considere si se puede mejorar.

No se va a sentar con la gerencia y decir 'todo está mal y necesita ser reescrito'. Eso no tiene sentido para ellos: cuesta mucho y es potencialmente muy arriesgado. En su lugar, deben ser conscientes de que hay problemas y de que hay un plan para mejorar lentamente a medida que se realizan cambios. Deben ser educados sobre los beneficios del código mantenible. Esto debe provenir de una persona mayor en la que confíen técnica y profesionalmente, no de usted.

Reescribir por completo? Casi siempre es una mala idea.

En última instancia, no hay mucho que puedas hacer porque eres nuevo. Si nadie quiere mejorar las cosas, entonces reúnes tu experiencia y pasas al siguiente lugar.

Kirk Broadhurst
fuente
10
+1 solo para la última línea. Las personas generalmente no están dispuestas a escuchar a un novato, incluso si el novato proporciona su propia experiencia y una perspectiva diferente que todos los demás están demasiado inundados en la cultura corporativa para ver. La gente también está ciega para escuchar la verdad (es decir, "Todo es malo porque las personas que lo organizaron eran idiotas que no sabían qué estaban haciendo") y prefieren bajar al barco que admitir que las cosas son malas y necesitan ser arreglado A veces es alucinante cómo los dueños de negocios se arriesgan a perder todo en lugar de tomarse el tiempo para arreglar cosas malas.
Wayne Molina
2
Para continuar con ese último punto, he visto muchos lugares donde la gerencia preferiría correr el riesgo de cerrar el negocio cuando el sistema de mala calidad colapsa sobre sí mismo en lugar de encargarse y abordar los problemas, incluso si esos problemas significan esperar en nuevas características.
Wayne Molina
55
Desafortunadamente, usar una especie de enfoque de 'guerra de guerrillas' para re-factorizar a veces puede conducir a que te dispares en el pie. A menos que el sistema tenga un buen conjunto de pruebas de unidad / integración escritas en su contra (que si es malo, lo más probable es que no lo haga) inevitablemente conducirá a la introducción de errores que necesitarán pasar una prueba completa del sistema a través del control de calidad para evitarlo.
aceinthehole
1
@aceinthehole: exactamente correcto. Si las pruebas son caras, la administración no querrá arriesgarse a ningún cambio 'innecesario', aunque sin ellas el sistema se volverá imposible de mantener en el futuro previsible.
Kevin Cline
2
@WayneM, y esos idiotas que no sabían WTF que estaban haciendo al comienzo del proyecto ahora son los gerentes senior. ¡Nunca olvides esa parte!
HLGEM
58

Lea Joel On Software : cosas que nunca debe hacer. Comprenda su razonamiento, luego lea algunos otros artículos sobre software defectuoso y cómo solucionarlo, escritos por gerentes, no por programadores. Armado con esta información, podrá presentar un caso para solucionarlo, en términos que los gerentes entiendan y se preocupen. Sugerencia: Los buenos gerentes no gastan tiempo y dinero basándose únicamente en las opiniones y sentimientos de los programadores sobre lo que se debe hacer.

"Este código es una mierda y necesita ser reescrito" sin duda va a ser devuelto a usted, incluso si es técnicamente correcto.

"Podemos quitarnos meses del cronograma actual del proyecto, costar menos y hacerlo más confiable". llamará su atención (observe la falta de mención de CÓMO piensa hacer esto en su etapa).

Lo que usted diga, asegúrese de estar en lo correcto. Si dices que es malo, tu reescritura tiene que ser muy buena. Si dices que tomará una semana, será mejor que te asegures de que será una semana, y sé bueno. Cualquier defecto en el código reelaborado le costará, personalmente, caro, independientemente de lo que podría haber sucedido si no hubiera realizado la reelaboración. Si alguien ha estado allí antes que usted y ha jodido o sobrevendido una reescritura, ríndase, a los gerentes no les gusta que los engañen y no dejarán que suceda dos veces. Por ese motivo, no lo arruines para los chicos que siguen, solo tienes una oportunidad en esto ...

Encuentre maneras de distribuir el costo durante un período de tiempo o número de proyectos. Los gerentes odian el riesgo, la inversión especulativa y el flujo de caja negativo: trabaje dentro de las tolerancias de sus gerentes con respecto a estos. Comience con una sugerencia pequeña, de bajo riesgo y bajo costo. Una vez que tenga la razón, puede ir por el pez más grande.

Mattnz
fuente
2
divertido ... me votaron por sugerir el sitio de Joel :-)
Robert French
66
@Robert French: su gerente está leyendo sus publicaciones ...
Dave Markle
8
En serio. No es divertido tratar de discutir "¿Puedo tener 6 meses de tiempo de desarrollador para reescribir todo? El resultado final será exactamente el que tenemos hoy, pero probablemente con algunos errores nuevos. Ah, y vamos a utilizar muchos de los mismos desarrolladores que crearon el montón actual de basura para la reescritura porque ahora lo saben mejor ".
JohnFx
3
@ joshin4colours: <quote> Sí, lo sé, es solo una función simple para mostrar una ventana, pero le han crecido pequeños pelos y cosas y nadie sabe por qué. Bueno, te diré por qué: esas son correcciones de errores . ... Cada uno de estos errores tomó semanas de uso en el mundo real antes de ser encontrados. ... Cuando tira el código y comienza desde cero, está tirando todo ese conocimiento. </quote>
Martin York
44
Lo sentimos, pero la experiencia de un año no otorga la credibilidad para hacer cualquiera de estos reclamos a su gerencia.
Jeremy
14

En primer lugar, encontrará cosas heredadas tontas en cualquier lugar donde trabaje como programador, a menos que trabaje desde el inicio y sea usted quien cree el código heredado original tonto. Tienes que poder rodar con estos golpes si planeas tener una carrera en programación.

En segundo lugar, a menudo hay consideraciones de costos para mejorar los sistemas antiguos. Por ejemplo, he visto a más de una compañía que todavía tenía en funcionamiento VB6 de 10 años y aplicaciones ASP clásicas. En algunos casos, esto se debió a que un gran proyecto para mover .NET falló gravemente. En otros, la razón fue "si no está roto, no lo arregles". Pero, en otros, el costo de la mudanza es justificable ya que los problemas causados ​​por el sistema heredado son demasiado grandes para ignorarlos.

En situaciones donde ha habido un gran fracaso en el pasado, es casi imposible lograr un cambio. En ese caso, pule tu currículum y comienza a buscar un nuevo trabajo. Si no está roto, es probable que no tenga motivos para quejarse del código en sí, pero que no estaba en una carrera profesional satisfactoria y creciente. Si está roto y parece que está en su caso, es cuando tiene la oportunidad de cambiar.

El mejor enfoque que he visto es no morder demasiado, sino comenzar con cambios incrementales que tendrán el impacto más positivo. Según su descripción, una mejor gestión de las solicitudes de cambio sería un lugar para comenzar. Una vez que esté bajo control, puede comenzar a buscar la creación de un marco de servicio u otras mejoras incrementales de diseño / código.

El peor enfoque que he visto es tratar de dar un gran salto directamente desde un sistema heredado al último y mejor, por ejemplo, saltar de un sistema VB6 / Classic ASP / COM + a un sistema MVC / Entity Framework.

jfrankcarr
fuente
3
"En primer lugar, encontrará cosas heredadas tontas en cualquier lugar donde trabaje como programador, a menos que trabaje en una empresa nueva y sea usted quien cree el código heredado original tonto". Fui el primer programador en mi inicio. Ocho más tarde, a menudo me encuentro diciendo '¿quién escribió este código tonto?', Solo para verificar y descubrir que soy la parte culpable.
Jim In Texas
La velocidad de iteración supera la calidad de la iteración. En otras palabras, haga muchos cambios pequeños, a menudo, y eventualmente llegará a donde quiere estar.
jasonk
11

"Hola, jefe, después de Big Project, a mí y al equipo nos gustaría algo de tiempo, idealmente X meses, para organizar nuestro código. Las cosas que deberían hacerse en minutos llevan horas porque todo está muy desorganizado. Si no es posible hacerlo justo después de Big Project, nos gustaría planificar un calendario realista ".

(parcialmente parafraseado del comentario de Azkar sobre la pregunta)

Emilio M Bumachar
fuente
10
En teoría, esto sería genial. En la práctica, la respuesta sería algo similar a "No, el CEO quiere que se Another Big Projecthaga en X meses". o "Tenemos nuevas funciones que deben hacerse de inmediato, no tenemos tiempo para arreglar lo que ya funciona"
Wayne Molina
2
Eso rara vez (si alguna vez) funciona. Especialmente si tiene un gerente que ha estado presente por un tiempo, porque él / ella habrá escuchado esta línea antes solo para verla explotar.
taylonr
1
Esto solo me hace reír. Nunca vas a obtener una reescritura completa en el calendario. Lo que potencialmente podría hacer es tener una tarea más pequeña en cada próximo proyecto para mejorar algún subsistema para que eventualmente (en el transcurso de un par de años) se cumpla con las especificaciones.
Martin York
En mi experiencia, este enfoque a menudo será rechazado. Un enfoque alternativo es hacer múltiples estimaciones de Big Project por 1.5 y pasar 1/3 del tiempo limpiando el código en el camino.
JBRWilkinson
2
Una respuesta muy frecuente es "¿Quién financiará su cheque de pago haciendo esto?" Si no tiene un patrocinio directo de la tarea, necesitará que la compañía haga la inversión a largo plazo. ¿O trabajarás gratis mientras haces esto?
7

Empieza a leer Joel on Software (Joel Spolsky / Fundador de Stack Exchange) ...

Lo PRIMERO que haría es realizar una Prueba de Joel .

Esto le permitirá presentarlo como "Mientras buscaba formas de mejorar como desarrollador ... Me topé con esta prueba de 12 preguntas sobre entornos de desarrollo, así que por diversión les respondí sobre dónde trabajo". ... Esto a su vez lo convierte en un tercero que describe qué tiene de malo su código y no usted personalmente.

A medida que lea más sobre Prácticas pragmáticas , mejorará e implementará cosas como rojo / verde / refactor y esto a su vez le permitirá limpiar la base del código para que sea mantenible. (a través del tiempo)

¡Espero que ayude! Bienvenido a la programación (el código de ayer suele ser una mierda) ;-)

Robert French
fuente
44
No creo que esto aborde cómo debe abordar la gestión.
Pubby
3
Parece que Azbar conoce el problema y sabe cómo solucionarlo, pero no sabe cómo hacer rodar la pelota para que se pueda solucionar.
Pubby
1
Sí ... estaba sugiriendo usar el punto de vista de un tercero al presentarlo. No pensé que estaba preguntando específicamente cómo hablar con su jefe.
Robert French el
44
Esta respuesta apenas merece tantos votos negativos. La primera oración merece +10. El problema con acercarse a la administración es comprender qué es importante para ellos, Joel, y esta respuesta aborda este tipo de problema observando las razones por las cuales, y por qué no, desde una perspectiva comercial, el código debe reescribirse.
mattnz
1
@Robert French +1 para una buena respuesta. Es importante que Azkar comprenda tanto el negocio como la tecnología. Sugerir que se forme su propia opinión a partir de las observaciones de una tercera persona altamente calificada ayudará en el desarrollo de Azkar como desarrollador, y no solo como codificador. Además, la historia de PB&J es divertida.
bakoyaro
7

Consejo rápido: si propone una gestión con una lista de razones por las que debe codificar de manera diferente, incluya como argumento "Mejora de la moral / condiciones de trabajo para los programadores".

Deje en claro que el equipo técnico escribirá más contenido y mantendrá código limpio que este desastre actual, y esto ciertamente puede mejorar su actitud hacia el trabajo. Podría ser un argumento útil.

John Q
fuente
Definitivamente es una buena idea y también muy cierto
sdm350
5
  • ¿La gerencia realmente dicta el diseño? Si tienes a la mayoría del equipo detrás de ti, ¿qué te detiene? Sea proactivo y decida en grupo. Elabora un plan para implementarlo de forma incremental . Entonces hacerlo.
  • ¿La administración dicta las herramientas de desarrollo que utiliza? A menos que haya un costo de tiempo para cambiar una herramienta de administración, generalmente no le importa. Sea proactivo y decida en grupo qué herramientas de desarrollo desea utilizar. Si necesita comprar de la administración, muéstreles un plan de migración y un análisis de costo-beneficio. Entonces hacerlo.
  • ¿La administración dicta los idiomas que usa? Sea proactivo y decida como grupo qué usar en lugar de VBScript. Elabora un plan para implementarlo gradualmente y hazlo. Si necesita una compra, muéstreles el plan. Entonces hacerlo.
  • No tengo nada para las especificaciones. Eso suele depender en gran medida de las personas y los procesos en su trabajo. Identificar lo que está roto y los cambios mínimos necesarios para arreglar el proceso requiere tiempo, análisis y comprensión de cómo funcionan las cosas actualmente y cómo deberían funcionar. Si sabe que puede llegar a un plan e intentar convencer a la gerencia.

Obtendrá más cambios y respeto si propone formas de cambio que no impliquen grandes cantidades de tiempo dedicado sin valor comercial (o suave) para demostrarlo.

dietbuddha
fuente
No / Sí / Sí La elección del lenguaje y las herramientas rara vez se realiza por razones técnicas. (ver: parashift.com/c++-faq-lite/big-picture.html#faq-6.5 ) Son las herramientas que la compañía ha tenido desde el principio. Es poco probable que vuelva a utilizar una empresa o un equipo debido a la caída de la productividad.
Martin York
1
+1 para planificar e implementar de forma incremental. reescribir todo es solo pedir un fracaso. Pequeñas victorias con el tiempo crean confianza. En cuanto a las especificaciones ... la mayoría de las especificaciones que obtienes como programador no tendrán nuestro trabajo para refinarlas. De vez en cuando te mima alguien que escribe buenas especificaciones. Por lo general, se mueven / promueven / encuentran un trabajo mejor lejos o rápidamente en lo que respecta al programador.
SoylentGray
@Loki Astari: En la mayoría de las empresas en las que he estado, he impulsado cambios que van desde el sistema de control de revisión, el marco, el proceso de desarrollo e incluso el lenguaje. Todo lo que necesita es un plan razonable que describa cuál será el costo y los beneficios del cambio. Solo porque rara vez se hace, no significa que no se pueda hacer.
dietbuddha
4

Hablando por experiencia: no es fácil. Es casi imposible A la gerencia no le importa que el código apesta y es más que probable que sean completamente ignorantes y / o no tengan idea de los problemas que se enfrentan, o lo habrían solucionado hace mucho tiempo y no se quedaría atrapado con él hoy. Lo mejor que puede hacer es hacer una lista de las razones por las que el código apesta, y luego el razonamiento detrás de por qué apesta para demostrar el valor comercial real al refactorizarlo / reescribirlo.

Un ejemplo podría ser para "El código no es mantenible":

El código actual no se puede mantener debido a X , Y y Z (enumere los motivos por los que no se puede mantener ). Esto hace que las solicitudes de cambio y las nuevas características sean muy difíciles de hacer, porque X , Y , Z (razones por las que hacer cambios es difícil). Debido a que los cambios son difíciles, el equipo de desarrollo no puede responder fácilmente a las correcciones de errores y mejoras.

Su única esperanza es que su jefe y la alta gerencia no sean demasiado estúpidos para comprender qué ramificaciones tiene el código, y estén dispuestos a dejar de presentar nuevas solicitudes de características para abordar los problemas, de lo contrario sus esfuerzos serán en vano . Hablando de la experiencia pasada, es muy probable que no vean nada malo en el código, y / o sus compañeros de trabajo sean demasiado despiadados para llevar sus preocupaciones a la gerencia.

Buena suerte. Lo necesitarás.

Wayne Molina
fuente
2
De acuerdo y "no mantenible" también funciona solo hasta cierto punto. Para muchos gerentes (especialmente sin antecedentes técnicos), el código de trabajo es igual al código que se puede mantener. Si afirma lo contrario, incluso podría ser visto como incompetente a sus ojos.
MaR
3

"Empecé recién salido de la universidad" - debería responder a tu pregunta.

La gerencia probablemente sabe que el código es subóptimo. La mayoría del código es a menos que haya contratado a Ray Gosling, Guido Van Rossum u otra persona realmente buena y costosa para escribirlo.

La gerencia también sabe que funciona utilizando cualquier definición de "obras" que se aplique a su empresa (no se bloquea, vende, entrega los informes o lo que sea).

Quieren que mantenga el código "funcionando" a un costo mínimo. No quieren una propuesta de proyecto costoso para volver a escribir todo.

James Anderson
fuente
Su primera línea está totalmente sesgada contra juniors. Por un lado, no conoces SU experiencia, así que no puedes concluir una respuesta a su pregunta. ¡Y generalizar como tal es ser extremadamente parcial contra los juniors! Llevo unos 20 años en esto y puedo garantizar que he visto más "novatos" más informados que "ignorantes mayores".
Jeach
No está exactamente predispuesto contra los juniors, pero, ¿tal vez debería reconocer la experiencia y el conocimiento superior de sus colegas que han estado trabajando durante algún tiempo? No todos pueden ser incompetentes viejos Wallies.
James Anderson el
2

El caso comercial es casi imposible porque su entregable es un software que funciona (lo que ya tienen) y no un código elegante.

Agregue el hecho de que en el software hay un gran costo de oportunidad de llegar al mercado con características primero. Si realmente lo piensa, no se garantiza la recuperación a largo plazo de la inversión de tiempo.

Dicho esto, sigue siendo un buen plan refactorizar y arreglar las cosas pequeñas (como obtener un buen VSS) en el camino en bocados manejables. En última instancia, este es un problema técnico, no administrativo. Simplemente haga lo que debe hacerse mientras sigue cumpliendo lo que promete y estará bien. La administración probablemente no estará interesada en los detalles esenciales de la calidad del código, incluso si presenta un argumento sólido.

JohnFx
fuente
2

Simplemente vete tan pronto como puedas (tal vez no te vayas demasiado pronto ya que no quieres parecer una tolva de trabajo). El hecho de que codifiquen es un desastre y la gente se queda allí significa que probablemente estés trabajando con desarrolladores pobres. Cualquier desarrollador decente que se preocupe por su trabajo no se quedaría mucho tiempo trabajando en esa basura.

La posibilidad de que se produzca una reescritura es bastante baja, a menos que pueda demostrar claramente que valdrá la pena la inversión.

Alistair
fuente
Este es, al final, el único curso de acción real. Lo dije antes, lo diré nuevamente: los desarrolladores inteligentes trabajan para compañías inteligentes que entienden por qué es importante SIEMPRE escribir un buen código y dedicar el tiempo necesario para garantizar un buen código. Los desarrolladores pésimos trabajan para compañías pésimas donde todos están demasiado enfocados en "hacer sus tareas" para preocuparse de que solo estén agregando más lodo a la pila e incluso vean que el código de refactorización que no está directamente relacionado con su tarea actual está "desperdiciando" hora". No vale la pena trabajar en estos lugares si te consideras inteligente.
Wayne Molina
1

A la gerencia no le importa el código. Les importa tener un producto para vender.

Si el sistema heredado es muy, muy malo y está agregando una cantidad ridícula de gastos generales para la mayoría del equipo (digo mayoría porque siempre hay un tipo que codificó grandes partes o todo y lo sabe como la parte posterior de su mano) luego, acérquese a ellos y diga que le está costando dinero al negocio en tiempo de desarrollo, y tendrá un efecto positivo con la satisfacción del cliente.

Pero una vez más, todavía no les importa el código, se preocupan por un producto, por lo que si bien esa respuesta puede hacer que digan "Sí, hagámoslo", también podría ordenar el código sin obtener el permiso de un gerente. No se exceda, asegúrese de hablar primero con el equipo, a nadie le gusta venir e intentar usar esa función que le tomó 3 meses para escribir y ahora parece no funcionar porque ha sido pirateada.

Nicholas Smith
fuente
Como insinúa ... Tiene que haber algo que pueda hacer para mejorar el código. Si se trata de una función gigante, hay cosas que puede hacer al respecto. El hecho de que incluso se queja de Source Safe es algo gracioso. Source Safe no tiene nada de malo, se usó durante años, podría tener algunas cosas que no tiene sentido en el mundo de hoy, pero eso es una retrospectiva.
Ramhound
Creo que SourceSafe en sí no es el problema, continúa usando SourceSafe cuando hay mejores herramientas gratuitas disponibles solo grita "Somos ignorantes de todo lo que está fuera de la caja" y "La mediocridad es la regla del día ya que nos quedaremos con un inferior producto en lugar de aprender uno superior ". El problema es la actitud que tienen la mayoría de los usuarios de SourceSafe.
Wayne Molina
"ordenar el código sin permiso" - suena como arreglar algo que no está roto.
James Anderson el
1
Mi sala de estar no es un peligro para la salud, pero aún así me aseguro de limpiarla regularmente. No se trata tanto de arreglar algo que no está roto, sino de hacer una tarea necesaria.
Nicholas Smith el
0

Acérquese a la administración de tal manera que demuestre que comprende los impactos presupuestarios de realizar grandes cambios en el código y los impactos presupuestarios de NO realizar los cambios. Me gustó la redacción de Emilio.

Es importante tener en cuenta que ese código "antiguo" siempre será horrible. Con esto quiero decir, todos crecemos como desarrolladores constantemente. Escribimos un buen código, luego aprendemos a escribir un mejor código más tarde y el código "bueno" anterior parece terrible. Demasiados desarrolladores quedan atrapados constantemente tratando de mejorarlo y desperdiciar más dinero a largo plazo. Es un acto de equilibrio. Dicho esto, siempre es genial si puedes mejorarlo a medida que avanzas. Cuando vaya a modificar esa función gigante, ¡divídala! Eventualmente llegarás a algún lado.

lampej
fuente
0

No lo hagas

Reescribir un proyecto grande desde cero es un gran error la mayoría de las veces de todos modos.

Cesar Canassa
fuente
Grande es relativo.
Luca
1
Mi definición es: si no puede reescribirlo usted mismo en 5 días, entonces es grande.
Cesar Canassa
-1

Nunca pensé que es fácil decirles a los gerentes, especialmente a los gerentes de proyecto, sobre códigos incorrectos y refactorización. Primero, deben confiar en ti, incluso si eres un hombre mayor todavía necesitas tiempo para ser confiable. En segundo lugar, simplemente no entienden qué tan grave es el problema. Si hoy es el último día para lanzar una nueva compilación, y la compilación falla. Saben lo grave que es, pero nunca saben que la compilación simplemente falló debido a muchos problemas, como código incorrecto, pruebas inadecuadas, etc.

He realizado tareas de configuración e implementación en un proyecto web. A menudo lleva mucho tiempo solucionar problemas inesperados cada vez que implemento una nueva compilación. La mayoría de los problemas fueron la seguridad y la integración (entre varias aplicaciones web / Windows). Nuestro código apesta, el código de otros apesta, son completamente códigos de espagueti.

Estábamos planeando una nueva versión y pedí encarecidamente que se refactorizara, solo agregue un registro detallado al código de inicio de sesión / autenticación donde a menudo ocurren errores. Los gerentes estuvieron de acuerdo, pero luego se incluyó en una lista agradable y no sé si se hará ya que ya teníamos una gran lista de características y un marco de tiempo ajustado.

Tien Do
fuente
-3

Hay dos tipos de gerentes: los que pretenden entender lo que haces y los que no. Los que pretenden comprender el software serán hostiles para usted. Los que no, simplemente están molestos por ti.

En cualquier caso, los gerentes son todos mentirosos, por lo que tienen una fuerte disposición a asumir que todos los demás lo son.

Mi punto es que si dices que el software está desactualizado, lo tomarán como una excusa. No les importa

Joe
fuente
+1 en "los gerentes son todos mentirosos, por lo que tienen una fuerte disposición a asumir que todos los demás lo son"
ZJR
-1 en el mismo; tanto falso como inútil
Jaap
@Jaap hay numerosos estudios que correlacionan el poder y la clase social con la deshonestidad. ¿Eso significa que retraerás tu -1? Ejemplos: msnbc.msn.com/id/35836844 blogs.discovermagazine.com/notrocketscience/2010/04/27/… news.sciencemag.org/sciencenow/2012/02/shame-on-the-rich.html
Joe
El segundo estudio reivindica especialmente mi punto exacto.
Joe
1
@ Joe: sus enlaces no (comienzan a) probar su afirmación de que "los gerentes son todos mentirosos".
Jaap