La elección de tecnología, arquitectura y diseño en proyectos de software, sin efectivo

Amigos! Continuamos una serie de publicaciones "sin cortes" sobre procesos de diseño, tecnologías de TI y cómo trabajar de manera efectiva. Hoy hablaremos sobre un tema muy doloroso que causa acidez estomacal en el cerebro: la elección de tecnologías, lenguajes de programación, el papel de arquitectos, analistas, líderes de equipo y psíquicos para resolver el problema épico: lanzar una solución de software, si es posible, en un tiempo razonable. Y nos detendremos por separado, para no aburrirnos en absoluto, en un análisis de la correlación de los tamaños de partes del cuerpo de una parte del equipo con la productividad del cerebro de otra. ¡Vierte café y vámonos!

Cómo convertirse en expertos


Para comprender objetivamente por qué todavía no hay claridad en los problemas indicados y hay tantas disputas "religiosas" con los sacrificios humanos, debe distraerse, sonreír y dibujar la vida de un especialista en TI con un cuchillo de cocina en forma de línea discontinua en la mesa con cuadrados que significan el conocimiento adquirido.


La diversión comienza con el hecho de que, por lo general, incluso en universidades especializadas no hay suficiente conocimiento para la programación profesional y la competencia de un especialista depende directamente de la lucha mental con la pereza: tome un libro / código durante un par de horas o descanse con una lata de cerveza frente al televisor. Obviamente, solo una pequeña parte es capaz de soportar las redes sociales, series de televisión, juegos en línea y aprender desinteresadamente, pero incluso si, como los monjes, sacrifican constante y diariamente una parte de su vida, pueden entender fácilmente uno, bueno, a veces dos lenguajes de programación industrial y varios tecnologías relacionadas. Y el bigote, comienza la pensión y mientras aprende a plantar abejas.

Pero con tanta dificultad, resulta que el conocimiento adquirido para el éxito aún no es suficiente y se requiere una especialización constante en proyectos de desarrollo, preferiblemente con plazos infernales, porque las habilidades de escritura de manera rápida y correcta se pierden muy pronto.

Como resultado, solo se pueden cortar unos pocos cuadrados con un cuchillo, y cuanto más a la derecha, menos cuadrados, por regla general, porque nacen niños, aparecen conocidos, pasatiempos y quieres vivir al menos un poco al menos por ti mismo por la noche y finalmente obtener suficientes tanques pequeños.

Una analogía muy comprensible de un experto en TI, tal vez, es un especialista en artes marciales que, después de la escuela, dejó Voronezh para China, pasó 10 años en un monasterio, se llenó los nudillos con los dedos hasta los hombros, se cortó la espada genital y entrena durante 20 horas al día. Incluso será bueno para un luchador conocer varios dialectos del chino, pero un día se encontrará con un tipo de piel oscura que se ha dedicado a la Capoeira . Lo más probable es que, a nivel de signos, se entiendan entre sí y puedan elegir la tecnología para el proyecto de software, pero, desafortunadamente, la mayoría de las veces tienes que conocer amantes agresivos de cosplay y ciencia ficción, con un disfraz de Jedi con un sable de luz de plástico en sus manos.

Copiar y pegar, marcos y ciencia ficción


Obviamente, solo unos pocos pueden estudiar y aprender la Verdad de manera tan desinteresada, y en la vida real, las reuniones y disputas sobre tecnologías y lenguajes de programación se producen principalmente entre fanáticos de diferentes "series" de moda, que a menudo no conocen la diferencia entre IP y TCP. El problema se ve agravado por el marketing agresivo externo: la mayoría de los grandes proveedores de TI están "reclutando" activamente a sus seguidores a través de canales de información. No necesita ir muy lejos por ejemplos: Mozilla está promoviendo Rust, Google está promoviendo Go, Oracle está interesado (?) En la promoción de Java, Microsoft está desarrollando C #, JetBrains es Kotlin, los extraterrestres son Haskell y la comunidad científica no se alegra cuando está bajo el disfraz de AI y ML, una neurona y datasatanism, por mucho dinero se venden ... cursos académicos polvorientos en teoría de la probabilidad, regla y estadísticas para siempre, amen :-)


