codebase - segun - qué significa código fuente
Organizar la base del código fuente al mezclar dos o más idiomas(como Java y C++) (7)
En este caso, los archivos en cuestión no son solo un idioma diferente, sino que también se ejecutan como un programa separado que interactúa a través de una interfaz definida. Esto significa que los archivos fuente se pueden tratar como un proyecto separado y, por lo tanto, se pueden guardar en otro lugar.
El caso es diferente en los proyectos .NET que mezclan C # y ASP.NET (por ejemplo) dentro de una base de código. ¿Cómo organiza la gente su código en tales casos?
Me encontré con un problema hace unos días cuando tuve que introducir archivos C ++ en un proyecto Java. Comenzó con una necesidad de medir el uso de la CPU del proceso de Java y se decidió que el camino a seguir era usar JNI para llamar a una biblioteca nativa (una biblioteca compartida en una máquina Unix) escrita en C. El problema era para encontrar un lugar apropiado para colocar los archivos C en el repositorio de origen (por cierto Clearcase) que consiste solo en archivos Java.
Pensé en un par de alternativas:
(a) Cree un directorio separado para colocar los archivos C (específicamente, un archivo .h y un archivo .c) en la parte superior de la base de la fuente como:
/ vobs / myproduct / javasrc / vobs / myproduct / cppsrc
No me gustó porque solo tengo dos archivos C y me pareció muy extraño dividir la base de la fuente en un nivel de lenguaje como este. Si partes sustanciales del proyecto se hubieran escrito más o menos por igual en C ++ y Java, esto podría estar bien.
(b) Coloque los archivos C en el paquete Java que lo usa.
Tengo las clases Java de llamada en / vobs / myproduct / com / mycompany / myproduct / util / y los archivos C también entran allí.
Tampoco me gustó esto porque creo que los archivos C simplemente no pertenecen al paquete Java.
¿Alguien ha resuelto un problema como este antes? Generalmente, ¿cuál es una buena estrategia a seguir cuando se organiza una base de código que mezcla dos o más idiomas?
Actualización: no tengo ningún plan para usar C o C ++ en mi proyecto, quizás algo de Jython, pero nunca se sabe cuándo mis clientes necesitan una característica que se pueda resolver solo mediante C o mejor resuelta mediante el uso de C.
Mantenerlos en carpetas separadas es una buena idea. Hace que sea más fácil encontrar que buscar paquetes Java para los archivos C, y también permite la posibilidad de agregar más código C en el futuro sin tener que moverlo más adelante.
Personalmente, en el caso de las soluciones de lenguaje dividido, las mantendría en proyectos o carpetas separados.
Una forma de ver el problema es tratar las clases C como cualquier otra API de terceros. Interconecte las dependencias (es decir, evite las llamadas directas) en su código java para evitar el acoplamiento ajustado y mantener la fuente C en un proyecto / carpeta separada del java.
Personalmente, separaría los dos, posiblemente incluso en sus propios proyectos separados, pero eso es cuando ambos son cosas separadas, al igual que no pondría dos conceptos diferentes en la misma clase. Se vuelve mucho más vago cuando ambos tocan la misma área conceptual. Por supuesto, siempre hay problemas a la hora de construir el código, es ponerlo en la estructura b) posible, por ejemplo, sin tener que hacer todo tipo de trucos para compilarlo. ¿Está planeando usar más C en el proyecto, en cuyo caso los archivos C se extenderían por todo su proyecto si sigue el mismo patrón ...
Usemos una terminología diferente. Hay un producto que no es proyecto. El producto consiste en el espacio de trabajo Java y el espacio de trabajo C / C ++, cada uno de los cuales se puede cargar desde el IDE diferente. Eventualmente, si usa uno y el mismo IDE, habrá solo un espacio de trabajo. Cada espacio de trabajo consta de varios proyectos. Cada proyecto tiene su propia estructura de carpetas (src, bin, res, etc.). Entonces, en caso de que sea solo un espacio de trabajo, entonces es mejor tener al menos un proyecto Java y un proyecto C / C ++ dentro, cada uno con diferentes configuraciones de compilación / ejecución / depuración / salida / ...
Entonces, usaría:
Product/Workspace(1)/JavaProject1/src
Product/Workspace(1)/JavaProject2/src
Product/Workspace(1 or 2)/CPPproject1/src
Product/Workspace(1 or 2)/CPPproject2/src ...
De esta forma, puede usar eventualmente una y la misma estructura de carpetas para cada proyecto, que es más consistente. Básicamente, este es solo un nivel más de abstracción: dividir el producto en diferentes proyectos relacionados.
"No me gustó porque solo tengo dos archivos C y me pareció muy extraño dividir la base de origen en un nivel de lenguaje como este"
¿Por qué parece extraño? Considera este proyecto:
project1/src/java project1/src/cpp project1/src/python
O, si decides dividir las cosas en módulos:
project1/module1/src/java project1/module1/src/cpp project1/module2/src/java project1/module2/src/python
Supongo que es una cuestión de gusto personal, pero la estructura anterior es bastante común, y creo que funciona bastante bien una vez que te acostumbras.
El diseño predeterminado generado por Maven para aplicaciones web es src/main/java , src/test/java , src/main/resources y src/test/resources . Asumiría que agregaría src/main/cpp y src/test/cpp manera predeterminada. Esto parece una convención bastante decente para mí.