sort prueba ordenamiento metodos metodo explicado escritorio java perl design shell

prueba - ¿Tiene sentido reescribir los guiones Perl y Shell en java?



shell sort java (20)

¿Es correcta mi "reacción visceral"? ¿Es Java más lento, más detallado y más difícil de mantener para la gestión de bases de datos, el análisis de hojas de cálculo y las tareas de procesamiento de archivos?

No.

Parece que su gerente le está encargando a la persona equivocada que haga esto. Está claro que no te sientes cómodo escribiendo Java y que no deberías estar haciéndolo. ¿Por qué uno de los desarrolladores del "lado de Java" no te ayuda?

Tengo un montón de scripts, algunos en perl y otros en bash, que se usan para:

  • Crear una base de datos (tablas, índices, restricciones, vistas)
  • Analizar hojas de cálculo y cargar los datos en la base de datos
  • Obtener información sobre un grupo de archivos y cargar eso en el
    base de datos.

Estos scripts se usan junto con una aplicación mucho más grande que está escrita en Java, y mi gerente me ha pedido que reescriba los scripts en java. Su razonamiento es que es más fácil trabajar con, portar, administrar, comprender y dar soporte si todo está en un solo idioma, y ​​que demasiadas piezas separadas son un problema de diseño.

Mi reacción inicial es que esta es una mala idea. Los scripts son muy concisos y rápidos, y las tareas que son triviales en los scripts, como el uso de expresiones regulares para buscar y reemplazar valores no válidos, serán mucho más prolijas y muy probablemente más lentas cuando se realicen en Java.

El único inconveniente de los scripts es que cuando se ejecutan en Windows requieren cygwin para ejecutarse. Por lo tanto, me gustaría dar una contraoferta de que transfiera todos los scripts bash a perl para que puedan ejecutarse en Windows sin cygwin, y que dedique tiempo a organizar y documentar los scripts.

El problema es que una respuesta tipo "reacción visceral" no será suficiente para convencer a mi gerente. Vengo de un fondo de Linux, él de Windows, y tenemos algunas de las diferencias de enfoque clásicas de Linux vs. Windows.

Entonces tengo dos preguntas:

  1. ¿Es correcta mi "reacción visceral"? ¿Es Java más lento, más detallado y más difícil de mantener para la gestión de bases de datos, el análisis de hojas de cálculo y las tareas de procesamiento de archivos?
  2. Si la respuesta a la primera pregunta es sí, ¿cuál es la mejor manera de presentar mi caso?

EDITAR: Gracias a todos por las ideas. Me gustaría hacer una aclaración: los scripts no son aplicaciones completas escondidas en scripts ofuscados. Son, en su mayor parte, tareas que se han hecho manualmente que automaticé a través de scripts y luego embellecí a medida que se desarrollaban los requisitos. Y la razón por la que utilicé un lenguaje de scripting en lugar de Java para empezar es porque estas tareas eran mucho más fáciles de hacer en los scripts. Por ejemplo, un script ejecuta un montón de consultas, formatea los resultados y los envía a un archivo. ¿Cuántas LOC crees que tomaría hacer eso en Java?

¿Deberían ser reescritos? Eso depende. El argumento más fuerte que tiene su jefe es que el resto de la aplicación está escrita en Java y parece que esa es la forma en que se dirige la organización. Reducir la cantidad de langues diferentes que debe soportar la organización es en realidad una decisión bastante inteligente a largo plazo. Sé, lo sé, la herramienta adecuada para el trabajo correcto, pero desde una perspectiva de costos, es muy posible que a la organización le cueste más dinero contratar a alguien que conozca PERL y JAVA que solo Java. Incluso si los guiones son hermosos, deben ser apoyados, y eso significa que debe mantener al menos una persona en el personal que sepa cómo hacerlo. Es otra cosa de la que él (y la organización) tienen que preocuparse al final del día.