Y cuando un fanático de Game of Thrones comienza a discutir con un fanático del Clan Soprano sobre los beneficios de la programación orientada a aspectos , mixins y cierres , todo lo que queda es reír sinceramente y rociar a los debatientes con arena sagrada del Tíbet y las papas de McDonald's. No podrá esperar conclusiones útiles y objetivas, y se confundirá aún más, y, lo que es peor, obtendrá una explosión viral y comenzará a caminar con un abrigo a rayas.

Tradiciones y "corrección"


El hecho es que ensamblar, por ejemplo, un automóvil hecho de hierro es una tarea bastante costosa y larga: necesita material, soldadura, conocimiento, una habitación, un póster de niña con las formas correctas, etc. Y escribir un programa, especialmente no solo, es bastante común. Creatividad virtual: explotó y continúa arruinando y estirando el mundo. Un mar de contenido digital, a menudo despistado y primitivo, donde todos los escritores y artistas han inundado la web. Como resultado de la relativa simplicidad de la "autoexpresión", en el mundo, en un período de tiempo relativamente corto, después de la Segunda Guerra Mundial, aparecieron una gran cantidad de programas no solo, sino también lenguajes de programación. Escribir un nuevo lenguaje de programación no es difícil, mucho más difícil, para que gane popularidad. Sucedió históricamente que los lenguajes que aprendieron "a escribirlos correctamente" (por ejemplo, C ++, Java, ECMA262) son populares ahora, y los lenguajes que "se hicieron más tarde y parecen ser mejores" (por ejemplo, C #, Python3, Rust, Kotlin) son mucho menos populares Al elegir un lenguaje "más correcto", corre el riesgo de no encontrar suficientes desarrolladores que lo conozcan, o puede suceder que el lenguaje simplemente deje de desarrollarse o ascienda a la eternidad, como Haskell. Por lo tanto, guiados por el sentido común, a menudo eligen tecnologías tradicionales, por así decirlo, incluso si no son "correctas" y consistentes, llenas de muletas y rastros de crecimiento, pero probadas, populares y desarrolladas.


En el contexto del desarrollo activo de la grafomanía (especialmente en la dirección del front-end, aunque npm también es divertido), me gustaría advertir contra el uso irreflexivo de bibliotecas y marcos . Es importante observar el historial de desarrollo del marco, el contingente de desarrolladores (cuanto más simple es la tecnología, más sorpresas hay) y la duración del soporte de la versión.

Por lo general, en proyectos de código abierto, no es habitual mantener el marco durante mucho tiempo, por ejemplo de 3 a 5 años o más; esto es cursi, costoso y aburrido. Por lo tanto, generalmente, después de obtener una masa crítica de "muletas", se crea la próxima versión, en un año o dos, y recomiendo que los usuarios de sus versiones anteriores transfieran su proyecto ... hágalo usted mismo, porque la versión anterior ya no se actualizará y los errores de seguridad tampoco se corregirán. Ejemplos de tal "irresponsabilidad" son simplemente el mar.

Las bibliotecas y los marcos comerciales, por regla general , no padecen una enfermedad infantil similar (aunque no todas, debe mirar cuidadosamente la documentación y estudiar este problema a fondo) y mantener la compatibilidad con versiones anteriores durante 5 o más años. Por favor, preste especial atención a esto, de lo contrario, de repente tendrá que volver a escribir su solución web desde cero.

En general, en este punto, es mejor usar un proverbio sobre una teta y una grúa.

Nuevo o ... terminado


Otro problema psicológico muy popular en el desarrollo es la elección entre "hacerlo desde cero" y "tenerlo listo". Te diré un secreto: todos quieren ser dioses, desarrolladores novatos, lo que, por cierto, es normal, quieren bombear y obtener una entrada en el currículum y elegir "hacerlo desde cero". Pero luego, generalmente, se van por aburrimiento después de seis meses o un año, y a menudo debido a la falta de experiencia, sus creaciones tienen que ser reescritas una y otra vez desde cero. Los monjes Shaolin experimentados, por lo general, se aseguran contra los errores y sorpresas de los niños, eligen soluciones y bibliotecas listas para usar, y dedican el tiempo libre restante a desarrollar funciones no estándar y exclusivas para este proyecto web. ¡Y no será aburrido!


Una buena asociación puede ser elegir una base de datos: qué llevar para un proyecto web, una base de datos Oracle o una base de datos MySQL (sí, sé que ahora están siendo desarrolladas por una compañía). Según la experiencia, el 99% de las tareas de desarrollo web, incluso bajo cargas elevadas, se resuelven excelentemente y a alta velocidad en MySQL. Y si el resultado no difiere, ¿por qué ...? :-)

