El programa tiene un objetivo que a veces se olvida.
Imagen de un martillo acostado en una pizarra. Un tornillo estaba atascado en el tablero, que anotaron duro allíParece que los programadores se han olvidado del propósito del software: resolver problemas del mundo real.
Hace 50 años, en 1968, el Comité de Ciencia de la OTAN organizó una
conferencia de trabajo sobre ingeniería de software . Luego comenzaron a notar que el software se estaba convirtiendo en una parte fundamental de la sociedad. Y al mismo tiempo se hace más difícil de entender. Después de esta conferencia, la programación comenzó a convertirse en una industria real. Comenzó a salirse del control comercial.
Independientemente del destino de la industria, todavía hay un problema con la separación del negocio y el desarrollo de software, o "ingeniería", como se anunció por primera vez en la conferencia. Si los programadores se centran demasiado en el desarrollo, pueden perder el objetivo para el cual se está creando el programa. Pueden perder soluciones ocultas que no requieren código en absoluto.
Aquí hay un ejemplo.
Una startup creó un dispositivo que abrió la puerta de una casa a través de Bluetooth. Interfaz gráfica para la comunicación con el dispositivo: un widget en una pantalla de teléfono bloqueada. Tiene un botón llamado "Abre la puerta".
Cuando el usuario se acerca a la casa, toma el teléfono, encuentra el widget y presiona el botón.
Alguien miró a este mecánico y preguntó:
Si usamos Bluetooth y asumimos que el dueño del teléfono puede entrar a la casa, ¿por qué obligarlo a tomar el teléfono y presionar el botón? Deje que la puerta se desbloquee cuando el teléfono esté dentro de un radio de 1 metro. ¡No hay necesidad de perder tiempo en el diseño y el código GUI!Este es un excelente ejemplo de un enfoque estrecho: el objetivo era abrir la cerradura con un mínimo esfuerzo. No tiene sentido crear una interfaz gráfica si los sensores son inalámbricos.
Si conoce los desafíos comerciales y las necesidades de los usuarios, puede combinar este conocimiento con su conocimiento de la tecnología. Solo entonces tendrá suficiente información para encontrar una mejor solución y comprender que el programa no necesita una interfaz.
Un gran ejemplo de cómo resolver un problema de software
sin una sola línea de código nuevo , además del código para abrir realmente el bloqueo. Pero,
como el deber técnico ,
nada puede justificar la programación innecesaria de todo lo demás.
No vale la pena escribir todos los códigos.
A veces, solucionar un error grave no es la tarea principal. Si usted es un intercambio de criptomonedas y el sistema permitió un
doble depósito , la intervención humana puede ser la mejor solución en términos de relación costo-beneficio si el costo de la solución es alto.
Esta compensación entre Importancia y Prioridad me recuerda un modelo recientemente mostrado por un
colega . Se llama matriz de prioridad: un
modelo bidimensional que se puede utilizar para priorizar errores en función de la gravedad y el número de usuarios afectados.
Matriz bidimensional de prioridades. El eje vertical representa el número de "víctimas" con los valores "uno", "varios" y "todos". El eje horizontal representa "seriedad" con los valores "cosmético", "incómodo" y "deja de funcionar". La prioridad del error está determinada por la posición en los ejes. Por ejemplo, si el error es cosmético y afecta a un usuario, la prioridad es 4 (mínimo). Si un error detiene a algunos usuarios, la prioridad es 1. Si detiene a todos los usuarios, tiene la máxima prioridad.El problema de doble depósito mencionado anteriormente cae en la categoría de
inconvenientes que afectaron a
un usuario . Por lo tanto, prioridad 3.
No vale la pena corregir todos los errores.
Los desarrolladores a menudo buscan prever todos los casos. Pero algunas tareas repetitivas pueden no merecer la automatización. No es necesario perder el tiempo escribiendo guiones si, como resultado, se oculta un conocimiento importante sobre el trabajo del equipo principal.
Hay una diferencia entre encapsular lógica compleja y abstracción de conocimiento útil. A veces solo se puede entender información clara. Si lo abstraemos, podemos obtener el efecto contrario: la comprensión es difícil.
Es más útil utilizar algunos tipos de comandos de bajo nivel en la CLI que los comandos de nivel superior con conocimiento abstracto,
como los alias de Git .
No todos los equipos merecen la descripción.
Hace muchos años estaba trabajando en un proyecto con
entrega incremental . Era un sistema de verificación de identidad que le pedía al usuario que proporcionara algunos datos personales para su verificación por parte de un tercero.
Y allí el equipo quería codificar una función de validación de campo inusual. Sin embargo, esta validación se retrasó en cada sembradora a medida que se acercaba la fecha límite. Al final, decidieron que esta función inusual no tiene ningún sentido.
Y he aquí por qué: ¡la validación ya está forzada!
Proporcionar información confiable era de interés para el usuario. Si proporcionó datos incorrectos, no pasarán la verificación y no podrá usar el sistema. Además, la mayoría de los navegadores admiten una validación HTML estándar bastante buena.
En el peor de los casos, si el usuario no puede ser verificado, llamará al soporte para la verificación manual.
No vale la pena codificar todas las funciones
Si comprende la esencia del problema que se está resolviendo, entonces, como desarrollador, puede encontrar un código mejor y, a veces, puede prescindir del código. No eres un
byldoder a quien se le paga por escribir líneas para la tarea. Eres un profesional al que se le paga para resolver problemas.
Pero no hay necesidad de resolver cualquier problema con las tecnologías, como si el código del programa fuera una solución universal para todo. De lo contrario, tendrá problemas para comprender las necesidades del cliente y generar grandes ideas.
Su objetivo y la tarea del código es crear valor y hacer del mundo un lugar mejor, y no satisfacer su idea egocéntrica de cómo debería ser el mundo.
Hay un dicho: "Si solo tienes un martillo, todo se vuelve como un clavo".
Es mejor ver primero un clavo para considerar la necesidad de un martillo.
Si realmente necesitas martillar esta uña.