¿Qué hace un gran software? Hacer el trabajo, hacerlo bien y recordar que estás escribiendo para personas, no para máquinas.
por Matt Asay
Twitter puede ser un basurero tóxico para opiniones mal informadas y maleducadas. También es donde Scott Hanselman de Microsoft pasa el rato, compartiendo la sabiduría de sus décadas en el software. Hanselman no es de los que se pavonean, así que a veces es fácil pasar por alto una mina de oro cuando la comparte. Como, por ejemplo, tal vez quieras entender cómo sabe cosas. Cómo se ha familiarizado profundamente con las tecnologías clave. ¿Fue a través de la escuela? ¿O tal vez un proyecto de código abierto? ¿O tal vez alguna asignación de trabajo?
Aunque es probable que cada uno de esos enfoques haya profundizado la comprensión de la tecnología de Hanselman, da una respuesta mucho más básica : “Ejecutar sitios reales y escalarlos”.
¿Quién sabía que podría ser tan fácil? En realidad, ese es su punto: no lo es. Cuanto más construimos, más aprendemos a construir. Como resume Hanselman: “Este es el consejo. No tutoriales. hacer una cosa Registrar el dominio; obtener el certificado; obtenga una A en los encabezados de seguridad; enviarlo a una tienda; corregir SEO; agregar Open Graph, funciones; hacer una PWA. Ejecute un sitio 24/7. Así es como sé cosas.
Por muy útil que sea construir cosas para aprender a construir un gran software, Megan Gleason de Honeycomb espera que dejes de construir tanto software en primer lugar. ¿Por qué? sigue leyendohttps://imasdk.googleapis.com/js/core/bridge3.508.0_debug_es.html#goog_10124068331 second of 27 secondsVolumen 0%
Construya menos; hacer más
Hanselman aboga por aprender haciendo, incluso cuando Gleason argumenta en contra de escribir software nuevo en primer lugar. Por supuesto, cuando Gleason declara que deberíamos “CONSTRUIR MENOS SOFTWARE”, no cuestiona el valor del software. Lejos de ahi. En cambio, señala que “centrarse demasiado en agregar nuevas funcionalidades arruinará su producto, sus usuarios y su equipo. Tal vez tu negocio.
Eso parece malo. Es malo.
En cambio, Gleason aboga por más mantenimiento de software en lugar de desarrollo de software. “Las características no son el único impulsor del valor del producto”, dice. De hecho, ” La calidad casi nunca proviene de nuevas capacidades; por lo general, agregar cosas empeora las cosas por un tiempo”. ¿De dónde viene esa calidad de software? “Viene del trabajo silencioso de cuidar el jardín”.
El problema, dice Gleason , es que “la gravedad siempre te empujará a construir más”. No solo más, sino más construido cada vez más rápido a medida que se acumulan las solicitudes de los clientes, con poco tiempo para la calidad del software en el camino. El problema es que los clientes no exigen necesariamente esa calidad, quieren funciones. “Ningún prospecto le dice que compraría su producto si solo completara la conversión de JS a TypeScript o terminara su sistema de diseño”. Eventualmente, toda esta deuda técnica lastra el desarrollo de nuevas características. Cuando los clientes notan su velocidad reducida, ya es demasiado tarde. Ella concluye : “Si continúa desarrollando funciones sin tener en cuenta las otras dimensiones de la salud del producto, el valor perdurable se le escapará”.
No eres solo tú
Esto nos lleva a una discusión más meta sobre cómo solucionamos esto, cortesía de Dragan Stepanović de Talabat , quien pidió a los desarrolladores que identificaran la fuente de las mayores deficiencias de software de su empresa. “Cuando observa las bases de código en la empresa con la que trabaja, ¿es la falta de conocimiento de algoritmos y estructuras de datos avanzadas el problema más grande y generalizado que ve? Supongo que no.
¿Cuál es el problema que los desarrolladores tienden a ver? ¿Y casi siempre se trata de una buena higiene del software, a la Gleason?
Primero, de Ian Cooper , un recordatorio de cuán crítica puede ser la documentación: “Escribir código que no tenga en cuenta [la realidad de que] alguien más necesitará entenderlo,… cambiarlo,… [y] poseerlo” es incompleto. , el argumenta. “Seguirás adelante; su código permanecerá.” O, como he escrito , “si no tienes buenos documentos, no deberías enviar”.
Haciéndose eco de Gleason, Adam Hisley señala la falta de enfoque en la mantenibilidad del software. En su opinión, garantizar que “la falla elegante/fácil de monitorear y rastrear es uno de los elementos de la calidad del software que creo que se traduce de manera más confiable en valor comercial real, pero a menudo se puede perder en la prisa por crear características”. Jakub Kočí añade : “El mayor problema es la claridad. Estamos escribiendo código para humanos primero, no para máquinas. Hacer que funcione es solo la mitad de la solución, hacerlo bien estructurado y mantenible es otra parte… a menudo más difícil”.
Esto nos lleva de vuelta a Hanselman. Una de las cosas que los desarrolladores aprenderían al construir su propio sitio o aplicación es la importancia de la higiene para mantenerlo fácilmente. Desafortunadamente, según las respuestas a los hilos de Gleason y Stepanović, tal mantenimiento parece ser la excepción, no la regla.
Fuente: https://www.infoworld.com/article/3655130/if-you-build-it-it-will-run.html