Por lo tanto, generalmente un proyecto de software ahora consiste en un conjunto de bibliotecas y marcos ya preparados y probados, con un buen período de soporte y solo una pequeña parte de la funcionalidad específica de este proyecto. Y esto, en mi humilde opinión, es correcto.

Difícil y largo o ... ¿rápido y fácil?


Esta es también una causa conocida de numerosas e interminables disputas. De hecho, las tecnologías de TI modernas y los lenguajes de programación se dividen, en términos generales, en 2 partes: simples para la mayoría (no es necesario profundizar, unos días para comprender) y difíciles para la minoría (necesita una especialización seria y larga, meses para comprender). Como vimos anteriormente, a la mayoría de la gente no le gusta aprender, por lo que si implementa la tecnología adecuada y confiable, no tendrá éxito porque nadie puede entenderla completamente y jugará a la ruleta rusa con un cuadro negro. Un ejemplo popular: la elección entre redis o cassandra , productos de diferente orden de complejidad. O, otro ejemplo: python o C ++.

De hecho, en lenguajes simples, la programación suele ser mucho, mucho más rápida: compare un script de Python con 5 líneas y un código C similar con 100 líneas. Pero, por lo general, los lenguajes "simples" y las tecnologías universales a veces funcionan mucho más lentamente y consumen mucha más RAM :-) Después de todo, tienes que pagar por todo.


Sin embargo, los lenguajes "simples" se utilizan cada vez más para resolver la mayoría de las tareas de un proyecto de software, donde no se necesitan requisitos especiales para supervelocidad y RAM. Y el hierro se vuelve más y más barato. PHP ahora es muy popular para el desarrollo web rápido, y python, con su sintaxis muy clara y legible, para tareas generales y aprendizaje automático. JavaScript es muy conveniente para automatizar no solo la interfaz web, sino también ... crear aplicaciones de servidor realmente rápidas en Node.js. Go, incluso con su sintaxis primitiva, le permite prescindir de Java más potente, pero mucho más difícil de entender en las tareas del sistema, y ​​una aplicación móvil puede crearse rápidamente por un orden de magnitud más fácil y más accesible para que los principiantes desarrollen Kotlin. Es posible, con riesgos mucho menores, ejecutar una aplicación de alta carga en Rust sin profundizar en las complejidades de la administración de memoria en C ++. Pero nadie en su sano juicio escribiría un juego en Java, recordando el popular minecraft, que solo se puede jugar a una distancia de 10 metros de la pantalla, entrecerrando los ojos :-)

Por lo tanto, para cada tarea, es aconsejable elegir una herramienta específica y popular afilada por ella. Cuantas más herramientas ya estén usadas, mejor.