Ciertamente estoy de acuerdo en que es más fácil para todos si trabajas con un conjunto de herramientas que la mayoría de ustedes conoce. Sin embargo, dado que tienes código Java y Perl, supongo que al menos algunos de ustedes conocen ambos, y como tal, honestamente no veo el gran problema de tener tanto el código Java como el código Perl.

Si los scripts de Perl funcionan como se esperaba y se pueden mantener, no pasaría mucho tiempo reescribiéndolos en Java. La creación de scripts es mucho más fácil en Perl que en Java, así que a menos que realmente necesite convertir, no veo el punto. Preferiría pasar las horas en algo que realmente agrega valor a lo que sea que estés haciendo.

Usted dice que los scripts necesitan cygwin para ejecutarse. He hecho un montón de Perl en Unix / Linux y Windows, y a menos que esté haciendo muchas cosas específicas de Unix, mi experiencia es que las secuencias de comandos pueden convertirse fácilmente para ejecutarse bajo Windows Perl, como ActiveState. Tal vez esa podría ser una opción en tu caso.

Creo que tu primera reacción es correcta. Un argumento es: si funciona, no lo "arregles". Otro argumento es que un desarrollador puede escribir casi la misma cantidad de SLOC independientemente del idioma que utilizó. Suena extraño si sabes cómo Java es detallado, pero piensa en cuán cuidadosamente debes diseñar tu código Java para obtener el mismo resultado usando las características de Perl como cierres, código generado dinámico, expresiones regulares instantáneas y otros. Y ahora, cuando la proporción de Java a Perl SLOC al mismo resultado es más de 10: 1. Cada línea de código debe leer, comprender y mantener. Java es más rápido. Sí. Java es más rápido para algunos piensa como el crujido de números y algún tipo de procesamiento de texto. Perl es más rápido para expresiones regulares y algunos otros procesos de texto y mucho más productivo que Java en general. Perl es peor mantenible si se compara con SLOC pero es igual o mejor que Java si se compara con la característica. Si Perl se escribe utilizando las mejores prácticas y mantiene el estilo de codificación que puede vencer a Java en la mantenibilidad, especialmente si se usa para scripts cortos.

Depende. Descubrí que el procesamiento de texto en Java puede tomar hasta 8 o 9 veces más cantidad de código que en Perl. Si estos scripts necesitan estar estrechamente integrados en la aplicación, entonces estaría de acuerdo con su gerente, pero si solo tuviera tareas de fondo, buscaría usar ActiveState en Windows y volver a escribir los scripts bash en Perl.

Desde mi propia experiencia (que incluye mezclar Java y Perl en un solo sistema), sugeriría lo siguiente:

1) "Java es más lento" no es necesariamente cierto, pero tampoco es relevante (incluso si es verdadero) a menos que el tiempo de ejecución adicional interfiera con algún flujo de trabajo de tiempo crítico.

2) la mantenibilidad a largo plazo es un problema legítimo. Tener, por ejemplo, una única capa DAO que no tiene que mantenerse en dos idiomas puede devolverlo en el largo plazo. ¿Qué cantidad de código Java y scriptage actual debería modificarse (dos veces) para cubrir una refactorización en la base de datos?

3) Si realmente prefiere una notación más liviana, pero su gerente quiere Java, ¿podría comprometerse con las bibliotecas Java (a partir del punto anterior) combinadas con uno de los lenguajes interoperables similares a scripting que se ejecuta en la JVM y podría compartir el uso? de las libretas estándar para las que escribe, p. ej. acceso a la base de datos? Estoy pensando en algo del espectro JRuby-Groovy-Scala-Jython.

En general, entiendo el deseo de su gerente de minimizar y estandarizar los diferentes idiomas / plataformas utilizados en su entorno.

Sin embargo, hay ciertas tareas para las cuales un lenguaje de scripting es mucho más adecuado que un lenguaje como Java. Si cree que ese es el caso con los scripts que se le pide que reescriba, tal vez en lugar de proponer el uso de Perl como un lenguaje único para esta tarea en particular, podría proponer la adopción de Perl (u otro lenguaje de scripting si cree que obtener un mejor buy-in) como el lenguaje "compatible" para las tareas de scripting.

