¿Demuestra un código malo al cliente?

Los no tecnólogos no son idiotas (en su mayor parte). Pueden entender un argumento técnico si lo mantienen lo suficientemente alto. Elija una tarea que pensó que debería ser simple, y explíqueles por qué no lo es.

  

Esperaba que este cambio fuera una palabra en un archivo. Lo más probable   El lugar para cambiarlo parecía estar aquí, pero cuando lo cambié allí,   Solo funcionó en un lugar, y rompió estos 7 otros lugares. Cuando yo   uno fijo, se rompió dos lugares más, causando un efecto dominó, por lo que un   El cambio que pensé que debería haber tomado 10 minutos terminó tomando 2 horas.   Eso es solo un ejemplo. Hay muchas más tareas inesperadas de 2 horas allí.

La estructura del código, el estilo, la deuda técnica son una cosa que, al menos inicialmente, hasta que el cliente confíe en usted, tendrá que convivir.

Las vulnerabilidades de seguridad son otra cuestión.

Personalmente, haría una estimación basada en el trabajo requerido utilizando la estructura y el estilo existentes y dejando en claro que hay problemas importantes con el código base. Plantearía las implicaciones de seguridad por separado: haga una demostración de un hackeo en la base de datos para llevar el punto a casa durante una reunión.

Me alegré mucho al hacer esto con un cliente anterior con un sistema de tarjetas de regalo de fidelidad cuando puse £ 5000 en "mi" tarjeta y le pedí que verificara la tarjeta en su caja.

Algunas sugerencias excelentes aquí sobre cómo transmitir y comunicar esto al cliente. Esperemos que paguen por ti.

¡Bandera roja importante aquí!

Si el cliente le pide que no realice ningún cambio que no sea lo que acordó (HTML y CSS), aprobaría este proyecto y retiraría mi oferta.

Incluso con una descripción escrita y bien comunicada de todas las fallas y problemas de seguridad, la responsabilidad potencial es demasiado grande para que me sienta cómodo. Incluso si el cliente nunca tomó ninguna acción legal o exigió arreglos después de un hackeo o incumplimiento; ¡Tu nombre y tu reputación aún están vinculados al trabajo!

Es posible que pierdas mucho más de lo que puedes ganar.

Explique y posiblemente demuestre la falla
Cuando es tu palabra contra la suya, todo lo que dices podría ser simplemente aire caliente en lo que a ellos respecta. Una vez que les muestra cómo se puede abusar de su aplicación a través de la inyección de SQL, de repente, usted es una persona de confianza. Vas a necesitar credibilidad para renegociar. Y esto es suficiente como un cambio de juego para dárselo.

Sea caritativo con respecto a su predecesor
Eso no significa fingir que los errores no están ahí, pero si te encuentras condescendiente, pierdes credibilidad. No digas una palabra sobre el programador, excepto quizás para darle el beneficio de la duda. Enfócate en el código, no en el codificador. Hacerles sentir que eres el "buen chico" te dará mucho más margen de maniobra en las negociaciones. Y los "buenos chicos" nunca dicen cosas malas. Al explicar los errores de seguridad existentes (como las vulnerabilidades de inyección de SQL) al cliente, prefiero decir algo como esto:

  

La seguridad de la aplicación web es un campo en rápida evolución. Muchas de las herramientas y técnicas de desarrollo que las personas aprenden, incluso hoy en día, evolucionaron antes de que la mayoría de estas hazañas fueran bien comprendidas. Para mantenerse a la vanguardia de los desarrollos de seguridad, debe seguir el campo muy de cerca y, en ocasiones, incluso cambiar todo su estilo de desarrollo. La mayoría de los programadores no hacen esto.

Ahí vamos. Ni una palabra de mal hablado sobre el desarrollador; Él es simplemente "la mayoría de los programadores", lo que significa que está en muy buena compañía. Y ahora has demostrado que no eres "la mayoría de los programadores", lo que te da un poco más de credibilidad y quizás una razón para que te paguen más dinero.

Negociar un nuevo acuerdo
Una vez que el cliente entienda que su aplicación está abierta a ser abusada por el público, querrá que se arregle. Probablemente usted sea la persona a quien le pedirá que lo arregle. Puede o no querer ese trabajo, así que piénselo bien antes de hablar con ellos.

Por lo menos, quieres más tiempo para terminar el trabajo que ya te dieron. Los has puesto lo suficientemente fuera de la guardia con la vulnerabilidad que probablemente no te mantendrán en tu estimación original. Pero asegúrate de que el cliente sepa lo que eres y no lo arreglarás como parte de este acuerdo.

Normalmente, el desarrollador (usted) preferiría rehacer todo desde cero. Y en casos como este, incluso podría ser una opción. Pero incluso así, el cliente va a querer algo que pueda mantener su negocio funcionando hasta que se construya la nueva aplicación. Esto significa que aunque estés empezando de nuevo, es probable que todavía tengas que actualizar un poco la aplicación anterior.

Comencé esto como un comentario, porque al principio pensé que era algo aparte, pero probablemente no lo sea.

Debería documentar completamente todo lo que usted cree que debería ser rediseñado, y por qué (qué sucede si no realiza el cambio), y una estimación sobre cómo solucionar el problema. Sería particularmente meticuloso con cualquier cosa que perciban como un riesgo de seguridad.

Haría esto antes de tocar el código cualquiera y me aseguraré de que su cliente tenga una copia de este informe, preferiblemente con algún tipo de marca de tiempo. Puede tomar algo de tiempo, pero también lo cubrirá si uno de estos riesgos de seguridad llega a buen término. Aún mejor si puedes conseguir algo firmado que diga que recibieron el documento.

Claro, puede apuntar a la fuente de control del código original que heredó si alguna vez sucede, pero será mucho más fácil señalar este documento y decir, de una manera más profesional, "¿Ven? Ya se lo dije. . "

Este documento puede ser el punto de inicio de futuras discusiones, e incluso puede ser utilizado por su cliente para obtener las "personas adecuadas" para otorgar el permiso para realizar algunos o todos los cambios.

Dicho esto, una vez que el cliente comprenda los riesgos, sonría y sopórtalo si le dicen que haga el trabajo de todos modos o se marcha.

Recuerde que el cliente le pedirá ayuda para mantener su aplicación. Es su trabajo como profesional señalar cualquier problema que encuentre con su aplicación. Es probable que el cliente no tenga idea de que estos problemas existen y que se les debe informar. Explique estos problemas de manera que puedan entenderlos y déjelos decidir cómo quieren proceder.

Use ejemplos del mundo real para ilustrar estos problemas, como la avería de un automóvil o una lavadora que necesite reparación. Señalar es usar ejemplos con los que ya están familiarizados. Para explicar la inyección de SQL, simplemente demostraría qué es eso y por qué es un problema.

Al final, desea transmitir que le preocupa el éxito de la aplicación en la que se le pide que trabaje.

Me gusta usar analogías con las que el cliente puede relacionarse. La cantidad de trabajo que puse por adelantado para ganar el trabajo dependería de la cantidad de dinero que el cliente tenía la intención de gastar ($ 100 es muy diferente de $ 20,000). Note que dije "con la intención". Su estimación personal del valor involucrado no significa mucho si no obtiene lo que está pidiendo.

En su situación, nuevamente dependiendo del dinero, podría dibujar una caja con una línea que sale de cada lado y decirle al cliente: "Así es como visualiza el software ahora. Los datos van en un extremo y salen del Otro, todo luce bonito y limpio y simple ". "Esto es lo que crees que parece el software en el interior" y luego dibuja una tercera línea que conecta las dos líneas dentro de la caja.

Luego dibujaría otra caja como la primera con las líneas de entrada y salida en el exterior, excepto que esta vez diría "Esto es lo que realmente parece el software dentro de la caja en este momento". y luego, para conectar las dos líneas, esta vez dibujaría un montón de spaghetti al azar, posiblemente con pausas, uniones y garabatos.

Finalmente diría: "Ahora, lo que me estás pidiendo que haga es esto ..." y dibujar una forma simple dentro de la primera caja, tal vez un semicírculo pequeño que toca la línea y luego decir "pero para hacer eso , Tendría que hacer esto ... "y dibujar un tornado con forma de espiral alrededor de la línea y continuar ..." para sortear todo esto ... "y señalar los espaguetis en el otra caja.

