Bueno … tal vez aquí? 🙂
1) analizar el paquete de código abierto
Su objetivo es presentarlo como un pequeño conjunto de matrices de funciones. En la forma típica de API, tendrá un pequeño conjunto de funciones de inicialización (piense en “abrir”), un gran conjunto de funciones a las que se puede llamar una vez que se amarra el servicio (piense en “buscar”, “leer”, “escribir” , etc.) y un pequeño conjunto de funciones de finalización (piense en “cerrar”).
Puede haber más estados que simplemente inicializar-usar-finalizar – pero mantener ese diagrama de transición de estado lo más simple posible. La complejidad es tu enemigo.
- ¿Qué PaaS, CloudFoundry, dotCloud, RedHat Linux, Heroku es el mejor?
- ¿La cuenta de Batch en Azure podría hacer las funciones que hace HPC o es solo un engranaje en el proceso de HPC?
- ¿Desplegaría una aplicación que compita directamente con Amazon.com en AWS de Amazon?
- Quiero desarrollar mi carrera en computación en la nube, entonces, ¿cuáles serían sus requisitos previos y cualquier curso al que deba asistir?
- Computación en la nube: ¿Cuáles son las características clave de una arquitectura de nube robusta, escalable y saludable?
Querrá descubrir cómo puede hacer una reorganización menor a la base de código actual como sea posible, para mantener al mínimo cualquier cambio que solicite que haya avanzado.
Además, deseará trabajar inicialmente con una COPIA de todas las funciones que tienen cada una “desactivada”: implementaciones, con todos los argumentos y tipos, pero funciones que simplemente imprimen el hecho de que se han llamado . Para simplificar la integración, es posible que desee que su conjunto de copias de las funciones eventualmente solo llame a las funciones reales.
2) agrega tus interfaces a la mezcla
¿Sobre qué estándares / protocolos desea que se superponga su API? Cree un nuevo código que inicialice e interactúe con esos protocolos, y llame al conjunto de funciones. Por ahora, solo haga que las interfaces llamen implementaciones “stub” de las funciones que imprimen el hecho de que han sido llamadas.
3) construya una gama completa de pruebas automatizadas para la API
Es posible que desee hacer esto ANTES # 2. Pero necesitas hacerlo. Deje que la computadora haga el trabajo: ejecute su API a través de un conjunto riguroso de pruebas, automáticamente, con cada compilación / lanzamiento.
4) conecta tus interfaces al paquete de código abierto real
Una vez que tenga la API funcionando correctamente sobre el (los) protocolo (s) en cuestión, y todas las pruebas funcionen sin problemas e impriman que están llamando a sus funciones apagadas, entonces querrá vincular las funciones REALES en lugar de las Los stubs, o como mencioné anteriormente, hacen que los stubs comiencen a llamar a las funciones reales (un nivel más de indirección). Si eliminar los trozos o usarlos dependerá de cuánto “pegamento” se necesite entre su API y las funciones originales. Si se necesita un montón de simplificación, donde tiene una función que llama 3 o 4 desde el sistema de código abierto para realizar un trabajo, convierta los apéndices en “llamadores” en lugar de eliminarlos.
4) depurar cosas
Inevitablemente, el código que no fue diseñado para un modelo de uso particular tendrá hipo. Depurar el código de otra persona nunca es divertido … pero, en primer lugar, no tuvo que escribirlo, así que considere el ahorro de tiempo.
5) publicar
El equipo de personas que desarrolló el código original y sus usuarios avanzados son una audiencia inicial increíble para su nueva API. Escriba una introducción concisa pero informativa sobre lo que hace la API y compártala en las listas de correo relacionadas con las diversas tecnologías del dominio.
6) buscar comentarios
No pienses que has terminado, busca formas de mejorar y ampliar la API. Déjalo crecer y florecer.
7) déjame saber cómo resulta
Estoy seguro de que me he perdido algo u otro en lo anterior, así que avíseme dónde hice una colina de una montaña.
