| Vocero |
Transcripción |
| Aurora Tiffany-Davis |
Hola, soy Aurora Tiffany-Davis. Soy desarrolladora de software del equipo de JMP Live. Hoy me gustaría hablarles sobre cómo desarrollamos software en el equipo. |
| |
Primero, me gustaría que imaginaras cómo es crear software. Si no eres desarrollador, la imagen que tienes en mente probablemente esté influenciada por la televisión y las películas que has visto. |
| |
Quizás te estés imaginando a alguien que trabaja solo, alguien que es realmente inteligente, tal vez incluso un genio y su proceso es realmente simple. |
| |
Piensan en un problema, escriben código y se aseguran de que funcione. Y probablemente funcione, porque, al fin y al cabo, son unos genios. |
| |
Si todos fuéramos genios en JMP Live, este sencillo proceso nos funcionaría. Pero no lo somos y vivimos en el mundo real. Así que necesitamos algo más. |
| |
En primer lugar, no trabajamos solos, trabajamos de forma muy colaborativa y nuestro proceso tiene pasos para intentar garantizar que no solo producimos cualquier software, sino software de calidad. |
| |
Les diré que no existe una única forma correcta de desarrollar software. Puede variar entre empresas o incluso dentro de ellas, pero les guiaré a través de nuestro proceso. |
| |
contándoles lo que haría si tuviera que desarrollar una nueva característica en JMP Live. |
| |
En primer lugar, antes de sentarme a escribir código, tengo que tener alguna necesidad de hacerlo. |
| |
Tiene que haber algún usuario real por ahí con un problema real, algo que hayan identificado en JMP Lives que no funciona... que no funciona como creen que debería. |
| |
Lo cual es una forma agradable de decir que encontraron un error o alguna característica que habían solicitado. |
| |
Mantenemos un registro interno de estas solicitudes en un sistema. Así que lo primero que haría sería acceder a ese sistema, encontrar un problema prioritario que se ajuste a mis habilidades y empezar a trabajar en él. |
| |
Ahora necesito comprender mejor la necesidad. Hablaré con la gente para intentar averiguar qué tipo de usuario necesita esta función y cómo la usarán. |
| |
Luego ejecutaré JMP Live en mi máquina y veré dónde podría encajar esta característica en JMP Live tal como existe hoy. |
| |
O podría abrir el código y ver dónde podría encajar el nuevo código en nuestra base de código existente. |
| |
Una vez que creo tener una idea bastante clara de lo que se necesita, empiezo a trabajar en el diseño. De nuevo, hablo con la gente. Les pregunto a los miembros del equipo: "¿Han trabajado en una función similar? ¿Han trabajado antes en esta parte del código?". |
| |
Y hablaré con los expertos en experiencia de usuario que tenemos en JMP. |
| |
Intentaré no reinventar la rueda. Así que si hay un aspecto de la función que es muy común y no es específico de JMP Live, por ejemplo, algo como registrar información en un archivo. |
| |
Ese problema ya está resuelto; miles de personas lo han tenido antes. Quizás exista una buena solución de código abierto. |
| |
Y si es así, podría usarlo después de examinarlo cuidadosamente para asegurarme de que es seguro usarlo. |
| |
Aún queda mucho por cubrir, mucho código específico de JMP Live por escribir. Por eso, escribiré artículos y diagramas. |
| |
Describiré mi propuesta y me aseguraré de que todos en el equipo estén cómodos con la dirección que estoy tomando con el diseño. Luego, me sentaré a escribir el código. |
| |
Para ello utilizaré un entorno de desarrollo integrado, que es una herramienta para escribir código que tiene muchas funciones adicionales que te ayudarán a ser más eficiente en tu trabajo. |
| |
Ya escribí código. Antes de revisarlo, quiero encontrar los problemas que existen en el código que acabo de escribir. Soy humano, así que las probabilidades de haber escrito código 100% perfecto a la primera son bastante escasas. |
| |
Voy a empezar buscando problemas muy obvios y para eso uso el análisis estático. |
| |
El análisis estático examina mi código no mientras se ejecuta, sino como si estuviera escrito en una página. Una analogía sería el corrector ortográfico de Microsoft Word. |
| |
El corrector ortográfico no puede decirte si has escrito una novela convincente, pero sí puede decirte si te falta una coma. El análisis estático hace eso con el código. |
| |
Una vez que he encontrado y corregido problemas tan obvios como ese, paso a buscar problemas menos obvios. Para ello, utilizamos un conjunto de pruebas automatizadas. |
| |
Esto se diferencia del análisis estático porque sí ejecuta el código. Ejecuta un fragmento de código con una entrada específica y espera una salida específica. Hemos desarrollado una amplia gama de pruebas para nuestro código. |
| |
Y me sentaré y escribiré pruebas para la función en la que estoy trabajando. |
| |
Esto es realmente útil porque escribir las pruebas me permite aclarar mi razonamiento sobre cómo debe funcionar exactamente el código. Además, me protege contra cualquier posible fallo accidental de la función en el futuro. Es una excelente manera de detectar problemas con antelación. |
| |
Ahora pasemos a las pruebas manuales. Ejecutaré JMP Live en mi equipo y probaré la nueva función para asegurarme de que funciona correctamente. |
| |
Incluso podría hurgar en la base de datos que se encuentra detrás de JMP Live y que realiza un seguimiento de los registros, publicaciones, grupos, usuarios y comentarios para asegurarme de que todos esos registros se escriban de la forma en que creo que deberían hacerse. |
| |
Ahora tengo un optimismo moderado de que he escrito un buen código y el siguiente paso es la revisión por pares. Me gustaría que mis compañeros me ayudaran a revisar el código y a encontrar cualquier cosa que se me haya pasado por alto. |
| |
Puede que me haya perdido algo porque no sé nada de algo o porque alguien de mi equipo tiene conocimientos que yo no tengo. Este paso también suele ser muy útil para el revisor, ya que puede aprender nuevas técnicas. |
| |
Después de pasar por la revisión por pares, estamos listos para confirmar el código o registrarlo en un repositorio de código fuente. |
| |
Contamos con un sistema de compilación continua en nuestros servidores que nos supervisa mientras ingresamos el código. Y cuando lo hacemos, realiza un montón de cosas con ese código. |
| |
Por ejemplo, se asegurará de que los archivos correctos estén en el lugar correcto, con el nombre correcto, etc. También volverá a ejecutar el análisis de la pila y todo el conjunto de pruebas automatizadas. |
| |
Esto es útil porque, al fin y al cabo, somos humanos. Alguien podría haber olvidado hacer esto antes en el proceso o algo podría haber cambiado desde la última vez que lo hizo. |
| |
Una vez que el código supera la compilación continua, está disponible para personas externas al grupo de desarrollo. Los primeros en darse cuenta fueron nuestros profesionales de pruebas de JMP. |
| |
Lo revisarán y podrían agregar información a nuestro conjunto de pruebas automatizadas. También podrían ejecutar algunas pruebas manuales. |
| |
Podrían analizar cómo funciona el software en diferentes sistemas operativos, navegadores, etc. Pensarían en cosas locas que el usuario podría hacer y observarían qué sucede y cómo responde el software. |
| |
Son una parte crucial de nuestro proceso. Piensan con mucha creatividad para identificar problemas en nuestro producto. |
| |
Una vez aprobado, el software estará disponible para su uso en nuestra próxima versión. Permítanme ampliar la información y mostrarles el producto... el proceso completo. |
| |
Y son muchos pasos. Son muchas cosas. ¿De verdad hacemos todo esto para todo nuestro código? |
| |
Aunque no lo creas, este proceso es muy escalable. Así que, para un error muy simple y obvio, vamos a explicarlo paso a paso rápidamente. |
| |
Pero para una nueva característica muy compleja, en cada paso de este proceso vamos a ir más despacio, tomarnos nuestro tiempo y tener mucho cuidado para asegurarnos de que realmente lo hacemos bien. |
| |
Todo lo que requiere tiempo, le cuesta dinero a una empresa. Entonces, ¿por qué JMP está dispuesta a invertir este dinero en la calidad del software? |
| |
Una razón es muy sencilla: nos enorgullecemos de nuestro trabajo y queremos producir un buen producto. |
| |
La segunda razón es un poco menos idealista. Sabemos que si nuestro producto tiene problemas y no los detectamos, nuestros clientes sí los detectarán, y eso perjudica el negocio. Por eso, queremos minimizarlo. |
| |
Debo señalar que si bien JMP invierte tiempo y dinero en la calidad del software, |
| |
No invertimos la cantidad de dinero que, por ejemplo, invertiría una organización como la NASA, así que no podemos prometer la perfección. Como cualquier software disponible en el mercado, |
| |
Puede que encuentres algo en JMP Live que no funcione como crees. Si encuentras alguna sugerencia, |
| |
Nos gustaría invitarlo a visitar www.jmp.com/support y dejarnos saber si hay algo que cree que debería funcionar de manera diferente o alguna característica que le gustaría tener en el futuro. |
| |
Ese tipo de comentarios de usuarios reales es increíblemente valioso para nosotros y los agradecemos mucho. Eso es todo por hoy, pero espero que disfruten del resto de Discovery. Gracias. |