Dicho esto, dependiendo de lo que quiera decir con "usado en conjunción con" (es decir, qué tan estrechamente acoplados están los diferentes bits), simplemente podría darse el caso de que estas tareas tengan más sentido si se escriben como bibliotecas Java para ser llamadas por el resto de la aplicación.

Para mí, depende de qué tan mal escrito esté el Perl (nunca he visto a Perl que diría que fue "BIEN" escrito), y si alguna vez necesitarás LEER el Perl.

Perl es a menudo un lenguaje de Escribir una vez, Leer nunca. Si todo funciona, y no es probable que tengas que modificarlo, yo diría que no lo toques.

Personalmente encuentro que db, la administración de archivos es más difícil de hacer con Java, pero puede ser más fácil de mantener una vez que se escriben.

Pero ¿vale la pena? Si funciona, no lo "arregles".

Personalmente, no me importa: si tengo trabajo, debatiré los pros y los contras con mi gerente y si ella insiste, lo hago y me pagan. Usualmente ella recupera el sentido y me da un trabajo más importante que hacer.

Puedo ver lo que dices, pero ser breve y conciso no siempre es fácil de mantener: a veces es fácil de mantener y explícito.

Además, una vez que todo esté en Java, será más probable que tengas una sensación de UI / consola de control que podría ser una mejora.

Si realmente te gusta la sensación del lenguaje de scripting, tal vez podrías contraproponer groovy. Su sintaxis es muy fácil de aprender para los programadores de Java y es 100% compatible con Java (incluyendo la extensión de clases de Java en Groovy y similares), pero es un lenguaje de scripting - tan poderoso como cualquier - con todo el poder y la falta de compilación eso implica

Por cierto, Java maneja bien las expresiones regulares.

También por cierto, si escribió todos estos scripts y es el único que está familiarizado con ellos, es posible que desee comenzar a buscar un nuevo trabajo. Lamento decirlo, pero pedirle que haga sus "trucos especiales" documentados y mantenibles es a menudo algo en lo que no piensan hasta justo antes de un despido.

Solo un punto. En muchos sentidos, él tiene un punto, pero ...

Perl (o bash scripting) es un lenguaje adhesivo. Es uno de los mejores idiomas disponibles para seguir los sistemas y hacer que funcionen mejor. Perl es un lenguaje totalmente interpretado, que le proporciona una potencia significativa para la escritura de código de tiempo de ejecución y estilos de programación más dinámicos. Puede pasar bloques de código perl como datos y modificarlos hasta el momento en que llame a "eval" en la cadena. Ya sea que exista o no la funcionalidad nativa de Java para incrustar Perl, puede crear fácilmente esa incrustación, lo que lo convierte en un sistema inmensamente poderoso.

Es posible que desee dejar en claro a su supervisor qué potencial perderá si retira el perl. En mi último trabajo, dos de los desarrolladores incorporaron IronPython a nuestra "lista de idiomas legales" para que pudiéramos implementar bibliotecas y pasarlas trivialmente a través de la base de datos para un proyecto de automatización a gran escala que se convirtió en un proyecto muy simple y muy pequeño. con un montón de código de python pegado y pegado a los módulos compilados.

En general, hay momentos en que un millón de líneas de Java no pueden hacer lo que hacen 10 líneas de script Bash. Es entonces cuando quieres usarlo. El resto del tiempo, tu jefe tiene razón, siempre y cuando tengas tiempo para hacerlo.

¿Has considerado a Ant? Debo admitir que nunca lo intenté, pero siempre quise portar mis scripts a Ant. Las operaciones de archivos son fáciles e incluso hay tareas para crear sentencias de SQL. Por supuesto, si sus scripts son más como programas, es decir, muchos constructos de bucle, entonces este no es el camino a seguir. Sólo una sugerencia.