Es cómico, pero en las realidades actuales, ni siquiera la elección del idioma, pero la elección de las características del lenguaje puede tener una influencia decisiva en el éxito. Por ejemplo, al tener un equipo que no tiene experiencia en programación orientada a objetos y conocimiento de patrones de diseño, puede escribir un zoológico de objetos tan evidente que podría ser más fácil resolver el problema con 100 funciones en un archivo monolítico, comprensible para todos que esconderse de cientos de objetos en una oficina monstruos con soporte en lugar de cabeza y orejas en lugar de patas. Es por eso que, a menudo, los lenguajes simples (como python, php, javascript, ruby) que no brindan oportunidades redundantes para el desarrollo de la grafomanía y el perfeccionismo, centrados en la claridad, la falta de ambigüedad (python) y la concisión (php), hacen que sea cada vez más posible tener éxito. No en vano, las historias son tan populares cuando se comenzó a crear un sitio web en C ++ y qué pesadilla le dio la vuelta más tarde.

Una buena analogía aquí es un ejemplo de caballeros medievales caros y difíciles de "sintonizar" y ... gamberros con armas de fuego. Puedes entrenar toda tu vida y convertirte en un samurai de Java multiproceso, pero de repente puedes terminar tu vida cuando conoces a un estudiante con una solución similar y mucho más simple en Python o Go.

ARQUITECTURAS Y ARQUITECTURAS


De hecho, hace 10-15 años, era necesario estudiar y leer libros gruesos durante mucho tiempo para comprender los principios de colocar objetos y su interacción en servidores y clústeres separados (j2ee, corba, com). Los ecos de este auge en la arquitectura y los arquitectos todavía se pueden encontrar en creaciones monstruosas como Spring . Pero los tiempos están cambiando, la tecnología se está volviendo más poderosa y asequible. Al implementar un par de servidores web gratuitos de Apache, la base de datos MySQL y la cola RabbitMQ en algún lugar de Amazon , puede resolver la mayoría de los problemas que anteriormente estaban disponibles en las configuraciones del servidor de aplicaciones que son comprensibles para la minoría abrumadora.


Si la tarea es admitir conexiones de red masivas, puede generar un clúster de máquinas Node.js, o mejor dicho, máquinas con Erlang y dormir tranquilamente, que escribir su propia solución de servidor en, por ejemplo, Go o C ++.

Si necesita investigar, constantemente, en el flujo, seleccionando uno de los modelos de aprendizaje automático de 10-20 y desplegándolos rápidamente en la nube para el servicio al cliente, entonces, por supuesto, Python con una gran cantidad de bibliotecas se convertirá en una solución muy conveniente y práctica, y así sucesivamente.

Por supuesto, en proyectos estrechamente especializados, aún se requiere un conocimiento profundo de OOP, FP , arquitectura, informática , pero cada vez más a menudo es suficiente saber de qué bloques armar la solución y esto a menudo llevará al sistema de software a la meta mucho más rápido.

Team Matching


Con base en lo anterior, es obvio que el equipo probablemente se desarrollará solo dentro del marco limitado del conjunto de tecnologías seleccionadas para el proyecto. Las unidades comenzarán a cavar temas relacionados, y una pequeña proporción de ellos leerá literatura especializada, pero esto, lamentablemente, es un caso excepcional. Por lo tanto, se recomienda seleccionar aquellos que ya tienen experiencia en los idiomas / bibliotecas indicados, que pueden verificarse en el currículum y en las entrevistas. Y solo aquellos que realmente no pueden ser noqueados por los programas de televisión y las redes sociales pueden ser tomados como "crecimiento" después de recibir un contrato firmado previamente por sangre arterial :-)

Sin embargo, en proyectos no estándar, tendrá que encontrar al menos un desarrollador que sepa algo más y sea excelente, excepto python, ruby, php, javascript, go, perl, bash, chanson. Las posibilidades de que el luchador conozca bien los algoritmos, los patrones de diseño, los estándares de red y la POO mejoran significativamente.


Si el proyecto está relacionado con el aprendizaje automático y necesita profundizar en algo, tendrá que encontrar un analista matemático real, preferiblemente con un título científico y conocimiento de Python. En serio: para el aprendizaje automático, sin una educación especializada, debes estudiar mucho durante varias horas al día (teoría de la probabilidad, álgebra lineal, método de mínimos cuadrados, estadísticas, teorema de Bayes y su técnica) durante varios meses, si no años.

