Aspectos para considerar a la hora de elegir tecnología para el trabajo

En cada proyecto de software – al menos al principio – existe la gran cuestión de qué tecnología elegir para hacer el trabajo. Incluso si no estás en el mundo de JavaScript con nuevos marcos que salen cada semana, es posible que encuentres una gran variedad de opciones. ¿Qué aspectos hay que considerar? 

Nosotros, como desarrolladores, por supuesto, tienden a la nueva tecnología caliente, el bombo actual, y aplicarlo de inmediato en nuestro trabajo diario. Sin embargo, la implementación prematura probablemente causará algunas malas sorpresas más tarde, pero incluso si usted está considerando la tecnología que ha existido durante años, encontrará un montón de opciones.

Ir con el consenso

En primer lugar debe elegir la tecnología que el equipo de desarrolladores está familiarizado con. Esto puede sonar obvio, pero he visto bastantes casos en los que un desarrollador de “rockstar” (o incluso peor: el arquitecto) elige alguna tecnología con la que está familiarizado – sin considerar todo el equipo – y se fue más tarde. En un equipo dominado por Java, la opción obvia es ir con Java o marcos simples escritos en eso y tal vez no añadir Go sólo porque es genial ahora. Y: Probablemente tampoco es deseable sobrecargar el número de lenguajes poliglota.

Factor de frescura

Hablando de frescor y bombo: Desaconsejo seguir ciegamente el último bombo y aplicar nuevas, cosas calientes en proyectos del mundo real. Siempre es digno de mirar en la nueva tecnología – pero simplemente no implementarlos de inmediato. Más bien se adhieren a su aburrida pero confiable batalla probado idioma y jugar en el tiempo libre. Como un empleado considere dar a sus desarrolladores oportunidades como los famosos proyectos de Google 20% para probar cosas nuevas y ganar experiencia y aplicarlas más tarde si está bien probado.

De vez en cuando, mire estos temas intemporales

Patrón de diseño y principios de buena ingeniería de software
Uso eficaz de Java
Unix
Concurrencia
Transacciones, sistemas distribuidos y protocolos de red
Incluso para los microservicios, Docker, Kubernetes, Apache Kafka, Akka, CQRS y lo que sea utilizado para resolver problemas mañana, estos temas son el fundamento de la práctica de ingeniería de software adecuada y de hecho necesita comprender cómo su marco está trabajando internamente.

El tema de los patrones de diseño y los principios es especialmente importante para matar la necesidad de un nuevo lenguaje, más elegante. Si diseña su programa correctamente, especialmente teniendo cuidado de la delegación y capas de abstracción, no necesita lenguajes dinámicamente mecanografiados o mucho azúcar sintáctico para producir código legible.

Pruebas

Esto es particularmente cierto para las pruebas. Para nuestras pruebas que tienden a ser menos estricta con la elección de la tecnología, ya que “no es la producción de todos modos”. La legibilidad y la facilidad de mantenimiento de las pruebas basadas en Groovy y Spock son ciertamente atractivas, pero afirmo que la misma productividad es fiable aplicando los principios de un buen diseño de software – especialmente delegación y capas de abstracción – a nuestro código de prueba. Desafortunadamente, el estilo de código de prueba no es tratado con la misma atención.

Las pruebas IMO JUnit tanto para las pruebas de unidad de uso de casos de uso en pequeña escala como para las pruebas de aceptación de sistemas a gran escala son capaces de proporcionar una tecnología de prueba efectiva y mantenible, si se está en un proyecto basado en Java. He grabado un video para demostrar esto en la implementación de las pruebas de aceptación. Pero otra vez: Vaya con lo que el equipo está más familiarizado con.

Marcos empresariales

Para la elección de la tecnología de la empresa que depende no sólo en el equipo, sino en la vida de su proyecto.

En los proyectos de más larga duración -que son sinceros para la mayoría de ellos- el soporte a largo plazo y la compatibilidad hacia atrás son un tema a tener en cuenta. ¿Quién sabe si el nuevo marco que acaba de salir por un año estará allí en 2, 5, tal vez 10 años?

Eso también incluye el hecho de cuán profundamente el marco utilizado necesita ser tejido en el código. Un par de anotaciones (a la Java EE o Spring) se pueden cambiar fácilmente más adelante – una API de programación menos bien. Diseño para eliminación no para reutilización 🙂

Whatelse es importante es el soporte de herramientas disponibles – incluyendo herramientas de construcción, IDEs o herramientas de base de datos.

Si compara los marcos empresariales entre sí, considere las últimas versiones y las mejores prácticas actualizadas para realizar el trabajo. No hay punto bashing tecnología con destructivos, sin saber como FUD – como peso pesado J2EE, servidores de aplicaciones de hierro viejo o Spring utilizando la configuración de bloated basado en XML.

Conclusión

Elija lo que el equipo está familiarizado con
No sea cool – juegue en su tiempo libre
Elija la herramienta adecuada para el trabajo
Prefieren los principios de un buen diseño de software sobre el último hype
No sobrecargue el número de idiomas
Educate a ti mismo y al equipo sobre las bases de la informática