He estado allí, hecho eso! Sí, hecho eso como desarrollador! Y cada vez, las razones eran evidentes, pero la persona que solicitaba que se diseñara un diseño era demasiado ciega para ver estos defectos.
Hace aproximadamente una década, un colega mío había diseñado una solución de seguridad que debería evitar que los usuarios accedan a la aplicación sin nombre de usuario / contraseña. Hacer tales diseños tiende a ser muy complejo porque debes considerar todos los vectores de ataque y lo que él había diseñado estaba lleno de agujeros de seguridad. ¡Y este colega era un especialista certificado! Fui a mi gerente y él todavía me exigió que lo construyera. Así que subí un paso más y expliqué que no podía ser considerado responsable de todos los agujeros de seguridad en el diseño y que básicamente estaría perdiendo el tiempo si lo construía. Además, dejé muy claro que no lo construiría y estaba dispuesto a aceptar las consecuencias.
Entonces, otro desarrollador echó un vistazo rápido y estuvo de acuerdo conmigo en que el diseño tenía serias fallas. Hizo que el jefe cuestionara las habilidades de mi colega, por lo que quería saber más sobre sus certificaciones. Resultó que eran falsos y fue despedido de inmediato, y su mal diseño fue abandonado. Luego, fue mi turno de hacer un mejor trabajo y lo hice.
Me he negado a codificar por razones similares para un empleador diferente. O bien, todo mi equipo se negó a codificar. Estábamos trabajando en dos equipos y mi equipo estaba trabajando en una aplicación de escritorio mientras que el otro estaba creando un servicio web al que necesitábamos llamar. Este servicio web debía ser seguro ya que tenía acceso a los datos financieros de los clientes. Desafortunadamente, ese segundo equipo había hecho un trabajo horrible al hacer una buena interfaz que pudiéramos usar y se había olvidado de la seguridad, así que les dijimos que lo arreglaran. Su solución para solucionarlo fue bastante mala y ninguno de los métodos estaba realmente protegido, por lo que aún permitiría a cualquiera acceder a los datos confidenciales. Sin embargo, afirmaron que habían terminado y necesitaban trabajar en algún otro proyecto, por lo que el Jefe nos dijo que lo arreglemos de nuestro lado.
- ¿Es interesante el diseño gráfico?
- ¿Cómo es ser diseñador gráfico? Quiero ser uno
- Si Apple diseñara un avión de combate, ¿cómo sería?
- ¿Qué importancia tiene su formación académica en el campo del diseño gráfico?
- ¿Qué tienen en común las mejores agencias de diseño móvil?
Pero no puede solucionar los agujeros de seguridad en el servidor solo desde el lado del cliente. Tenían que mejorarlo en el lado del servidor. Por lo tanto, ninguno de nosotros quería ninguna responsabilidad por esta mala seguridad y, por lo tanto, se negó a hacer el código relacionado. Esto fue dos semanas antes de la fecha límite. Los jefes no estaban muy contentos y después de varias discusiones y de probar cómo esos agujeros de seguridad podrían ser utilizados por cualquier niño script para recopilar toda esta información personal, todavía querían que intentáramos algo, hasta que también les recordamos que hacer tal El sistema inseguro con agujeros de seguridad completos que daban acceso a datos financieros privados podría resultar en una multa considerable y definitivamente molestaría a muchos clientes. Eso causó una mejor impresión, por lo que el plazo se canceló y el otro equipo se vio obligado a arreglar su trabajo. Lo cual no les gustó. Y nuestro equipo fue designado como su observador para asegurarse de que cualquier cosa que hicieran calificara como lo suficientemente segura.
Para otro empleador tuve que negarme a codificar simplemente porque lo que querían era imposible. Estábamos trabajando en un sitio ASPnet y necesitaba recuperar datos de algún servicio web alojado por un tercero. Y sí, afirmaron que era un verdadero servicio web y proporcionaron muchos ejemplos sobre cómo usarlo. Desafortunadamente, su servicio fue escrito en PHP y los ejemplos fueron solo PHP. No hay WSDL ni ninguna biblioteca .NET, por lo que fue imposible simplemente crear una solución C # que acceda a este servicio. Por lo tanto, mi empleador tendría que hablar con este tercero para encontrar una solución, pero se negaron a apoyarnos para hacer una solución C #. Tendríamos que usar PHP en su lugar.
Aquí, finalmente terminé escribiendo código, pero eso fue porque mi jefe me dio carta blanca para encontrar cualquier solución creativa que pudiera encontrar. Así lo hice, al crear una herramienta simple que analizaría los ejemplos de PHP, recopilaría todos los métodos de servicio y los convertiría a métodos y clases de C #. Con algo de lógica adicional para llamar al servicio usando comunicaciones TCP / IP y algunos encabezados ficticios, logré construir algo que pudiera hacer realidad todos los datos. Y cada vez que el servicio cambie, podríamos recrear toda la biblioteca nuevamente ejecutando la herramienta de conversión. Definitivamente no es una solución bonita, pero afortunadamente, gracias al uso de Expresiones regulares, logré construirlo razonablemente rápido.
Asi que…
Lo que digo es que es probable que esos desarrolladores tengan una muy buena razón para no querer construir su diseño. Tal vez estás preguntando algo imposible. Tal vez no tienen las habilidades adecuadas. Tal vez su diseño tiene serios defectos de diseño. Para averiguarlo, tendrás que hablar con esos desarrolladores.