Mis notas de ingeniería de software

Sobre el proceso de desarrollo

1. El código no solo está destinado a ser ejecutado directamente, sino que también es un medio de comunicación dentro del equipo y una forma de describir a los demás una solución a un problema. Escribir código legible es una parte fundamental del proceso, no solo "buenos modales". Implica refactorizar el código, elegir nombres de variables significativos y agregar comentarios a cualquier cosa que necesite explicación.
2. Piensa en lo que tu solicitud de incorporación de cambios puede hacer por los usuarios y la comunidad en su conjunto, no por tu avance profesional. Evite a toda costa "invertir en exceso". No agregues una función si no tiene nada que ver con los objetivos reales de tu producto.
3. Tener buen gusto también se aplica al código. El gusto es un proceso de satisfacción de limitaciones, gobernado por un deseo de simplicidad. Mantén el rumbo hacia la simplicidad.
4. El hecho de que alguien te pida que agregues una función no significa que tengas que agregarla. Siéntase libre de responder "no". Cada característica tiene un costo que va más allá de la implementación inicial: costos de mantenimiento, costos de documentación y su costo mental. Siempre pregúntate: ¿Realmente necesitamos hacer esto? A menudo, la respuesta es "No".
5. Tenga en cuenta que no siempre debe decir que sí a la solicitud de un usuario para agregar un nuevo caso de uso, ya que el escenario solicitado a menudo no es óptimo. Los usuarios se centran en su caso de uso específico, y usted debe centrarse en la visión del proyecto en su conjunto. En su lugar, concéntrese en mejorar las funciones existentes.
6. Invierta en la integración continua y apunte a una cobertura completa de pruebas unitarias. Asegúrate de que estás en un entorno en el que puedes escribir código con claridad y confianza. Si no es así, comience por construir la infraestructura adecuada.
7. No te preocupes si no has planeado todo con anticipación. Pruébalo poco a poco y mira qué pasa. Si no estás satisfecho con algo, renuncia a esta idea lo antes posible. Asegúrate de crear un entorno en el que puedas hacer esto.
8. Un buen software simplifica el proceso. El hecho de que una tarea parezca complicada no significa que tenga que ser larga y difícil. Con demasiada frecuencia, los ingenieros encuentran las mismas soluciones a problemas complejos (¡Usemos ML! ¡Construyamos una aplicación! ¡Agreguemos una cadena de bloques!) en situaciones en las que está disponible una alternativa mucho más simple, aunque menos obvia. Antes de comenzar a codificar, asegúrese de que su tarea sea lo más simple posible. Proceda a partir de sus "principios originales".
9. Evite las reglas poco claras. Las reglas que desarrolles siempre deben ser claras y accesibles para los demás. Siempre que pienses en un flujo de trabajo, debes intentar formalizarlo en un proceso documentado para que otros miembros del equipo puedan beneficiarse de él. Además, debes intentar automatizar tus flujos de trabajo con software (por ejemplo, validación).
10. Sus elecciones deben influir en todo el proceso de diseño, no solo en los ingresos y el desarrollo. ¿Qué impacto tiene su software en los usuarios y en el mundo? ¿Hay algún efecto secundario no deseado que supere los beneficios? ¿Qué puede hacer para resolverlos conservando todos los beneficios del software?

Acerca del diseño de API