El problema es que tu reacción Intuitiva podría ser correcta, pero eso no significa que tu gerente esté necesariamente equivocado, probablemente tenga muy buenas razones para querer hacerlo todo en Java. No menos importante, si te encuentras bajo un autobús, encontrar un reemplazo que sepa java, perl y bash va a ser mucho más difícil que encontrar a alguien que conozca a Java. Y eso está dejando de lado el tema "solo se pueden ejecutar en una PC con cygwin instalado". Y con toda probabilidad, el rendimiento no es un problema tan grande como crees.

Habiendo dicho eso, tu mejor opción es dedicar un poco de tiempo a estimar el tiempo que llevará transportarlos todos a Java, para que pueda tomar una decisión informada. Y mientras lo hace, calcule cuánto tiempo llevaría portar los scripts bash a Perl y documentarlos. Entonces déjalo decidir. Recuerde: no pasa la mayor parte de su tiempo codificando, como usted, por lo que es justo que tome algunas decisiones.

Si decide continuar con la opción java, ingrese uno de los scripts lo mejor que pueda, luego repórtelo con las dos versiones y, si tiene razón acerca de la concisión de los scripts perl / bash, debería ser capaz de obtener un poco de kilometraje al examinar las dos versiones una al lado de la otra.

EDITAR: MCS, para ser honesto, me parece que esos scripts se implementan mejor en Perl y / o Bash, en lugar de Java, pero ese no es realmente el punto; el punto es cómo demostrar eso a su gerente. Si abordas eso, abordas la pregunta de "reacción visceral" (por cierto, este es un consejo: comienza a referirte a tus reacciones viscerales como "juicio basado en la experiencia") y la "mejor manera de presentar mi caso".

Ahora, lo primero que debe darse cuenta es que su gerente (probablemente) no va por este camino solo para enojarse. Es casi seguro que tiene preocupaciones genuinas sobre estos scripts. Dado que probablemente sean preocupaciones genuinas (y no tiene sentido ir más allá si no lo son; si ha decidido hacer esto por algún motivo político, entonces no vas a cambiar de opinión, no importa qué, así que continúe con esto y agréguelo a su CV), se deduce que debe proporcionarle información que resuelva sus inquietudes si va a llegar a algún lado. Si puedes hacer eso, entonces estás a más de la mitad de conseguir tu propio camino.

Entonces, ¿cuáles son sus preocupaciones? En función de su publicación y de mi juicio y experiencia :-) Diría que son:

  • mantenibilidad
  • eso es todo, solo mantenibilidad

También creo que sus preocupaciones no son:

  • actuación

Podría estar equivocado acerca de este último, por supuesto; en el último lugar en el que trabajé teníamos un problema de rendimiento de SQL Server relacionado con la replicación que afectaba la capacidad de la empresa para brindar soporte al cliente, por lo que el rendimiento era un problema, por lo que lo abordamos. Pero, en términos generales, el rendimiento no es un problema tan grande como piensan los programadores. Si él realmente te dijo que el rendimiento es un problema, entonces dale importancia. Pero si él no lo mencionó, olvídalo; probablemente solo tú pienses que estos guiones se ejecutan más rápido en perl / bash de lo que probablemente ocurrirán en java importa para nada.

