1 - Desarrollo de software y revisión de software existente en C ++ (Qt5). 2 - Desarrollo de GUI en QtWidgets / QML. 3 - Participación en el diseño de la arquitectura de varios sistemas. 4 - Experiencia en desarrollo en C ++. 5 - Buen conocimiento de Qt5. 6 - Experiencia en el desarrollo de aplicaciones multiproceso. 7 - Comprensión de la programación orientada a objetos. 8 - Conocimiento de Linux como usuario experimentado.
Ahora echemos un vistazo a los puntos. O mejor dicho, cómo lo leo cuando me encuentro con este tipo de propuestas.
1. Desarrollo de software y revisión de software existente en C ++ (Qt5)
En este punto, todo está bien. La versión actual de la biblioteca y el idioma se indican simplemente.
2.Desarrollo de GUI en QtWidgets / QML
Sí, QML es parte de Qt, nadie lo disputa. Pero hay un pequeño punto: por supuesto, es posible escribir un proyecto que se sienta en dos sillas al mismo tiempo, pero interferir con ambas es un signo de mala arquitectura. ¿Quizás la gente solo se refiere al desarrollo QML? Bueno, de hecho: el proyecto está escrito en QML, pero necesitas tus propios componentes, y están escritos en C ++ usando QtWidgets ... No está claro todavía, así que sigue leyendo. Por cierto, volveremos a la arquitectura más tarde.
3. Participación en el diseño de la arquitectura de varios sistemas
¿A qué sistemas específicos te refieres? Las preguntas surgen de inmediato: ¿cuántos de ellos tienes? ¿Son estos varios proyectos en los que una persona necesita trabajar al mismo tiempo o la programación clásica de Qt está mezclada en un proyecto monstruoso con QML y algunos otros enfoques? A juzgar por el hecho de que QtWidgets en el párrafo anterior se refiere al llamado "desarrollo clásico en Qt" (hacer un formulario - escribirle una clase) sin ningún QML, queda claro que el programador tendrá que sentarse en dos sillas al mismo tiempo.
4. Experiencia de desarrollo en C ++
¿Para qué está escrito? ¿Para que no venga un boxeador de QML que nunca ha visto C ++ en su vida? ¿O la experiencia de los desarrolladores actuales no es suficiente para volver a cambiar de QML a QtWidgets? ¿Quizás no quieren involucrarse en el mantenimiento del código antiguo?
Me parece que todo es algo más complicado: el hecho es que las capacidades estándar de QML no suelen ser suficientes para una aplicación completa, así que tienes que crear tus propios complementos QML. Para lo que se necesita C ++. En otras palabras, el proyecto para las personas ya estaba escrito parcialmente en QML, pero luego se encontraron con la falta de oportunidades, y luego la caja QML resultó ser insuficientemente hábil o estar ocupada el doscientos por ciento de su tiempo solo con la creación de formularios, pero QML -componentes en C ++, de alguna manera no puede escribir. Queda claro lo que haremos: este es el soporte del código clásico y la creación de nuevos componentes QML.
Sin embargo, esta no es una, sino dos vacantes. En el código Qt clásico, generalmente hay un mar de errores difíciles de corregir y el programador que se sienta en el soporte estará ocupado arreglando más del cien por ciento de su tiempo (trabajando con reelaboración). Tampoco podrá escribir nuevos componentes QML "de vez en cuando", debe hacerlo todo el tiempo. Probablemente piensen que una persona soportará principalmente el código antiguo, a veces "rápidamente y de alguna manera" reemplazándolo con QML. En este caso, surge la pregunta, ¿quién está involucrado en la arquitectura de toda esta desgracia? Recuerde el punto tres: "somos esos rescatadores". En fin, haz lo que quieras, de todos modos no hay nadie que se ocupe de la arquitectura, nadie va a contratar a un arquitecto de proyectos, y el gerente no es arquitecto y no conoce este tema, por lo que todo será culpa de nosotros.
5. Buen conocimiento de Qt5
¿Cierto? No, simplemente no puedo creer que con poco conocimiento de algo, puedas ir a algún lugar para conseguir un trabajo. Es decir, en general valió la pena escribir sobre eso, de lo contrario es cierto, ¿vendrán con cosas malas? ¿Quizás descifremos algo en este punto? Resulta que cuando escriben esto, piensan que sus desarrolladores actuales no conocen Qt lo suficientemente bien (lo que sea que eso signifique), y si es así, entonces ya han intentado ahorrar dinero en programadores.
6. Experiencia en el desarrollo de aplicaciones multiproceso
De hecho, lo descifraron. El desarrollo de aplicaciones multiproceso con Qt requiere un conocimiento muy bueno del mismo. Pero personalmente leí algo completamente diferente en este requisito, no lo que probablemente quiso decir cuando escribieron esta frase. Primero, averigüemos por qué Qt es multihilo.
La parte clásica de Qt es una biblioteca basada en eventos . Sin embargo, se le agregó una funcionalidad posterior que le permite ejecutar subprocesos. Sin embargo, toda la interfaz todavía funciona en un solo hilo principal, y hasta que salte de la función anterior, no se llamará a la otra, sin importar cómo los conecte con las ranuras de señal.
El subproceso múltiple generalmente se requiere en el nivel que no es de interfaz: en las aplicaciones Qt, la separación cliente-servidor se usa a menudo de una forma u otra, y si el servidor no está muy bien diseñado arquitectónicamente (por ejemplo, sus llamadas son estrictamente síncronas), entonces, en este caso, se necesitarán subprocesos para organizar la espera. en el nivel de la interfaz. ¿Qué significa esto cuando se aplica a una vacante?
En primer lugar, el front-end entre el cliente y el servidor está mal diseñado o no existe. Escribimos lo mejor que pudimos y al menos parte de la lógica de negocios está mezclada con el código del cliente, y tendremos que lidiar parcialmente con la programación del sistema (terminando lo que el programador del sistema no terminó a nivel del servidor). Aquí debo decir que generalmente hay un programador de sistemas en estos equipos, pero muy específico. Es él quien vendrá a la entrevista para culparte con preguntas sobre la pila de protocolos TCP / IP, aunque fue él quien se vio obligado a diseñar el sistema para que no hubiera ningún código de sistema en las ventanas. Y él, por cierto, recibe el salario máximo de todos, y tendrás que tomar la culpa por sus imperfecciones, utilizando una programación de múltiples subprocesos.
Segundo: como resultado de las llamadas sincrónicas, el programa ya es tan lento que la administración de la empresa (que no debe confundirse con los gerentes) ha recibido comentarios
7. Comprensión de la programación orientada a objetos
Oh ... esto es algo de la categoría "Puedo codificar en C ++, pero no tengo idea de qué es POO". No funciona de esa manera. Excepto quizás para los estudiantes de posgrado que han escrito un curso de un solo trimestre en C ++ en C ++ y que se identifican inmediatamente por edad y por respuesta a una vacante. Por tanto, se quiere decir algo más. ¿Qué exactamente?
Por mi propia experiencia, puedo asumir que el programa fue notoriamente jodido para nosotros. Seguro que todo empezó, como siempre, muy chévere, interesante y divertido: arquitectura correcta, capas de abstracción y todo lo que suele acompañar a un proyecto competente. Pero entonces comenzó la carrera por la funcionalidad, que desdibujó las capas de abstracciones. Lo más probable es que, si resulta que el proyecto es antiguo, sus desarrolladores originales lo hicieron en QtWidgets, pero se fueron durante mucho tiempo, hace tanto tiempo que los estudiantes muy jóvenes que comenzaron a esculpir QML lograron trabajar en su lugar (asegurando a sus jefes que era genial) ... Quienes, a su vez, también crecieron y se dieron cuenta de que el código similar a un fideo que escribieron al principio, eventualmente se convirtió en ravioles a partir de abstracciones (ver antipatrones).Y ahora, para cada ventana, se llaman una docena de microclases casi vacías en lugar de una clase de forma normal, que hacen malabarismos con los datos entre sí, y no directamente, sino a través de algún tipo de inyector de impulso (esto estaba de moda hace varios años). Este malabarismo termina con el hecho de que después de atravesar docenas de capas adicionales, te topas con el mismo código similar a un fideo con"TODO: reescribe todo humanamente cuando aparezca el tiempo" en algún rincón apartado del proyecto.
Como resultado, el código no se puede entender tanto que ya no es posible desarrollarlo. Los programadores resolvieron todo hace mucho tiempo y los dejaron en lugares más hospitalarios. Sin embargo, la dirección del proyecto no aprendió nada y ahora (después de ver un simple script QML) cree que el problema se puede solucionar "rápidamente" con la ayuda de otra bala de plata. El siguiente punto nos dice que este es probablemente el caso:
8. Conocimiento de Linux como usuario experimentado
Finalmente, quedó claro para qué era el proyecto. Se podría argumentar, se puede argumentar (en los comentarios), pero el desarrollo de Linux en nuestros tiempos difíciles no es en absoluto los ideales del software libre (con el que probablemente todos soñamos). En el noventa y nueve por ciento de los casos, estos son guardias de seguridad con la idea de monitorear todo ya todos, y como Linux nos referimos a Astra, porque el camarada Mayor lo dijo. Es decir, no se trata de una empresa de TI y nadie ha oído hablar de los enfoques arquitectónicos habituales allí, y todos los problemas (por experiencia) se resuelven mediante “zapatear una pulga”. De ahí la conclusión: el salario no se indicó por una razón. Aquí es necesario contratar a tres personas mayores (con un número apropiado de intermedios y junio para cada uno de ellos) para una refactorización completa del código, y no buscar una "persona que resuelva todos los problemas". Sin embargo, los empleadores no pueden pagar esto,porque esto solo es posible en una economía normal con un mercado de inversión maduro. Pero este es un tema diferente y sobre él en otro momento.