1. Su API tiene usuarios, por lo tanto, la API tiene experiencia de usuario (UX). A la hora de tomar cualquier decisión, ten siempre en cuenta a tus usuarios. Piensa en los sentimientos de cada usuario, ya sea un principiante o un desarrollador experimentado.
2. Intente minimizar la carga mental de los usuarios mientras usan la API. Automatice lo que se puede automatizar, reduzca el número de acciones y opciones requeridas por el usuario. No agregues parámetros que no importan, desarrolla flujos de trabajo simples y secuenciales que reflejen modelos mentales simples y consistentes.
3. Las cosas simples deben ser simples, las cosas complejas deben ser posibles de hacer. No aumente, ni siquiera mínimamente, la carga mental de los escenarios de uso general para casos de uso especializados.
4. Si la carga mental del flujo de trabajo es lo suficientemente baja, el usuario debería ser capaz de hacer todo desde la memoria (sin usar documentación o un tutorial) después de haberlo hecho una o dos veces.
5. Esfuércese por asegurarse de que su API se ajuste a los modelos mentales de los expertos y profesionales del dominio. Si alguien tiene experiencia con dominios, pero no experiencia con su API, debería poder comprender intuitivamente su API utilizando una cantidad mínima de documentación, principalmente con solo mirar algunos ejemplos de código, objetos disponibles y sus firmas.
6. El significado del argumento debe ser comprensible sin ningún contexto relativo a la implementación subyacente. Los argumentos que proporcionan los usuarios deben estar relacionados con los modelos mentales que los usuarios atribuyen a un problema determinado, no con los detalles de implementación del código. Las API siempre tienen que ver con los problemas que resuelve el código, no con cómo funciona el software en segundo plano.
7. Los modelos mentales más poderosos son la modularidad y la jerarquía. Del mismo modo, una buena API es modular y jerárquica: fácil de usar, pero expresiva. Existe un equilibrio entre tener firmas complejas en menos objetos y tener más objetos con firmas más simples. Una buena API tiene un número razonable de objetos con firmas bastante simples.
8. Inevitablemente, su API refleja sus opciones de implementación, en particular su elección de estructuras de datos. Para obtener una API intuitiva, debe elegir estructuras de datos que sean naturalmente apropiadas para el dominio, esto está en línea con los modelos mentales de los expertos en dominios.
9. Diseñe intencionadamente flujos de trabajo de un extremo a otro en lugar de un conjunto de funciones atómicas. Muchos desarrolladores, a la hora de diseñar APIs, se hacen la pregunta: "¿Qué capacidades necesitamos añadir?". En su lugar, es mejor preguntarse: "¿Cuál es el caso de uso de esta herramienta?" ¿Cuál es la secuencia de usuarios óptima para cada caso de uso? ¿Cuál es la API más sencilla que puede admitir este flujo de trabajo? Las funciones atómicas de la API deben responder a una necesidad clara que surge en un flujo de trabajo de alto nivel. No se deben agregar funciones como "en caso de que alguien pueda necesitar esto". ¡No los necesitas!
10. Los mensajes de error y, en general, cualquier comentario proporcionado al usuario al interactuar con la API, forman parte de la API. La interactividad y la retroalimentación son una parte integral de la experiencia del usuario. Genere intencionadamente mensajes de error en la API.
11. El código es un medio de comunicación, por eso es tan importante asignar nombres a proyectos o variables, por ejemplo. Los nombres reflejan tu actitud ante el problema. Evite los nombres comunes (x, variable, parámetro), evite los nombres excesivamente largos, evite los términos que puedan crear controversias innecesarias (maestro, esclavo) y asegúrese de ser coherente en su elección de nombres. La consistencia en la nomenclatura significa tanto consistencia interna (no llames "tenue" a lo que se llama "eje" en otros lugares) como consistencia con las convenciones establecidas para el dominio problemático. Antes de elegir un nombre, asegúrese de comprobar los nombres existentes utilizados por los expertos en dominios (u otras API).
12. La documentación es fundamental para la experiencia de usuario de tu API. No es un complemento de la API, como mucha gente cree erróneamente. Invierta en documentación de alta calidad y obtendrá mayores rendimientos que invirtiendo en otras funciones.
13. Mostrar, no decir: Tu documentación no debe hablar de cómo funciona el software, sino de cómo usarlo. Demostrar ejemplos de código para flujos de trabajo de extremo a extremo; Ejemplos de código para cada caso de uso común y características clave de la API.

Acerca de las carreras en ingeniería de software

1. El avance profesional no se trata de cuántas personas administras, sino de cuánta influencia tienes: la diferencia entre un mundo que tiene los frutos de tu trabajo y un mundo que no los tiene.
2. El desarrollo de software es un esfuerzo de equipo; Se trata tanto de relaciones como de habilidades técnicas. Sé un buen compañero. A medida que persigues tu objetivo a propósito, no te olvides de otras personas.
3. La tecnología nunca es neutral. Si tu trabajo tiene algún impacto en el mundo, es una influencia moral. Las elecciones técnicas aparentemente inocuas que hacemos en los productos de software modelan las condiciones para acceder a la tecnología; incentivos para su uso; Quién ganará y quién lo sufrirá. Una elección técnica es también una elección ética. Por lo tanto, siempre concéntrese y sea sincero sobre los valores que desea apoyar y promover. Encarna tus valores en tus creaciones.
4. La autogestión, el libre albedrío en el trabajo y las circunstancias, es la clave para la satisfacción con la vida. Asegúrate de proporcionar suficiente autonomía a las personas que te rodean y asegúrate de que la carrera que elijas te genere más agencia.
5. Crea para el mundo lo que necesita, no lo que tú quieres. Con demasiada frecuencia, los ingenieros viven en su propio mundo de fantasía, centrándose en productos que satisfacen sus necesidades específicas. Busca oportunidades para ampliar tus experiencias de vida que te permitan comprender mejor lo que el mundo necesita.
6. Al tomar decisiones con consecuencias a largo plazo, ponga sus valores por delante del interés propio a corto plazo, así como descarte las emociones innecesarias, como la codicia o el miedo. Deja que tus valores, no tus emociones, te guíen.
7. Cuando se metan en un conflicto, hagan una pausa y recuérdense mutuamente los valores y objetivos compartidos. Seguro que estás del mismo lado de las barricadas.
8. La productividad se reduce a una alta velocidad de toma de decisiones y una propensión a actuar. Esto requiere: a) una buena intuición, que se basa en la experiencia de vida, para tomar las decisiones correctas con un mínimo de información; b) una comprensión clara de cuándo proceder con más cautela y esperar más información, ya que el costo de tomar la decisión equivocada será mayor que el costo del aplazamiento. El equilibrio óptimo entre la velocidad y la calidad de la toma de decisiones puede variar mucho en diferentes condiciones.
9. Tomar decisiones rápidamente aumenta el número de decisiones que tomas a lo largo de tu carrera. Como resultado, esto conduce a un aumento en el nivel de tu intuición a la hora de tomar decisiones. La experiencia es la clave para una alta productividad, y el alto rendimiento le da más experiencia: un ciclo altamente eficiente.
10. En situaciones en las que te des cuenta de que la intuición no te ayuda, apégate a los principios abstractos. Crea una lista de principios probados y agrégala a lo largo de tu carrera. Los principios son intuiciones formalizadas que tocan una gama más amplia de situaciones y requieren mucha menos experiencia de tu parte.

François Chollet: Notas para mí mismo sobre la ingeniería de software