Entonces, mantenibilidad. Esto se reduce a responder la pregunta "¿quién mantendrá estos guiones si MCS cae bajo un autobús?" y la pregunta complementaria "¿me causará eso (es decir, su gerente) problemas?" (Aparte: no te obsesiones con todo el asunto del autobús. "Caer debajo de un autobús" es una abreviatura útil y diplomática para todo tipo de riesgos, por ejemplo, "qué sucede si alguien lo atrae con un salario que mi compañía no puede pagar". ¿coinciden? "," ¿qué pasa si él decide emigrar a las Bermudas? "," ¿qué pasa si quiero despedirlo? "," ¿qué pasa si quiero promocionarlo? "y, por supuesto," qué sucede si solo deja de presentarse un día por algún motivo desconocido, posiblemente relacionado con el autobús? ")

Recuerde, es trabajo de su gerente considerar y mitigar estos riesgos.

Entonces, ¿cómo hacer eso?

Primero, demuestre cuán mantenibles son estos scripts en realidad. O al menos cuán mantenibles pueden ser. Documentarlos (en documentos apropiados, no en el código). Entrene a un colega para mantenerlos (elija a alguien que le gustaría adquirir / mejorar sus habilidades perl y bash, y en quién confíe su gerente). Refactorícelos para que sean más legibles (sacrificando el rendimiento y los ingeniosos trucos de scripting si es necesario). Si desea continuar usando bash, cree un documento que proporcione instrucciones paso a paso para instalar cygwin y bash. Independientemente, documente el proceso de instalación de Perl y ejecute las secuencias de comandos.

Segundo, elija uno de los scripts y póngalo en java. Siéntase libre de elegir el guión que mejor demuestre las ventajas de perl / bash sobre java, pero haga el mejor trabajo posible para portarlo. Usa java.util.regex para hacer las mismas cosas inteligentes que haces en tu perl. Documentarlo en el estándar que otras utilidades internas de Java están documentadas. Si el rendimiento es realmente un factor, mida su rendimiento en relación con el script perl / bash.

En tercer lugar, después de haber realizado ese ejercicio, sea honesto consigo mismo acerca de su mantenibilidad relativa. Pregúntale al chico que entrenaste lo que él piensa. Si aún cree que los scripts perl / bash son más o menos tan mantenibles como lo serían las versiones de Java, calcule el trabajo necesario para portar los scripts restantes a java con la mayor precisión posible (podrá hacerlo con bastante precisión ahora, porque habrás portado uno). Luego, lleve los scripts comparativos y la documentación y las estimaciones (y las cifras de rendimiento, si corresponde) a su gerente y repáselos con él. Presente sus contrapropuestas (a. Déjelos en perl y bash pero documéntelos y entrene a un colega, y b) porte los scripts bash para perl, documéntelos y entrene a un colega).

Finalmente, permita que su gerente evalúe toda la información y decida, y acate su decisión. De hecho, no solo acate su decisión, acepte el hecho de que él podría estar en lo correcto. El hecho de que usted sepa más sobre perl / bash / java que él no significa necesariamente que sepa más acerca de la administración del equipo / departamento que él. Y si su decisión es quedarse con perl / bash, o port a perl, ¡regocíjate! Debido a que no solo ha salido a su manera, ha subido en la estimación de su gerente y aprendido una valiosa lección en el camino.

Simplemente haz lo que dijiste: convierte tu caparazón en Perl y documentalo

El código que menciona parece no ser parte de la aplicación, parece ser un código de "configuración" o un código de "mantenimiento". Como un aviso de respuesta, "un trabajo = una herramienta":

  • para su aplicación, es Java,
  • para empaquetar su aplicación, es una hormiga o maven o make,
  • para configurar el entorno, completar el DB, hacer informes de los registros, es un lenguaje de scripting (Perl, Python, shell).

Para convencer a tu jefe:

  1. http://en.wikipedia.org/wiki/Golden_hammer
  2. migrar de un idioma a otro es arriesgado: tendrá que pasar mucho tiempo para verificar los errores de regresión
  3. En mi experiencia, una línea de Perl = 20 líneas de Java (pruébalo: migra uno de tus guiones de Perl). Entonces, la base del código se multiplicará por 20, y más código para mantener es más duelas

  4. Perl mantiene todos sus módulos y documentos en el mismo lugar (cpan.org). Para Java, no hay un "punto de referencia". Tendrás que perder el tiempo en la red para elegir entre analizadores de hojas de cálculo Java, aprender a usarlo (espero que el documento esté bien) y crear algunos códigos java-cryptic-glue:

    SheetHolder = ParserFactory .newInstance (Configuration.asProperties ()) .parse (SheetReader.asStream ());

Convertir a todos Perl

Su derecho a pensar que la Regexp Java es más lenta. La variante Regexp Perl ha sufrido muchos cambios para asegurarse de que sea lo más rápido posible.

La conversión de BASH a Perl debería ser fácil de realizar, Perl puede hacer lo que está haciendo en BASH .

