java - online - ¿Cómo puedo hacer que mi flujo de trabajo de desarrollo sea más "empresarial"?
development environment online (13)
Aunque lo pones como la última cosa, creo que deberías comenzar a utilizar jUnit sin demora.
La razón es que probablemente sea la ambición más fácil que hayas identificado, y las herramientas ya están integradas en tu compilación de Eclipse.
Crea una nueva carpeta en tu proyecto llamada ''jUnit''.
Supongamos que tiene una clase Employee, con los métodos setAnnualSalary () y getMonthlySalary ().
Haga clic derecho en la carpeta jUunit, nuevo -> "jUnit test case". Esto hará una nueva clase. Llámalo TestEmployee. Eclipse genera las cosas estándar para usted, como de costumbre.
Agregue un método vacío con un nombre que comience con ''prueba'':
public void testSalaryCalc() {
Employee emp = new Employee("John Doe");
emp.setAnnualSalary(12000);
assertEquals(1000,emp.getMonthlySalary());
}
Haga clic derecho, "ejecutar como" -> "jUnit test". (Es la primera vez que Eclipse puede pedirle que haga algo de configuración para el proyecto. Solo haga lo que dice).
Si el empleado funciona correctamente, verá una barra verde. Sabotee la clase Empleado, vuelva a ejecutar la prueba y verá una barra roja, así como una salida que le indicará cuál fue el error.
Felicidades: ¡estás haciendo pruebas unitarias!
Al hacer clic con el botón derecho en el directorio principal y seleccionar "Ejecutar como jUnit test" se ejecutarán todas las clases de Testcase en el directorio. Más tarde puede incorporar jUnit en su proceso de compilación, pero no se preocupe por eso por ahora.
Autocompletar le mostrará todas las variaciones en assert() que puede usar. Puede leer sobre él y apuntar hacia las prácticas en las que escribe los casos de prueba antes de la implementación que los aprueba. Pero solo hacer las cosas simples anteriores te da grandes beneficios.
Soy el único desarrollador de un consorcio académico con sede en una universidad en el noreste. Todo mi trabajo de desarrollo implica herramientas internas, principalmente en Java, por lo que no se lanza nada al público. En este momento, siento que mi flujo de trabajo de desarrollo es muy "aficionado" y no se parece en nada a una empresa de desarrollo de software con experiencia. Me inclinaría a decir que realmente no importa ya que soy el único desarrollador de todos modos, pero no puede hacer ningún cambio, solo por hacer mi trabajo un poco más fácil y obtener algunos más tecnologías en mi currículum. En este momento mi flujo de trabajo es algo como esto:
Hago la mayor parte de mi trabajo de desarrollo en Eclipse en mi computadora portátil. Todo se guarda localmente en mi computadora portátil, y no uso un VCS, ni hago una copia de seguridad de mi código (a excepción de ocasionalmente enviarlo por correo electrónico a mí mismo para que pueda verlo en una computadora diferente - sí, te dije que mi entorno de desarrollo necesita trabajo).
Cuando termine con un proyecto y desee implementarlo o si solo quiero probarlo, utilizo la herramienta incorporada Jar en Eclipse para crear un .jar ejecutable de mi proyecto. Si uso bibliotecas .jar externas, utilizo el plugin Fat-Jar para incluir esos .jar en mi ejecutable .jar.
Después de crear el archivo .jar, lo cargo manualmente en el servidor a través de SFTP y lo
java -jar MyProject.jarcon algo comojava -jar MyProject.jar.
Oh, sí, ¿mencioné que no hago una prueba unitaria?
El problema más evidente que me gustaría solucionar primero es mi falta de control de la fuente. Me gusta git por su naturaleza distribuida, pero no parece integrarse bien con Eclipse y he oído que no funciona muy bien en Windows, que es mi sistema operativo de desarrollo principal. Por lo tanto, me estoy inclinando hacia SVN, con el que tengo cierta experiencia. Tengo mi propio servidor personal, y creo que usaré eso para mi control de fuente, porque prefiero ser mi propio administrador que lidiar con la burocracia de la universidad. Tuve algunos problemas para configurar SVN una vez, pero le daré otra oportunidad. ¿Tal vez también instalaré algo como Trac o Redmine para rastrear errores, lista de tareas pendientes, etc.?
¿Qué hay de la construcción y el despliegue? Tiene que haber una forma mejor que usar Fat-Jar y subir manualmente mi jar al servidor. He oído hablar de herramientas como Ant y Maven. ¿Se aplican a lo que quiero hacer? ¿Cómo puedo comenzar a usar esos?
Supongo que eventualmente me gustaría integrar pruebas unitarias con JUnit también. Aunque probablemente debería ser, esa no es mi principal preocupación en este momento, porque hasta ahora mis aplicaciones no son terriblemente complejas. Realmente me gustaría trabajar en simplificar y agilizar mi flujo de trabajo en este momento, y luego facilitaré las pruebas unitarias.
Perdón por la larga pregunta. Supongo que mi pregunta se reduce a, para un único desarrollador, qué herramientas y metodologías puedo / debo usar para no solo facilitar mi trabajo, sino también para exponerme a algunas tecnologías que se esperarían conocimiento requerido en un desarrollo dedicado ¿casa?
editar: Gracias por las excelentes respuestas hasta ahora. No quise sugerir que deseaba que mi flujo de trabajo fuera "empresarial" solo por el mero hecho de hacerlo, sino para simplificar mi trabajo y para poner en práctica algunas tecnologías que normalmente se usan en entornos de desarrollo empresarial. Eso es todo lo que quise decir con eso.
Como han dicho otros, ya sabes claramente lo que tienes que hacer. Un VCS es obligatorio, el CI o el seguimiento de errores pueden ser excesivos (para un único desarrollador, una hoja de cálculo puede ser suficiente para el seguimiento de errores).
Una cosa que podría beneficiarlo mucho es mantener una acumulación de productos organizados. En desarrollo solo, encuentro que mantenerme enfocado en las características de alta prioridad y evitar el arrastre de características es uno de mis mayores desafíos. Mantener un retraso acumulado ayuda inmensamente. No tiene que ser mucho más que una lista priorizada de características con algunas notas sobre el alcance de cada una. En mi lugar de trabajo, guardamos esta información en Trac, pero una vez más, una hoja de cálculo puede ser todo lo que necesita.
Y quiero poner un tapón para las pruebas unitarias, particularmente el Desarrollo controlado por prueba (TDD). El libro de Kent Beck es un buen lugar para comenzar. Encuentro que TDD me ayuda a mantenerme honesto y enfocado en lo que realmente necesito hacer, particularmente en un proyecto de desarrollador único sin QA. A veces parece que el código se escribe solo.
Consulte el Kit de inicio pragmático de los programadores pragmáticos .
Te enseña sobre los fundamentos básicos del desarrollo de software que las universidades / etc. parecen pasar, como el control de versiones, pruebas de unidades y automatización de proyectos (en ese orden), y lo hace de una manera muy accesible.
Te dará una base sólida para seguir desde allí.
Creo que respondiste la mayoría de tus propias preguntas.
- Control de fuente: selección de SVN: fácil instalación, gran integración con Eclipse (subclipse).
- Use Ant para construir su proyecto y desplegarlo (tarea SCP / SFTP)
- Mantenga toda su configuración (configuración del proyecto Eclipse, compilación xmls, etc.) en SVN.
- Use Bugzilla para realizar un seguimiento de sus errores / problemas / solicitudes / ideas.
Eche un vistazo en el Appfuse de Matt Raible.
Incorpora Maven y Unit Testing.
Me parece que en realidad tienes una idea bastante buena de lo que tienes que hacer.
Usar Subversion (u otro VCS) es imprescindible. Aunque podría ser conveniente configurar un repositorio SVN separado para su código relacionado con el trabajo en lugar de utilizar uno personal.
Puede integrar Subversion con Eclipse usando un plugin como Subclipse, que he encontrado funciona bastante bien.
Definitivamente usaría Ant o Maven; mi preferencia es Ant porque es más flexible, y creo que se adaptaría mejor a tu estilo de desarrollo que a Maven. Pero también es posible que desee investigar Apache Ivy , que maneja la administración de dependencias.
Básicamente configura una tarea ant que ejecuta los pasos de compilación, compilación e implementación, de modo que cuando crea un paquete JAR final, puede estar seguro de que se ha probado en unidades, ya que es parte de su script ant. La mejor manera de comenzar con la hormiga es mirar algunos ejemplos y leer el manual .
En cuanto a las pruebas unitarias, puede acumularse gradualmente con las pruebas unitarias. Recomendaría usar JUnit junto con una herramienta de cobertura de código como Cobertura (que es fácil de configurar), le ayudará a comprender la cantidad de código que cubren sus pruebas y es un indicador de cuán efectivas son sus pruebas.
También puede valer la pena configurar algo así como Trac: es importante poder realizar un seguimiento de los errores, y una wiki es sorprendentemente útil para la documentación.
En otras palabras, todo esto parece que estás en la línea correcta, ¡solo necesitas comenzar a utilizar algunas de estas herramientas!
Obtuviste algunas respuestas realmente sólidas por lo que en breve publicaste un enlace a un artículo sobre el desarrollo impulsado por prueba que es una práctica ágil que se verá bien en tu CV. TDD
Sería MUY beneficioso comenzar a trabajar con el control de versiones. Comience ahora, no demore! Git se está moviendo REALMENTE rápido, y ya se está desarrollando una TortoiseGit. SVN sigue siendo un gran estándar para trabajar. Y no he trabajado con Mercurial, pero ese es otro VCS que vale la pena investigar.
Aparte de eso, no veo por qué tu flujo de trabajo tiene que ser productivo. Solo tiene que ser eficiente y cómodo. Dicho esto, creo que deberías intentar trabajar con un editor de texto simple y compilar desde la línea de comandos. La mayoría de los mejores programadores del mundo todavía usan eso en lugar de un IDE, y lo ayudará a comprender los procesos debajo de su IDE favorito.
Si está ejecutando un Servidor de Windows donde desea colocar su servidor SVN, use SVN Visual como servidor. Es súper fácil de configurar y usar, admite autenticación básica y autenticación de Windows. También es de uso gratuito.
Eclipse tiene bastantes módulos para integrar con un servidor SVN, así que use uno de esos, o el ya sugerido Tortoise SVN.
Si realmente tienes el control de fuente distribuido, te recomendaría que busques en Bazar . Su control de fuente distribuida similar a GIT que está diseñado para realizar fusiones de muy alta calidad. Fuera de la caja, funciona en todas las plataformas, incluido Windows, y tienen un cliente TortoiseBZR .
Realmente, cualquier control de fuente es mejor que ninguno. Si eres el único desarrollador, no hay necesidad de nada más complejo que SVN. Las grandes empresas y proyectos usan SVN todo el tiempo con pocos problemas.
En cuanto a las pruebas unitarias, debes familiarizarte con JUnit . El hecho de que conozca las pruebas unitarias y sepa que debe hacerlo sigue siendo varios pasos por delante de la mayoría de los desarrolladores ad-hoc.
Una vez que tenga un control de versión configurado y unas pocas pruebas unitarias, consideraría un servidor de integración continuo (quería ser empresarial, ¿no?).
Incluso si eres y eres el único desarrollador, esto podría ayudarte a descubrir algunos errores. Cosas que olvidaste registrar o me gusta. Un servidor CI revisa regularmente todas sus fuentes, realiza una compilación limpia y ejecuta todas sus pruebas. También se contacta con usted en el caso de errores.
Esto le garantiza que usted (o cualquier otra persona) puede verificar su código y crear / ejecutar sus proyectos.
Yo recomendaría echar un vistazo a Hudson
Usa control de versiones Período. SVN tiene una gran integración con Eclipse y Windows. Obtenga el cliente TourtisSVN para Windows y use el plugin subclipse con Eclipse.
Recomiendo obtener un HD externo o usar uno de los servidores de sus empresas para poner su repositorio y hacer copias de seguridad a menudo. Subversion también funciona muy bien con implementación y actualización. Solo aprende cómo hacerlo y nunca mirarás hacia atrás :)
En cuanto a las pruebas unitarias, algunas personas dirían que ese es el camino a seguir, pero no he encontrado suficiente evidencia para comenzar la práctica yo mismo. Si un demonio en esta pregunta puede convencerme de lo contrario, ¡por favor!
Además, no intente hacer que su flujo de trabajo sea "empresarial"; busque mejorarlo. Las prácticas que funcionan bien con grandes equipos y corporaciones pueden no funcionar bien para usted. Soy prácticamente el único desarrollador y conozco la situación en la que se encuentra. Simplemente pruebe todo y solo conserve lo que parece natural después de un tiempo.
¡Pero asegúrate de probar SVN! Si su compañía tiene un servidor LINUX con Apache, vea si puede configurar su servidor allí usando DAV-SVN.
:)
Todos los comentarios anteriores cubrieron casi todo lo que puedas necesitar :-)
Quiero agregar otro enfoque sobre cómo desarrollar (el flujo de trabajo de desarrollo).
Le sugiero que lea el siguiente artículo y, aunque se trata de un flujo de trabajo de git, puede utilizar la misma idea para cualquier otra herramienta que pueda estar utilizando.