Creo que eso llevaría el punto a casa en unos 2 minutos. Si ellos insisten en que lo hagas de todos modos, entonces documéntalo como otros lo mencionaron anteriormente.

¿Cómo puedo explicarle a mi cliente qué tan malo es este código?

Tal vez pueda usar una analogía como la plomería en una casa que con el tiempo, después de arreglos y remodelaciones, se vuelve tan inconstante y acoplado que al arreglar una cosa, afecta y posiblemente rompe otra cosa que luego necesita ser reparada y no hay manera de hacerlo. Usted debe conocer todos los lugares donde ocurrirá esto.

Es mi palabra en contra del consultor anterior, entonces, ¿cómo puedo dar ejemplos simples y concretos que un cliente no técnico entendería?

Tienes razón, es una palabra en contra de cualquier aspecto visual que el consultor anterior haya creado en sus cabezas. Mi sugerencia es hacer justo lo que está pidiendo, dar ejemplos simples y concretos. Como se trata de un rediseño, muestre cómo se muestra un fragmento HTML definido en el código compilado con el resto de una página HTML y cómo afecta o no al cambio que afecta al resto de la página. Quizás ese mismo código compilado genere el marcado después de aplicar alguna regla "comercial". Muestra la diferencia.

Este es un problema difícil y MUY común. Buena suerte con él.

Sé honesto y directo.

Pero lo más importante es que no acepte un trabajo que no cumpla con sus expectativas. La mayoría de las personas no se dan cuenta de que un contratista puede despedir a un cliente, pueden y deben hacerlo si el trabajo es más problemático de lo que vale.

Aquí hay una analogía que he usado (aunque no garantizo su efectividad): Imagine que su sitio web es una máquina física, como una prensa de impresión mecánica que de alguna manera acepta comentarios.

Probablemente piensan que la máquina tiene un componente que hace X y otro que hace Y. En realidad, son aproximadamente 20 máquinas similares. Algunos de ellos ya no hacen nada, todos intentan realizar funciones que los demás ya hacen y nadie, además del consultor anterior, ha visto algo igual a ellos anteriormente.

  

"Vea este gizmo aquí que analiza las variables de publicación y luego envía   este componente en un agujero de conejo de si-elses? No hay solo uno   de estos, hay uno de estos en cada página (o lo que sea), algunos de   desinfectan la entrada y algunos no (o todos no) y sin   leyendo todo lo que no puedo saber cual ".

Un punto que aún no se ha mencionado realmente es que, en este caso, podría estar sobrepasando lo que su cliente realmente quiere de usted. El exceso de rendimiento es excelente y puede darte mucha satisfacción laboral. Pero si al cliente simplemente no le importa, piensa que el rendimiento actual es "lo suficientemente bueno" y solo quiere algunas actualizaciones menores, puede ser imposible convencerlo de que haga una gran inversión en usted para revisar el código base.

En ese momento, probablemente deba decidir si respaldar los principios y negarse a aceptar un trabajo que lo obligaría a adjuntar su buen nombre a un vergonzoso código o si puede controlar su posición, entrar, obtener el trabajo realizado con un poco de cinta adhesiva y salga con su pago.

Si decide seguir adelante con el trabajo de la cinta adhesiva, asegúrese de documentar, documentar, documentar y ser lo más transparente posible. Lo último que desea es que se le culpe de que algo salga mal en el futuro como resultado de una falla en la aplicación que le advirtió al cliente pero que el cliente decidió que no era lo suficientemente importante como para tratar en ese momento.

En lo que respecta a los riesgos de inyección de SQL, como han dicho otros, debería poder demostrarles los peligros de esa manera que muestre los riesgos sin hacer nada destructivo en la producción. Pero nuevamente, si lo ven y no les importa lo suficiente como para pagarle para que lo arregle, usted ha hecho su diligencia de buena fe en este caso.

Es una salsa noob para ingresar a un proyecto y sugerir una reescritura, realizar un pequeño subconjunto de las modificaciones y usarlas para ilustrar cuánto más simple y barato podría haber sido . Entonces tiene un caso demostrable sobre por qué el aumento en el costo de un desarrollo más limpio conducirá a menores costos de mantenimiento y un desarrollo más rápido a largo plazo, dado un pequeño costo del lado de la fuente.