Procesos o tecnologías?


A menudo puede encontrar proyectos de software grandes y de larga duración escritos en lenguajes de programación o conjuntos de bibliotecas aparentemente "inapropiados". Por ejemplo, a menudo se encuentran enormes secuencias de comandos de control de bash o bibliotecas y marcos científicos masivos para cálculos precisos en ... python con Dodbyba duck typing . El secreto está en procesos y prácticas rigurosos. Utilizando:

  • Diseño preliminar, pruebas de tensión y análisis de riesgos.
  • Unidad automatizada y pruebas de integración (preferiblemente 100% de cobertura)
  • estándares de codificación comunes
  • buena documentación de código y componentes del sistema
  • máxima comunicación transparente dentro del equipo
  • monitoreo y análisis del entorno del servidor

Puede crear una solución de software, en principio, en cualquier tecnología que viva durante años y deleite a los clientes. Y viceversa, al trabajar con "exhibiciones" caras con cajas negras, sin profundizar en los detalles de la tecnología, alentando la negligencia y los intereses personales en lugar de los del equipo, puede intentar iniciar un proyecto durante meses, corregir un error y dar lugar a docenas, desafortunadamente, esta situación es bastante común.


Resumen


Para resumir y priorizar:

  • Cada vez más, se puede observar una situación en la que la velocidad de lanzamiento de un proyecto de software es un factor decisivo para el éxito. Hacer algo innecesariamente largo y difícil es peor que lanzar rápidamente una solución que sea útil para los clientes y recopilar comentarios para el próximo imbécil
  • Un inicio rápido solo es posible cuando se utiliza el máximo de componentes, marcos y bibliotecas listos para usar con un período de soporte adecuado (teniendo en cuenta la vida útil esperada de su sistema web)
  • Desafortunadamente, el conocimiento algorítmico y arquitectónico tiene menos demanda. Con mayor frecuencia, la experiencia en la resolución de problemas similares y la práctica de usar cajas de herramientas y las fortalezas de los proveedores de la nube son bienvenidas.
  • No hay necesidad de limitarse y hacer todo con una sola tecnología y un lenguaje de programación MEJOR: un arma de fuego en las manos de un niño es más eficaz que estudiar artes marciales con un samurai, toda la vida consciente e inconsciente. El perfeccionismo y la idealización matan los sistemas de software. Elija el arma adecuada para cada tarea en el proyecto. Tome el acabado y enfoque los esfuerzos restantes en lo no estándar.
  • Las tecnologías seleccionadas deben ser simples, claras y accesibles para la mayoría del equipo. Mira lo que escriben un proyecto similar en el principal y toma esta pila de tecnología para ti. No automatice el alojamiento con Haskell y no escriba sitios web en C ++ :-) Si su proyecto "despega" y comienza a desarrollarse, solo entonces puede considerar reescribir sus partes pequeñas en tecnologías más complejas y lenguajes de programación. Pero, por lo general, los proyectos de software no alcanzan esta etapa o llegan unos años más tarde.
  • El marco le permite acelerar el lanzamiento de un proyecto de software por órdenes de magnitud. Asegúrese de verificar la disponibilidad de buena documentación y especifique el período de soporte para el marco para que no haya problemas con una reescritura completa en 2-3 años. Este es un caso muy frecuente de nuestros clientes.
  • No crea en la capacidad del equipo para aprender: hay demasiadas distracciones en la vida y la situación solo empeora. Estudie cuidadosamente su currículum, verifique los certificados y los exámenes e intente concentrarse lo más posible en el resultado práctico. Ponga la práctica por encima de la teoría, al menos al momento de crear la primera versión de una solución de trabajo.
  • La tecnología y los lenguajes de programación no son factores críticos de éxito. Concéntrese en construir los procesos más necesarios e implementar prácticas clave de desarrollo y diseño. Los procesos correctos, como regla, están garantizados para conducir al resultado "correcto". « » « », . , 2-3 .

, , !

Source: https://habr.com/ru/post/es436460/


All Articles