Al deshacerse de los archivos BASH , también puede deshacerse de Cygwin.

En un proyecto en el pasado, el código de Perl se transportaba a Java, lo que resultaba en un aumento significativo de la velocidad. La compañía tenía principalmente programadores Java y nuestras herramientas Eclipse, Ant, JUnit y Maven no eran adecuadas para el desarrollo de Perl. He visto el código Perl en muchas empresas, pero la mayoría de las veces solo fue una solución temporal, una solución rápida, un prototipo, una demostración, etc. Tiene sentido reescribir, pero debe analizarlo caso por caso. , a veces el tiempo o la mano de obra no lo permitirían.

Recuerde que Java no es el único lenguaje JVM; quizás algo como Groovy o Jython sería un compromiso que mantendría a todos contentos.

"Para manipular archivos y mover cosas, quiere que el SO esté de su lado"

¡Tenga cuidado siguiendo este consejo sin entender el contexto apropiado!

El sistema operativo admite API de programación como man (2) y (3) y comandos de usuario man (1).

Tener un script de Perl, por ejemplo, manejar una secuencia de man (1) no se ejecutará tan rápido como una JVM emite efectivamente una secuencia de man (2) o man (3).

Considera este ejemplo:

En la compañía a la que me uní, descubrí que tenían un módulo Perl que llamaba a la utilidad Java en un bucle, parte de un artilugio de creación híbrido make / perl / java.

En la superficie, debe haber parecido razonable tener el perl leído en metadatos y ejecutar / llamar a una JVM para hacer el trabajo pesado (una forma patentada de fusión de archivos en un bucle perl).

La sobrecarga (configuración / desmontaje) de este enfoque multiproceso fue significativa y fue especialmente malo en el sistema operativo Windows.

El problema del rendimiento tuvo que ser abordado.

Los equipos trataron el problema del rendimiento "reutilizando" el programa java hospedándolo en un servlet y creando un protocolo para enviar comandos desde el perl al servlet java. Ahora se redujo la configuración iterativa JVM / desmontaje en un bucle y todo el mundo estaba contento hasta que hubo casos de uso de borde como problemas de tiempo de espera donde el equipo agregado duerme en la mezcla.

La cultura anima a los equipos de herramientas a usar perl y al equipo de servicio para usar Java. El mejor enfoque para reemplazar el perl con Java y eliminar todos los gastos generales se perdió para todos o las fuerzas políticas influyeron en la solución de rube-goldberg ...

Hacer la compilación en un lenguaje JVM como ANT o Maven evita todo esto.

De nuevo, ten cuidado :-)

Si construyes un cobertizo y usas un martillo 80-90% de las veces, ¿se sigue que solo debes usar martillos para construir cobertizos? No, usted usa las herramientas más apropiadas para cada parte del trabajo, ¡tal como lo hizo!

También el nivel promedio de habilidades / experiencia de la fuerza de trabajo de TI ha aumentado en los últimos años. Por ejemplo, esta encuesta SO mostró que el programador medio SO está en sus 30 años con más de 10 años de experiencia.

Tu jefe no tendrá problemas para reclutar programadores con una amplia combinación de habilidades y experiencia.

Esto es ahora muchos años después, pero acabo de convertir las secuencias de comandos bash con algunos scripts de Perl. Reescribí un sistema en una aplicación de Java y también agregué Groovy. Java y Groovy funcionan bien juntos.

  • Groovy ejecuta código Java simple.
  • Puedo acceder y manipular todos mis objetos / estructuras / datos java en groovy. Llamo guiones maravillosos que manipulan datos en mi programa Java en ejecución.
  • Groovy tiene una buena sintaxis a mano alzada. Puedo abrir fácilmente un archivo y escribir en él con una sola línea.
  • groovy también tiene alguna sintaxis de expresiones regulares cortas.
  • Los archivos groovy script se interpretan en tiempo de ejecución, así que mientras mi programa java aún se está ejecutando, puedo cambiar mi groovy script code y la próxima vez que se llamen los archivos usará el nuevo código.