Hace algunos días comentábamos sobre lo que era DX (experiencia de Desarrollador), y por qué era, o es, importante.
Vimos que el DX es parecido al UX, pero que en este caso el usuario final del producto es un desarrollador web o un desarrollador de aplicaciones.
Además de comentar sobre cuatro pilares de la experiencia de desarrollador — estabilidad, facilidad de uso, claridad, función-, llegamos a la conclusión que el DX se merecía un trato especial en tus estrategias digitales y en las toma de decisiones.
Buenas prácticas
Pero también cometamos que la experiencia de desarrollador necesita centrarse en cómo el desarrollador o el programador utilizará un producto, sus SDKs, bibliotecas, frameworks, APIs y documentaciones.
Esto significa que debes seguir un determinado número de buenas prácticas en cada una de estas herramientas. Estas buenas prácticas son las que harán de tu producto un producto fácilmente adoptable por la comunidad de desarrolladores. Por eso, en el artículo de hoy repasaremos algunas de estas buenas prácticas.
Open Source
No siempre todo tu código debería ser propietario. De hecho estoy seguro que alguna parte de este código puede o debería ser Open Source. Los proyectos Open Source son una buena forma de hacer que la comunidad se involucre y aprenda sobre tu herramienta.
Esto es positivo para desarrolladores junior, y es por tanto una buena práctica, ya que juntamente con desarrolladores más avanzados, estos podrán ver el código fuente, buscar y solucionar errores. También podrán eliminar código sospechoso y así ir ganando confianza con tu producto.
Mantén la consistencia
La consistencia es una forma de evitar el error en el UX. Esto también es clave para las interfaces para desarrolladores. Por eso tu producto debe ser consistente con el resto de la plataforma a la que pertenece.
Para lograr este objetivo, debes investigar otros códigos y saber qué es común en la plataforma o lenguaje que estás utilizando. ¡El código abierto (Open Source) de la plataforma puede ser un buen punto de partida!
Respeta la jerga y las normas
Puede ser confuso muchas veces estar leyendo documentación de Drupal y leer Plugin habiendo trabajado con Wordpress, o incluso leer una documentación de Wordpress y leer Módulo.
Tu biblioteca, SDK, o API debe respetar las normas de la comunidad, así como la jerga de la plataforma, porque esto es lo que evitará confusión y mantendrá la consistencia.
Notas de Lanzamiento e historial de versiones
Las notas de lanzamiento deben plasmar claramente qué es lo nuevo, qué no funcionaba y se ha arreglado, y si hay algún problema de compatibilidad instalando la nueva versión. Por ejemplo, a mi me gusta repasar las notas de lanzamiento de Drupal para entender de forma fácil qué hay de nuevo en la nueva versión, o el historial de versiones de Symfony para entender qué ha cambiado y por qué debo actualizar o no.
Las notas de lanzamiento pueden informar sobre vulnerabilidades de seguridad, que a su vez pueden motivar al desarrollador a actualizar el sistema, si no han querido hacerlo por alguna otra razón.
Buena Documentación
Bertrand Meyer ya decía que “documentación incorrecta es a menudo peor que ninguna documentación”. Tu documentación le habla directamente al desarrollador y, para que sea buena, debe imaginarse que el desarrollador es un principiante, alguién que está empezando ahora a conocer tu tecnología y su plataforma.
Relacionado con el punto sobre la “consistencia”, es importante mantener esta consistencia de lenguaje, pero la de nomenclaturas y enfoque también. Por ejemplo, si tu usas “función” envés de “método” en tu documentación, todas las personas que colaboren con tu documentación deben hacer lo mismo. Si no, es muy fácil perderse mientras se intenta entender al documentación.
Una buena documentación debe tener una buena estructura lógica, ser coherente y consistente. Una buena documentación no debe tener miedo de la verbosidad — no tienes nada a esconder y todo a ganar-, pues es tu mejor herramienta de marketing, en mi opinión. Todo lo que puedas decir con la intención de ayudar al desarrollador, ayudará al desarrollador. No vale la excusa que el “código debe ser autodocumentado”.
Video de programador muy enfadado destrozando su ordenador
Paradigmas de programación
Asumir paradigmas o estilos de programación es un error. Que a ti o a tu organización os guste la programación imperativa, o la declarativa, la lógica, la funcional o la orientada a objetos, no significa que a todo el mundo le guste y estén preparados para adoptar tu biblioteca desarrollada con tu estilo preferido.
Mi recomendación es que utilices siempre que puedas alguna forma más estándar y simple. El objetivo es que cualquier programador pueda utilizar tu biblioteca sin que tenga que aprender un nuevo paradigma.
Comunicación
En un próximo artículo hablaremos más sobre este tema, y hablaremos sobre cómo la comunicación es importante en el Mundo IT. Los desarrolladores necesitan trabajar su comunicación, pero si no eres desarrollador y tienes un producto que quieres que sea utilizado por desarrolladores, entonces también necesitas mejorar la tuya.
La comunicación auténtica, abierta y honesta es clave para la una experiencia de desarrollador exitosa. Esto se aplica a como hablas, pero también a como comunicas sobre tu producto, sobre la hoja de ruta del producto, status, briefs, etc…
Léame
Un buen Léame (Read Me) debe contener las notas de instalación, una buena descripción, ejemplos simples, problemas identificados, pautas de contribución, enlaces a otras documentaciones, etc.
Versionado
También es importante versionar correctamente tu código y productos. Deberías usar el versionado semántico para ello. Con SemVer, una versión tendrá tres partes. Por ejemplo “A.B.C”, en las que A corresponde a Major, B corresponde a Minor y C corresponde a Patch. Major elimina caracteristicas obsoletas, y lanza características más grandes. Minor agrega pequeñas características y Patch (los lanzamientos de parches) corrige errores.
Conclusión
Estas son solamente algunas de las buenas prácticas que debes tener en cuenta si tu objetivo es proporcionar una buena experiencia de desarrollador, y quieres que tu producto o servicio sea adoptado por los desarrolladores, y además quieres que estes sean embajadores de tu herramienta.
¿Cómo saber si tu DX es bueno? Pues, ponte en la piel de cualquier desarrollador, imagina que no sabes nada sobre tu producto y comprueba si es usable.
¿Qué otras buenas prácticas crees que son necesarias para un buen DX? ¡Coméntalo abajo!
Foto de Ketut Subiyanto en Pexels
Fuentes:
