Los programadores parecen haber olvidado que el verdadero prop贸sito del software es resolver problemas reales.
Hace 50 a帽os, en 1968, se organiz贸 una
conferencia de trabajo sobre ingenier铆a de software , que se organiz贸 con el apoyo del Comit茅 de Ciencia de la OTAN. En ese momento, la gente comenz贸 a notar que el software se estaba convirtiendo en una parte fundamental de la sociedad. Sin embargo, tambi茅n se volvi贸 demasiado dif铆cil de entender. Despu茅s de esta conferencia, la programaci贸n se ha convertido en una industria. Y comenz贸 a alejarse del control de la gente de negocios.
No importa en qu茅 direcci贸n haya ido la programaci贸n desde entonces, todav铆a existe un problema con la separaci贸n entre el negocio y el desarrollo de software, o "INGENIER脥A", como la conferencia lo llam贸 por primera vez. Si los desarrolladores est谩n demasiado centrados en el desarrollo, pueden perder el objetivo del software que escriben. Es posible que no vean soluciones ocultas que no requieren ning煤n c贸digo.
Aqu铆 hay un ejemplo.
Hubo una startup que cre贸 un dispositivo que permit铆a a una persona abrir la puerta de su casa a trav茅s de Bluetooth. Se utiliz贸 un widget como interfaz visual, que era visible incluso cuando el tel茅fono estaba bloqueado. Ten铆a un solo bot贸n llamado "Abre la puerta".
Cuando el usuario se acerc贸 a su casa, tom贸 el tel茅fono, encontr贸 el widget y luego presion贸 un bot贸n para abrir la puerta.
Alguien lo mir贸 y pregunt贸:
Si usamos Bluetooth y nuestro modelo comercial permite que cualquier persona que tenga un tel茅fono ingrese a la casa, 驴por qu茅 deber铆amos obligar a alguien a tomar el tel茅fono y presionar el bot贸n? Deje la puerta abierta cuando el dispositivo se acerque a 1 metro. Por lo tanto, no tenemos que pagar por el desarrollo y la programaci贸n de la interfaz visual.
Esta historia de Bluetooth es un gran ejemplo de un enfoque limitado: el objetivo era abrir la puerta con un m铆nimo esfuerzo. No tiene sentido desarrollar una interfaz visual si los sensores son inal谩mbricos.
Si sabe qu茅 objetivos quiere alcanzar la empresa y qu茅 es de valor para el usuario, puede combinar este conocimiento con su conocimiento de la tecnolog铆a. Solo entonces tendr谩 suficiente informaci贸n para encontrar las mejores respuestas y concluir que el producto no necesita una interfaz.
Este es un gran ejemplo de c贸mo resolver un problema t茅cnico sin tener que escribir ning煤n c贸digo adicional adem谩s del c贸digo de desbloqueo. Sin embargo, al igual que con
Tech Debt ,
nada deber铆a justificar la escritura de c贸digo de mierda.
No vale la pena escribir todos los c贸digos.
A veces, solucionar un error grave puede no ser una prioridad. Si tiene un intercambio de criptomonedas y el sistema ha realizado el mismo pago dos veces, la intervenci贸n humana puede ser la mejor soluci贸n en t茅rminos de costos y beneficios, si el costo de resolver este problema es alto.
Esta compensaci贸n entre Seriedad y Prioridad me recuerda el modelo que me mostr贸 recientemente mi
colega . Se llama la "Matriz de prioridades", un
modelo bidimensional que se puede utilizar para priorizar errores en funci贸n del n煤mero de usuarios que afectan y la gravedad.
El problema de re-dep贸sito descrito anteriormente cae en la categor铆a de inconvenientes que afectan a un usuario. Por lo tanto, prioridad 3.
No vale la pena corregir todos los errores.
Esto es algo muy com煤n cuando los desarrolladores intentan escribir un script para todo. Sin embargo, no vale la pena automatizar algunas tareas repetitivas. No necesita perder tiempo programando scripts si va a ocultar el conocimiento necesario sobre c贸mo funciona el equipo principal.
Hay una diferencia entre encapsular l贸gica compleja y abstracci贸n de conocimiento 煤til. Algunas veces la informaci贸n necesita ser aclarada. Si los abstrae, pueden tener el efecto contrario y ser谩n m谩s dif铆ciles de entender.
Es m谩s 煤til usar algunos tipos de comandos de bajo nivel en la CLI que un comando de alto nivel que abstrae conocimiento, como
Git .
Hace unos a帽os estaba trabajando en un proyecto usando
entrega incremental . Era un sistema de verificaci贸n de identidad que requer铆a que el usuario proporcionara algunos datos personales para su verificaci贸n por un proveedor externo.
Esta fue una caracter铆stica especial de validaci贸n de campo que el equipo quer铆a crear. Sin embargo, el historial de auditor铆a se prioriz贸 en la planificaci贸n de cada sprint, ya que la fecha l铆mite se acercaba cada vez m谩s. Al final, el equipo descubri贸 que no ten铆a sentido tener una validaci贸n extra帽a.
Y he aqu铆 por qu茅: 隆la verificaci贸n era obligatoria!
Es del inter茅s del usuario proporcionar informaci贸n confiable. Si el usuario proporciona datos incorrectos, no ser谩n verificados y no podr谩n usar el sistema. Adem谩s, la mayor铆a de los navegadores admit铆an la validaci贸n HTML est谩ndar, que era bastante buena.
En el peor de los casos, los usuarios que no pod铆an verificarse a s铆 mismos pueden llamar al soporte para verificar todo manualmente.
No vale la pena programar todas las funciones.
Si usted es un desarrollador y comprende el problema que est谩 tratando de resolver, puede encontrar un mejor c贸digo y, a veces, puede hacer frente sin el c贸digo en absoluto. Usted no es un "
mono de c贸digo " al que se le paga por escribir caracteres en la pantalla. Eres un profesional al que se le paga para resolver problemas.
Sin embargo, si intenta resolver todos los problemas utilizando la tecnolog铆a, sin pensarlo, tendr谩 problemas para comprender lo que es valioso para el cliente y para encontrar grandes ideas.
Su objetivo y el objetivo del c贸digo que escribi贸 es crear valor y hacer del mundo existente un lugar mejor, y no satisfacer su visi贸n egoc茅ntrica de c贸mo deber铆a ser el mundo.
Hay un dicho: "Si solo tienes un martillo, todo parece un clavo".
Es mejor tener un clavo primero para poder considerar la necesidad de un martillo.
Es decir, si necesita un clavo primero.
隆Gracias por leer el art铆culo!
Si tengo errores en la traducci贸n, 隆escr铆balo en los comentarios!
Tambi茅n visite mi sitio para acceder r谩pidamente a las preguntas y respuestas de JavaScript -
Preguntas y respuestas de JavaScript
Te estar茅 muy agradecido y agradecido)
Estoy en
twitter y
vk隆Muchas gracias por su atenci贸n!