Nunca olvides que, fundamentalmente, les estás pidiendo que te paguen para hacerte la vida más fácil, en su mente, la única necesidad de encontrar "el tipo" que puede tener las características de X a un costo de Y y aumentar la complejidad de tu proyecto puede elimina la oportunidad para ti. Es un camino difícil cuando lleva un mes en la reescritura y tiene una reunión con el desarrollador original solo para darse cuenta de que la aplicación completa fue escrita en una ventana extremadamente contratada por un desarrollador que entendió completamente todos los compromisos que se hicieron. Si la aplicación se ve horrible, pero funciona externamente bien, como dices, es muy probable que este sea el caso. A menudo, la deuda técnica dentro de una base de código es un producto de las restricciones de recursos en las que se desarrolló el código y si no están formando un equipo y, en cambio, están subcontratando cosas ... probablemente todavía no sean serios con respecto al mantenimiento.

Solo estoy diciendo

Voy a interpretar al defensor del diablo aquí (de forma similar a lo que dice @khrome: "no estás pagando a los clientes para hacer que sea tu vida más fácil"). Incluso me atrevería a afirmar que el caso que presentó es demasiado parcial porque describió el caso de manera general. La mayoría de los consultores que llegan a un nuevo proyecto arrojarán una mala luz sobre el anterior ... No estoy diciendo que eso sea lo que están haciendo aquí, pero hasta que veamos ejemplos, no puedo simplemente tomar su palabra.

Dicho esto, intentaré abordar los problemas punto por punto:

• Inyecciones de SQL . De acuerdo, supongo que el programador estaba usando concatenaciones de cadenas en lugar de consultas parametrizadas y / o procedimientos almacenados. Esto es muy fácil de solucionar, especialmente en ADO.NET ... Personalmente lo mencionaría al cliente, pero no le daría mucha importancia.
• HTML se está generando en la lógica de negocios y sería una pesadilla para resolver . Ok, amigo, este es uno de esos donde me das más detalles. A menos que estés usando MVC, esta es una tendencia a suceder ... pero no es necesariamente algo malo ... es una de esas cosas donde la mayoría de los programadores dirían " goto es malo; nunca lo uses es "pero sabes qué? He usado goto donde tenía sentido. Entonces, ¿está seguro de que no están usando clases de ayuda que comparten el mismo espacio de nombres que la DLL de código de negocio? Una vez más, no es tan difícil de aislar.
• La lógica de negocios se extiende por toda la aplicación, hay mucha duplicación y un código sin salida que no hace nada. ¿Y? El cliente sólo le está pidiendo que cambie HTML / CSS. ¿Por qué te importan estos temas?
• sigue lanzando excepciones que están siendo sofocadas, por lo que el sitio parece funcionar sin problemas . De nuevo, muy vago. Las excepciones son normales en cualquier aplicación, es por eso que tenemos cláusulas try / catch en nuestro código. A menos que crezcan en la interfaz de usuario y arruinen la experiencia del usuario (como mostrar HTTP 500 innecesariamente), tampoco creo que esto sea algo que debería preocuparte ...

En resumen, te aconsejaría que tomes el camino correcto. Si crees que no vale la pena dedicar tu tiempo y quieres reescribirlo a expensas de tu cliente, deja el trabajo. En serio, al final, el cliente paga su tiempo para que todo funcione con la menor cantidad de $$$.

En mis muchos años de experiencia en el campo, siempre digo que los mejores programadores que he encontrado son los que pueden hacer que un sistema sea estable al escribir la menor cantidad de código , no al reescribir todo .

Edit: Ya veo que mi respuesta no es la más popular (ya esperaba esto) pero mantengo mi respuesta. Edité esto para hacerlo menos sarcástico. ;-)

Ciertamente, los ataques de inyección SQL y otras fallas funcionales en la aplicación tuvieron prioridad, pero también puede "demostrar" malas prácticas y calidad de código. Con las herramientas de métricas de código, puede demostrar claramente qué tan malo es el código y mostrarle cuánto se acumulará en el costo de futuros cambios y corrección de errores. No estoy familiarizado con el entorno .net, pero estoy seguro de que hay varios de los que se puede recoger.